软件架构设计师岗位职责

软件架构设计师岗位职责（共15篇）

1.软件架构设计师岗位职责 篇一

关键词：通讯,时钟,时序,容错能力

1 前言

汽车制造商在设计初期, 就开始考虑增加车载GPS导航的配置, 并逐渐成为车上的基本装备。GPS导航产品的稳定性和可靠性, 决定车辆品味及质量的关键要素。

2 导航系统参数

本文中的机型在设计的状态如下:主机与导航地图采用分离式, 地图为SD卡存储, EBOOT时钟频率32MHz, TFT显示屏, 显示屏主控芯片 (GDC) 采用Mstar776。

3 导航系统设计常见问题及注意事项

GPS导航系统, 与空间、地面控制部分进行数据交换, GPS车载设备需要对数据进行大量运算, 故系统涉及范围广, 更需要性能稳定、运行可靠, 下面就设计开发过程中经常遇到的问题, 进行详细阐述:

3.1 导航停止响应, 复位后进入黑屏状态;

但主机能切换到其他界面, AM, FM, DVD, 蓝牙等其它功能正常;若多次出现, 需对系统匹配方面进行检查;检查导航系统与SD卡通信状态, 即考虑SD卡数据交换、时钟通讯频率的情况:

地图SD卡通讯频率上限为25MHz, 数据显示, EBOOT CLK时钟频率超出SD卡通讯频率, 这样会引起SD卡初始化不能完成, 系统内核无法加载, 表现为主机黑屏, 不能进入导航工作状态;可优化EBOOT CLK时钟频率, 使之与地图SD卡的通讯频率保持一致。

3.2 手写输入或设置目的地时, 存在较小概率导航不响应触摸屏操作, 导致导航无法工作, 但主机能够切换到其他界面, AM, FM, DVD, 蓝牙等其它功能正常。

检查软件容错处理能力, 主机MCU与导航系统通讯异常, 导航软件无法接受MCU发出的触摸屏坐标信息, 查看导航系统接收MCU串口协议消息中是否有错误信息, 导致导航运行错误。

检查步骤如下:

(1) 检测导航系统停止响应状态时MCU与导航之间的串口通信, 包括触摸指令和相关交互协议, 是否存在MCU有指令发出, 导航没有回应的现象。

(2) 检测从MCU发过来的数据, 人为在串口通讯的收发段间歇短路加入干扰。检查导航系统是否存在停止响应概率加大, 干扰或者错误数据容易引起导航系统运行不正常的现象。

(3) 上述无异常时, 分析通讯异常处理部分程序, 是否存在发生数据异常后的数据指针未按设计要求进行加一操作 (及调的下一帧数据, 而是继续判断有错误的帧的数据, 形成死循环) , 通讯线程死锁。正确的通讯协议帧是由“帧头+长度+数据+校验和”组成的, 当外加干扰, 或其它数据异常发生时有可能发生数据错位, 此时数据指针应该丢弃错误的数据, 再寻找正确的帧头。

我们可以通过修改导航系统的串口容错机制, 确保数据异常时能够自动从错误状态恢复, 不引起线程死锁。

3.3 USB状态关机 (POWER OFF) , ACC断电后再上电, 开机后TFT屏正常显示USB的UI界面和歌曲信息, 0.5秒后UI界面变为LO-GO (USB歌曲信息维持正常) , 随后USB的UI界面立刻恢复正常。

软件架构流程中的显示logo背景的部分程序存在冗余现象。最终优化后的软件程序如下图所示:

4 总结

2.软件架构设计师岗位职责 篇二

关键词：面向服务架构（SOA）；面向对象架构（OOA）；软件设计

中图分类号：TP311文献标识码：A 文章编号：1009-3044(2007)16-31142-02

New Designing Idea of ERP Software Based on Service Oriented Architecture

WU Ru-xiao,LIU Zhong-ying

(School of Management Science and Engineering, Tongji University, Shanghai 200092,China)

Abstract:There turns out many problems during the ERP is applied in the enterprise，which is designed by traditional architecture. This paper introduces a new designing idea of ERP, which is based on service oriented architecture. Then the paper compares the differences between ERP which is designed by service oriented architecture and the one by object oriented architecture. And it shows the advantage of the ERP designed by SOA with the case of the SAP Company, which is producing the software of NetWeaver and Enterprise SOA.

Key words:service oriented architecture; object oriented architecture; software designing

0 引言

ERP由最初的财务软件逐渐发展起来，内容越来越丰富，功能也越来越齐全[1]。到目前为止，ERP的产品模式最常见的有两种：通用型ERP和专业型ERP。通用型ERP，顾名思义，是适用于多种行业的套装软件。通过对其进行二次开发、系统配置，达到满足不同行业的管理信息化需求。它的拓展性好、通用性高，成为目前的主流。专业型ERP，也称之为行业型软件，是专门针对某一特定（或相近）行业设计和定制的，便于满足目标行业的个性化管理需求。

但这两种ERP产品都存在各自的缺陷，从而导致了应用实施过程中出现了很多问题，最终以失败告终的案例也不在少数。如通用型ERP，它的优点也正是它缺点所在。通用代表了缺乏个性，流程固化，不能针对不同企业做出有效的变化，只能通过企业进行业务流程再造，来满足ERP产品的需求，忽视了企业的个性化需求；专业型ERP的最大缺陷是它的开发成本高，使企业望而却步，同时适用的企业并不多，所以这种专用型ERP，企业很少主动开发，往往是在目标企业提出某种需求的前提之下，进行定制开发，需要很高的成本。

传统ERP产品存在的这些缺陷，大部分原因是其架构理念的落后，开发方法的局限。现在，面向服务架构（SOA，Service Oriented Architecture）这种新的架构理念被引入到ERP软件的设计与开发中，为传统ERP产品走出困境带来了希望，为ERP领域的又一次革命性的飞跃奠定了基础。

1 面向服务架构SOA

早在1996 年，Gartner Group就已经明确地提出了SOA的理念，但目前尚未有一个统一的、业界广泛接受的定义[2]。IBM的高级软件工程师李珉先生说过，不同行业的人可以从不同的视角来理解SOA，从程序员的角度，SOA是一种全新的开发技术，新的组件模型，比如说Web Service；从架构设计师的角度，SOA就是一种新的设计模式，方法学；从业务分析人员的角度，SOA就是基于标准的业务应用服务。

一般认为：SOA——面向服务架构是一个组件模型，它将应用程序的不同功能单元——服务，通过服务间定义良好的接口和契约联系起来。接口采用中立的方式定义，独立于具体实现服务的硬件平台、操作系统和编程语言，使得构建在这样系统中的服务可以使用统一和标准的方式进行通信。其中服务，是指仅基于两个组件接口之间的契约，由一个组件提供其行为方法给另一个使用。

SOA中一般都包含三个角色：服务的提供者、服务的请求者、服务代理[3]。三个角色是根据对服务提出不同的需求和行使的不同功能来划分的。它们的关系可以简单理解为：服务的提供者将它提供服务的具体描述发布在服务代理，以方便服务的请求者查询；服务的请求者通过对服务代理搜索，查找到需要的服务及其提供者的地址；最后是服务的提供者与服务的请求者进行直接的绑定，完成服务（见图1）。 举个最简单的例子，我们若要在网上下载一首歌，先可以通过搜索引擎GOOGLE等，搜索可下载这首歌的网站，获知这首歌的免费下载的地址，最后我们直接链接这个地址下载歌。在这个过程，网站即相当于一个服务代理，我们是服务的请求者，而最后那个下载地址背后的服务器为服务的提供者。

图1SOA 三者关系图

