This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I am currently doing a document workflow system as my part of final year project. I am doing sponsored based project which means i am developing a document workflow system for an orgnization. Recently, I was ask to come out with the feature and flow chart of the system but the problem is i dont really understand what is actually document workflow system. I am currently in the planning stage. I am really weak in programming so i really help of kind samaritan to help me wiith this. For your information, I need to develop this DCS in purely java. I really hope that someone out there can help me out with this problem. Thank you.
Somebody will probably move this to another forum, but let's start anyhow.
Document workflow probably means something like one person authors a new document, passes it to the next person who reviews it, passes it to another for legal approval, passes it to another for deployment and it finially winds up on a web site or document repository.
Workflow in general means four things to me, and the acronym QRST is a cute way to remember them, though not quite in the right order.
Sequencing is figuring out the next task. When an author writes a document, does it need legal review or not? You can do workflow without a sequencing component if each person picks the next task and sends it explicitly.
Routing is figuring out who should get the work next. Legal review on Financials should go to Bob, but Information Technology should go to Larry.
Queueing is putting something into an in-box and delivering it to the next worker. You might have in box management, prioritization, reassignment, etc. EMail is perfectly good queueing in some cases.
Timing is checking to see if things are done on time and taking some action if not. If legal doesn't finish review in 3 days, send a nasty note to their boss or route it to an error queue.
In software design you can make these quite independent.
For a school project I'd write up a list of stories - ways people interact with the system at a fairly fine grained level - and try to implement at least one or two in each of those four areas. That way you can show you grasp all the concepts and make your instructor believe you could fill in the other stories with time.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi