考虑一个小例子，抽象描述系统

本文通过一个小例子，试图抽象描述一个系统。

考虑一个简化的计费系统，有如下一些实体：

1）客户档案，记载客户基本情况

2）电价档案，描述电价情况

3）用电记录，描述客户在一段时间内的用电情况

4）电费档案，描述客户每个月应收的电费

5）收费档案，描述客户实际的缴费情况

这个计费系统，包括如下用例：

1）维护客户档案

2）维护电价档案

3）维护用电记录

4）维护电费档案

5）维护收费档案

如果只是一个维护的操作，分解成增删改查，就可以了，但是，采用这种一致的模式，不能构成易用的系统。

系统需要有一些合适的模式来增加易用性

1）各对象之间应该能够进行合理的链接

2）多个对象会被同时显示，以便于参照

3）每个对象的展示需要有合适的模式，例如按树的结构来描述一个客户的电量、收费等情况

另外，存在一些事务来组合多个对象的操作，例如，一个缴费的操作，需要

1）记录收费档案 2）更新电费档案

另外，一个计费的过程应该是自动进行的，每当用电记录被录入，那么，电费档案就应该被生成。

好了，就如上这些过程，如果想抽象表述出来，能够自动生成一个可用的系统，该如何描述？

这里，抽象的表述应该具备一个如下的原则：

1）和UI的实现方式无关，不管是用哪钟客户端技术，这个抽象的过程始终始终适用

2）和后台的实现无关，是通过Java Bean，还是存储过程，还是WebService，描述上不应带有这些具体技术的字眼

实际上，一个描述的非常合理的use case，就具备这种特点，但是，use case没有把表述的过程对象化，过程化，所以难以构造出自动的生成系统。

为了得到能够自动构造出目标系统的抽象描述，必须根据系统的特点定义出抽象的概念，然后，对这些抽象的概念进行组合，来构造系统。

按照我的经验，应该具备这些概念：

1）类或对象，描述能够被持久化的实体对象，体现数据

2）基本服务，描述对实体对象的原子操作，这些操作应该是开放事务的，就是说，这些原子服务能够自由组合在事务中

3）UI组件，描述和用户进行交互的那些对象

4）业务过程，一个业务过程，代表一个对基本服务和对UI组件的组合，表达一个协同的工作过程

5）工作流，描述一个由多个角色协同完成的业务过程，是一个宏观的业务过程。

和EOS或Bea workshop相比较，很容易对位到一些现有的概念，但这里希望更抽象一层。

除此之外，为了抽象的表达如上各概念，还应该有：

6）实体对象的模型，描述一个实体对象包含哪些属性，各属性类型等，以及实体对象之间的关系

7）基本服务接口，描述一个基本服务，包含的输入和输出，处理中用到的相关实体对象

8）UI组件模型，描述一个UI组件的输入和输出

如上的各个核心概念，可以认为是service，都运行于各自的容器之中，对象之间的互相调用，都是通过容器来进行的，每个service包括输入和输出两部分，异步的输出是通过event来提供的。

另外，需要单独提出的一个概念，就是规则：

规则是对变化的处理过程和数据的一种抽象，影响到各个组件之中，和各组件一起配合，来构造成一个适应变化的系统。

另外， 为了能够描述工作流和业务过程的权限，系统还应描述角色的概念。

业务过程和工作流程是这个过程中，最稳定的过程，一个人熟悉某方面的业务，实际上最核心的就是熟悉这里面的业务过程和工作流程，相比之下，业务过程更加稳定。

下面就描述这么一个抽象的业务过程：缴费。

1）UI组件1，输入：操作员的操作（以后这种输入略），输出：用户编号user_id

2）基本服务1，输入：user_id ，处理：查询电费档案，输出：电费档案1

3）UI组件1，输入：电费档案1，输出：缴费情况1

4）基本服务2，输入：缴费情况1，处理：进行缴费动作，输出：缴费结果信息1

5）UI组件1，输入：缴费结果信息1，输出：无。

实际的程序实现中，UI组件为了考虑易用性，本身往往具备一个较长时间的生命周期，所以，一个UI组件往往会组合实现一个业务过程或多个业务过程的多个环节，例如，查询业务过程，往往会被缴费业务过程所包括，所以，缴费的UI组件，会同时处理查询和后续的缴费操作。这样，UI组件的设计本身就是一个归类设计的过程。