程序架构

2024-08-26

程序架构（共8篇）

程序架构篇1

摘要：本文介绍了基于.net和FLASH技术的汽车销售系统的设计与开发。基于.net三层架构设计以及AJAX技术的融入, 以及基于XML的Flash动态显示技术的运用改善了传统的基于B/S架构的销售管理系统的不足。

关键词：.NET,AJAX,XML,Flash,B/S,C/S

1. 引言

传统的采用c/s架构的系统具有强大的数据操作和事物处理能力，以保证数据的完整性和安全性，但随着企业规模的日益扩大，应用程序的复杂程度不断提高，逐渐也暴露出一些问题，例如开发成本比较高、移植困难、界面风格不统一，维护复杂，信息内容和形式单一等。由于c/s架构的种种弊端，而且基于web的应用技术逐渐成熟，国内的企业级开发开始从基于c/s的架构向基于b/s的架构转型，基于web的企业级系统简单而且统一、易于维护。但最突出的问题就是用户操作界面不好，缺乏c/s架构的用户交互式体验，用户体验差。

本文以某汽车销售系统为背景，综合运用.net和flash技术，实现简单方便的运用B/S版页面对汽车产品进行管理和发布，发布后的产品以flash的方式展现出来，甚至企业可以利用带flash播放器的触摸屏来独立展示自己的产品。

2. 主要技术

2.1 AJAX技术

在开发手段上，为了使产品发布管理系统更为人性化，我们采用了基于.net的AJAX技术。

随着互联网的发展, 很多企业发布系统开始使用B/S模式, 但是B/S应用程序受制于HTML的限制，无法像C/S那样使用丰富的效果来展示数据，用户体验比较糟糕。随着Web应用程序复杂性越来越高，传统的Web应用程序已经渐渐不能满足使用者更高的、全方位的体验要求了，比如可输可选的下拉框，数据联动，页面等待等问题一直没有优雅的解决方案。任何与服务器的交互都要求刷新页面，这意味着这中间需要2到5秒的延时，还要刷新整个页面，在基于.net的web应用程序中引入A-JAX技术可以很好地解决这些问题。AJAX可以通过与服务器通过"fire and forget"的方式来与服务器交互:用户执行一个操作，系统可以在后台处理该任务，同时用户可以继续处理其他任务。UI只需要更新有新信息要显示的部分即可，而不用重画整个页面．如果一切顺利，AJAX风格的UI让用户实现并维护这种流程，从而提高用户满意度和生产力。

2.2 XML与FLASH

为了使产品展示系统更加人性和美观，我们使用了flash来表现我们的产品。而基于Flash的产品展示网站是目前最优秀的Web交互式网, XML语言是目前和将来最有前途的、在Internet上保存和传递信息的语言。基于XML的Flash动态显示系统就是结合它们的优点实现了对数据库的访问和数据的更新。

3. 系统设计与实现

3.1 系统部署

本销售系统部署为内三层外三层的结构，作为基于.net和AJAX技术的系统，整个B/S程序基于sql server2005数据库，程序采用三层架构，及数据操作层、业务规则层和表示层，使程序具有良好的可维护性，每层独立出来，使业务规则更加明晰。外三层，系统生成的XML供Flash调用，形成产品可以随时更新的销售系统。

通过该系统部署，可以实现B/S和C/S的融合，有B/S的程序配置系统（上面的部分）产生xml文件，flash去读这个xml文件产生不同效果的页面。目前大多flash也是根据固定xml来配置flash页面，但该系统中xml内容是动态的。

其具体部署图如下图所示：

3.2 功能模块

本产品销售系统分为八个功能模块，分别是公司信息管理、公司机构管理、公司产品大类管理、公司产品子类管理、公司产品详细信息管、公司成功案例管理、片头视频文件管理、关于我们视频文件管理。其中公司信息管理、公司机构管理和片头视频文件管理构成一个产品目录展示，当更新公司信息或机构信息时将触发生成一个Custom.xml的纯文本XML文件，该文件记录这三个模块的信息，而这个XML文件被FLASH所调用并展示产品目录。公司产品大类管理、公司产品子类管理和公司产品详细信息管理这三个模块构成一个产品详细介绍，当用户更新这个三个模块的时候将触发生成XML文件，不同的子类有不同XML文件，而这些XML文件名正是以子类的名称命名，既区分开不同子类之间的数据，让数据具有独立性，同时也使得FLASH更容易读取XML信息并展示详细信息。公司成功案例管理与关于我们视频文件管理这两个模块是独立的。其中，公司成功案例的数据将保存在Stories.xml文件中供FLASH读取并展示，而关于我们视频文件是通过上传功能将视频文件保存在硬盘上，FLASH通过视频存放的路径直接读取文件并播放该视频。如图3-2所示

4. 总结

本项目以产品销售系统为对象，通过引入AJAX技术，尝试开发人性化的产品销售和管理系统。系统实现了销售产品的管理（包括产品录入、修改、删除、）。为中小企业的信息化建设提供了一个更人性化的操作。本系统的创新之处在于，一方面实现了企业产品展示的各个操作的无缝链接，使产品发布的各个环节进一步的规范化和可视化。另一方面采用最新的web开发技术-AJAX进行产品管理，同时利用XML保存数据供前台FLASH读取，使得进一步提高客户浏览速度，从用户习惯角度设计软件系统，体现了新一代人性化软件的发展方向。

参考文献

[1] (美) 戈洛斯..NET 2.0模式开发实战.北京:人民邮电出版社, 2007

[2]徐晓蝗, 邹晨, 朱慧华.Web 2.0动态网站开发--ASP.NET技术与应用.北京:清华大学出版社, 2008

[3]SasJacobs著.XML基础教程:入门、DOM、Ajax与Flash.北京:人民邮电出版社, 2007

程序架构篇2

Android：从程序员到架构师之路

Android发展多年的今天，很多工程师都遇到职业发展瓶颈了，不知道如何向上走，因此麦可网携手台湾Android教父高焕堂老师推出了《Android架构师之路》这套国内唯一的课程，通过这套课程学习，学员们会学习高老师提出的EIT架构设计模式，能从普通Android工程师往Android架构设计师这个新的台阶攀登，同时更加熟悉Android本身体系结构设计，也可以换位以Android系统的设计师角度来思考问题。

由于Android是开源开放的平台，国内开发者不仅涉及App应用开发，也深入到底层软硬整合开发。

随着Android产业急速扩大，上下层模块日益增多，复杂性增高。无论是软硬件开发者都需要优越的架构思维、模式和方法，来支撑复杂的软硬整合、跨平台和自动化测试问题。

本课程解析移动应用开发的架构思维、模式和方法；并落实为Android的多层框架体系；所介绍的架构设计决策，都能落实为代码，为一个非常务实的课程。

随着这套课程的推出，麦可网已经有了高级应用，Framework，底层嵌入式，架构师之路等一系列互补系统的Android课程，全面覆盖纵横领域。毫无悬念的麦可网已经具备了国内最强大，系统，专业的Android课程体系。

这套课程的针对人群： Android开发已经有至少两年经验的IT工程师，多年开发经验想深入了解Android这个开源平台的资深工程师，Android项目团队的技术管理者。

我们不建议：不建议Android初学者学习这套课程；不建议没有项目经验者学习这套课程；不建议没有遇到瓶颈者学习这套课程。