SOA主要特征是将应用程序功能包装成服务，服务间彼此独立，可单独作为组件使用。它具备松散耦合，提供粗粒度的服务和标准化的接口等。SOA旨在提供一个通用的，可互操作的和有弹性的行业标准架构，可以在软件基础架构之上建立一系列可重复利用的服务，实现企业适应业务流程变化的需求。

2 基于SOA的ERP与传统架构下的ERP的比较分析

2.1 ERP传统体系结构和基于SOA的ERP体系结构的区别

传统的ERP软件在其体系结构上可以分为三层：表现层、业务逻辑层和数据库[4]。在这种体系结构下，其客户端访问存在很多的问题。如表现层在访问业务逻辑层的各个业务对象时，一个客户端可能同时访问多个业务对象，一个业务对象也可能同时被多个不同的客户端访问。因此它们之间关系杂乱、复杂，造成层与层之间的耦合性强；表现层与业务逻辑层相互依赖，访问接口不是公开标准的，而是依赖于特定的接口函数，一旦其中的某一层发生改变，其接口函数也要作相应的改变，导致系统地扩展性和维护性差（见图2）。

图2传统ERP体系结构

将SOA思想引入ERP软件的设计开发之后，其传统的三层体系结构，将会在概念上演变为四层结构，包括表现层、服务层、业务逻辑层和数据库。其中，服务层是抽象层，是独立的、由可重用的、基于标准的服务组成。每一个具体的服务包含了接口部分和实现部分，其接口部分定义了服务使用者和服务提供者进行程序访问的契约；实现部分包含了服务作用和商业逻辑等信息（见图3）。

由图3与图2比较可以清楚地看到两者的区别，SOA架构的四层体系结构，客户端并不像传统的体系结构直接调用业务对象实现最终目的，而是通过调用一个独立的服务，服务再调用相关的业务对象去实现最终目的。由于它调用服务的接口包含在服务层内，所以，各个层之间都是独立的、松耦合的，没有很强的依赖性。任何一层发生变化，只要接口不变，不会影响服务的实现，有利于系统地扩展和维护。

因此，设想以SOA思想实现的ERP软件，具备很强的弹性，可以根据不用企业的不同需求进行调整，符合企业的个性化需求，具体会在后面的实例中说明。

图3 SOA四层体系结构

2.2采用SOA和OOA进行ERP软件设计开发的区别

ERP软件发展至今，它的开发方法由最初的面向过程（POA）的开发方法，发展到面向对象（OOA），至现在提出的面向服务（SOA）的开发方法[5]。面向对象的开发方法是目前ERP软件开发中的主流技术，但它本身存在很多的缺陷。它对编程语言有很强的依赖性，封装粒度小，耦合度高，未形成标准的模型和概念，从而难以形成标准和开发规范，不能达到软件重用的可移植性和互操作性，产生了大量的“对象孤岛”。

相对于传统的面向对象体系结构的紧耦合，SOA是一个粗粒度、松耦合的面向服务架构，其服务之间通过公开、精确定义的接口进行通讯，不涉及底层具体编程接口和通讯模型，服务与服务之间是相互独立的，且服务可以被重复调用，也可以被任何潜在需求者调用。

以下是某公司针对订购产品这一实务做出的一系列数据处理的例子，分别从面向对象架构与面相服务架构这两种不同架构理念对软件设计开发的不同要求做出的比较（见图4）。

面向对象设计中，公司在生产和销售产品的时候，是根据收到的采购订单进行的。采购订单有很多属性，但它的订单编号是唯一的。根据其订单编号，编制公司的销售订单。根据其销售订单中产品清单编号主码，关系到产品清单。最后根据其具体产品编号关系到产品目录，一层一层的处理数据。以上过程，就是软件面向对象架构的最基本思路，对象之间继承关系的依赖性很强，层层相扣。因此，对象的分析与设计及编程实现，要求很高，也很复杂。

图4面向对象架构与面向服务架构

现采用面向服务架构思想对软件进行开发。可以把所有相关的主体分为三个层次，从基础的对象层，到由不同对象组成的组件层，至最终的服务层。关于这项订购实务，公司要处理的有四个基本对象，采购方信息处理，采购订单，产品清单，与产品目录；组件层包括采购方信息和单据两个实体；而它们都包含在订购产品这项服务中。那么公司在开发这项订购产品服务的时候，可以把它分为若干部分，从对象这个最小粒度开始，再组合成不同的组件，到最终完成一项服务。这样对开发人员技术的要求会低一点，且不同部门可同时进行软件开发。

这里需要说明的是，SOA并不是OOA的完全替代，如开发人员对单个对象，或组件乃至整个服务采用面向对象的架构设计，但在整体上是面向服务的，主要原因是接口的设计。

2.3 SAP的NetWeaver平台和ESA思想

目前，SOA的思想被越来越多的用于ERP产品的开发上，ERP产品的巨头SAP也不例外。企业服务架构ESA就是SAP基于SOA的思想提出的新产品的模式。提到ESA就不得不提到它的另一个产品NetWeaver，因为企业服务架构是建立在这个技术平台之上的。

NetWeaver是SAP于04年正式推出的一个产品，它是一个底层技术平台，SAP的很多新产品的应用都是跑在这个平台上，相当于一个中间件产品。它主要提供了以下四方面的功能，人员集成，信息集成，流程集成和应用平台。它是由交换架构XI,主数据管理MDM，解决管理Solution Manager等组件构成。它是目前支持所有SAP应用的基础产品，是企业应用软件的开发平台、同时又为企业搭建一个基于NetWeaver的面向服务的IT架构。

SAP的企业服务架构并不是简单的技术层面的SOA，而是面向企业层面的，它将原有的ERP、SCM、PLM等模块在NetWeaver这个技术平台上集成，组合成业务流程平台（见图5）。企业在这一个平台上可以共享很多组件，不同的企业也可以根据不同的需求，增加或选用不同的企业服务库，或自主开发部分功能，实现企业的个性化。

图5 SAP NetWeaver平台业务组件

SAP的一位主管曾作过这样一个比喻，将软件的企业服务架构化比作电路的集成化。集成块(IC)本身是功能模块化设计的，但它是更复杂电路的基本组件，设计一个个的集成块，把他们组成电子设备，而不再是从电阻、电容、电感、晶体管等基本元件来组建电路。以后软件业业一样，要设计这些“集成块”和利用这些“集成块”，这些“集成块”就是企业服务(Enterprise Service)。 这也是面向服务架构思想在ERP软件开发和产品发展中应用的最佳体现。

3 总结

面向服务架构（SOA）得到了各大软件公司的重视，如IBM、Oracle、SAP等，说明其理念是先进的，相对于传统的架构模式存在很大优势。本文也具体阐述了其存在的优势，但大部分也只存在于理论，因每个公司对SOA的理解各不相同，基于此理论设计开发出的产品也是各有特点，没有得到一致的公认。

本文分析了SAP基于SOA思想提出的ESA这个思想，其最终产品仍处于开发阶段，只能对其主导思想略为阐述。现在是SOA乱战时代，但可以预见，随着SOA思想的发展和完善，以及在软件业的广泛应用，它的优势会逐步显现出来，为传统的ERP软件带来革命性的转变。

参考文献：

[1]黄双柱.我国财务系统软件在ERP发展中的演进[J].厦门科技,2004(4).

[2]王兵.基于面向服务架构的应用系统开发与集成研究[D]. 四川: 四川大学,2005.

[3]吕希艳.基于SOA的企业信息资源整合[J].中国科技论坛,2006(3).

[4]陈其明. Web Services在URP系统中的应用研究[D].广东: 广东工业大学,2004.

