今天下午第2次碰头，小G带来了刚刚构思好热乎乎的数据模型：逻辑模型和物理模型。
小J刚刚用visio整理了部分流程。大家就这两部分展开了讨论。
小G用的Sybase Powerdesign做的UML模型，他将系统分成参与人，流程管理，结算管理，车辆管理，系统管理5个模块。
参与人是一个类，有ID，名字，创建时间等公用属性。下面派生出员工，电信，其他单位等实例。
员工属性有：工号，联系电话，所在组织ID，职务(普通员工，部门负责人，公司分管领导，公司主管领导，驾驶员)
电信组织属性有：所在地区，所属上级组织ID，
其他单位属性有：...
流程管理是小G介绍的重头戏，他的概念我理解就是：
1.在申请单提交的一刻就确定了该单据应该走的流程，我们把它叫做流程模式，针对不同种类的申请单制定不同的流程模式。将该模式存到数据库中。
2.流程模式对应实际的流程图，其中环节部分对应一个元任务，比如部门审批环节就对应部门审批任务操作，每个任务执行的结果就是将此单据在这个环节的状态设成已处理结果返回值。
3.每个活动的单据（没有走完流程的）都在活动单据表中，并且有当前所处的流程状态字符串。
4.流程调度就是该环节的角色登录后，界面向流程调度程序（引擎）要待处理的单据，引擎根据当前环节的ID和所属的流程模式ID从活动单据表中将符合条件的尚未处理的单据调出。如果该环节角色执行了操作，就执行了任务程序，也就执行第2点的操作。
但实际上，这个流程调度思路还存在一些问题，比如流程模式是否能够从已开始就确定，存在流程的分支的时候，是分成2个独立的模式，还是分成分支模式，尤其是流程要求可配置的时候。
流程状态字符串的具体实现等。。。
结算管理实质是申请单->派车单->结算单的统计，故此模块属于单据的实例。可略去
车辆管理是车辆基本信息，由车辆类派生出 ...
系统管理基本上就是任务菜单的管理，由于权限的分配，不同的角色登录系统得到不同的操作菜单界面。
总之，这个模型我觉得设计的比较理想化，在未来几天还需要细细推敲，以便可实际的被编码。
小J刚刚用visio整理了部分流程。大家就这两部分展开了讨论。
小G用的Sybase Powerdesign做的UML模型，他将系统分成参与人，流程管理，结算管理，车辆管理，系统管理5个模块。
参与人是一个类，有ID，名字，创建时间等公用属性。下面派生出员工，电信，其他单位等实例。
员工属性有：工号，联系电话，所在组织ID，职务(普通员工，部门负责人，公司分管领导，公司主管领导，驾驶员)
电信组织属性有：所在地区，所属上级组织ID，
其他单位属性有：...
流程管理是小G介绍的重头戏，他的概念我理解就是：
1.在申请单提交的一刻就确定了该单据应该走的流程，我们把它叫做流程模式，针对不同种类的申请单制定不同的流程模式。将该模式存到数据库中。
2.流程模式对应实际的流程图，其中环节部分对应一个元任务，比如部门审批环节就对应部门审批任务操作，每个任务执行的结果就是将此单据在这个环节的状态设成已处理结果返回值。
3.每个活动的单据（没有走完流程的）都在活动单据表中，并且有当前所处的流程状态字符串。
4.流程调度就是该环节的角色登录后，界面向流程调度程序（引擎）要待处理的单据，引擎根据当前环节的ID和所属的流程模式ID从活动单据表中将符合条件的尚未处理的单据调出。如果该环节角色执行了操作，就执行了任务程序，也就执行第2点的操作。
但实际上，这个流程调度思路还存在一些问题，比如流程模式是否能够从已开始就确定，存在流程的分支的时候，是分成2个独立的模式，还是分成分支模式，尤其是流程要求可配置的时候。
流程状态字符串的具体实现等。。。
结算管理实质是申请单->派车单->结算单的统计，故此模块属于单据的实例。可略去
车辆管理是车辆基本信息，由车辆类派生出 ...
系统管理基本上就是任务菜单的管理，由于权限的分配，不同的角色登录系统得到不同的操作菜单界面。
总之，这个模型我觉得设计的比较理想化，在未来几天还需要细细推敲，以便可实际的被编码。