程序架构篇3

Android智能手机平台是Google公司在2007年11月5日与33家手机厂商(包括摩托罗拉、三星、LG等)、手机芯片供货商、移动运营商建立的开放手机联盟OHA(Open Handset Alliance)发布的一个专为移动设备设计的软件平台。Android是一个针对移动设备的程序集,它包括操作系统、用户界面、中间件和应用程序,拥有移动电话工作所需的全部软件,同时其开放性保证该平台不存在任何阻碍移动产业创新的专有权障碍。Android是第一个完成、开放、免费的手机平台。

2 Android的架构及应用程序的组成

2.1 Android架构

Android平台的系统架构和其他系统一样,采用了分层的架构,从结构图1所示,Android分为4个层,从高层到底层分别是Android应用程序层、应用程序框架层、用户空间层(系统函数库和Android Runtime)和Linux内核层。

2.1.1 Android应用程序

Android会同一列核心应用程序包一起发布,该程序包客户端、SMS程序、日历、地图、浏览器、联系人管理程序等。所有的应用程序都是使用Java语言编写。

2.1.2 应用程序框架

开发人员可以完全访问核心应用程序所使用的API框架。该应用程序的架构设计简化了组件的重用,任何一个应用程序都可以发布它的功能块并且任何其他的应用程序都可以使用其所发布的功能块。同样,允许用户在相同的机器上方便地替换程序组件。

(1)隐藏在每个应用后面的是一系列的服务和系统,其中包括:

丰富而又可扩展的视图(Views),可以用来构建应用程序,它包括列表(Lists),网格(Grids),文本框(Text boxes),按钮(Buttons),甚至可嵌入的Web浏览器。

(2)内容提供器(Content Providers)使得应用程序可以访问另一个应用程序的数据(如联系人数据库),或者共享它们自己的数据。

(3)资源管理器(Resource Manager)提供非代码资源的访问,如本地字符串,图形,和布局文件(Layout files)。

(4)事件通知管理器(Notification Manager)使得所有的应用程序可以在状态栏中显示自定义的提示信息。

活动管理器(Activity Manager)用来管理应用程序生命周期并提供常用的导航功能。

2.1.3 用户空间

2.1.3.1系统函数库

Android包含一些C/C++库,这些库能被Android系统中不同的组件使用。它们通过Android应用程序框架为开发者提供服务。以下是一些核心库。

系统C库:一个从BSD继承来的标准C系统函数库,以BSD许可形式开源。

媒体库:基于Packet Video的Open CORE,该库支持多种常用的音频、视频格式回放和录制,同时支持静态图像文件格式包括:MPEG4、H.264、MP3、AA、AMR、JPG和PNG。

Surface(界面)管理:用于对显示子系统的管理,并且为多个应用程序提供了2D和3D图层的无缝融合。

Lib Web Core(核心库网):一个最新的Web浏览器引擎用,支持Android浏览器和一个可嵌入的Web视图。

SGL:隐藏的2D图形引擎。

3D库:基于Open GL ES 1.0 APIs实现的库,用于3D图形加速或提供高优化的3D软件光栅器。

自由类型:位图和向量模式的字体绘制。

SQLite:一个强大的轻量的关系型数据库引擎,用于所有的应用。

2.1.3.2 Android Runtime

Android包含一组核心库,为Java语言核心库内提供了大部分功能。所有的Android应用都运行在它自己的进程里,该进程是一个Dalvik虚拟机的实例,Dalvik被设计成能在一台设备上高效的运行多个虚拟机实例。Dalvik虚拟机的可执行文件被封装成Dalvik可执行格式(.dex)。这是被优化过的最小内存依赖的格式,Java编译器(dx工具)将注册了的和运行时用到的类编译成.dex格式。Dalvik虚拟机依赖于底层linux内核提供的功能,如线程机制和内存管理机制。

2.1.4 Linux内核

Android依赖Limix版本2.6提供的核心系统服务,如安全、内存管理、进程管理、网络堆栈、和驱动模型。内核另一个作用是为硬件和上层软件提供一个虚拟的中间层。Android的特点主要包括:应用程序框架、Dalvik虚拟机、集成的浏览器、优化过的图形机制、SQLite、媒体支持、GSM技术、蓝牙、EDGE、3G、WIFI、Camera、GPS以及丰富的开发环境。

2.2 Android应用程序的组成

对于一个Android应用程序来说,主要的4大组件分别为:活动(Activity)、服务(Service)、广播接收器(Broadcast Receiver)和内容提供商(Content Provider)。但不是必须的,有时需要组合来用。

2.2.1 活动(Activity)

Android中,Activity是所有程序的根本,所有程序的流程都运行在Activity之中,Activity可以算是开发者遇到的最频繁,也是Android中最基本的模块之一。在Android的程序中,Activity一般代表手机屏幕的一屏。如果把手机比作一个浏览器,那么Activity就相当于一个网页。在Activity中可以添加一些Button、Check box等控件。当一个新的屏幕打开后,前一个屏幕将会暂停,并保存在历史堆栈中。用户可以返回到历史堆栈中的前一个屏幕。当屏幕不再使用时,还可以从历史堆栈中删除。默认情况下,Android将会保留从主屏幕到每一个应用的运行屏幕。

2.2.2 服务(Service)

Service是Android系统中的一种组件,它跟Activity的级别差不多,只能后台运行,并且可以和其他组件进行交互。Service是没有界面的长生命周期的代码,Service是一种程序,它可以运行很长时间,但是它却没有用户界面。比如打开一个音乐播放器的程序,这个时候若想上网了,那么,打开Android浏览器,这个时候虽然已经进入了浏览器这个程序,但是,歌曲播放并没有停止,而是在后台继续一首接着一首地播放。其实这个播放就是由播放音乐的Service进行控制。当然这个播放音乐的Service也可以停止,例如,当播放列表里边的歌曲都结束,或者用户按下了停止音乐播放的快捷键等。Service可以在多场合的应用中使用,比如播放多媒体的时候用户启动了其他Activity这个时候程序要在后台继续播放,比如检测SD卡上文件的变化,再或者在后台记录地理信息位置的改变等等。

2.2.3 广播接收器(Broadcast Receiver)

在Android中,Broadcast是一种广泛运用的在应用程序之间传输信息的机制。而Broadcast Receiver是对发送出来的Broadcast进行过滤接受并响应的一类组件。可以使用Broadcast Receiver来让应用对一个外部的事件做出响应。例如,当电话呼入这个外部事件到来的时候,可以利用Broadcast Receiver进行处理;当下载一个程序成功完成的时候,仍然可以利用Broadcast Receiver进行处理。Broadcast Receiver不能生成UI,也就是说对于用户来说不是透明的,用户是看不到的。Broadcast Receiver通过Notification Manager来通知用户这些事情发生了。

2.2.4 内容提供商(Content Provider)

应用程序能够将它们的数据保存到文件中、SQL数据库中,甚至是任何有效的设备中。当你想将你的应用数据与其他的应用共享时,Content Provider将会很有用。一个Content Provider类实现了一组标准的方法,从而能够让其他的应用保存或读取此Content Provider处理的各种数据类型。

3 实现案例

依据Android平台的架构,结合实际进行名为My Message的短信息发送的程序步骤如下。

