SinoNetscape-Appkit商用业务基础平台Appkit-体系架构.doc

SinoNetscape计算机软件系统有限公司

SinoNetscape Appkit商用业务基础平台

Appkit体系架构

<版本 2.0>

作者：

单位：

成文信息
编 号：

主题词：
体系架构
作 者：

文档类别：
技术
主 送：

存档日期：

抄 送：

发布日期：

变更信息
版本
原因
作者
日期
1.01
起草

2005.07.05
1.02
完善

2005.08.05
2.01
完善

2009.04.10
2.02
完善

2009.06.02

目 录
第1章 前言 1
1.1 内容 1
1.2 适用范围 1
1.3 相关资料 1
第2章 Appkit的体系架构 2
2.1 定义 2
2.2 概述 2
2.3 术语与概念 3
2.3.1 应用系统 3
2.3.2 工程 3
2.3.3 模型 3
2.3.4 数据空间 4
2.3.5 类 4
2.3.6 属性 4
2.3.7 连接类 4
2.3.8 对象 5
2.4 技术能力 5
2.5 系统原理图 6
2.6 系统部署图 7
2.7 开发体系图 8
2.8 开发流程图 9
第3章 附录 10
3.1 附录1 相关理论及应用 10
3.1.1 软件复用 10
3.1.2 构件及CBSD方法 12
3.1.3 领域工程 12
3.1.4 软件产品线 14
3.2 附录2 优势与效益分析 14
3.2.1 Appkit的优势 14
3.2.2 效益预测 15
3.3 附录3 Appkit的文件资源 16
3.3.1 核心资源 16
3.3.2 应用系统资源 17

