说明: 为金融集成软件工程师编写的教材内容，先把稿子放在网上请在同行提供一下意见。

Delphi是C/S开发模式时代流行的RAD快速开发工具，有大量的控件可供使用，并且很多控制提供源代码可以自行重新定制。但相对.Net和Java而言，缺少可用的ORM工具包，导致无法完全应用面向对象工程方法论。

1. 软件架构

大部分Delphi的数据控件不支持对象数据源，而是直接访问数据库，建模方法通常采用面向信息建模方法论。在面向对象建模方法流行的今天，在Delphi上应用面向对象建模遇到了拦路石。在Delphi平台上开发，考虑结合面向对象建模和信息建模技术，处理领域逻辑采取面向对象分析设计，仅在使用到数据控件的地方部分采用信息建模，主要使用在业务查询功能上，并且信息建模的工作放在面向对象建模工作之后，因为这时面向对象分析设计最后阶段已经可以导出数据库设计。

1.1. 基本软件架构

使用Delphi开发的软件架构可采取以下的结构：整个软件架构分为用户展示层、业务领域层、数据模块层、外界系统访问层。用户展示层的部件分为两类，一类使用数据控件的查询界面，另一类不使用数据控件的业务交易界面；业务领域层反映业务控制、领域知识，使用数据数据模块层、外界系统访问层提供的方法；数据模块层就是Delphi中的DataModule，封装数据访问及为数据展示控件提供数据；外界系统访问层封装外界系统的访问接口。

图1

在实际应用中，除了业务领域层外，其他层次都大量使用Delphi特有的大量控件提高开发速度，比如查询界面使用各类的Grid控件，外界系统访问层使用WebService、Indy控件等。

1.2 企业软件架构

考虑在一个企业的环境里，企业可能已经部署了许多基础软件系统及业务应用系统，新开发的系统必然或多或少与其他系统进行集成，最常见的集成包括认证和授权（如基于SAML协议的企业统一认证平台）、安全环境（加密、数字签名等）、企业核心业务系统等，这类系统都在新开发的系统边界之外，向新系统提供各种各样的接口。另外新系统中除了业务领域功能外，还包括有使系统能正常运行的环境，常见的有外部环境参数、内部业务的环境参数等。

参考BCE（Boundary, Control, Entity）模型，将系统分解成以下部件：

1、边界类：应用界面（FORM）、后台主控、外界系统接口（包括安全）

2、控制类：业务控制、数据模块、配置

3、实体类：业务实体

图2

2. 案例

某银行每天向某产品监管机构报送该产品资金进出情况，交易接口使用WebService方式：

2.1 需求分析

相对大型软件系统，小型系统用户并不重视需求分析，更多依赖设计师自行提出系统功能需求。参考Peter Coad的交易模式，本系统是一个简单的交易系统，本系统提供的交易是资金进出日报，本交易没有交易明细。从交易出发，交易相关有帐户和银行，交易参与者有银行柜员，柜员属于银行下属的各个营业机构。

图3

另外自下而上从接口分析系统需提供的业务功能：

1）当天报送数据录入功能：分析是否所有数据都需要手工输入，银行编号、交易帐号、户名应自动或由用户选择，其他由用户输入。

2）考虑到一个银行分配一个银行编号，银行编号更多属于全局数据配置的范围，因此需要一个维护系统参数的功能。

3）帐户和户名是需要预先登记的数据，方便在录入功能中供用户选择而不是录入，因此需要维护帐户登记簿。

综合起来，系统功能包括：

（1）交易功能：资金进出日报录入发送

（2）交易查询

（3）银行、营业机构、帐户簿、柜员的维护功能（添加、修改、删除、查询）。

2.2分析设计

参考BCE模型和交易模式，首先得到“汇总日报”控制类、“汇总日报”实体类，考虑到帐户簿功能简单，不再设控制类。除了控制类、实体类外，加上系统边界类，得到下图：

图4

对汇总日报录入发送功能绘画出序列图，首先摆上“填报人”、“输入界面”、“汇总日报”。在绘制序列图过程中，根据消息交互的需要，陆续加上“帐户簿”、“监管机构WEB接口”。

图5

考虑帐户簿的维护功能，如下图的序列图。如果一个帐户曾经有过资金进出日报报送的记录，是不是可以修改其帐户和户名呢？或者可以将这个帐户删除？从业务角度来说是不应该修改它的帐户及户名，更不能删除掉，因为如果这样做系统的另一个登记的交易与本银行的资料将不一致。事实上业务角度来看，一个客户只会将帐户销户，或者销户后重新启用一个新的帐户，或者按会计制度规定，多少年以后银行可以将一个呆滞帐户清除。考虑上述因素，本系统不提供修改功能，但提供删除功能。

图6

3. 小结

从工业角度看培养从事信息系统开发的Delphi工程师，个人认为需要掌握以下内容：

附例子源代码及UML图(使用StarUML)