(1)创建新项目

在Eclipse下创建一个基于Android2.2版本的新项目My Message。

(2)修改用户界面

修改res/layout/main.xml文件的内容,从上到下分别增加文本域、一个用来输入号码的可编辑文本框、文本域、用来输入短信内容的可编辑文本框以及一个用来方法送短信的按钮框,来完成发送短消息的主界面。

(3)设置权限

在Android Manifest.xml中添加发送短信权限的声明,代码为.

(4)实现短信发送功能

修改主程序My Message.java,为发送短信按钮的单击事件增加处理方法,关键代码为

其中使用一个叫做send SMS的方法来实现短信的发送,关键代码为:

当用户按下“发送信息”键之后,用户界面会重新回到My Message的初始界面。

(5)运行结果

在Eclipse中运行程序,系统会启动一个Android模拟器,通过Windows的命令行再启动另外一个Android模拟器,这样两个模拟器就可以实现两个手机间的电话或者短信的功能。

4 结语

随着技术的飞速发展,智能手机成为越来越多人的首选,Android平台由于易用性和开放性,无论对于使用者还是对于研发人员来说都能够给予更大的自由空间。

摘要：Android本义是指“机器人”,是Google公司发布的智能手机平台,凭借良好的可移植性与开放性,迅速成为比较流行的移动终端操作系统。

关键词：Android平台,架构,应用程序

参考文献

[1]朱婷婷,李惠.基于Android的应用软件的综述[J].电脑与电信,2011,(01):42-43.

[2]叶炳发.Android操作系统移植及关键技术研究[D].广州:暨南大学,2010:5-10.

程序架构篇4

随着时代发展和社会进步,各类委托人对独立审计结果的要求越来越严格,对审计报告的需求也日趋“多元化”,使独立审计处境十分艰难,风险也越来越大。审计报告是审计最终成果的反映,同时也是审计风险的最终储备库。但国际国内审计相关准则系统却“格式化”了这类重要风险变量因素,仅认定会计报表重大错报风险和检查风险两个变量指标。这虽明确了注册会计师(以下简称CPA)识别风险的主攻方向,但却无助于中国CPA开展风险导向审计,也妨碍了中国CPA全面风险意识的提高和强化。为此,必须立足CPA执业实践,全面分析审计风险体系,研究风险要素指标更加健全的审计风险模型。

一、审计风险模型及意义

随着现代风险导向审计的全面推行,财政部于2010年11月1日以“财会[2010]21号”发布了《中国注册会计师审计准则(CSA)第1101号——注册会计师的总体目标和审计基本要求》等38项审计准则,规定从2012年开始实施。CSA第1101号第13条规定:“审计风险,是指当财务报表存在重大错报时,注册会计师发表不恰当审计意见的可能性。审计风险取决于重大错报风险和检查风险。”表明新修订的CSA完全认同国际审计和保证准则委员会(IAASB)规定并从2004年12月15日起实施的新审计模型:

审计风险=财务报表重大错报风险×检查风险

该模型系依照审计重要性原则架构而成,因此可称之为“重要性审计风险模型”。式中,重大错报风险和检查风险均同审计风险正相关。但同作为自变量的重大错报风险与检查风险之间,则在既定的审计风险水平下,可接受的检查风险水平与认定层次重大错报风险的评估结果成反向关系:评估的重大错报风险越高,可接受的检查风险就越低;评估的重大错报风险越低,可接受的检查风险就越高。

审计准则强调了重大错报风险是财务报表在审计前存在重大错报的可能性。可见,重大错报风险是由于被审计单位控制环境(管理层诚信缺失、治理层监管虚弱)或其他因素(经济萧条、行业寿命周期短等)影响而发生的“会计风险”。但是,如CPA没有预先评估和识别报表错报风险,采取审计程序就难免盲目,而且会违背审计的重要性原则,从而增加检查风险。所以,将财务报表重大错报风险设为审计风险变量,表面看并不符合审计风险内涵逻辑,但实质是指导CPA不能仅注重“查账”技能训练以防范技术性的检查风险,还须将风险导向前移到被审计单位的经营风险影响层次,注重对审计对象的财务环境评估,让审计任务和范围逆向拓展到会计报表形成的内部控制背景、治理结构、管理责任、账户余额真实性、会计核算资产处理方法正确性、报表内容完整性等,采取恰当的审计程序进行有针对性的测试和评估,确保做到有备无患,检查有的放矢。

二、审计风险类型体系

审计风险伴随审计全过程,可谓无时无处不客观存在。因此,其种类繁杂,形式多样。为便于开展理论研究和便于实践中识别,应根据审计风险存在的不同标准进行划分。

1.按审计风险源泉,分为外源性风险和内源性风险

外源性风险即源自审计之外的风险,应涵盖源自被审方面的财务报表重大错报风险、行政干预风险、审计报告使用风险等。其中,行政干预风险属于不可控风险,审计注意运用规避手段防范;而重大错报风险和审计报告使用风险,均具有可控性。因为它是一种可以预见的客观实在,只要承认了经济事实的合理性,就意味着接受了该种风险。CPA应特别注重重大错报风险,应认真遵循CSA1211号一—通过了解被审计单位及其环境识别和评估重大错报风险,评估财务报表层次和认定层次的重大错报风险,并根据既定的审计风险水平和评估的认定层次重大错报风险,确定可接受的检查风险水平。

内源性风险是审计过程中因工作疏忽和检查程序、测试方法失当而承担不良后果的可能性。通常包括审计签约风险、检查风险、报告风险等。内部风险均属可控风险,审计应加强自身文化修养和执业涵养,不断提升职业评断能力和查账技术水平,增强审计服务意识和责任思想,防微杜渐。

2.按审计风险存在形态,可分为固有风险、控制风险和检查风险等三种,或综合为财务报表重大错报风险和检查风险两种

固有风险是指假定不存在相关内部控制时,某一账户或交易类别单独或连同其他账户或交易类别产生重大错报或漏报的可能性;控制风险是指某一账户或交易类别单独或连同账户或交易类别产生错报或漏报,而未能被内部控制防止、发现或纠正的可能性;检查风险是指某一账户或交易类别单独或连同账户或交易类别产生错报或漏报,而未能被实质性程序发现的可能性。前两种风险也可合并称为被审计单位的财务报表重大错报风险,这也是国际国内审计准则确立审计风险模型的理论依据。

3.按审计风险管理,分为可控风险和不可控风险

可控风险是指由审计机构或审计人员可控制的因素导致的审计风险。例如,由于审计人员的素质、审计人员工作态度、审计方法选用、审计机构对审计工作的管理等因素导致的审计风险;不可控风险是指由审计机构或审计人员不能直接加以控制的不确定性因素所引发的审计风险,包括被审计单位内外两种因素,外部因素如国家经济形势的变化,内部因素如被审计单位内部控制健全程度等。

4.按风险对审计程序的依赖,可分为审计准备阶段风险、实施阶段风险和终结阶段风险

审计风险贯穿于准备、实施、终结等各个审计程序环节。基于风险导向审计,审前准备阶段隐含的风险主要是审计业务约定书订立风险即“签约风险”和财务报表重大错报风险,其中签约风险指因审计谈判忽略意外不确定事项而发生无法按时保质完成审计任务或发生审计纠纷的可能性;实施阶段风险即检查风险;审计终结阶段风险包括审计报告类型选择、撰写、复核和使用四环节的风险。