[5]魏东.基于SOA体系结构软件开发的研究与实现[D].西安: 西北大学, 2005.

3.软件架构师的岗位职责描述 篇三

1.负责核心系统的基础架构设计、重构、优化，解决开发中各种系统架构问题;

2.负责核心基础组件研发，如RPC框架，消息推送，缓存，数据访问等定制开发;

3.负责项目中关键技术难点的攻关和预研;

4.带领团队攻克例如大数据量、高并发、高稳定性等带来的各种挑战及技术难关。

任职要求：

1.深刻理解并掌握分布式架构原理，熟悉微服务治理思想和EDA架构,具有大型分布式、高并发、高负载、高可用技术设计、开发和调优经验

2.精通JAVA主流技术，如Spring Cloud、Spring Boot、SpringMVC、Mybatis、Zookeeper、JPA、OSGI

3.熟悉缓存技术(Redis)、搜索技术(ElasticSearch)、消息队列(RabbitMQ、Kafka)、集群与负载均衡(Nginx、HAProxy)等领域

4.熟悉大数据解决方案，包括Hadoop平台、Spark、storm、机器学习、深度学习等大数据解决方案。

5.熟悉基于Docker和Swarm/Kubernetes的分布式部署和服务架构，有DevOps和PaaS平台实施经验更佳

4.软件架构师工作的职责 篇四

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

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

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

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

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

任职资格:

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

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

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

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

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

- TOGAF Architect

- PMP

5.软件架构师的职责内容 篇五

1.负责总体技术框架的规划与设计，出具实施解决方案，包括：系统架构设计、接口规范制定、指导开展技术文档撰写等;

2. 能够完成系统核心模块的代码编写;

3. 帮助团队解决系统出现的性能或关键问题;

4. 具备良好的沟通表达能力，协同他人并组织跨团队协作，保证项目质量与进度，负责代码Review和技术审查;

5. 针对新人、普通开发人员进行有效辅导，帮助其快速成长。

岗位要求：

1、软件工程、计算机科学与技术专业本科以上学历，5年以上JAVA开发经验，2年以上JAVA架构设计经验(主持开发或主要设计)。

2、精通SOA框架，精通SpringMVC、Spring Cloud/ boot、MyBatis/Hibernate等常用开源框架，对框架本身的体系有较为深厚的理解和应用经验， 熟悉微服务、分布式和高并发架构设计、精通多线程编程。

3、熟悉HTML、JavaScript、CSS、XML、AJAX，理解W3C及Web标准。

4、熟悉Oralce数据库、MySQL等数据库的安装、部署、调优;熟悉数据仓库模型

5、熟悉hadoop、spark、storm等开源大数据软件安装、部署、调优。

6、对常用数据挖掘、机器学习算法有一定了解。

7、对大数据平台体系的建设和演进有一定理解，至少具备一个数据挖掘、数据处理、数据管理、大数据平台建设等领域的项目经验。

8、有高并发服务端整体架构经验者优先。

9、熟悉地理信息系统经验值优先。

6.软件架构设计师岗位职责 篇六

BIT是航空电子设备检测故障的重要手段,在改进系统的可靠性和安全性方面发挥着重要的作用[7,8]。BIT是系统或者内部提供的自动测试能力,不依赖于任何的外部设备,且对系统的运行不会造成影响,适合用于系统的在线测试。

传统的BIT偏重于系统硬件检测,较少提及软件功能测试和软件运行状态的监控。结合综合化模块化航空电子系统的特点,参照ASAAC标准,将BIT为节点级、子系统级、系统级三级测试,每一级均设计了上电自测试、周期自测试和维护自测试,不但能检测系统的硬件状态,同时还可监控软件的运行状态,完成系统整个运行周期的软硬件测试。

1 ASAAC标准

ASAAC标准定义的系统管理采用了分层的结构,将系统分为3 层,由下到上依次是资源层RE ( Resource Element) 、综合区域层IA( Integration Area) 和飞机层AC( Aircraft)[9]。RE是最底层的管理实体,管理单一的进程单元; IA级是多个应用的逻辑组合,其管理一个或多个RE级; AC是最顶层的管理者,控制并监控整个航空电子系统的运行,如图1 所示。

2 自测试系统

BIT是系统或者设备内部提供故障检测、故障隔离的自动测试能力。根据BIT启动的方式,可分为3种: 上电自测试PUBIT( Power - Up - BIT) 、维护性自测试MBIT( Maintenance - BIT)[9]和周期自测试PBIT( Periodic - BIT) 。系统上电后,PUBIT自动运行,对系统的硬件和软件功能进行全面测试,判断系统是具备正常工作的能力; 系统正常运行中,运行PBIT,对系统的软硬件功能进行周期性的检测,判断系统是否发生故障; MBIT是由用户启动对系统检测,用户根据飞机的实际情况启动MBIT检测软硬件功能[10]。

依据ASAAC标准的层次架构,对系统的检测,不但需要检测每个RE节点的硬件功能和软件功能,还需检测每个IA级的软件和硬件功能,最终完成AC级的检测。因此,将自测试系统分为三级,分别是模块级、子系统级、系统级,每一级又根据自检测的不同种类,包含PUBIT、PBIT和MBIT[11],如图2 所示。

2. 1 模块级自检测

模块级PUBIT: 系统上电后,模块级上电BIT自动运行,对本模块的硬件资源和软件启动情况进行测试。测试本模块所有的硬件资源,包括CPU、NVRAM、RAM、中断等基本的硬件资源,还包括RS232、RS422、1394B的串口设备和总线设备等,该测试结果能全面的反应该模块的硬件情况。PUBIT与刚启动的应用程序交互,判断应用程序是否正常启动,达到监控应用程序启动状态的目的。

模块级BIT对RS232、RS422、1394B只能进行简单的测试,并不能彻底的测试其状态是否正常,这类设备的测试需外部设备给出相应的输入; 对软件测试也只能测试软件是否正常启动,而不能确定软件是否能完成相应的功能。

模块级PBIT: 系统正常运行时,模块级PBIT对本模块的硬件资源进行周期性的检测,并监控模块上程序的运行状态。PBIT对模块的测试原则是不能影响系统的正常运行,因此只测试了模块的部分硬件资源,包括CPU、NVRAM、RAM等基本的硬件资源。PBIT通过与应用程序的周期性交互,监控本模块上应用程序的运行状态,达到监控应用程序的目的。

模块级MBIT: 模块级MBIT响应上一级MBIT的命令完成对本模块硬件资源的检测和软件运行状态的监控,并把检测的结果返回给上一级MBIT。接收到上一级的MBIT的命令后,对本模块的CPU、NVRAM、RAM等硬件资源检测,查询本模块应用软件运行状态,并将最终的结果上报给上一级MBIT。

2. 2 子系统级自测试

子系统PUBIT: 子系统PUBIT是对该子系统内部所有的硬件资源和软件启动情况的测试,依赖于直接隶属于该子系统的模块级PUBIT和子系统PUBIT的结果。子系统上电后,查询直接隶属于该子系统的所有模块级PUBIT和子系统级PUBIT的结果,获取子系统的硬件资源健康状态和应用软件启动情况。子系统的PUBIT上电后,对子系统内部软硬件资源的分配有着重要的意义,根据模块或子系统的健康状态,调整其承担的角色,将故障对系统所造成的影响降到最低。

子系统PBIT: 子系统PBIT是对子系统正常工作时硬件资源测试和软件运行情况的监控,子系统PBIT周期性的查询隶属于该子系统的所有模块的周期BIT结果,从而获取子系统的健康情况。