第1章 前言
1.1 内容
本文档阐述了Appkit的体系架构、原理、组成、基础理论、发展过程及优势与效益。同时描述了基于Appkit进行开发活动所获得的软件制品（面向模型与构件的应用系统），从制品的角度评价了应用系统快速构造整体集成套件。
1.2 适用范围
本文档是Appkit的核心技术文档，用以阐述整个技术架构并确立这一方法的运用。
本文档的读者主要包括企业决策层人员、消费者复用活动所涉及的应用系统项目管理者、设计、开发及实施人员。
1.3 相关资料
1 《软件构件库管理系统》 赵俊峰，北京大学软件研究所 北京大学软件工程国家工程研究中心，2004年4月
2 《软件复用的过程》 王亚沙，北京大学信息学院软件研究所
3《软件复用标准指南 Software Reuse A Standards Bascd Guide》 王亚沙 谢冰 赵俊峰，电子工业出版社
4 《领域工程概述》 李克勤 陈兆良 梅宏 杨芙清，北京大学计算机科学技术系
5 《软件产品线简介》 张世琨，北京大学软件工程国家工程研究中心
6 《软件构件模型及其标准》 黄罡，北京大学软件研究所 北京大学软件工程国家工程研究中心，2004年7月12日
7 《领域工程方法简介》 北京大学软件研究所领域工程小组，2004年6月3日
8 《软件制作指南》 北京大学软件工程国家工程研究中心，2004年7月12日
9 《软件复用技术与领域工程》 北京大学软件工程国家工程研究中心，2004年7月12日
10 《软件体系结构构造技术》 北京大学软件工程国家工程研究中心，2004年7月12日
第2章 Appkit的体系架构
2.1 定义
Appkit（Database Application Develop Kit：数据库应用开发工具包），是由一个可复用构架、一组可复用COM构件及Web部件、一系列软件工具及特定方法与过程共同构成的一个软件体系架构，它主要用于数据库领域商业应用系统的快速开发，从而大幅提高数据库工程的生产率、同时降低开发成本和周期。
Appkit是一个业务基础平台产品，也称为Appkit platform，即Appkit平台。
业务基础平台在软件业内的定义：
业务基础平台是指以业务导向和驱动的、可快速构建应用软件的软件平台。它解决了管理软件的业务描述以及与操作系统、软件基础构架平台之间的交互管理问题，同时它屏蔽了技术细节，使开发人员能够集中全力关注产品研发中的业务与管理问题，摆脱技术细节的困扰，从而提高了产品研发效率。
2.2 概述
Appkit platform 提供了一个可复用构架和一组可复用构件（控件），这个可复用构架就是一个分布式三层体系结构的计算模式，基于Appkit的应用系统，就是需要复用构件开发一个负责界面表现和逻辑调用（而非逻辑处理）的瘦客户端或Web端，这个瘦客户端或Web端插接到Appkit的体系中就构成了一个完整的分布式应用系统。
Appkit的主要组成：
² 构架：应用服务器与Web服务器软件环境。
² 构件：可复用COM构件、Web控件及Web公共部件。
² 工具：可执行程序。
Appkit是一个大型基础架构，实现对数据库应用系统基本业务、框架、功能、逻辑的有效封装。
Appkit的体系具有以下特征：
u 微内核
u 自动化工具快速开发支持
u 实现分布式三层体系结构
u 商业数据库无关
u 具有强大的可扩展性
u 具有良好的可伸缩性
2.3 术语与概念
2.3.1 应用系统
Appkit应用系统，是指除Appkit platform及其数据之外的整个程序，包括专门编写的专用构件、可执行文件、Web页面、设置文档及模型库等。
Appkit应用系统可以理解为不含数据的、纯粹的软件部分，应用系统因为不含数据因此是不能运行的，许多时候应用系统和模型两个概念可以等同使用。
2.3.2 工程
Appkit应用系统加上完整的数据（数据库）之后即称为工程（或项目），工程是应用系统的一个实例，工程才是真实可运行的。
Appkit创建一个应用系统时总会默认创建一个工程，该默认工程具有和应用系统相同的标识名称。
应用系统工程这种架构的优势在于即使部署在同一台计算机环境中，一个软件也可以提供出多个软件服务来，例如，远程办公管理系统的工程A可以服务于A企业、工程B可以服务于B企业、工程C则可以服务于软件开发商本企业。
许多场合下，应用系统和工程的概念可以等同使用。
2.3.3 模型
模型又称为数据模型，是Appkit类型设计的结果，从面向对象的观点来看，模型包含了一个应用系统所涉及的类、类之间的关系、类的属性等基本完整的设计内容，从数据库的观点来看，模型包含了一个应用系统所涉及的表、表之间的关系、表的字段等基本完整的数据存储体系内容。
模型的文件载体是一个Access数据库文件，称为模型库，存储于Platform\bin\{应用系统}目录，一般命名为MD_{应用系统}.mdb，同时，该信息还存储在Platform\Lib\OprEngine.xml文档的特定部分。
2.3.4 数据空间
Appkit模型中数据空间的描述非常简单，一个数据空间仅需要一个标识和显示名称，数据空间是真实数据源（或数据库、或数据库库连接）的抽象，类及连接类必须要指定数据空间，即所映射的数据表一定需要存储在某个数据库中，但是在Appkit模型中没有针对这种抽象的具体实现。
数据空间的具体实现由工程来完成，例如，一个应用系统A可以有多个工程，对于工程A1而言，可以将主数据空间MAINDB实现为一个Oracle数据库，对于工程A2而言，则可以将主数据空间MAINDB实现为一个SQL Server数据库，Appkit类型设计时，数据空间总是抽象的。
一个应用系统可以具有多个数据空间（默认为5个），即应用系统工程的业务数据可以存储在分布的、异种的、不同数据库中。例如，应用系统A的工程A1，可以对数据空间进行以下实现：主数据空间Oracle、辅助信息数据空间Access、业务控制数据空间Access、系统数据空间Access、日志数据空间SQL Server，即应用系统A的工程A1运行时将涉及3种、5个数据库。
2.3.5 类
类又称为类型（在有些场合可能被称为元素），Appkit的类综合了面向对象的类以及数据表双重的概念，在理解上应该是映射到表、而不仅仅是表，映射到面向对象的类、而不仅仅是面向对象的类。
2.3.6 属性
属性是类的子项，一个类总是具有多个属性，Appkit通过属性组来对类的属性进行分组管理。Appkit的属性同样综合了面向对象的类的成员以及数据表的字段双重的概念：映射到面向对象的类的成员、而不仅仅是成员，映射到表的字段、而不仅仅是字段。
2.3.7 连接类
连接类用于描述两个类之间的关系，一个连接类首先表明相关的两个类是具有关联关系的，其次，更进一步说明这两个类具有什么样的关系。Appkit的连接类，按照数据库的观点可以映射到一个用于存储两表关联关系的另一个表，按照面向对象的观点，则一般类似于在一个对象中包含有一个集合（列表）类型的成员，集合中的每个元素是另外一种类型对象的引用。
2.3.8 对象
Appkit的对象概念和普通面向对象的对象概念基本一致，都是指一个类型的一个动态的实例。如果在理解上把类型映射为表，那么对象可以映射为一条记录。
2.4 技术能力
基于Appkit设计开发的应用系统软件，具有以下功能和特征：
u 基于浏览器运行
u 完整的数据处理能力
u 完整的数据集成能力
u 完善的组织机构体系
u 多层面立体式的安全与权限控制
u 强大的搜索引擎
u 工作流与业务过程
u 在线报表
u 在线文档
u 离线html文档
u 基于Excel的离线报表
u 完善的图表
u 系统监控与警示
u 消息与邮件
u 订阅与送阅
u 集成整合现有系统
u 数据分析与深度挖掘
u 决策支持及商务智能
u 软件按需定制与随需应变
u C/S与B/S架构无缝集成
2.5 系统原理图