此外,还可按审计风险表现形式,分为显性审计风险和隐性审计风险;按风险承担主体,可分为审计组织风险和审计人员风险;按风险成因,分为主观风险和客观风险;按风险后果,分为法律风险、行政风险、财产风险等。

总之,审计风险不仅局限于国际国内准则规定的财务报表重大错报风险和检查风险两种。

三、基于审计风险体系的审计风险模型架构

(一)健全性审计风险模型体系结构

设计健全性审计风险模型,既要遵守审计理论要求,又要符合国际国内审计准则,更要考虑本国审计实践的客观需要。

1. 审计签约风险

签约风险是审计的基础风险,是指事务所及授权CPA在签订业务约定书过程中,因关键要约含混不清或有疏漏而履行后产生责任危害的可能性。比如CPA未能认真填写委托目标、范围、报告类型及用途限定等关键条款,就可能潜存风险。同时,在功利时代,企业违背商业规则司空见惯,讨价还价、斤斤计较同样存在于审计市场。失衡的价格必然影响到审计效率和质量,也会埋下风险隐患。但不论怎样,合同风险都属于可控风险。CPA应依据个人专业素质和风险驾驭能力等因素,设定风险度的强弱。

2. 财务报表重大错报风险

财务报表重大错报风险,具体包括环境风险、战略经营风险、财务风险、治理结构风险、内部控制风险和会计错弊风险等。需说明,上述各风险虽有不可分割的内部联系,但都在各自领域内保持相对独立,其对财务报表重大错报风险形成,并不能产生严格意义上的乘积因子关系,而是简单的叠加关系。本文主张将财务报表重大错报风险评估置于审计约定书签订之前,作为评估审计风险的基础和判定审计师是否接受审计任务的客观依据。但CSA1211号更关注审计师的行为责任风险危害,因此第7条将注册会计师审计目标定位于通过了解被审计单位及其环境,识别和评估财务报表层次和认定层次的重大错报风险(无论该错报由于舞弊或错误导致)。在CSA1231号第4条进一步强调CPA的目标是针对评估的重大错报风险,通过设计和实施恰当的应对措施,获取充分、适当的审计证据。并针对评估的认定层次重大错报风险,考虑形成某类交易、账户余额和披露的认定层次重大错报风险评估结果的依据以及评估风险程度对证据的要求,设计和实施进一步审计程序。显然,从审计理论看,重大错报风险识别是在审计约定书签订之后。换言之,审计准则对独立法人事务所在行权中存在的签约风险要求其自觉控制,CPA可不予考虑。

3. 审计检查风险

是指审计报表存在重大错报、漏报而CPA未予发现的可能性。如CPA履行程序不慎或遗漏必要的调查测试环节而造成证据采集不足,或报表审计方法运用不当抑或检查粗枝大叶而不能发现会计报表存在的错误和舞弊,等于间接地掩盖了事实,助推报表对外错报或漏报,造成阅误读误判甚至错误决策。所以,检查风险堪称为审计的“内源性风险”或称之为“实质性风险”,应由执行程序风险、测试方法风险、证据效力风险和职业道德风险四个要素构成,各种相互联系的风险因素叠加为检查风险。用公式表示为:

检查风险=职业道德风险+执行程序风险+测试方法风险+证据效力风险

其中职业道德风险是指因执业审计师玩忽职守或为谋取私利导致事实真相被隐瞒,或故意出具虚假审计报告导致相关责任后果的可能性。职业道德是独立审计的质量基石,也是独立审计风险的第一道防线。如CPA忽略职业道德修养,将背弃审计工作守则和准则要求,玩忽职守,至审计生命于不顾地谋取局部或个人私利,从而瓦解个人业务技术和工作能力。此项风险应由CPA事务所综合考虑承担审计任务人员的具体情况设定;程序风险是由于采取了与检查重大错报、漏报不相适应的程序或程序追加取舍程序不当的可能性,是检查风险中影响力较弱的因素;测试风险又可称为“技术风险”、“方法风险”和“能力风险”等,是CPA实施审计测试中抽样等技术方法选择失当、缺少必要的专业性判断或判断偏误等的可能性。它对检查风险具有显著的直接影响,并且将延伸到证据风险;证据风险是最为关键要素,指实施审计过程中未获得有价值证据、取证量不足或没有经过认真分析和缜密筛选而综合成严密证据链的可能性。这三种风险类型均决定于审计过程中的技术性把握和执业能力控制,因此又可将之统称为“技术能力控制风险”。这样,审计检查风险公式即演变为:

检查风险=技术能力控制风险+职业道德风险

4. 审计报告风险

特指CPA审计报告出具时发表了不当审计意见和对审计报告使用失察,导致委托人误判事实、产生使用纠纷等并被追究相关责任的可能性。审计报告既承载着撰写过程中发表审计意见风险、措辞不当风险,又汇集了审计事项约定不慎风险、完善审计程序风险、补充审计证据风险,还要牵连到审计报告使用跟踪监测风险等。审计报告风险具有“多元性”:一是审计报告类型选择风险。如应出具有保留意见的审计报告,而CPA却选择出具了无保留意见的审计报告。虽然该风险属于小概率事件,但也客观存在且不容忽视;二是审计报告撰写风险。因执笔人文化修养和写作能力局限而列举问题与描述事实不清、审计依据运用欠妥、审计评价措辞或语法错误、行文不规范等,造成委托人误读误用产生不良审计责任和后果的可能性;三是审计报告质量复核风险。审计报告汇集了所有的“审计过程风险”,即其固有着审前“合同风险”和审中“检查风险”,如事务所未对审计评价内容、措辞等实施专门复核程序,就会使问题遗留并形成“质量复核风险”;四是审计报告使用风险。当委托人超范围使用或不慎使用审计报告,而事务所没有执行跟踪回访和后续服务监控而引发危害的可能性。这四种风险因素叠加,即形成审计报告风险:

审计报告风险=选择风险+撰写风险+质量复核风险+使用风险

综上,审计风险除了审计准则规定的财务报表重大错风险和检查风险之外,还客观地存在着一系列的审计签约风险和审计报告风险。只是从审计理论角度分析,这些风险是事务所固有的“经营风险”,归于审计事务所的管理控制范畴,不在审计行为规范之列;同时,这类风险通常不具有较大的直接危害性,是依靠民间审计组织和审计师自觉把握控制基本可以消除的风险弱项。所以,审计准则对审计风险模型设计上通常是不予考虑或可以忽略不计的。

(二)以审计准则为基础的系统性审计风险模型架构

如前所述,事务所在审前谈判协商的核心关注点绝非合理收费问题,而是了解被审计单位经营政策、管理控制和财务状况等,以识别和评估审计签约风险和财务报表重大错报风险;进而,针对委派CPA执业能力、专业水平、职业道德、执行程序、实质性程序手段与方法、证据证明力等要素,全面系统地识别检查风险;最后,需针对审计报告的类型选择、撰写能力、复核措施、使用跟踪回访等因素,识别审计报告风险。审计前期的签约风险和重大错报风险将直接辐射给审计检查风险,并形成对审计道德、审计程序、审计测试和审计证据等四种检查风险的强烈干扰;而检查风险将直接传导到审计报告并影响其类型选择和评价方向以及使用反应,即检查风险越高,审计报告风险相应越大;反之亦然。由此可见,审计签约风险和审计报告风险,属于同重大错报风险和检查风险具有直接相关性的两个自变量因素,它们的相互独立又彼此紧密联系,共同构成了审计风险因变量,公式表示为:

审计风险=审计签约风险×财务报表重大错报风险×检查风险×审计报告风险

该模型保留了审计准则模型即“重要性审计风险模型”的风险要素及全部内涵特征,并完善了相关的风险变量,使审计风险因素更加全面、系统,故此称为“系统性审计风险模型”。模型公式中,审计签约风险同财务报表重大错报风险存在着非线性函数关系,二者具有交叉存在的相容性,在审计业务约定书签订之前的调查谈判阶段,审计就需要对被审计单位经营风险和财务环境等进行了解测试,这其中一个重要方面就涉及到重大错报风险识别,测试的签约风险越高,说明重大错报风险也越大;反之亦然。同样,审计报告风险与审计检查风险之间也存在着非线性关系,二者存在不确定性的交互影响:检查风险对报告风险具有正向传递性影响,即检查风险越高,审计报告风险越大;审计报告风险越高,检查风险会因其反向辐射而趋于扩大。

(三)健全性审计风险模型的应用

1. 正确认识结构审计风险模型的全面风险体系链路

CPA主要是对授权委托方承担对被审计单位审计的风险责任。随着审计业务约定书签订,CPA即进入审计程序(准备、实施、终结)。由于审计风险无时无处不在,并沿着审计程序各个节点依次单向递延和逐步传递,形成了可以支撑健全性审计风险模型的审计风险体系链,并最终汇集成单项审计的“风险库”,记入审计风险档案。如图1所示。

CPA应全面掌握审计风险要素结构体系,时刻注意风险导向,认真思索审计风险信息传递路径,坚持职业怀疑态度,培养敏感的执业风险嗅觉,用“全面风险观”理念指导审计工作,养成风险识别环节前移(出表单位内控和经营)和后延(委托单位使用审计报告),扩大审计风险识别范围。

2. 灵活运用健全性审计风险模型

在具体审计任务中,并非链路图中的每个风险要素都会出现,即使同时出现也不可能都产生严重审计危害。为此,要求CPA在全面梳理风险导向思想前提下,要善于对识别的各项风险按其风险评估值做取大舍小、避轻就重的甄选,以避免模型运用僵化,测度风险指标过细过杂而影响审计工作效率和信心。比如,公司董事局委托开展应收款账龄审计,签约风险和报告风险均属于可以忽略不计的轻度风险。此时,沿用审计准则规定的重要性审计风险模型就足以保证风险评估需要;再如,许多中小事务所业务范围局限于验资、鉴定、内控、咨询和代理等,从不接受会计报表审计业务。这样,两种审计风险模型都对之无用。

3. 加强审计风险模型应用培训

中国CPA由“官方机构”——财政部下设的中注协(CICPA)按“高考”教育模式进行认证和管理。考试环节注重专业知识(理论知识和应用技能知识),所以中国CPA大都靠拼记忆力和理解力考取资格;执业资格获取环节依然是参加CPA全国统成绩考试及格并执业审计二年以上,即可由省级注协注册批准。于是,出现在校大学生、失业会计纷纷考证和事务所“挂证”保执业阅历等乱象。这批CPA进入审计队伍开展风险导向审计难度极大。所以,应全面开展专题培训,强化审计合伙人和CPA队伍的审计风险意识,指导其按采用风险导向审计方法执业。重点辅导CPA深刻认识、正确理解和科学应用审计风险模型,并让其知道审计风险模型作为审计工作指南,绝非强制使用,也不是所有审计业务都“一刀切”地运用,而是要因事、因人制宜,区别对待。如承担上市公司报表审计,务须进行审计风险识别评估,对非上市公司报表审计则尽量开展风险识别评估;同时,根据委托审计范围和目的,确定风险分布环节、概率和程度并依次识别风险因素种类和评估风险度,据以选择审计风险模型种类和应用操作方式等。

四、结论

程序架构篇5

关键词：三层架构,VS2005

引言

在目前的软件架构设计中, 出现了许多不同的设计思想, 这些设计思想都有着自己的鲜明的特点, 可能在解决某一类问题会有较大优势, 但要谈到谁是最常用最通用的设计思想非“分层”莫属, 而“分层”中最经典的又非“三层”莫属。

三层架构是一种软件架构, 三层架构示意图如图1。从理论上说它并不依赖于某一种开发环境, 但作为软件业领头羊的微软公司推荐的软件架构, 从某种意义上说已成为一种标准, 而且这一标准在其集成开发环境VS2005中得到了最好的支持。对于刚入门的软件开发者来说, 使用VS2005搭建三层架构应用程序成为了最好的选择, 本文以一个基于ASP.NET的三层架构Web应用程序为背景简述了整个搭建过程, 供读者参考。

1. 业务实体库的实现

业务实体库由业务实体类组成, 实体类是描述应用程序实现的业务所涉及实体的类, 即将数据表中的每一个字段定义为属性并使用类封装。具体实现步骤如下。

(1) 新建业务实体库类库项目。打开VS2005, 新建一个类库项目。

(2) 在“新建项目”窗口中定义项目名称和解决方案名称。类库的名称即默认的程序集文件名, 解决方案名称可以考虑使用应用程序的名称或公司名称。

(3) 添加实体类的类文件。

(4) 修改程序集名称和默认命名空间。程序集名称即类库项目编译后生成的Dll文件的文件名。默认命名空间在定义时需考虑整个应用程序的一致性和可用性, 通常来说, 整个应用程序都是在同一命名空间中, 为了区分命名空间中不同元素的作用, 可以通过添加子命名空间的方式实现, 如“Corp.Model”, “Corp”为公司名称, “Model”代表子命名空间主要包含业务实体类。

(5) 版本控制。单击项目属性页中的“程序集信息”, 设置程序集版本和文件版本。通过设置版本信息, 可以实现应用程序开发中的版本控制, 从而保证应用程序正确更新和避免版本冲突而产生的各种问题。

(6) 编译项目。右击项目名称, 选择“生成”, 系统自动将数据访问层类库编译为Dll文件。

值得一提的是, 编写实体类实际上是一种缺少技术性的重复劳动。现在可以找到很多自动生成工具来生成实体类, 我们可以通过这种方法获取实体类文件并将其导入项目中, 这样既提高了工作效率, 又可以避免手工编写过程中可能出现输入错误。

2. 数据访问层的实现

数据访问层的功能主要是负责访问业务数据, 这些业务可能存放在各种数据库中, 也可能存放在如XML等文本文件中。具体地说, 就是实现对业务数据的查询、添加、删除、修改等操作。下面介绍建立数据访问层的具体步骤。

(1) 新建数据访问层类库项目。在业务实体库项目的资源管理器窗口中, 右击解决方案名称, 选择“添加—新建项目”。

(2) 在“新建项目”窗口中定义项目名称。需要注意的是, 由于在上一步骤中使用直接在解决方案中添加的方法新建数据访问层类库, 这里不要修改项目位置。添加后的项目将与业务实体库项目包含在同一解决方案中, 并同时显示在资源管理器窗口中, 方便文件管理和开发过程中不同项目之间的切换。