通过子系统的周期性测试,可了解子系统内各个模块或者子系统硬件资源状态和软件运行情况,在发现模块或者子系统发生故障后,重新分配子系统内部的资源,将故障对系统所造成的影响降到最低。子系统PBIT为1 + 1 模块备份的主从切换和子系统内部的重构提供了重要依据。

子系统MBIT: 子系统MBIT是由上一级MBIT启动,对该子系统内所有模块和子系统的软硬件资源进行检测。子系统接收到上一级的MBIT命令后,向直接隶属于该子系统的所有模块和子系统发出MBIT命令,并收集返回的测试结果,上报给上一级MBIT。

2. 3 系统级自测试

系统级PBIT: 系统级PUBIT能反映整个航空电子系统的上电状态,通过查询各个子系统的上电BIT的结果,得出系统总体的上电状况。该结果对航空电子系统有着重要意义,在某些重要的功能无法实现时,及时给飞行员发出警告,并进入应急工作模式。

系统级PBIT: 系统级周期BIT能反映整个航空的电子系统的运行状态,通过周期性的查询各个子系统的周期BIT的结果,得出系统总体的运行状态。该结果对航空电子系统有着重要意义,在某些重要的功能发生故障时,及时给飞行员发出警告并采用相应的措施避免灾难发生。

系统级MBIT: 由用户向航空电子系统发出测试命令,系统级MBIT响应用户的命令,向直接隶属于该系统的所有模块和子系统发出MBIT的测试命令,并将最终的结果返回给用户。

2. 4 PUBIT、PBIT和MBIT的对比

PUBIT、PBIT和MBIT在系统运行的不同阶段对系统进行测试,测试的软件和硬件资源不尽相同,如表1所示。

3 结束语

本文研究了ASAAC标准和自动测试技术。依照ASAAC标准,将自测试分为系统级、子系统级和模块级,每一级又分别包括PUBIT、PBIT和MBIT,覆盖了系统飞行及地面维护状态下各个部件、各个阶段的自测试需求。该自检测系统不仅能测试系统的硬件资源,还可以监控软件的运行状态,提高航空电子系统的自检测能力。

摘要：为检测和定位航空电子系统的故障,研究了ASAAC标准和自动测试技术。参照ASAAC标准的多级结构,将自测试系统分为节点级、子系统级和系统级三级测试,每一级分别设计了上电自测试、周期自测试和维护自测试,实现了对系统各个运行阶段及不同层次的测试。该系统不仅能检测系统的硬件状态,还能检测软件的启动和运行状态,提高了航空电子系统的自检测能力。

7.基于B/S架构的软件项目开发 篇七

关键词：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-），女，四川绵阳人，本科，研究方向：软件工程。

8.软件架构师的工作职责 篇八

1、承担公司软件系统平台的规划与制订;

2、负责公司自动化系统的软件架构设计;

3、软件架构设计，需分层合理，接口清晰，同时具备良好的可扩展性、可测试性、稳定性;

4、参与制订公司软件开发流程及规范，引入相关规范化的系统或工具;

5、部门内软件架构设计方面的培训与指导;

6、完成上级领导及公司交办的其它任务。

任职要求：

1、5年以上的软件开发工作经历;3年以上复杂系统软件架构设计经验;

2、精通软件系统架构、系统分析、框架设计，具备良好的设计思路;

3、能够熟练运用系统分析相关工具;

4、良好的沟通能力、团队协作能力、学习能力、强烈的责任心;

9.系统架构设计师的岗位职责 篇九

1. 负责公司系统的架构设计、研发工作

2. 配合产品经理对公司产品以及公司基础研究项目进行技术需求分析，承担从业务向技术转换的桥梁作用，根据产品业务需求提出技术方案和系统设计

3. 负责制定系统的整体框架，编写软件架构设计文档。对系统框架相关技术和业务进行培训，指导开发人员开发并解决系统开发、运行中出现的各种问题

4. 主持和参与系统逻辑模型和物理模型设计，负责开发和维护统一的软件开发架构，保证软件模块的复用性

5. 参与各项目、各阶段的技术评审;特别是技术架构方面和软件复用方面

6. 参与部门研发技术方向规划，负责提供软件产品框架和技术路线;负责关键技术的预研与攻关, 解决项目开发或产品研发中的技术难题

7. 协助部门经理合理分配软件研发任务使项目团队高效率运作，确保技术架构得以推进和实施

岗位要求：

1. 本科及以上学历，计算机或相关专业毕业, 8年以上软件产品开发及架构设计经验

2. 具有丰富的大中型开发项目的总体规划、方案设计及技术队伍管理经验

3. 熟悉C/C++或JAVA等开发语言，并且实际开发工作不少于5年;熟悉常见的数据库系统，如MySQL、Oracle和MongoDB等

4. 精通设计模式和开源的框架，有面向对象分析、设计、开发能力(OOA、OOD、OOP)，精通UML，熟练使用Rational Rose等工具进行设计开发

5. 对计算机系统、网络和安全、应用系统架构等有全面的认识，熟悉项目管理理论，并有实践基础

6. 在可扩展、高性能，高并发，高稳定性系统设计，开发和调优方面有实际经验

7. 良好的业务分析能力和文档编写能力

8. 良好的团队意识和协作精神，有较强的内外沟通能力

9. 拥有系统架构师证书者优先考虑

10.软件架构设计师岗位职责 篇十

软件无线电[1](Software Defined Radio,SDR)是一种新型的无线电体系结构,在理想状态下可以通过下载适合的通信波形实现以任意频率、带宽、调制方式和数据数率进行通信[2],即可以通过软件定义来完成不同功能。SDR平台对多种无线通信体制的支持,尤其是3G,4G,WLAN,WIMAX等计算密集型通信体制的出现,对硬件平台的处理能力以及硬件和软件框架的可重构能力提出更高的要求,无线电平台设计在功耗、可编程性、计算能力、尺寸、重量等方面面临新的挑战[3]。

1 主要技术背景

软件通信体系结构[4](Software Communications Architecture,SCA)是美军在联合战术无线电系统(Joint Tactical Radio System,JTRS)计划中提出的,旨在提供一种标准的、开放的、可互操作的软件平台。波形是为了实现信息的无线传输对信息的一系列变换,包括无线通信双方为实现信息传输而采用的所有协议。实现一套完整功能的软件模块或单元称为组件。SCA的架构如图1所示。

SCA使用CORBA中间件技术屏蔽了操作系统、编程语言的差异为软件开发提供了一个统一的编程环境,实现软件无线通信中各种软件组件的移植和重用,但是受处理器件特性和开发复杂度等因素的限制,在SHP上不运行CORBA中间件。

在SDR的信号处理中,数据流信号处理任务(滤波、编码等)适合在DSP和FPGA等专用处理器(Specialized Hardware Processor,SHP)上实现,这些任务在许多的SDR应用都会用到,只需要对相关频率进行调整就可以在不同SDR波形实现中复用,因此可以通过将处理任务分配到异构处理器平台上执行来提高计算性能、降低功耗。但是异构处理器平台中计算性能的提升和功耗的降低是以软件开发的复杂性的增加为代价的[5]。软件无线电的分层结构图如图2所示。

为了使不同平台实现无缝通信并为上层软件屏蔽底层通信接口的差异性,有效地支持向SHP上部署波形组件,实现消息的透明传输,需要设计异构处理器上的互联架构屏蔽底层硬件差异为软件应用提供透明的消息传输机制;实现软件开发与硬件平台设计的分离,提高系统开发效率,以提供对异构处理器平台上的软硬件资源的抽象和管理,支持软件框架对硬件设备的管理和控制。