2.6 系统部署图

2.7 开发体系图

2.8 开发流程图

第3章 附录
3.1 附录1 相关理论及应用
3.1.1 软件复用
软件复用是指重复使用“为了复用目的而设计的软件”的过程。软件复用是在软件开发中避免重复劳动的解决方案，使得应用系统的开发不再采用一切“从零开始”的模式，而是以已有的工作为基础，充分利用过去应用系统开发中积累的知识和经验，从而将开发的重点集中于应用的特有构成成分。
依据复用的对象，可以将软件复用分为产品复用和过程复用。产品复用是指复用已有的软件构件，通过构件集成（组装）得到新系统，产品复用是目前显示的、主流的途径；过程复用指复用已有的软件开发过程，使用可复用的应用生成器来自动或半自动生成所需的系统，过程复用依赖于软件自动化技术的发展。
依据对可复用信息进行复用的方式，可以将软件复用分为黑盒（Black-box）复用和白盒（White-box）复用。白盒复用指已有构件并不能完全符合用户需求，需要根据用户需求进行适应性修改后才可使用；黑盒复用指对已有的构件不需作任何修改，通过构件组装的方式直接可以复用。这是目前的研究热点，也是将来的发展趋势。
关于复用，还涉及以下两组概念：一组是即兴复用和系统化复用，即兴复用（ad hoc reuse）是指复用是无计划的、作为软件生命周期的隐含的副产品；系统化复用（systematic reuse）是指按照定义良好的可重复过程进行复用的实践活动。另一组是生产者复用和消费者复用，生产者复用（producer reuse）指为了复用目的而进行的开发活动（Develop for reuse）；消费者复用（consumer resuse）指基于复用的开发活动（Develp with reuse）。
下图描述了实现软件复用的关键因素：