(3) 添加引用。右击数据访问层类库项目名称, 选择“添加引用”, 在打开“添加引用”窗口中选择“项目”选项卡, 在项目列表中选择业务实体库类库项目并确定。在三层架构设计中, 不同层次之间传递数据的主要是业务对象, 也就是业务实体类经过实例化后产生的对象, 在项目中使用业务实体类需要通过添加引用的方法引用业务实体库类库项目。

(4) 建立数据访问类的类文件。数据访问层类往往与数据表有一一对应关系, 在命名类时可以考虑以“Dal_表名”为格式, 如“Dal_Users”, 以示该类为数据访问类并对应于Users数据表, 便于今后对数据访问类的调用。

(5) 修改程序集名称和默认命名空间。

(6) 版本控制。

(7) 项目编译。

在每个数据访问类中会使用大量相类似操作, 比如执行SQL语句获取查询结果并将数据以Data Table类型返回, 可以将这些操作作为成员方法封装在一个数据访问辅助类中。关于数据访问辅助类现在也有很多第三方开发的程序, 也可以直接将其集成在应用程序中使用。

3. 业务逻辑层的实现

业务逻辑层的功能主要是负责实现业务规则、业务流程等与业务需求相关的设计。在分层架构设计思想中, 下一层对上一层是“无知”的, 而上一层依赖于下一层, 业务逻辑层依赖于数据访问层。

业务逻辑层的实现步骤与数据访问层大致相同, 有所区别的是, 在添加引用, 需要添加业务实体库类库项目和数据访问层类库项目。

4. 表示层的实现

表示层主要负责实现人机对话界面。在Web应用程序中, 表示层主要指的是Web页面。表示层的实现步骤同样可以参考数据访问层, 但需要注意两点, 第一, 在新建表示层的项目时需选择“ASP.NET Web应用程序”模板;第二, 添加引用时需添加业务实体库、数据访问层和业务逻辑层三个类库项目。

5. 结束语

三层架构已经在软件开发领域中被广泛应用了很长一段时间, 但在相关文字中往往更多集中在对分层思想理论上的讨论, 很少涉及具体地, 对学习者实际操作上有帮助的内容, 本文简述了在VS2005开发环境中搭建基本三层架构应用程序的主要步骤, 希望能够起到“入门”的作用, 从而进一步学习领会工厂设计模式、MVC设计模式等更加复杂同时也更加先进的软件开发思想。

参考文献

[1]Dino EspositoAndrea, Saltarello.NET软件架构之美 (英文影印版) .北京.人民邮电出版社.2009

程序架构篇6

ASP.NET是微软公司为满足网络化需求而推出的.NET开发平台,是一种Web环境中的应用程序开发技术,应用十分广泛。由于在ASP.NET技术中采用了更加合理的开发设计模型,使得Web环境中的应用程序解决方案的结构更合理,更便于维护。这里在对ASP.NET技术和相关特点进行介绍后,对面向Web用户程序开发的三层设计模型进行重点分析,并以工程实例的方式对此类设计模型的实现过程进行说明。

2 ASP.NET技术优点分析

ASP技术,即Active Server Page,是ASP.NET技术广泛应用之前,在Web应用程序开发领域中的一种主流开发技术。利用ASP技术,能够非常容易地将VB-Script语言所编写的网络服务器脚本嵌入到Web页面中,然后在服务器端对相应的页面内容进行动态生成;此外,还能够通过多种类型的COM组件实现与数据库的连接,进而为用户提供更加强大的事务处理功能。正是由于这些特性,才使得ASP技术在Web程序开发中得到广泛应用。

SP.NET技术是一种基于微软.NET平台的Web环境应用程序开发技术。该技术主要以CLR为基础,能够对.NET Framework环境中所提供的所有功能进行调用。基于ASP.NET所开发的Web程序,能够为异常控制、类型安全、功能继承与动态编译等提供全面支持。同时,在ASP.NET程序中,还能够为多种不同面向对象编程的强类型语言提供支持,实现对网络中各种复杂控制逻辑的编写,如Visual C#、Visual Basic.NET等。主流ASP.NET技术主要为Web Form编程模型,可以实现从底层系统自动向客户、服务器层之间的交互;同时,还为用户提供了完善的系统状态管理功能,使得系统能够在不同的页面请求之间,对页面数据进行维护。开发人员大基于页面的应用程序开发中,还能够使用多种服务器控件。

3 基于分层理念的Web应用程序设计

3.1 分层的概念

分层模型已经成为工程开发领域中的优秀的设计思路。在Internet中广泛采用的TCP/IP协议,就是一种典型的分层设计模型。在互联网发展过程中,TCP/IP协议所起到的作用至关重要。TCP/IP协议体系能够在互联网领域中获得成功,主要利益于其中所采用的分层模型,这也就决定了现有的网络协议中都普遍采用这种分层理念的设计思路。

3.2 应于用Web环境的应用程序三层模型

作为一种分布式的应用程序,Web程序中功能的实现主要由服务器端的Web服务器与客户端的浏览器互相配合才能实现。这种程序的实现结构又可以称为B/S结构。B/S结构中的大部分功能与逻辑主要在服务器端来实现。

参考前面所介绍的Web应用程序与Asp.NET技术中的优点,人们在实际的工作中逐渐找到一种基于ASP.NET技术体系的三层Web应用程序开发设计模型。在这种三层设计模型中,可以将Web应用程序划分为三个功能完善的基本层次,即:用户界面层、业务逻辑层以及数据访问层。具体如下:

1)用户界面层

用户界面层即User Interface Tier,主要用于对客户浏览器中的用户界面显示进行实现。在用户界面中,可以选择和采用适当的形式对业务逻辑层所传送的数据信息进行可视化显示。在此过程中,主要通过HTML标记与CSS模式来实现。同时,用户界面层还负责获取用户通过界面所输入的数据,在对相关数据进行有效性校验的基础上,将用户录入的数据传送给业务逻辑层。

2)业务逻辑层

业务逻辑层即Business Logic Tier,该层在整个模型中主要作为中间层来使用,是整个分层模型中的最重要层。该层的主要作用就是为用户界面层提供功能调用支持,同时,还能够利用数据访问层所提供的功能,对系统数据库进行访问。在具体的应用中,该层需要根据整个系统的功能和性能设计,对工程实现中的关键对象进行构造,实现工程中的大部分逻辑控制与功能。

3)数据访问层

数据访问层即Data Access Tier,通常作为整个分层体系的最底层来使用。该层的主要功能和作用是实现与系统数据库的交互,也就是对数据库中的数据和信息进行查询、插入、删除操作。通过数据访问层,能够为整个体系中的业务逻辑层提供服务,并根据业务逻辑层的具体需求,从相应的数据库中提取数据信息,或者对数据库中的数据进行修改。相关数据表明数据访问层优化,可以有效提高整个系统的性能与可靠性。

4 工程实例分析

本节中所介绍的工程实例,是一个企业的信息集成管理系统,所包含的功能相对简单,主要有:公文传送、文件审批、物品管理以及电子论坛等。该信息管理系统作为企业所投资研发的Web应用程序,可以为所有的授权企业员工提供网络接入功能,并根据各自的权限来完成相应的工作内容。该系统所软件设计结构就是上述的三层模型。接下来,主要针对该系统在实现与开发过程中的电子论坛进行介绍。