JTRS先后提出了几种硬件互联结构,包括HAL-C[6],CP289[7],MHAL[8],MOCB[9]等,其中MHAL方案考虑了硬件的抽象和组件互联是较为完善的解决方案。为波形组件和其他组件之间数据和控制流信息交互提供与SCA兼容的通信服务,但是由于国际武器管制组织的管制,MHAL方案的具体内容不对外公开,为硬件抽象层的实现增大了难度。

2 主要设计思想

异构处理器互连架构的实现首先要对硬件模块的对外接口进行抽象,将其与外界的交互进行独立设计,即要实现底层屏蔽功能并为波形组件提供异构处理器环境下透明的消息传输机制的硬件抽象层。带有硬件抽象层的硬件平台能为软硬件开发提供便利的条件,能实现系统设计中软件开发与硬件平台设计的分离,降低系统开发的复杂程度和重要软件组件接口的重新编写,提高系统开发效率。针对GPP、DSP、FPGA组成的异构处理器互连架构设计的硬件抽象层如图3所示。

第二,要实现传递数据在异构处理器环境中的数据路由功能。由于专用处理器之间、专用处理器与通用处理器之间采用逻辑地址(logical Destination,LD)进行数据和控制信息的交换,因此硬件抽象层必须提供对传递数据的封装、解析和分发功能。

第三,要支持配置查询功能,SDR系统中一块处理器上可能需运行多个组件,由于不同组件所需的端口数量、连接方式和消息长度等都有所不同,因此需要通过动态配置的方式使硬件抽象层能够适应不同的组件需求,同时支持配置结果和运行状态的动态查询。

3 互连架构的实现

在互联架构中,硬件抽象层通过屏蔽硬件平台相关的底层通信机制、封装标准的通信接口,实现波形组件间通信方式与硬件平台的分离,提高了波形应用在异构硬件平台间的跨平台可移植性;硬件抽象层收发模块不关心收发数据的格式,对数据的封装由硬件抽象层API采用统一报文格式进行封装,调用硬件抽象层API收发数据;应用组件通过硬件抽象层API实现对组件的控制管理、寄存器寻址和数据端口间通信,支持应用组件的可复用、可移植和应用的动态部署。

3.1 数据报的构造

为了支持异构处理器中装配控制器与组件控制端口、组件数据端口之间的互连互通,需要指定组件端口间传输数据的统一格式;保证不同硬件处理器能以相同的语义理解数据,以根据收到的数据进行正确的响应。

为了与MHAL规范兼容,硬件抽象层消息帧格式采用MHAL的帧格式如图4所示。

每个处理单元上的每个波形组件都会提供若干信源函数和信宿函数,信源函数是发布硬件抽象层消息的线程,负责请求其他处理单元上的信宿函数执行特定的操作,或返回本地处理单元上特定函数的执行结果,信宿函数对硬件抽象层消息进行解析并执行相关操作,每个信宿函数都由一个LD进行惟一的标识,从而使硬件抽象层通信函数能够进行正确的路由转发。硬件抽象层负责接收波形组件数据,并将报文发送到LD相匹配的目的处理器。同样,从I/O接口驱动接收到数据后,将数据分发到与LD相匹配的波形组件上。

3.2 流量控制

硬件抽象层通信的流量控制在数据发送端实现,发送端根据传输链路中的数据量调整发送数据包的时间。硬件抽象层的实现中设计一个用于监测通信链路状态的线程,当通信链路中的数据包过于密集时向发送端发送消息,发送端经过一个随机延迟后再发送数据。

4 各处理器上互连架构的设计

为了灵活地支持多种波形及不同的业务类型,提高物理信道的复用率,降低时延,提高传输效率,互连架构的实现需要支持多线程、多优先级并提供配置接口,基于包交换的互连架构分层结构如图5所示。

硬件抽象层位于应用层之下,驱动层之上,由通信函数和接口组件两部分组成:接口组件提供消息传输功能,负责将硬件抽象层消息通过外部传输链路向外部发送,或者从外部传输链路中接收硬件抽象层消息。GPP和DSP硬件抽象层接口组件为硬件驱动程序,FPGA硬件抽象层接口组件为硬件接口实体模块;通信函数提供硬件抽象层消息的路由功能,负责将接口组件接收到的硬件抽象层消息或解析后的数据转发到特定的信宿函数,或者将特定信源函数传递过来的硬件抽象层消息或数据封装并通过接口组件向外发送。

4.1 GPP硬件抽象层设计

硬件抽象层设备提供的接口通过硬件抽象层设备组件进行封装,为上层GPP波形组件提供数据收发和路由功能。GPP硬件抽象层的实现如图6所示。

硬件抽象层设备根据目的组件的LD和物理通道的映射关系,通过相应的设备驱动将数据发送到与LD对应的处理器MHAL接口;反之,从与之互连的处理器的接口接收到数据后,根据接收数据与LD的映射关系,将报文转发给与LD相匹配的GPP波形组件上。

4.2 DSP硬件抽象层设计

DSP硬件抽象层设备可以看做对DSP各种外围设备接口提供的设备间通信机制的封装,DSP上的不同物理通信接口(PCI、rapid IO、以太网、EMIF、异构处理器I、GPIO等)提供的通信方式不尽相同,在速率、接口规范等方面有较大差异,因此需要对其进行不同方式的封装。提供接口配置、驱动、容错处理等机制,为DSP上的波形应用提供符合Qo S要求的通信API。

4.3 DSP硬件抽象层模块

DSP硬件抽象层如图7所示,DSP硬件抽象层通过I/O接口驱动实现数据收发:当有数据从I/O接口到达时,MHAL设备从相应I/O接口驱动中接收这些数据,对其进行适当解析,根据LD将其分发给本地的波形组件;当本地的波形组件有数据要向外发送时,硬件抽象层设备对数据封装,然后将处理后的数据通过I/O接口驱动向外部发送。

硬件平台开发者实现DSP硬件抽象层中定义的标准接口函数。DSP上的波形应用通过将DSP硬件抽象层实体在编译时联编到波形应用中,实现DSP上的完整功能。

4.4 FPGA硬件抽象层设计

FPGA硬件抽象层应实现对外部I/O接口和外部存储器访问接口驱动的封装,为FPGA波形组件提供一套标准的硬件抽象层接口时序,从而为波形组件提供异构处理器环境下透明的消息传输机制,硬件抽象层对传递数据进行封装、解析和分发,能够对到达数据进行解析,根据LD分发到对应的组件,同时对等待发送的数据进行适当封装,发往LD所指定的组件。

硬件平台开发人员负责提供FPGA中硬件抽象层的实体模块,FPGA波形应用开发人员通过将FPGA硬件抽象层实体模块例化到自己的设计中,实现完整的FPGA功能,经过一起编译后形成统一的映像加载到FPGA中运行。一个FPGA片内只需要设计一个硬件抽象层设备,所有的波形组件与I/O接口驱动均连接到硬件抽象层设备。软件无线电系统中同一块FPGA上可能需运行多个组件,由于不同组件所需的端口数量、连接方式和消息长度等都有所不同,FPGA硬件抽象层通过动态配置的方式适应不同的组件需求,同时支持配置结果和运行状态的动态查询。

5 结语

异构多处理器平台互连架构通过硬件抽象层为波形应用提供了统一接口,实现了软硬件的分离和组件间无缝通信,一般而言,对硬件接口的抽象层次越高,组件移植性越强,但可能存在复杂度高而性能降低的不足。寻找更加有效的软硬件分离方法以及对接口抽象与性能之间关系的建模和量化研究将有助于异构处理器互连架构的设计。

参考文献

[1]MITOLA J.The software radio architecture[J].IEEE Communi cation Magazine,1995,33(5):26-38.