软件复用是任何软件企业都无法回避的必然实践，它能够很显著地提升软件生产率和质量，同时也可以显著地降低软件开发和维护的成本，这已经成为不争的事实。
Appkit的产生正是源于软件复用的思想，是为高层次、高收益的软件复用而设计的。通过Appkit中可复用构件的组装而获得数据库应用系统符合产品复用的特征，而Appkit中提供的类设计器、表单及Web页面工具（半自动化工具）符合过程复用的特征；使用Appkit中的可复用构件不需要进行任何的修改，已经达到黑盒复用的标准；基于Appkit进行应用系统开发是一种系统化复用的活动，Appkit中可复用构件的获取和实现符合生产者复用的范畴，而基于Appkit进行应用系统开发则符合消费者复用的范畴。
涉及软件复用的相关国际标准有：
ISO 9000质量管理体系，由国际标准化组织质量管理和质量保证技术委员会（ISO/TC176）制定。
ISO/IEC 12207标准，由国际标准化组织（ISO）和国际电子技术委员会（IEC）联合制定。
IEEE/EIA 12207标准，由电器和电子工程师协会（IEEE）和电子工业联盟（EIA）联合制定。
IEEE 1517标准，由电器和电子工程师协会（IEEE）制定。
ISO 15504标准，由国际标准化组织（ISO）制定。
CMM，作者为美国卡内基·梅隆大学软件工程研究所（CMU SEI）。
3.1.2 构件及CBSD方法
构件，什么是构件？
目前为止，构件还没有一致共识的定义，大多数对构件的谈论还是集中在实现层次，即代码类构件。
l 从部署的角度定义，构件是独立的可部署单元，可作为第三方的组装单元，要求构件必须能完全跟它所在的环境和其他构件相分离；必须具备足够好的内聚性、封装自己的实现；必须清晰说明自己的依赖条件和所提供的服务。
l 从运行的角度定义，构件是可在物理或逻辑设备上运行的软件实现，要求构件遵循某种构件模型，可以在不修改构件的前提下按照特定的组装标准部署到特定的构件框架中。
l 从复用的角度定义，构件是软件系统中具有相对独立功能、可以明确辨识、接口由契约指定、和语境有明显依赖关系、可独立部署、且多由第三方提供的可组装软件实体。
构件理论和方法是软件复用的核心基础，构件模型及构件技术为软件复用提供了必备的技术支持和手段，软件的构件化是软件发展的必然趋势。
大量的实践表明：高抽象层次构件的复用更为重要和更有价值，它所带来的收益明显大于低抽象层次构件的复用，代码构件的复用仅仅是软件复用的初级阶段。
CBSD方法，即基于构件的软件开发（Component Based Software Develop）方法，它综合了软件复用、构件、构件库、领域工程、软件生产线等重要的思想，正逐步成为软件开发的主流方法。目前中国最主要的研究机构为北京大学软件工程国家工程研究中心及北京大学信息学院软件研究所。
基于Appkit进行数据库应用系统的开发是CBSD的一个实践，Appkit中的可复用构件符合业界对构件的基本定义，其中的核心构件（如数据模型构件、业务引擎构件和外壳功能构件）属于高抽象层次的构件。
3.1.3 领域工程
领域工程是为一组相似或相近系统的应用工程建立基本能力和必备基础的过程，它覆盖了建立可复用的软件构件的所有活动。
领域是指一组具有相似或相近软件需求的应用系统所覆盖的功能区域。
领域工程对领域中的系统进行分析，识别这些应用的共同特征和可变特征，对刻划这些特征的对象和操作进行选择和抽象，形成领域模型，依据领域模型产生出领域中应用共同具有的体系结构或生产过程，并以此为基础识别、开发和组织可复用构件。
当开发某一领域中的新应用时，可以根据领域模型，确定新应用的需求规约，根据特定领域的软件构架形成新应用的设计，并一次为基础选择可复用构件进行组装，从而形成新系统。
有关软件复用的问题可以分为两类，一类是关于面向复用的开发，主要是关于如何产生具有较高可复用性的构件和生成过程；另一类是关于基于复用的开发，主要是如何找到可复用构件，如何判断可复用构件是否符合当前需求以及如何对可复用构件进行适应性修改。领域工程有助于上述这些问题的解决，从而对软件复用提供了有力的支持。
当在某个领域而不是单个系统考虑问题时，就会发现一些特性是领域中所有系统共同具有的，而另一些特性只是个别系统具有的，所有系统都具有的特性是该领域中系统的本质特性，体现为该领域中系统的共性，只是部分或者个别系统具有的特性则体现为领域中系统的变化性。识别共性和变化性并进行变化性控制是领域工程的核心内容。
下图描述了基于领域工程思想，在特定领域进行的软件复用的活动和产品：