众所周知,电子论坛主要是为企业员工提供一个信息化平台,利用该平台可以发表观点、咨询问题与讨论热点,并能够为用户提供文章发表、观点回复等功能。在该工程的开发与实现过程中,所采用的开发工具为微软公司所推出的Visual Studio.net,利用Visual C#为系统提供逻辑编码。在Visual Studio.net平台中,整个工程主要作为一个Solution来处理;相应地,在分层模型中每个层,则与项目所对应;所有的项目都包含在方案中。所有的项目,都有开发平台为其提供的命名空间,这样做的目的不仅能够为不同代码之间的调用提供便利,还能够有效避免重复命名与冲突。具体而言,在本工程中,所包含的项目主要有四个,其中,Web项目、Bussiness Facade项目和Data Access项目分别与设计模式中的层次相对应。此外,则还包含Common项目,主要用于对不同层之间的数据接口进行定义。下面对这四个不同的项目进行介绍。

4.1 Web项目

Web项目与用户界面层是对应关系,可以将项目类型设定为“ASP.net Web Application”。在该层中还包括了二十多个Web Form页面,所有的Web Form页面的显示部分都能够存入到aspx文件中,而对应的控制代码则被存放到aspx.cs文件中。对于每个Web Form页面而言,都能够与页面中的类相对应,所有的对应类则由System.Web.UI.Page派生出来,这样,在这些类中,就能够对每个页面中所使用的Server Controls及其对应的逻辑控制进行准确定义。同时,在该层中,还能够使用Business Facade项目中所提供的多种功能,只要在每个页面中将Business Facade项目所对应的名称空间引入进来即可。

4.2 BusinessFacade项目

对于Business Facade项目,主要与三层结构中的“业务逻辑层”相对应,可以将该项目类型选择为“Class Library”。在该层中,所定义的类数量较多,这些类与系统中的四大功能相对应。对于这些定义的类,其中的成员函数能够根据用户界面层的具体需要来进行定义。需要补充的是,在该中可以通过引入Data Access项目的名称空间,并利用其中所提供的功能对系统数据库进行访问。

4.3 Data Access项目

对于Data Access项目,主要与三层结构中的“数据访问层”相对应,在实现的过程中可以将项目类型定义为“Class Library”。同样,在该层中,也包含了四个不同的类,每个类中的成员函数都能够响应业务逻辑层的需求,对SQL Server中所提供的“存储过程”进行访问。对于所定义的四个类,都包括了System.Data.Sql Client.Sql Data Adapter类型所定义的私有成员变量。这是,Sql Data Adapter主要由.NET平台所提供,可以实现在SQL Server数据库与Data Set类所创建对象之间的数据交互。其中,作为ADO.NET构架中的关键类,Data Set类中包含了多种Data Table,这些Data Table能够用于存储和数据库进行交互时的相关数据。

4.4 Common项目

在不同的层结构之间,为了能够实现数据的交互与传递,就必须在各层之间建立起统一的数据接口。所以,在软件开发过程上,为了能够实现该功能,在三个层次所对应的项目以外,还设计和开发了Common项目,可以将该项目的类型设置为“Class Library”。对于上述项目Web、Business Facade与Data Access等项目中所定义的类,其成员函数所采用的参数与返回值类型,则能够采用Common项目中所定义的类,这些类能够为不同层之间的数据传送提供更加标准的接口。

5 结论

从软件工程的角度来看,采用基于三层结构的设计模型,能够在软件工程的设计、开发、测试与维护的不同阶段起到重要的作用,同时,ASP.NET技术体系所具有的优秀特点,也对于优化工程结构至关重要。所以,ASP.NET平台中的Web应用程序三层设计模型,也就成为整个软件能够成功研发的基础。

参考文献

[1]高扬.基于.NET平台的三层架构软件框架的设计与实现[J].计算机技术与发展,2011,21(2):77-80.

[2]张军伟.基于三层框架的C#ASP.NET程序设计[J].电脑编程技巧与维护,2010(9):28-30.

[3]包芳.C#项目开发使用教程[M].北京:清华大学出版社,2013:119-121.

程序架构篇7

软件安装程序是应用程序的发布软件,可以说是每个商业化的软件都必须具备的安装工具,以便于用户将该软件部署到自己的设备上。因此,设计安装程序已经成为软件开发过程中必不可少的一个重要环节。

创建安装程序的方法之一是采用系统软件自带的打包工具。其主要优点是使用简捷;缺点是可以定制的功能太少,不能对安装过程进行更多地控制,难以实现对系统的一些较为复杂的配置,此外界面也比较单调。为此,提出了一种基于C#的通用软件安装程序的架构,在该架构的基础上,可以非常容易地实现功能扩展和代码维护。

1通用架构的设计与实现

1.1主体架构

软件架构的设计需要综合考虑各模块之间的耦合度。当模块之间具有较低的耦合度时,会增强软件的可维护性以及可扩展性,反之则会增加软件的复杂度,造成软件难以维护和难以进行功能扩展。对于安装程序,需要考虑的功能包括多界面的切换问题、界面间数据共享问题以及每个界面执行的操作等。图1给出的是一个安装程序的简要架构。

由图1可以看出,对于每个页面,都会有一个保存指向下一个页面名称及指向上一个页面名称的页面连接属性,从而使得主窗体可以通过接口非常方便的进行页面切换,同时也便于以后的扩展和维护。

1.2窗体设计

主窗体的显示区域可采用VS.NET工具箱中提供的Panel控件,通过该控件的Controls属性的Add()方法,可以非常方便地将需要显示的页面放入其中。对于控制区域,可根据所需的不同效果选择相应的控件,例如采用Button控件实现一般的按钮效果,或者采用PictureBox控件实现绚丽的动态变换效果等。

最简单的安装程序可由欢迎页面、选项页面和安装过程页面组成。每个页面都是一个控件,并且实现了统一的接口,从而可通过主窗体上放置的Panel控件这一容器实现不同页面的切换和页面之间的数据共享。

1.3接口设计

接口的设计主要是为了在主窗体中实现多态的切换各个页面,可以在很大程度上实现每个页面控件的完整封装。因此,可以将每个页面控件看作一个独立的组件,当需求发生变化,从而需要将某个页面控件去除的时候,只要调整前后页面之间的连接属性即可。此外,保证每个页面控件的相对完整性有利于团队开发,当需要设计的安装程序比较庞大而复杂时,可以由多个编程人员设计不同的页面,完成之后在主窗体中设置各页面之间的连接属性即可。

图2所示的是各页面控件需要实现的IPage接口和某一页面控件实现的IPage接口。

1.4代码设计

由于篇幅所限,这里仅以选项页面和主窗体的代码设计为例进行介绍。

(1) 选项页面中实现IPage接口的主要代码

图3为选项页控件的示例,三个可用的选项分别是安装、升级和卸载。与此对应,在安装配置参数类中也设置了三个相应的属性,如图4所示。

在OptionPage控件中实现IPage接口方法的主要代码如下:

(2) 安装程序主窗体的主要代码

首先定义两个私有成员:pages和installParams。

实现的页面连接效果如图5所示。