[2]ULVERSOY T.Software defined radio:challenges and oppor tunities[J].IEEE communications Surveys and Tutorials,2010,12(4):531-550.

[3]GOMEZ I.MAROJEVIC,V,GELONCH,A.ALOE:an Open Source SDR execution environment with cognitive computingresource management capabilities[J].IEEE CommunicationsMagazine,2011,49(9):76-83.

[4]Anon.JTRS support and rationale document for the softwarecommunications architecture specification(version:2.2.2)[S].Joint Tactical Radio System(JTRS)Joint Program Office,2001.

[5]BIEBERLY F.Heterogeneous processing in software de fi nedradio:flexible implementation and optimal resource mapping[D].Blacksburg:the Virginia Polytechnic Institute and StateUniversity,2012.

[6]JTR Joint.Specialized hardware supplement to the softwarecommunication architecture(SCA)specification[S].[S.l.]:[s.n.],2004.

[7]JTRS JPO.Extension for component portability for specializedhardware processor(SHP)change proposal 289(CP289)[S].[S.l.]:[s.n.],2005.

11.系统架构设计师的具体职责范本 篇十一

1.可以独立搭建软件开发项目系统架构(平台、数据库、APP+WEB接口设计和应用架构等)，缓存架构，文件服务器架构

2.负责软件系统平台核心功能模块设计、核心代码开发

3.负责组织技术架构、解决方案的评审，编辑设计、开发、接口文档等

4.主导承担过至少一个大型项目

5.高可扩展能力，高并发性能，高吞吐能力以解决以后日益增长的用户

任职要求：

1、计算机、信息、软件工程等相关专业大学本科及以上学历

2、6年以上后端工作经验，3年架构经验

3、有很强的分析复杂问题和解决复杂问题的能力，有强烈的责任心和使命感

12.软件架构设计师岗位职责 篇十二

UIPower在充分了解中海油的后台系统的需求后, 建议中海油采用UI设计+UI开发的整体UI解决方案。

UI设计阶段: 进行了用户研究、交互设计、用户体验测试和视觉设计等方面的工作。 首先解决了软件难用的问题, 对软件中的各种窗体进行了重新规划, 详细分析了各种控件在实际使用中的频率。接着提出中海油作业软件的整体交互设计规范。 从规范上确保未来的各个软件系统保持一致的操作习惯。通过对新的交互设计严格的实验室测试来检验它的科学合理性, 去除里面不合理的地方, 不断迭代最终形成易上手、易操作的软件交互模型。UIPower的视觉设计师根据多年的经验对软件进行整体风格、色调、质感等的创意, 最终形成在视觉上具有高度专业性的软件高保真设计稿。

UI开发阶段: 对于UI改造项目来说, 设计出漂亮的界面其实已经很困难了, 而要将专业的UI设计真正实现出来则是难上加难。原因是客户端各个开发工具对UI的实现均支持不足, 无法满足各种新特效新质感的窗口或控件的交互和视觉呈现。一般来说, 要实现高保真的效果图程序需要花费半年甚至更多的人月数。然而, 现实却无法允许这样的界面开发进度。UIPower一直采用自主研发的DirectUI产品作为他们的界面开发的基石。DirectUI可以将一个软件的所有界面在1周内全部实现出来, 而且对界面的效果做到没有损失, UIPower对项目验收的标准是“像素级比对”, 即在最后的成型程序与高保真的视觉设计稿通过屏幕的逐像数比对, 只要有一对像素的值不一样即认为是不通过验收。正是基于这样的验收标准, UIPower在业内迅速成为国内大型企业争相合作的对象。

经过2个多月的整体改造, 中海油集团内的几款重要的软件系统, 均已成功上线, 并正式投入了使用。从集团上上下下的相关人员对本次的UI改造成果表示了高度的认可和极大的满意。

13.企业管理软件平台架构 篇十三

企业管理软件，由于进入门坎低，各行各业各层次企业都需要，做面向企业应用比做面向个人应用要赚钱多，好销售，所以中国内地有相当大部分的程序员在从事着企业管理软件的开发。

尤其是接项目的软件公司，这类公司往往在中国当前软件行业占很多。3-4个或5-6个程序员，老板拉来什么项目就做什么项目，进销存、费用报销、销售管理、客服维修工单、请假考勤管理等等为大部分单子内容。

有朋友留言：就10来万的单子，就1-2个程序员，从调研到设计到开发到测试到打包到实施安装到培训到推动上线到支持，全活儿。哪来的精力再去开发平台。再说了，都是10来万的单子，开发平台就大才小用了，什么设计模式，什么OO，什么界面和代码分离，什么代码重构，都扯淡，往界面拖控件，用ADO连数据库，OK。费那精神干嘛，把钱快速赚到才是真理。

其实，你发现没，你做的管理软件(叫它MIS也行，你爱戴高帽就叫它ERP)有一些东西都挺相似。我有个专门给小企业做网站的哥们，5天一个网站。他手里面从免费邮箱服务器、BBS论坛、流量统计软件、网站新闻内容管理系统全从网上找好源代码，各种图标图片素材库，机器上装好Dreamweaver、PhotoShop、Flash。小企业老板来了，他把过去做的案例往出一拿，你挑吧。然后七凑八凑几天完工。

这是不是平台呢?

我们为什么需要平台?我们需要什么样的平台?平台应该包括哪些东西?一个完备的平台是怎样的?

带着这些问题，我们一一揭秘。

拿我哥们刚才的例子剖析。我个人认为那就是一个平台。我们为什么需要平台?就是为了不每次都重新发明轮子，为了能快速的完成代码工作(可以多赚点钱或者可以多打会游戏或者瞌睡或者可以多时间去泡MM)。

快速完成，是平台的第一目标。但是快速三下五除二干完了，去客户那里一跑，BUG百出，倒霉，还得熬夜修改，长期出差回不了家。修改代码，痛苦，还不如推倒重新正式写代码。

看来，平台的第二个目标必须是稳定。

既能快速开发，又能稳定，这是个好平台了吧。

不，客户个性化需求来了，发现真难改。按照普通简单流程处理(增/删/改/查 列表/明细)，确实平台能给很大帮助，但是客户一个性化，平台就不灵了，个性化代码怎么都插不进去手。平台自成一套圈子，外围异常代码根本插不进去(这是现在很多号称平台的产品都共有的最大弊病)。

好不容易遇到个好个性化定制的平台，平台性能不佳，老挂机，客户的电话吼的真想把电话线拔掉，甚至幻想全公司电话和互联网和自己的手机都坏了。终于搞定以上的所有问题，给客户安装上，培训好，推动上线，终于可以闪人了。回到自己的床上，真舒服呀。

没想到恶梦才刚刚开始。客户的电话来了：我发现报表不对呀，数对不上去，你看哪里出问题了?

O，My God。我刚回来，你就...。我又不能飞过去。好吧，好吧，你有QQ或PcAnyWhere吗，我们来连一下，我给查一下数据库。什么?服务器不容许上网?那我怎么办?

看来需要一个排错、可跟踪、可输出详细日志、可过滤日志的东西，就像SQLSERVER的查询跟踪器一样。

嗯，好不容易把问题搞定，修改完代码，需要给客户升级。

什么，你们家没有网管，都是兼职的，根本不会SQLSERVER，脚本怎么执行，怎么备份，不知道?

算我倒霉，电话我告诉你一步步操作。(长途电话费N多，老板冲你发火，你低头不语，心里念到这个猪头)

什么?升级了也不好用?那你肯定没按我说的操作来。

什么?有的机器好用，有的机器不好用?你肯定没有把所有客户端都升级了。哦，看来需要一个自动升级的模块。

挖咔咔，软件卖的好好哦。咿呀咿呀咿。可是，可是...。居然有家伙盗版使用我们的软件，看来我不加密不行了。

加密，加KEY，加并发用户数，加正版判别，加使用期过期。

嗯，终于天下太平了，抱得美人归。

从以上来看，我们似乎并不是为了平台而平台，为了市场宣传和销售便利而做平台噱头。我们确实在多如牛毛的小项目的水深火热战火纷飞中，我们渴望有这些东西将我们快速解脱。如果我们是开发中大型系统的，我们的产品需要延续生命周期8-10年，需要部署给成千上万的客户，客户需要管理几亿的关键数据，有几千个客户并发，我们更需要平台。

所以，不管做小项目的，或者做大项目的，我们都需要平台。

那我们需要什么样的平台。其实上述的场景中已经把平台的关键特性都说了一遍，现在我总结一下：

1可以帮助开发人员快速开发

2稳定

3可以个性化定制

4可以跟踪日志排错

5可以自动升级

6软件版权保护

为了做到这些，国内软件精英不知有多少人前赴后继的的投入研究(甚至做OA的，做工作流的，也号称做平台)。让我们历数历数，看看各自的特点和优缺点，以对照一下我们需要的特性，他们的平台具备不?

大连雅奇，95年我就知道它了。当时好像是Foxbase版本的。可以生成菜单、界面代码。其他的我现在忘了。不过去年CSDN还报道了一次大连雅奇。1报表打印，支持二维、交叉、套打、单据格式、多栏头、导出HTML、PDF、EXCEL、DBF肯定是必须的。计算公式有没有?变量有没有?代码调用API有没有?嵌入图表有没有?小分组合计行不行?最底最右的总合计有没有?支持不支持主从?支持不支持链接钻取?

2图表 当然支持折线、直方、饼图。不知道EXCEL所能支持的图表，它是否都能支持，而且像EXCEL一样好看。漏斗图有没有，里程图有没有?做领导报表(可以起名为管理驾驶舱或商业智能门户)时非常需要。

3控件 可分组、可过滤、可定制查询、可定制列视图、可多排序、可导出、可预览、可小计的Grid控件有没有?可以权限管制行列数据，定制列视图的参照录入控件有没有?日历控件有没有?财务凭证控件有没有?

4企业内部即时通讯模块、邮件收发模块、预警提醒模块有没有呢?

其实，这是在企业应用中极为常见的一些公共功能。有一部份朋友给我QQ留言，他说平台架构就是：中间件+Hibernate(ORM框架)+structs(MVC框架)+spring(AOP框架)+JSF控件(UI框架)+Log4j(日志框架)+JUnit(测试框架)+Ant(Build框架)+JasperReports(报表框架)+JFreeChart(图表框

架)+osWorkFlow(工作流框架)。

我说对，这是平台架构，但不是企业管理软件的平台架构。企业管理软件的平台架构需要更上一层，能方便开发人员快速稳定的开发和修改。

大连雅奇能一直存活到如今，从各方面看虽已跟不上未来，但目前很多小软件公司和小企业还在进行着初步的信息化，所以还是有很多的市场空间的。(我看到华军软件里有人发布的所谓强大平台，一下载一看，原来是一个数据库维护软件，让人尴尬，但是还有大量的个人或2人工作室在不断奋斗制造着这类软件，我已经看到了很多雷同的软件了，也有市场?可能)。

讲完最老的大连雅奇，在企业管理软件平台界，最有名的就数思维加速(现在改名起步)。起步从1999年开始起步，技术一直跟的很紧，做的也非常深入，我个人认为，起步是做企业管理软件平台最优秀的一个。起步加入了工作流，非常适应时代

2加入了集团企业多组织结构，非常适应时代

3起步有数据库建模工具，有版本管理工具，有部署工具，报表、图表自不用说。居然还有甘特图和日历，还有即时通讯工具

4起步拥有自己研发的代码开发IDE。这是国内没有的。老宋为了解决常规平台自我封闭无法定制的诟病下了很大的气力，让简单开发和个性定制融合。5能支持JAVA中间件，也能支持COM+，能WEB，也能C/S。这也是国内没有的。

IDE，既是起步的杀手功能，也是起步的软肋(想起一句古龙的话：敌人的优点也就是他的缺点)。IDE这个东西，世界有三巨头：Eclipse、visual studio、Borland。大家都是干软件的，大部分都是选择这三类IDE，对这三类IDE很是习惯。但是现在要舍弃三巨头，用了起步的平台，就需要用起步的IDE，而且IDE还没有三巨头做的好(要想做好，谈何容易。君不见Eclipse有IBM巨资推动，visual studio更是微软的一个重要产品线，投入大量人力。如果起步也要做，那岂不是平台、IDE、工作流都要并进?要知道，这三块中的每一块，都是需要单独一个公司，而且是相当实力的公司才能做好)。

于是，上海普元学乖了。IDE，我们就用Eclipse。

当然，还是老三套：控件+工作流+报表。

普元的平台框架有组织结构管理(不知道是否支持区域管理组织和集团管理组织?)、部署工具、权限管理(这个非常重要，不知道能不能管理到业务实体的每一个操作和数据行列可访问性?)、业务字典管理(这个没必要单提出来吧?运行参数的配置才是最重要的)。不过普元具备了日志、异常、定制任务。更难能可贵的是，普元还提出了Cache机制(这个在企业管理软件领域中其实挺难。它不像咱们的通常论坛网站，如天涯，也并发量大需要Cache，但是天涯也仅仅是看，而企业管理软件主要是频繁读写和业务计算处理，这怎么Cache，我也需要学习学习，过去一直主要依赖数据库设计和代码写法和功能设计来保证性能)。普元做JAVA，金富瑞就做.NET。

三大件继续拿上来：控件+工作流+报表。

但很可贵的是，金富瑞提出了虚拟组织这一说法。这个确实老遇到。还有就是权限管理，从菜单到数据到列到行到按钮，控制的挺细，不过细就是多，多就会漏洞多，看来金富瑞需要深刻去思考一下数据库架构的设计。

这些都是专注做平台的。

但是，那些主要做管理软件的公司，也有自己的平台。甚至自己的平台还卖。如浪潮楼上(不过山东人的朴实与粗糙，尽在软件中)。

自己用的平台，东软也有，但没有对外宣传，也不卖。偷偷自己用，做了N多医保、税务局之类的项目。(我曾经剖析的时候，发掘设计的思想和金蝶K3的平台特别相似)

用友、金蝶这两大企业管理软件公司当然也有自己的平台。用友有U8平台和NC平台，金蝶有K3和EAS平台。不过，明显的是，金蝶的平台架构思路比用友高一级。从业务实体自省到权限控制到日志到二次开发，金蝶颇有套路，思路清晰抽象高度。而用友的平台，似乎还看业务是业务，看菜单是菜单。

讲了这么多，几乎主流的平台厂商我都数了个遍，当然从事各细分行业管理软件的公司也都有自己的平台，只不过那类平台和本行业业务又结合的特别紧密，开发自己行业软件特别快速稳定易用，但不具有普遍意义。

我把我在上一篇文章中写的企业管理软件平台架构内容再贴到最后，以使大家好总览：

1登陆用户口令验证、license许可验证、盗版验证、过期失效验证、版本差异验证

2主控台 用户功能树 管理主控台

3表单设计器、业务实体设计器、工作流设计器、报表设计器、功能菜单设计器、多语言设计器、多皮肤设计器、查询过滤定制器

4UI框架：Grid/Toob bar/Tree/TabSheet/Menubar/参照录入组件