Appkit中可复用构件的获取和实现完全基于领域工程的方法，所选定的领域为数据库应用系统领域，通过对大量已有数据库应用系统的分析、及对该领域需求和问题的收集整理，提取了数据库应用领域共性的同时、也识别和控制了该领域的变化性，最终获得了数据库应用领域的需求模型、设计模型及高抽象层次的可复用构件。前面提及的模型（或数据模型）正是对大量数据库应用系统数据结构关系的高度抽象和描述。
3.1.4 软件产品线
软件产品线（Product Line）的概念由CMU SEI提出，已经被迄今为止的实践证明是可行的，可以有效地提高生产率、缩短产品上市时间、提高质量和客户满意度。
产品线方法必将成为新世纪中占主导地位的软件生产模式。
产品线的方法可以看作软件复用发展的一个更高阶段。
一个产品线是共享一组公共的、可管理的特性，并且满足特定市场需求的产品集合。产品的灵活性是市场的必然需求，而产品线将通过裁剪、生产出满足特定用户和用户群需求的产品。从开发者的角度，产品线的成功在于产品之间通过共性的共享、达到了生产上经济的目的。
软件产品线方法的基本活动包括以下三个方面：
1） 核心资产开发
2） 产品开发
3） 管理
Appkit体系中既包含一组可复用的构件，同时包含快速构造工具（半自动化工具）及相关的过程标准与技术支撑手段，其核心任务和目的是大幅提高软件的生产率，因此，Appkit已经成为软件产品线的一个基本阶段。
3.2 附录2 优势与效益分析
3.2.1 Appkit的优势
u 高效率
u 低成本
u 优化团队
u 降低人员风险
u 源于成熟的理论
u 标准的开发技术
u 专著于专业领域的业务
u 快速进入新的业务领域
3.2.2 效益预测
1. 需求分析工作量减少30％
需求分析一般由称为行业专家的人来担任，他们忽略具体的软件实现技术、网络通信技术以及数据库技术等等，紧紧从用户的角度来描述软件应该具有的功能、应该提供给用户什么样的操作和指示。
基于Appkit的开发方式，需求分析的工作量会减少40％以上，Appkit的产生源于软件复用和领域工程，按照领域工程的基础理论，一个新的应用系统的需求分析是不会从头开始的，而会从生产者复用所获得的领域模型基础上去派生一个新的应用系统需求模型。
2. 系统概要设计工作量减少50％
系统概要设计总体上从技术角度来规划整个软件系统，确定系统的网络拓扑结构、体系（C/S、三层体结构或B/S）、具体的实现技术、程序语言、数据库及其部署、面向对象系统的类/对象关系等，需要考虑所采用的技术是否存在缺陷或风险，是否需要技术尝试等。
基于Appkit的开发方式，数据库应用系统项目的这部分工作量会减少60％以上，因为Appkit本身已经是一个可复用的三层体系架构、支持分步式计算和部署、能够适应多种商业数据库。
3. 数据库设计工作量减少80％
这是一个非常占用时间而且索然寡味的工作，从需求分析最后确认的存储要求，要转化为数据库设计中无数个数据表的描述、然后是数据库脚本，再然后是数据库中的实体对象......，最大的风险和挑战是，一旦在开发过程提出数据结构的修改，那么随之从文档、脚本、数据表指导访问数据表的程序代码都要随之而变。
基于Appkit的开发方式，数据库设计和更新的工作量就会减少80％以上，可以由非专业技术人员在类设计器中按照业务需求来定义和调整，而不再成为专业技术人员一项繁重的工作。数据结构的调整对程序代码的影响降到最低，因为软件平台已经良好地处理了模型和业务实体的关系，其中的复杂逻辑被隐藏。
4. 详细设计和程序编码工作量减少60％
一般的软件项目，如果不存在技术问题和难关，从详细设计到完成程序编码，其间的工作量大约占到整个项目的45％～60％（和具体的项目特点、开发习惯有很大的关系），在这部分工作中，基础工作、也就是大多数项目都需要去做的工作大约占到50％以上。
基于Appkit的开发方式，详细设计到程序编码的工作量将减少60％。
首先，一系列的可复用构件已经完成了对数据库系统共性的封装和变化性的控制，重复的工作降到最低；其次，Appkit体系中应用系统原型工具可以快速正确的生成大量的代码单元。
用户对软件是有个性化需求的，不同的项目是有自身特点的，Appkit从抽象和业务无关的角度来考虑问题，但是并不解决所有可能的问题和需求，因此提供一个灵活的、开放性的构架，使之支持良好、简易地二次开发。
5. 测试工作量减少60％
基于Appkit的开发方式，由于系统的代码大幅度减少、完全手工代码大幅度减少、复用了一系列经过验证和确认的可复用构件，因此一个新的应用系统项目的调试、修改和测试的工作量将相应地大幅度减少，减少60～70％。
软件的测试是不可或缺的工作，但是Appkit体系在经过若干应用系统的验证之后基本上已经处于正确的状态，那么测试的重点将转向以业务需求为中心的业务功能方面，测试的难度和工作量的减少是自然的。
3.3 附录3 Appkit的文件资源
Appkit通过注册表信息来引导环境的运行，其注册表项为：
HKEY_LOCAL_MACHINE\Software\Appkit
通过该注册表项及子项的信息，描述了Appkit设计及运行环境在计算机系统上的文件部署及相关运行设置。
3.3.1 核心资源
Appkit包含两个核心的目录Platform和WebApps，以安装时选择D:\Appkit为例，这两个核心目录分别是D:\Appkit\Platform和D:\Appkit\WebApps，以下简要介绍一些关键的目录及文件。
Platform\Lib：该目录存储Appkit所有的基础构件、公用构件及辅助构件，这些构件绝大部分为COM构件。
Platform\Lib\OprEngine.xml：该文档是Appkit的核心关键文档，存储所有应用系统及其工程的配置信息，所有工具及应用系统的运行都离不开该文档，如果丢失或损坏将导致Appkit及应用系统不能运行。开发者不应手工修改该文档，可以通过XmlEditor.exe工具或浏览器进行查看和了解。
Platform\bin：该目录存储Appkit所有的开发及支持工具。
WebApps\Adjunct：该目录存储Appkit辅助部件的页面资源，包括活动会话查看、当前用户信息、消息发送、事务诊断、简单OA及在线交流等。
WebApps\Base：该目录存储Appkit在Web领域一些基础技术实现的页面资源，包括视图同步及会话同步等。
WebApps\Common：该目录存储Appkit应用系统间公共部件的页面资源，包括登录、功能树、退出处理等。
WebApps\Components：该目录存储Appkit在Web领域关键的可复用部件的页面资源，包括年月日选择、对象选择、模型信息选取、消息框、文件上传与下载、对象树型视图、对象列表视图及报表打印等。
WebApps\Template：该目录存储被Appkit的开发工具Web页面所使用的页面模板资源。
WebApps\Css：该目录存储Appkit一些常用的公共的层级样式表文件。
WebApps\Images：该目录存储Appkit一些常用的公共的图片文件。
WebApps\JavaScript：该目录存储Appkit核心关键的、公共的javascript脚本文件，其中common.js、InputCheck.js、message.js、select.js及SelectObject.js会被广泛地引用。
WebApps\Search：该目录存储Appkit所有与公共搜索相关的页面资源，包括普通搜索列表、普通搜索管理、自定义搜索列表、普通搜索交互、自定义搜索交互、搜索执行及搜索结果显示等。
WebApps\Tools：该目录存储Appkit公共基础的工具部件的页面资源，包括组织与权限控制、搜索设计、数据安全定义及通用数据管理等。
WebApps\XSLT：该目录存储Appkit用于搜索的XML结果显示的基本XSLT文档，当应用系统没有特定的XSLT文档时会使用该目录的文档。
3.3.2 应用系统资源
Platform\bin\{应用系统}：该目录存储一个应用系统的模型数据库（MD_*.mdb，Access 数据库文件）及系统的专用构件。
Platform\bin\{应用系统}\{工程}：该目录存储一个应用系统的某个工程的文本型数据库（一般是Access 数据库文件），其RptTmpls子目录为报表模板Excel存储文档目录、PrntDocs子目录为C/S架构应用系统所产生的报表的存储目录。
WebApps\{应用系统}：该目录存储某一个应用系统的所有页面资源，Homepage子目录用于存放主页；Login子目录用于存放登录页；OprObject子目录用于存放每种类型的数据录入或修改页面、数据表格页面；DataView子目录用于存放数据分析、汇总、查询、计算等业务处理的页面。
WebApps\{应用系统}\{工程}.aspx：某一个应用系统某个工程的首页。
WebApps\App_DATA\{应用系统}\{工程}：该目录存储某一个应用系统某个工程相关设置的资源文档，文档均为标准的XML文档，扩展名可能为.xml、.config或.xslt，其中SysMenu???.xml文档为功能树文档、MyDesk???.xml为我的桌面文档。Config子目录主要为搜索相关的各种表现设置，Search及SqlSearch子目录存储表格设置、chart子目录存储图表设置、treetable子目录存储树型表格设置、treeview子目录存储树型视图设置、Upload子目录存储文件上传的设置。
WebApps\App_Code\{应用系统}：该目录存储某一个应用系统专用的代码资源，包括由类设计器或对象化编程支持工具自动生成的类的代码文件、以及开发者自行设计的类的代码文件。
WebApps\RuntimeDATA\{应用系统}\{工程}：该目录用于运行期所输出的各种临时文件，如上传、提供下载、动态创建的各种文件等。

第 18 页 共 18 页