Modelling work-flow plus interaction with a database - quick and accessible options

Question

I'm wanting to model a (proposed) manufacturing line, with specific emphasis on interaction with a traceability database. That is, various process engineers have already mapped the manufacturing process - I'm only interested in the various stations along the line that have to talk to the DB.

The intended audience is a mixture of project managers, engineers and IT people - the purpose is to identify:

• points at which the line interacts with the DB (perhaps going so far as indicating the Store Procs called at each point, perhaps even which parameters are passed.)
• the communication source (PC/Handheld device/PLC)
• the communication medium (wireless/fibre/copper)
• control flow (if leak test fails, unit is diverted to repair station)

Basically, the model will be used as a focus different groups on outstanding tasks; for example, I'm interested in the DB and any front-end app needed, process engineers need to be thinking about the workflow and liaising with the PLC suppliers, the other IT guys need to make sure we have the hardware and comms in place.

Obviously I could just improvise in Visio, but I was wondering if there was a particular modelling technique that might particularly suit my needs or my audience. I'm thinking of a visual model with supporting documentation (as little as possible, as much as is necessary).

Clearly, I don't want something that will take me ages to (effectively) learn, nor one that will alienate non-technical members of the project team.

So far I've had brief looks at BPMN, EPC Diagrams, standard Flow Diagrams... and I've forgotten most of what I used to know about UML... And I'm not against picking and mixing... as long as it is quick, clear and effective.

Conclusion:
In the end, I opted for a quasi-workflow/dataflow diagram. I mapped out the parts of the manufacturing process that interact with the traceability DB, and indicated in a significantly-simplified form, the data flows and DB activity. Alongside which, I have a supporting document which outlines each process, the data being transacted for each process (a 'data dictionary' of sorts) and details of hardware and connectivity required.

I can't decide whether is a product of genius or a crime against established software development practices, but I do think that is will hit the mark for this particular audience.

Answer 1

It will be difficult to produce one diagram of sufficient detail to satisfy managers, engineers, and IT people. The IT people will want to know the sproc parameters, the engineers will be concerned about fault cases, and the managers will get bored by all the details and start fiddling with their Blackberrys.

What is the point of the presentation? You said -

the model will be used as a focus different groups on outstanding tasks; for example, I'm interested in the DB and any front-end app needed, process engineers need to be thinking about the workflow and liaising with the PLC suppliers, the other IT guys need to make sure we have the hardware and comms in place.

First, think of the presentation as a map, not a project plan. Make it simple enough that the managers can understand it, and you can be certain that the engineers and IT people will also understand it. (The converse is not true.)

Second, use the simplest, most obvious diagram possible. Annotate the diagram with footnotes for the details so the diagram does not become cluttered or grow too large.

I'm assuming that the purpose of the initial presentation is to achieve a common group comprehension of the overall project. To that end, I suggest using pictures of each component with lightning-bolt lines to indicate points of DB interaction (don't clutter the diagram with a bunch of DB icons, or try to tie all the interaction lines back to one DB icon, that will clutter the diagram and add no value). Just put a footnote number on each interaction line, and print the footnotes on a separate page for reference. Do not display the footnotes on your presentation slides, but just talk about them and refer to the diagram. Make the footnotes available as handouts or post/email them later. Keep the audience focused on understanding the big picture. Let the focus teams work out the details once they reach a common understanding.

Answer 2

Trying to find a single model to effectively communicate an entire system is a fool's errand. I know that RUP has fallen out of favor with Agilists. But I think the real problem is the same problem I see with some Agile projects. People attempted to use an approach without fully understanding it.

You mentioned that you only want to create as much documentation as is necessary to effectively communicate the design to the audience. This is RUP in a nutshell. You aren't required to fill out every artifact in the catalog. It just provides a number of artifacts and templates as a starting point for communicating. It's up to the individual to decide which ones are necessary.

There is a great book, Agile Modeling, that discusses this approach (called eXtreme Unified Process), written by Scott Ambler.

Edit: I haven't read it yet, but there also appears to be a sister book to Agile Modeling called Agile Documentation

Answer 3

Looks like you're wanting to cover both the physical and logical architecture. So just use whatever is easiest for you and make sure the labeling and the keys are clear!

Answer 4

Omondo did an ambitious try to cover physical (e.g. database) and logical (e.g UML object) integration by creating a Database profile. I used the tool and must admit it really worked well. The idea is to create java annotation in code live synchronized with the model and database stereotypes.

What I like with this tool is the full pojo support. From object to database and from database to model. Just marvelous for me !!