/Edit/Button/Combo之类

5单实体输入框架、主从List/Detail输入框架

6运行配置参数设置、单号计数器、业务预警设置

7异常框架、业务实体权限框架、业务实体存储引擎、业务实体查询引擎8报表：套打、单据报表、普通二维查询统计报表、交叉报表、图表9工作流引擎、消息引擎、自动任务引擎

14.软件架构师的工作职责 篇十四

1、协助公司总经理制定总的产品技术路线、技术队伍发展规划及相应资源布局，制定年度开发度量与产品技术框架; 2、制定技术体系规范和流程，制定技术标准，组织编写相关技术文档。

3、制定产品或系统的技术架构方案和实施路线。

4、组织完成产品或系统核心技术架构的开发。

5、协调和培训开发人员，辅助完成产品或系统开发。

任职要求：

1、8年以上IT行业技术研发类从业经验。3年以上技术管理岗位工作经验，3年以上技术架构经验;

2、精通.net c#或Java等高级开发语言与架构，有三个以上大型b/s架构项目设计开发经验。;

3、丰富的数据库设计经验，对设计模式、架构有较全面的了解和实践经验;

4、有完整的解决方案设计与编写能力，对行业技术发展能提出独立的意见与思路;

15.软件架构设计师岗位职责 篇十五

1 构建软件项目实训平台目的

为了提高实践教学质量，在现有的教学条件下充分利用校内实训基地现有资源，实现对软件技术专业人才培养与实际人才需求的对接，采用基于ASP.NET三层架构开发了软件项目实训平台，把IT企业的工程项目开发引入实训教学，使学生在校内提前熟悉企业工作流程，掌握了企业主流开发技术，积累实际的工作经验，实现从学生向员工角色的快速转变，提升学生的专业技能和职业素质。

2 ASP.NET三层架构

ASP.NET三层架构是从传统的C/S架构发展起来的，是严格意义上的分层即在客户端与数据库之间加入了一个“中间层”，也叫组件层。三层架构中应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互。ASP.NET三层架构如图1所示，三层架构是指表示层(UI)，业务逻辑层(BLL)和数据访问层(DAL)。

表示层(UI)：主要是指与用户的交互界面，负责接收用户的输入、将输出呈现给用户以及访问安全性验证，表示层用于用户接口的展示，以及用业务层的类和对象来“驱动”这些接口。在ASP.NET中，该层包括aspx页面、用户控制、服务器控制以及某些与安全相关的类和对象。

业务逻辑层(BLL)：是表示层与数据层之间的桥梁，负责系统领域业务的逻辑处理、逻辑性数据的生成、处理及转换。在ASP.NET中，业务逻辑层通常为类库。业务逻辑层在ASP.NET三层架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。

数据访问层(DAL)：负责与数据源的交互，即实现数据的插入、删除、修改以及从数据库中读出数据等操作。数据访问层访问的数据源有关系数据库、文本文件和XML文档，在ASP.NET中，数据访问层通常为类库。

各层之间调用不能任意相互调用，表示层不能直接调用数据访问层访问数据，只能通过业务逻辑层来调用数据访问层访问数据，数据访问层也不能直接调用表示层将数据传送给表示层，也必须通过业务逻辑层访问数据访问层的数据再过业务规则处理后传给表示层，各层之间的依赖关系为表示层依赖业务逻辑层，业务逻辑层依赖数据访问层，三层架构的优点是结构清析、安全性高、易于维护和扩展。

3 软件项目实训平台系统功能设计

通过对企业工程项目开发的工作流程进行调研，及对当前校内软件项目实训教学的现状分析研究，充分了解了用户的需求，设计了系统的功能模块由管理员功能模块、教师功能模块和学生功能模块三大功能模块构成。管理人员通过平台可以添加、删除和查看教师、学生和实训项目的信息;查看实训整体教学情况，学生学习及项目完成情况等。教师通过平台可对实训学生进行分组，发布开发计划，按阶段开放项目资料，查看审阅开发日报，各项目组会议纪要，查看各项目组完成情况，审阅项目代码。学生通过平台可了解项目团队成员情况，项目开发计划，各阶段需完成的任务，小组成员的任务完成情况，提交开发日报，提交项目会议纪要，学习各阶段老师分配的学习任务，提交测试结果，提交项目总结及实训调查。

4 软件项目实训平台系统设计

通过对软件项目实训平台系统的业务需求分析，采用ASP.NET三层架构来实现系统功能。软件项目实训平台系统三层架构如图2所示。在项目中建了MODEL、BLL、DAL三个类库和一个WEBUI网站。

MODEL(实体)类库是为方便数据传递添加的辅助类库，一个实体用一个类来封装，一个实体类也就是数据库中的一个表，如数据库中学生信息表(student)封装为实体类student，表中的每个字段都封装成公共属性。

数据访问层(DAL)主要为是BLL提供数据，根据BLL传入的值来对数据库作增、删、改操作。在.NET框架使用ADO.NET实现对数据库的访问，ADO.NET是一组向.NET程序员公开数据访问服务的类，是创建分布式数据共享应用程序的编程模型。数据访问层采用“面向对象接口编程”思想，以工厂模式的设计模式为主。抽象出来的数据库访问模块，脱离了与具体数据库的依赖，实现对数据的保存和读取操作。

业务逻辑层是系统的核心模块，主要处理系统的(下转第19页)核心业务。业务逻辑层负责处理用户在表示层输入的信息，或者是将这些信息发送给数据访问层进行保存，或者是调用数据访问层中的方法再次读出这些数据，进行业务逻辑处理后提供给表示层。对数据访问层的调用是通过接口来完成的。业务逻辑层作为中间层，在表示层和数据访问层之间起到了桥梁的作用。系统的业务规则处理在业务逻辑层中编码现实，业务逻层从表示层接收请求，转换为对数据访问层的请求，从数据访问层中获取数据或将数据发送到数据访问层，将处理结果传回表示层。

表示层(WEBUI)为用户提供交互的操作界面。表示层由WEB页面.aspx文件和隐藏代码.aspx.cs文件构成，可使用ASP.NET提供的控件和自定义控件来设计人机交互界面.aspx页面。用户在.aspx页面中输入的数据由隐藏代码.aspx.cs文件调用业务逻辑层实现业务规则处理。

5 结语

软件项目实训平台将企业的软件工程项目开发流程引入到教学中，将工作情境与专业专业知识有效结合，学生在训练实践技能的基础上，更进一步体会了完整的项目开发工作任务流程，利于学生就业及以后的发展。软件项目实训平台系统开发中采用基于ASP.NET的三层架构，适合团队开发，有利于分工协作，便于系统的维护和扩展。用户通过浏览器就可访问实训平台，使用方便，系统用户界面友好，适合高职院校计算机软件专业及相关专业进行实训使用。

摘要：高职教育的人才培养目标是培养适应生产、建设、管理、服务第一线的高等技术应用型专门人才,实践性教学环节是实现这一目标的重要保障。本文采用基于ASP.NET三层架构开发的软件项目实训平台,把IT企业开发软件工程项目引入实训,采用企业的运作方式管理实训,这将实现高职教育的人才培养与实际社会用人需求的无缝连接,提高教学质量。

关键词：实践性教学,ASP.NET,三层架构,软件项目,实训平台

参考文献

[1]MaroBellinaso.ASP.NETWeb站点高级编程[M].北京:清华大学出版社,2002.

[2]余文芳,张文博,廖非凡.基于ASP.NET三层开发架构应用探讨[J].软件导刊,2008.

[3]冉德君.校园网的实训项目开发及网络综合实训室建设探索[J].中国职业技术教育,2007.