下面的代码实现对各个页面之间的切换控制。

2结束语

从实际应用的角度而言,一个完整的安装程序需要包含向导界面、文件操作(包括创建快捷方式、压缩、解压文件等)、注册表操作等内容,而更为复杂的安装程序还可能包含有数据库连接、Windows服务选择、网络操作、可执行文件的版本关系、覆盖冲突的解决、COM或ActiveX对象的自动注册、快捷方式管理等。本文提出的通用软件安装程序架构将各个功能页面看作一个相对独立的组件,便于实现功能的扩展,因此便于构建不同需求的安装程序。

参考文献

[1]Richard Conway,等.C#类设计手册[M].杨浩,译.北京:清华大学出版社,2003.

[2]Meilir Page-Johes.面向对象设计——程序员必读[M].申玉强,曹济,等译.电子工业出版社,2004.

[3]Tobin Titus,等.C#Threading Handbook[M].Wrox Press,2004.

程序架构篇8

框架是一种微体系结构,为特定领域内的软件系统提供完全可以实现的模板,是一个将要被扩展或复用的子系统[1]。软件框架(Software framework),通常是指为实现某个业界标准或完成特定基本任务的软件组件规范,也指为实现某个软件组件规范时,所要求的基础功能的软件产品。软件框架是实现大粒度复用的重要途径,其往往针对特定领域,同时支持设计复用和代码复用[2]。

良好的软件框架或结构设计将为软件项目开发带来较大益处,特别是在软件稳定性、灵活性、可维护性和扩展性等方面。在软件开发中,开发人员可根据实际需求对框架进行对象实例化与代码重构,从而快速形成“半成品”的应用系统程序,然后通过对业务流程的再分析和再设计使整个应用系统得以实现[3]。

以面向对象信息系统桌面程序为例,整个系统功能是由各对象间相互协作完成的,虽然这些对象间的具体交互由企业实际业务流程决定,但可从系统中提取软件框架结构,对该系统进行分层框架设计,实现软件最大粒度的可重用性[3]。

本文将结合.NET平台所提供的相关技术,搭建一个具有三层架构设计思想、面向对象和可复用的桌面应用程序软件开发框架。

2框架设计

目前,应用程序的实现一般划分为3个层次,从低向高分别为:数据访问层、业务逻辑层、表示层。数据访问层实现对数据库记录的操作,这对于特定DBMS是固定的; 业务逻辑层调用数据访问层实现业务逻辑,该层是关键层,如果用户业务需求发生变更,可在该层修改,业务逻辑层有很多独立方法;表示层调用业务逻辑层实现用户功能,只要业务逻辑层有这个功能即可调用,表示层只需要提供输入、输出和提示等[4]。三层体系架构划分如图1所示。

各层任务如下:1数据访问层。针对每个数据表,设计一个数据访问类。在Common类库中的数据操作公共类db.cs的基础上,为满足业务流程中每个最底层基本记录操作需求,设计一个方法,实现记录的增、删、改、查等功能。为实现业务逻辑提供数据库访问基础。设计数据访问层的原则是满足业务流程中每个最底层的操作步骤;2业务逻辑层。针对用户的每个整体性逻辑功能,设计一个业务逻辑类。此时,类中的每个方法,需要调用数据访问层相关类,来实现整体逻辑功能中的每个功能需求。设计原则是调用数据访问层,满足用户界面每个逻辑功能的需求;3表示层。一般不需要设计特定的类,只需要针对用户具体需求,为每个功能模块部署输入控件、操作控件和输出控件,并利用从这些控件获取的实参调用业务逻辑层中相关类的方法来实现该功能。

3具体实现过程

基于ASP.NET,以C#为开发语言,以Visual Studio 2010为开发平台,以SQL Server 2005为数据库,详细解析该框架桌面程序的搭建过程。

3.1实现目标

编写桌面程序,实现对SQL Server数据库ClassWeb中一张名为userInfo的用户信息表中所有记录的增加、删除、修改和查询等操作,表结构如表1所示。

3.2解决方案、项目创建及启动项设置

启动VS2010,单击菜单 “文件 ”———新建———项目———其它项目类型———Visual Studio解决方案———空白解决方案———自定义解决方案名称,例如ClassWeb;在右侧“解决方案资源管理器”面板中,右键单击解决方案ClassWeb———添加———新建项目,在弹出窗口中,选择 “Windows窗体应用程序”,并命名为UI;在右侧的“解决方案资源管理器 ”面板中,右键单击解决方案ClassWeb———添加———新建项目,在弹出窗口中,选择“类库”, 并命名为BLL;再添加3个类库,依次命名为DAL、Model、Common。右键单击表示层UI,在弹出快捷菜单中单击“设为启动项目”。包含多个项目的三层体系架构解决方案资源管理器如图2所示。

3.3数据操作公共类的编写

在信息管理类的程序中,会频繁对数据进行增、删、改、查等操作。将数据库连接和常用数据操作方法抽取在自定义的数据操作类中,实现代码优化。

在类库Common中,添加新项数据操作公共类db.cs类,并在类中引用如下命名空间:

3.4对象关系映射——实体类设计

对象关系映射 (Object Relational Mapping,简称ORM,或O/RM,或O/R mapping),是一种程序设计技术,该技术用于实现面向对象编程语言时,实现不同类型系统间的数据转换。从效果看,其实是创建一个可在编程语言中使用的“虚拟对象数据库”。

以用户信息表userInfo为例,在Model类库中,创建UserInfo.cs实体类。

根据表中相应的字段,编写如下代码:

3.5添加引用

遵循从低到高原则,依次添加引用。在DAL类库中, 右键单击“引用”———添加引用———在弹出的“添加引用” 对话框的“项目”选项卡中,添加对Common和Model类库的引用;在BLL类库中,右键单击 “引用”———添加引用———在弹出的“添加引用”对话框的“项目”选项卡中,添加对DAL和Model类库的引用;在UI表示层中,右键单击“引用”———添加引用———在弹出的“添加引用”对话框的“项目”选项卡中,添加对BLL和Model类库的引用。

3.6数据访问层(DAL)中类的编写

在数据访问层类库DAL中,添加新项数据操作公共类userInfoDal.cs类,并在类中引用如下命名空间:

3.7业务逻辑层(BLL)中类的编写

在业务逻辑层类库BLL中,添加新项数据操作公共类userInfoBll.cs类,并在类中引用如下命名空间:

3.8用户表示层(UI)的布局与功能实现

在用户表示层UI中,添加新项Windows窗体UserInfoManage,如图3所示,对该窗体进行设计与布局。

在该窗体的cs文件中进行编码实现相应功能。首先,引用如下命名空间:

在UserInfoManage的窗体加载事件Load中编写如下代码,实现所有用户信息的获取与显示。

dgvUserInfo.DataSource = userInfoB.GetUserInfoList();

依据上述思路,可继续完成用户信息的带条件查询、添加、删除和编辑等功能。

4结语

本文探讨了三层体系架构的划分原理,使读者理解各层次的作用、设计原则和各层之间的关系。演示基于三层架构的.NET桌面应用程序的框架搭建过程,通过搭建框架,降低系统之间耦合,提升系统的构件化水平。基础框架模块与扩展模块之间的功能定位准确,使系统各层次之间的分工更为明确。