工作流设计

① 怎么设计类似工作流的表结构

不难，只是内容多，有时间可以和我交流

② 通过excel设计一些简单的工作流吗

使用插入中的 SmartArt，选择合适的模板即可
对于其中的结构可以调整

③ 通达oa怎么将设计的表单导入工作流。

系统管理-工作流设计-表单设计。新建一个表单后会看到导入操作，选择已经做好的htm文件导入即可。也可以从表单设计器里直接设计。导入后需要做的是在表单中增加可写的控件。
还不懂问我

④ 工作流系统设计与关键设计实现

本书以作来者自主研发的“自钱塘”工作流管理系统为分析对象，阐述了如何设计和实现一个完整的工作流管理系统。本书共分五章，第一章介绍了工作流领域相关概念和“钱塘”工作流管理系统的体系结构：第二章讲述了流程建模工具的设计和关键实现；第三章讲述了工作流引擎的设计和关键实现；第四章讲述了分布式流程管理的设计和关键实现；第五章介绍了如何基于“钱塘”工作流管理系统进行流程管理。此外，本书以光盘形式附带了可运行的“钱塘”工作流管理系统、使用手册和使用案例。.

⑤ 软件开发的工作流的过程是怎样的

计划
对所要解决的问题进行总体定义，包括了解用户的要求及现实环境，从技术、经济和社会因素等3个方面研究并论证本软件项目的可行性，编写可行性研究报告，探讨解决问题的方案，并对可供使用的资源（如计算机硬件、系统软件、人力等）成本，可取得的效益和开发进度作出估计，制订完成开发任务的实施计划。
分析
软件需求分析就是对开发什么样的软件的一个系统的分析与设想。它是一个对用户的需求进行去粗取精、去伪存真、正确理解，然后把它用软件工程开发语言（形式功能规约，即需求规格说明书）表达出来的过程。本阶段的基本任务是和用户一起确定要解决的问题，建立软件的逻辑模型，编写需求规格说明书文档并最终得到用户的认可。需求分析的主要方法有结构化分析方法、数据流程图和数据字典等方法。本阶段的工作是根据需求说明书的要求，设计建立相应的软件系统的体系结构，并将整个系统分解成若干个子系统或模块，定义子系统或模块间的接口关系，对各子系统进行具体设计定义，编写软件概要设计和详细设计说明书，数据库或数据结构设计说明书，组装测试计划。在任何软件或系统开发的初始阶段必须先完全掌握用户需求，以期能将紧随的系统开发过程中哪些功能应该落实、采取何种规格以及设定哪些限制优先加以定位。系统工程师最终将据此完成设计方案，在此基础上对随后的程序开发、系统功能和性能的描述及限制作出定义。

设计
软件设计可以分为概要设计和详细设计两个阶段。实际上软件设计的主要任务就是将软件分解成模块是指能实现某个功能的数据和程序说明、可执行程序的程序单元。可以是一个函数、过程、子程序、一段带有程序说明的独立的程序和数据，也可以是可组合、可分解和可更换的功能单元。模块，然后进行模块设计。概要设计就是结构设计，其主要目标就是给出软件的模块结构，用软件结构图表示。详细设计的首要任务就是设计模块的程序流程、算法和数据结构，次要任务就是设计数据库，常用方法还是结构化程序设计方法。

编码
软件编码是指把软件设计转换成计算机可以接受的程序，即写成以某一程序设计语言表示的“源程序清单”。充分了解软件开发语言、工具的特性和编程风格，有助于开发工具的选择以及保证软件产品的开发质量。当前软件开发中除在专用场合，已经很少使用二十世纪80年代的高级语言了，取而代之的是面向对象的开发语言。而且面向对象的开发语言和开发环境大都合为一体，大大提高了开发的速度。
测试
软件测试的目的是以较小的代价发现尽可能多的错误。要实现这个目标的关键在于设计一套出色的测试用例（测试数据与功能和预期的输出结果组成了测试用例）。如何才能设计出一套出色的测试用例，关键在于理解测试方法。不同的测试方法有不同的测试用例设计方法。两种常用的测试方法是白盒法测试对象是源程序，依据的是程序内部的的逻辑结构来发现软件的编程错误、结构错误和数据错误。结构错误包括逻辑、数据流、初始化等错误。用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果。白盒法和黑盒法依据的是软件的功能或软件行为描述，发现软件的接口、功能和结构错误。其中接口错误包括内部/外部接口、资源管理、集成化以及系统错误。黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。
维护
维护是指在已完成对软件的研制（分析、设计、编码和测试）工作并交付使用以后，对软件产品所进行的一些软件工程的活动。即根据软件运行的情况，对软件进行适当修改，以适应新的要求，以及纠正运行中发现的错误。编写软件问题报告、软件修改报告。一个中等规模的软件，如果研制阶段需要一年至二年的时间，在它投入使用以后，其运行或工作时间可能持续五年至十年。那么它的维护阶段也是运行的这五年至十年期间。在这段时间，人们几乎需要着手解决研制阶段所遇到的各种问题，同时还要解决某些维护工作本身特有的问题。做好软件维护工作，不仅能排除障碍，使软件能正常工作，而且还可以使它扩展功能，提高性能，为用户带来明显的经济效益。然而遗憾的是，对软件维护工作的重视往往远不如对软件研制工作的重视。而事实上，和软件研制工作相比，软件维护的工作量和成本都要大得多

