Guido Casper <[EMAIL PROTECTED]> writes: > > Hunsberger, Peter wrote: > > > Guido Casper <[EMAIL PROTECTED]> writes: > > > >>Hunsberger, Peter wrote: > >> > >>>For the end user I believe you always have to have modeling > >> > >>tools for > >> > >>>building work flow, the internal implementation should be > >> > >>completely > >> > >>>transparent; the first time I wrote GUI modeling tools for > >> > >>work flow > >> > >>>was 13 years ago (as a subcontractor for one of the major work flow > >>>vendors) I don't believe the end user expectations have > >> > >>declined since > >> > >>>then! > >> > >>I'm slowly starting to see an unsolvable conflict :-) > >> > >>Some are looking for a tool for developers and some are > looking for a > >>tool for users. And I guess we'll be having a hard time > >>finding a single > >>tool being both. > > > > > > I probably should have written "For the end user I believe > you always > > have to have the option of having modeling tools for building work > > flow...". However, even as written originally I don't see > a conflict? > > I think it's not unreasonable to assume that the modeling > tools will > > be independent of Cocoon. > > > > What is needed is a way to take the models, where ever they may > > originate, and implement them in Cocoon. I think the only > way that's > > going to be generally possible is if Cocoon has some form > of template > > based model (even if it is internally used to generate a > script based > > implementation via some XSLT). > > As I see it, a user tool can only work within a limited context. The > more you try to widen that context, the more the user tool starts > resembling my development tool (with a UI still intended for > end users) > and things get messy.
Hmm, maybe, but I don't think so; work flow modeling has been around for a pretty long time now. The modeling tool I worked on 12-13 years ago is still being sold although I think that package was sold off and the company we did the work for now sells something based on a different code base. The concepts, even then, where well defined, and there wasn't much in the way of work flows you couldn't model. > If my state objects and my action objects both are Avalon > components I > can easily build really complex conditions and state transferring > activities. I hardly see how these may be modelled in a user tool. > > IMO modeling tools are great tools for communicating using > models being > reduced representations of the reality (isn't that what models are > about?) but are usually hard to use to generate the reality > out of the > model. I believe model based engineering is going to be more and more common. You may have heard of Model Driven Architecture? Really, I think this is Integrated CASE becoming a reality for all code... I do know that for what we want to do we can't do it without tools that the business analysts can use to build the work flows; there is no way that we can involve developers for each of the 1000's of work flows that we will building over the next couple of years. > I think it would be a good idea to talk about these two > -a user-oriented workflow tool with a modeling UI and a well defined > limited context > -and a more flexible development tool > > as separate implementations sharing the same interface. > I don't see any reason to limit the user oriented tool? Start from a flexible underlying model, be aware that it should be possible to generate the model form some GUI....
