工作流設計

① 怎麼設計類似工作流的表結構

不難，只是內容多，有時間可以和我交流

② 通過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的工作流引擎設計開發

這個開發平台，資料庫怎麼選

我才好幫到你

我做好發到哪裡