⑥ 需要一个jbpm工作流引擎设计器，要运行在web上的，最好是和jsp/java/sevlet结合的

“工作流”到处都在，
一个人独自干活也有工作流，一般不需要什么“引擎”。 讲究点的装个To Do在手机上。
如果是小型创业公司，十几个人，工作流简单，也没必要上专门的软件，收益和成本相比不合算。
如果是较大的公司，流程设计部门多，发觉效率低了，或管理失控了，就有必要制定严密的工作流程，然后用合适的软件系统来运作这个流程。
介绍几个系统供参考：
天翎、华为是当前比较好的工作流软件系统，在欧美企业用的相当多。成本相对低，上线也快。扩展性极强，小公司用1台服务器，随着业务扩展，可以增加服务器，我公司已经在全球有200多台Domino服务器了。
天纵的平台也有工作流功能，但是用户比较少
也有某些公司开发的的工作流，尤其很多政府在用，界面花哨，看似强大，其实扩展性和维护性很差。

⑦ 关于工作流的数据库设计

项目(Item)
项目ID(ItemId) 项目描述(ItemName) 流程ID (RoutID) 申请人ID (ApplyUserID) 状态(State) 项目类型(ItemType)
1 郑州出差借款 1 1 借款单
2 郑州出差报销 3 1 报销单 这里的项目，是泛指，可以是公文，借款单，报销单等等需要流转的数据.

任务列表(TaskList)
任务ID(taskId) 项目ID (itemId) 步骤ID (actorId) 状态(state) 版本(version) 1 1 1 检出 100
2 2 3 检出 1001
3 3 3 待检出 1002项目申请后，任务列表插入一条记录.用户审批通过或者拒绝后，update当前步骤ID（上一步骤或者下一步骤）.某个步骤可能有多个审批人，如果要审批，必须先检出.version字段是为了乐观锁控制，保证只能有一人检出.

任务历史记录(TaskHistory)
ID(id) 项目ID (itemId) 步骤ID (actorId) 备注(memo) 操作人ID (operateUserId) 创建时间(createDate)1 1 1 成都出差 1
1 1 2 批准 2
1 1 3 批准 3
每个步骤的操作，都写入任务历史记录

流程(Rout)
流程ID(routId) 流程描述(routName) 部门ID (deptID) 版本号(version) 状态(State)
1 借款流程 1 1 发布
2 报销流程 1 1 草稿
2 预算审批流程 1 1 停止 流程草稿状态是可以修改删除，发布状态就不能修改和删除，只能新增一个版本，或者新增一个流程，或者停止流程。

步骤(Actor)
步骤ID(actorID) 步骤序号(sortNo) 步骤描述(actorName) 流程ID (routId) 1 1 借款申请 1
2 2 部门经理审批 1
3 3 财务经理审批 1 步骤序号是步骤执行的顺序，审批的时候，根据当前序号，查找下一步骤，然后将下一步骤update任务列表的步骤ID,审批拒绝，则查找上一步骤，然后update任务列表的步骤ID

步骤处理人(actorUser)
步骤ID(actorId) 处理人ID (operateUserId)
1 1
2 2
2 3 一个步骤，是有多个处理人。处理人先检出任务列表，然后才能审批。

视图：待我处理的工作
select t1.taskId,t1.itemId,t3.operateUserId from taskList t1 join actor t2 on t1.actorId=t2.actorId join actorUser t3 on t2.actorId=t3.actorId where t1.state='待检出'

视图:我申请的工作
select t1.itemId,t1.itemName,t1.state,t1.applyUserId,t2.actorId from item t1 join taskList t2 on t1.itemId=t2.itemId

