Delphi快速开发模式

1. 软件架构

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

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

2. 案例

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

域                名称               类型/长度                 说明

报送日期   ReportDate         Char(8)

银行编号   BankNo              Char(4)

交易帐号   AccountNo         Char(20)

户名        AccountName     Char(50)

当天存入  DepositToday      Decimal(12,2)

当天划出  WithdrawToday    Decimal(12,2)

累计存入  DepositTotal        Decimal(15,2)

累计划出  WithdrawTotal     Decimal(15,2)

余额       Balance               Decimal(15,2)

2.1 需求分析：

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

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

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

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

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

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

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

（2）交易查询

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

2.2分析设计：

对资金进出日报录入发送功能绘画出序列图，首先摆上“柜员”、“交易输入界面”、“资金日报”，考虑到资金进出日报录入功能为系统最复杂的功能，增加一个业务控制类“资金日报控制”。在绘制序列图过程中，根据消息交互的需要，陆续加上“帐户簿”、“报送接口”。

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