I think your vision of “workflow” as an utopic target is correct.

From my experience developing with Naked Objects, I think that even if you try to model a process-driven model (somehow a contradiction), the NOF paradigm will still give more power to the user than the controller (i.e. the process).

Far from dangerous, this proofs to be a very powerful aspect. Turning the user into a mere process follower tends to either fail in the long run (….probably because is not in the homo-sapiens nature…I guess is the same reason why Taylorism doesn’t work either from a human viewpoint).

Sebastián

I think my main reason for advocating events as distinguished primitives of design/modelling is the power this gives in terms of composition, and therefore abstraction and reuse, of behaviour (see http://www.metamaxim.com/download/documents/OEPM.pdf ). I haven’t seen anything like this built from the standard notions of OO programming (objects, methods, properties and hierarchical inheritance).

> One of the issues I have with your concept, though, is that it is a tool for simulating
> the final system. I think your argument would be more powerful, if, as with Naked
> Objects, the modelling exercise led directly into the delivered system, with full round-
> trip modification.

That’s a fair comment. But I don’t think it is an issue with the *concept* so much as our particular current implementation of it. I see no reason in principle why what you propose could not be done — although how best to do it is another matter!

Rgds
Ashley

When I’m working with clients, we strive, DDD style, for an ubiquitous language, where everything in that language translates, very directly, into a construct in the final code — as you say, into an object, or a property on an object, or a method. The fact that I have done this on a large scale, and large complexity business models, without ever coming across the need to model an event (in the sense that you use it) combined with the fact that such things wouldn’t anyway translate into any distinct construct within the target (OO) technology platform, is why I can’t see any value in introducing them. (Note that the applications we work on don’t always end up running on Naked Objects – sometimes we are using that just for the prototyping – but they do always end up being OOP).

I have not (at least in recent years!) fallen into the trap of claiming that pure OO is the only correct (or even the ‘natural’) representation of the real (business) world. Just that I have found it to be the most effective.

If the target platform was one in which Events (in the sense you use them) were tangible software constructs, then, of course, it does make sense to seek to capture requirements in terms of events. One of the issues I have with your concept, though, is that it is a tool for simulating the final system. I think your argument would be more powerful, if, as with Naked Objects, the modelling exercise led directly into the delivered system, with full round-trip modification. One of the big advantages we have is that we are effectively modelling in a language (can be Java or C#) that is ultimately capable of implementing, reasonably well, all the requirements of a business system. My concern about process/event language is that, even though it can be proven at a theoretic algebraic level that they can model all requirements (as can a Turing machine), in practice they are not considered to be comprehensive programming languages. So you end up having to augment your process/event language with implementations in, what shall we call it, a ‘pragmatic’ programming language.

I think I understand your difficulty with “events” better now.

I think my comfort with the notion of event stems from my background in modelling (JSD, Syntropy, Catalysis, etc.) and process algebras (CSP, CCS, etc.) where the concept is well embedded.

It doesn’t have a counterpart in OO programming, so you have to represent an event (in the modelling sense above) as either a method or an object. If this your background/focus, the concept of “event” is probably a bit alien.

Rgds
Ashley

P.S. I haven’t written a book — but perhaps it’s a good idea!

To me Cancel is a method on Order, and withdraw is a method on Account (whether or not they create Cancellation or Withdrawal objects in the process). I understand that you model cancel and withdraw as events, but I just can’t think of events that way.

My comment about your approach not being OO was possibly too strong – but as you say it is not standard OO. (Ironically, I do think of Naked Objects as being just plain old OO – even though everyone else seems to think its very radical!). I certainly don’t have any problem with AOP or the approach of inheritance by mixin instead of by hierarchy – that fits very well conceptually with Naked Objects, though we haven’t really used AOP in anger yet.

I guess it is just this Events thing that is the real blocker for me. Incidentally, there is no Event concept in Eric Evan’s Domain Driven Design – the word doesn’t even feature in the index. Not that I consider DDD to be any kind of definitive reference (though an increasing number of people seem to) -to me it is just an aspirational idea plus a number of very specific patterns.

I will, however, order and read your book.

Richard

Many thanks for your comments.

> You use the term ‘Event’ somewhat differently to the way that I use it in my modelling. I
> use it in a rather narrower sense. To me an ‘event’ is a notification that something has
> happened somewhere OUTSIDE the system that you are modelling, such as ‘Customer Has
> Died’, ‘Order Has Been Cancelled’.

I view events exactly in this manner. I don’t think we differ here at all. However the names you use: “Customer Has Died”, “Order Has Been Cancelled” are really names of states, of Customer and Order respectively. You can tell that they are states because they persist: the predicate “Customer has died” remains true through time. The corresponding event names are, I hope you will agree, “Customer Dies” and “Someone Cancels the Order”; and these are not persistent predicates, so not states.

> So, if I was writing a banking system where I was providing specific functionality for
> opening accounts, making withdrawals and/or transfers, I would not personally refer to
> Open, Withdraw or Transfer as ‘Events’.

Can you tell me what you would regard as “events” in world of Accounts? Surely “Close an Account” is not that different from “Cancel an Order” (which you give above as an example of an event)? They both represent business decisions that result in change to the state of an object represented in the system.

> The issue about involving more than one object is a bit of a red herring, I feel.

Good. I agree with that.

> Personally, your representation does not resonate with me.

That’s a pity – as many of our ideas are very similar. In particular, we agree on the main point: the desirability and feasibility of eliminating the “Controller” layer. Perhaps what we are doing is “Naked Events”?

> I also don’t think yours is really an object-oriented representation at all: it is an
> event-transition representation.

This is a comment I don’t understand. The event-transitions are used to model object behaviour, in a good object-oriented way. There are certainly differences between “standard” O-O and what we have been doing, relating mainly to the inheritance model. We have (for very good reasons) adopted a pure mixin approach to inheritance, rather than a hierarchical one. This comes very naturally from our use of CSP (per Tony Hoare) composition as the means of combining partial behavioural descriptions. Other than that, I think we are pretty much in line with O-O.

> I originally read Engineering Science at university, and 90% of the degree seemed to be
> about considering alternative representations for the same problem space (Laplace
> transforms, z-transforms and so on).

Mathematics myself (Cambridge). So we have similar background here, and I understand what you are getting at.

> I think that the approach I’ve advocated is gaining a lot of ground, particularly with
> advent of the Domain Driven Design movement (with which it is very compatible). But new
> representations emerge all the time: Aspects being in the ascendancy right now.

Indeed. CSP based composition applies very nicely to modelling stateful (behavioural) aspects. And CSP composition allows local (modular) reasoning across composed behavioural descriptions, which in my book is “a must” if you are to retain intellectual control over complexity in the world of Aspects.

I think we both aim to address DDD.

All the best,

Ashley

I am very familiar with these arguments, and I accept that far more people would agree with your position than with mine.

In particular, most people would agree with your statement that ‘business procss is a very useful scoping mechanism’. After all, almost every methodology, from waterfall to agile, is ‘use-case driven’. But I do not agree with this. Use-case driven analysis leads to poor object modelling in my experience. My position on this is that use-cases should be used to validate the object model, not to identify it. That is a subtle but very important distinction.

I have been in several situations (some documented in the book), where there has been a very strong pro-process lobby. Indeed I have been many times told that ‘you can’t possibly model the business without starting from the business processes’. Or that ‘the business processes fundamentally ARE the business.’ But we have, and we have succeeded. The DSFA will confirm that we designed and built their complete Common BOM without anything that resembled a business process representation. When we were done, another consultancy came in to do the change management programme, and the first thing they did was draw enormous process diagrams that covered the whole wall of a large room. It added no value and was never ultimately used. In fact the DSFA’s own conclusion was that this was a much weaker representation of the essence of their business than the BOM itself.

You are not the first person to suggest that the Naked Objects concept could be applied to a (process-like) ‘higher level abstraction’, but I’ve yet to see anyone do it. If you do decide to go ahead with it, I would, of course, be very interested to see the results.

Richard

i strongly sympathise with your aversion against “command-and-control”-type management, but i’m afraid that this (rather then true employee empowerment) still is the dominant form of management – regardless of how Naked Objects deals with business processes and workflows.

the fact that business processes are contested at all is because they essentially comprise the true value of an information-oriented business – hence the urge for managers to get them under their control (often with sinistre intentions).

the use of a “Task” object as you describe it is the ad-hoc creation of an element of business processes. nothing inherently wrong with that.

but you *do* lose the other elements of business processes and workflows that can be very useful:

1. the fact that a business process is a very useful scoping mechanism: some entities (aka process variables) are needed during the course of a business process (and need to be persisted because the process is long-lived) but not afterwards.

2. the fact that a business process is a state machine that is a very effective means of capturing/communicating the more coarse-grained flow of information and control amongst objects (or services; but i guess you don’t like that word). your use of “Active” and “Completed” also strongly points into that direction. just like you did it with “Task” it’s probably quite straighforward to create a “BusinessProcess” in an ad-hoc fashion with Naked Objects…

3. contrary to your statement that business processes “do not work in practice” i would argue that many processes do have a very useful default flow – the default transitions in the state machine that the process is. many users may be thankful for a “now proceed as usual”-button that essentially tells the business process to take the default transition. i suppose your argument about business processes “not working” is an argument against to rigidly defined processes transitions.

i must confess that i don’t know how this fits with Naked Objects, other then having a hunch that it is somehow missing as a higher abstraction above the domain model and that Naked Objects and it’s “reflective” UI could very well make good use of workflow-related features, as hinted at above…

regards,
gerald