申请时
"1--查找所选流程的第一个步骤
select actorId from actor
where routId =1
order by sortNo
limit 0,12--插入任务列表taskList
insert into tasklist(actorId,state,version,itemId)
values()3--插入任务历史记录
insert into taskhistory(itemId,actorid,memo,operateBy,createDate)
values()
4--修改项目Item的状态为待审批
update item set state='wait_to_approve' where itemId=1"

审批通过
"1--update任务列表的步骤ID为下一步骤ID
update taskList set actorId=
(select actorId from actor
where routId = (select routId from actor where actorID=1)
and actorID>1
order by sortNo
limit 0,1
)
where taskId
2--插入任务历史记录
insert into taskhistory(itemId,actorid,memo,operateBy,createDate)
values()
3--修改项目Item的状态为审批中
update item set state='approveing' where itemId=1"

审批拒绝
"1--update任务列表的步骤ID为第一步的ID
update taskList set actorId=
(select actorId from actor
where routId =(select routId from actor where actorID=1)
order by sortNo
limit 0,1)
where taskId=1
2--插入任务历史记录
insert into taskhistory(itemId,actorid,memo,operateBy,createDate)
values()
3--修改项目Item的状态为审批拒绝
update item set state='jujue' where itemId=1"

⑧ 如何设计一个基于Lotus的可配置的工作流

要实现流程的“可配置”，即相当于由用户自己“组建”流程，那么，对于程序的开发者，要做的事自然就是一个相反的过程（“拆解”流程）。考虑如何拆解流程能使用户重新组建时省力省心，实际上就是设计一个好用的、可配置的工作流的过程。
清楚了我们要做的事之后，在开始做事之前，我们还需要制定一些做事的原则（“拆解”的原则和方向），毕竟，我们的初衷，不仅仅是能把事做完，把事情做好才是最终目标。那么，什么才是一个好用的可配置的工作流呢？我们认为，好的工作流应包含下面几个特点：组建过程简单、快速，易于维护，用户无需培训、易于掌握等。
制定了上述原则后，我们现在就开始来拆解流程了，首先画一个简单的流程图作为参考。
简单流程图
大致看一下图1中的流程图，先不考虑复杂的内容，我们对一个流程最直观的判断是：流程由环节和路径组成。如果仅将流程拆分成这两个元素，对用户来说是非常好理解的。那么下面，我们就尝试使用这两个元素建立可配置的流程。先粗略地拟一下各元素对应的表单需要包含的域：
1、环节文档：环节名称、处理人员
2、路径文档：路径起点环节名称、路径终点环节名称、流转条件
上面两个文档都是配置文档，要建立一个完整的工作流系统，除配置文档之外，我们还要建立一个包含待审批的业务信息的文档（以下称为主文档），主文档要与配置文档相关联，就需要在主文档中记录一些配置文档相关的信息，这里也先粗略地拟一下这些信息：
3、主文档：当前环节、当前用户
相关基础文档建立起来之后，接下来就开始考虑将各个分散的内容连接起来形成一个完整的工作“流”。假设当前主文档处于申请人环节，那么下一个环节是A领导还是B领导呢？从我们现有的配置文档来看，两个环节文档是通过路径文档连接的，那么我们首先要找到以申请人为起点的所有相关路径，搜索结果为：路径1、路径2、路径3都符合要求。接下来就是判断当前文档符合哪一个路径流转的条件即可筛选出唯一确定的一个路径。然后，从唯一确定的路径文档中可获得下一个环节的名称，通过下一个环节的名称搜索环节文档即可获得下一个环节的处理人员。将上述处理过程放大，就可以实现一个任意庞大的流程。
流程流转过程
看上去上面的方案似乎已经完全实现了一个“可配置”的流程，实际如何呢？下面，我们拿一个复杂一点的流程来分析这种方案的优缺点：
有重复环节和路径的流程图
可以看到，“B领导审核”环节和“会计”环节出现了2次，“B领导审核”到“会计”的路径也出现了两次，假设当前环节为“A领导审核”环节，如果通过上面的处理方式，我们搜索到的符合条件的下一个环节是“B领导环节”环节，然而，“B领导环节”以后有2个可能的路径，如果仍按上述方式处理，我们本来要走的路径5可能会走到路径6而导致流程最终无法流经“总经理”环节。为了避免这种情况，我们可以有很多种选择，下面列出了其中的两种：
第1种：将两个“B领导审核”环节命名为不同名称，如其中一个环节名称改为B领导审核2。
第2种：在环节文档中增加一个位置域，标志其所处位置以区别不同位置出现的同一个环节名称，即使用位置取代环节名称作为环节文档的关键字。
采用第1种方式虽然较“笨”，但是可以不修改我们原来的程序，而且流程的组建过程也是最简单的。但是有些用户可能不会接受这种方式，因为在这样的系统架构下，组建流程的管理员需要绞尽脑汁地考虑“第二名称”怎样命名，而且这个“第二名称”不一定会获得最终用户的认可。为了避免这些麻烦，我们可以采用第二种方式。
下面我们看看环节文档中增加了位置域的效果（图4）。采用“位置”域作为关键字，在主文档、路径文档也相应增加当前位置域即可以唯一确定流程的走向。
增加环节的位置信息
在环节文档中增加位置域的方法解决了环节名称重复的问题，但进一步看，我们仍需要为相同环节名称不同位置的两个环节建立两个环节文档，站在系统管理角度来说，这也是一种很不好的方式，因为调整这种重复环节文档中的任何信息（如：调整环节包含的人员）的时候都需要修改2个或者更多的文档（很可能改了一个忘了一个）。因此，我们有必要将环节名称的其他信息和位置信息再拆分，拆分后各文档包含的域有：
角色文档（职位文档）：角色名称、处理人员
环节文档：角色名称、位置
同时，为了配合这一改动，我们还需要将路径文档、主文档中当前的环节信息拆分成当前角色和位置：
路径文档：路径起点的位置、路径终点的位置
主文档：当前角色名称、当前位置、当前用户
解决了同一流程中重复环节的问题后，我们将流程继续扩展，接下来还将遇到不同流程使用同一环节，不同部门使用同一流程等问题。经过同样的分析过程，我们仍将面临为各种配置文档添加关键字域以区别不同情况或再次拆分成不同配置文档的情况。就像上面提到过的一样，选择添加域或者拆分各有有缺点，添加域可以维持程序的易用性，而拆分成不同文档可以减少系统中的重复配置，提高配置文档的可重用性和可维护性。易用性和可重用性这两个特性在大多数时候是一对矛盾体，如何取舍就全靠我们的系统设计人员把握了。我们这里采用的是以易用性为主，可重用性为辅的策略。图5显示了我们这种策略下的一种数据结构。
可配置的工作流的数据结构
刚才我们都是将流程不断扩大来细化我们的拆分方案，现在，我们将从另一个同样重要方向来继续这一过程，即流程环节的增、删、改。上面我们也曾提到过流程环节的“修改”（修改承办人员），一般情况下修改环节都不是问题，难点的在于增加和删除环节。下面我们尝试在“A领导审核”环节和“B领导审核”之间增加一个“C领导审核”，看看我们的系统是否需要做出修改，见下图：
增加环节
增加环节时，我们需要删除路径4文档（起点位置为2，终点位置为3），增加“C领导审核”环节文档和路径8文档（起点位置为2，终点位置为8）、路径9文档（起点位置为8，终点位置为3）。假如当前环节为“A领导审核”，程序流转时仍将使用主文档中保存的当前位置（位置2）搜索路径文档，此时结果可以从路径4文档变成路径8文档，可见这种设计是可以适应增加环节的。同样，这个设计也可以适应删除环节的情况。
注意，环节增删改时还有一种特殊情况，即删改当前环节。这种情况下不仅仅要修改流程配置文档，主文档中的相关内容也要进行更新，如果没有“外力”，主文档包含的当前处理人（这个还涉及了主文档的读写权限）和当前位置是不会自动发生变化的，因此，需要其他手段配合才能实现一个完美的“可配置”工作流。
到目前为止，一个简单的可配置的工作流就算完成了（跟关系式数据库建模的过程非常相似）。经过这一个过程，才发现其实IBM在Lotus WorkFlow中建立的工作流引擎（数据结构）在技术上已经是一种比较完美的方案了。我们绕来绕去自以为会发现新大陆，到了最后还是回到了前人走过的路上（对比Lotus WorkFlow，主要的不同之处是我们这里没有把人员和角色分拆，原因是不想再配置一次names.nsf中已存在的用户）。不管怎么样，从这个简单的可配置流程设计的过程中，我们还是获益匪浅，也深刻认识到一个再完美的工作流引擎也不可能成为普世真理，因为工作流的易用性和适应能力常常是矛盾的，不同的用户会提出不同的要求。因此，技术人员不必执着于技术不可自拔。

⑨ 工作流的创建，需要的数据库如何设计。。。

表单表
流程表
数据表
权限表

⑩ 想做一个基于b/s的工作流引擎设计开发

这个开发平台，数据库怎么选

我才好帮到你

我做好发到哪里