Naked Objects
Naked Objects - a BOF session after the end of the normal day here. Naked Objects - oddball thing about the name - book lookup on Amazon yields some "interesting" nearby subjects
The idea - to get rid of all the extraneous things - reduce to the leanest, bare essentials. Four layers in classic architecture:
- Presentation
- Application/Controller
- Domain Object Model
- Persistence
Naked Objects eliminates the controller layer - encapsualtes all business functionality on the entity objects (note - this elides any issues with session access to behavior that is permission based). Make the presentation layer generic. Make the persistence layer generic. In theory, generate the presentation and persistence layers from the domain model. I detect MVC being reinvented in the Java sphere :)
An example - conference registration:
- BOF
- Delegate
- Room
- Resources
- Company
Noting that a delegate can be part of a company. The demo proceeded using Together/J to build the domain using UML (ed. - I am historically very wary of this kind of tool and development model. In particular, I find it easier and faster to just use a browser :) ). After building the four domain classes, a build yields a simple set of classes that have some basic UI behavior (not unlike a Smalltalk inspector, although less powerful than Trippy to be sure). Relationships? There's a visual programming way of doing that (like PARTS, noting that we've been there, and it doesn't scale...). Important note on that being that the Together/J linking behavior is not a necessary part of Naked Objects - it's a part of Together/J that is independent of what you are doing.
My main concern would be the assertion that we can make the UI generic. In my experience, lots of work ends up going into the UI that is only marginally related to the domain - ways that the UI can be configured by the end user (in BottomFeeder, for instance, the ability to zoom/unzoom different parts of the UI, and how that depends on the current UI state. I guess I just have a hard time with the notion of a generic UI. It flies in the face of what I've had to do with Bf.
Now a second session on ModelScope - a prototyping tool. The notion is model driven prototyping, using state transition diagrams. The tool interprets that to create the model. No code generation from the tool - it generates models. Events change the system, but may not be associated with a single object - thus the usage of state transition diagrams. No GUI for the front end, so things are loaded from a front end text file. They have an engine that generates models.
MODEL OT2004 OBJECT BOF NAME BOF Name ATTRIBUTES BOF Name String STATES proposed scheduled cancelled TRANSITION @new*Propose=proposed*Schedule=scheduled @any*Cancel=cancelled OBJECT Room NAME Room Room ATTRIBUTES Name Name String STATES available TRANSITION @new*Make Available=available available*Schedule=available EVENT Propose ATTRIBUTES BOF BOF BOF Name String EVENT Schedule ATTRIBUTES BOF BOF Room Room EVENT Cancel ATTRIBUTES BOF BOF EVENT Make Available ATTRIBUTES Room Room Room Name String
Then you run the model generator (ed. - Java based - wouldn't Smalltalk or Lisp be way, way easier for this sort of thing?). You get a model that allows you to work with the state transitions as they have been defined. Hard to tell much at this point - needs more fleshing out.
Comments
Untitled
[Carl Gundel] March 30, 2004 20:04:18.468
This is supposed to be a new idea? How many Smalltalkers have invented this whole thing all by themselves. We built a prototype system just exactly like this back in 1996 at Kronos. No special tools were required.
Naked Objects - pity the user
[Isaac Gouy] March 31, 2004 10:25:05.215
a hard time with the notion of a generic UI
You aren't the only one.
See "The Emperor Has No Clothes"
Naked Objects - the users love it!
[Richard Pawson] April 1, 2004 15:00:47.539
The largest system that we know of built according to the Naked Objects pattern (which a completely generic auto-generated UI) is at the Department of Social & Family Affairs in Ireland - an 80 user system for benefits processing. In a post-implementation survey of users, not only did they report that they strongly liked the look and feel of the UI, and that they valued the flexibility it offered in choosing how to approach a task, but 15 out of 15 users interviewed reported that the system 'contributed positively to their sense of job satisfaction'. That's not something you hear very often in regard to the hand-ctafted UIs that so many people seem to beleive are necessary. Oh, and this is one the few cases where the system has genuinely enabled massive organisational change and the organisation is already getting substantial benefit from it. Before it went live they had a backlog of 20,000 claims. That backlog is now down to a steady 3,000 which is their operational goal.
Re: Naked Objects
[James Robertson] April 1, 2004 19:53:42.408
Comment on Naked Objects by James Robertson
Richard
I can find anecdotal evidence to support nearly any assertion. I'm still very unconvinced about this kind of generated UI
NO and MVC
[Patrick Logan] April 2, 2004 1:47:14.880
I detect MVC being reinvented in the Java sphere :)
Except NO generates the V and C automatically. If you are happy with the defaults, you save a lot of effort. If you are not happy with the defaults, you can create new class-specific defaults and write a new V and C for that class.
I wrote a mostly operational NO for Python and used it in some small examples. I think it has potential in some end user situations and certainly prototyping. Not sure how widely for end users, but the NO's results are encouraging.
Naked Objects and ModelScope
[Ashley McNeile] April 2, 2004 3:00:40.057
When I talked about ModelScope at OT2004 I think I explained the relationship between Events and Objects in a rather confusing manner. The idea is that an Event is associated with, and can affect the state of, multiple Objects. For instance, a funds transfer between accounts is one Event but affects two Objects (two accounts) and changes the balance of both. This is an important difference between Events (as in ModelScope) and Messages (as in OOP), as Messages only have one receiver so only affect one Object. Messages can be used to implement Events, so Events are at a higher level of abstraction than Messages. Other modelling techniques that have also have concept of Event similar to that in ModelScope are: JSD (Jackson), Syntropy (Cook and Daniels) and Catalysis (D'Souza and Wills). An interesting question is this: Would the Naked Objects approach be improved if it too supported Events? It would seem likely, as a user interface should work at the Event rather than the Message level of abstraction. Another small point: It is not quite correct to say that ModelScope "generates a model". It is a model interpreter, so it executes a model without code generation.
Naked Objects and events
[Richard Pawson] May 7, 2004 0:57:00.375
Ashley McNeil said: "Would the Naked Objects approach be improved if it too supported Events?" I don't think so. I believe that your events construct merely encourages poor object modelling. You cite the example of a bank transfer as an 'event' that impacts two bank accounts. A bank transfer should be an object in its own right.
Naked Objects and Events
[Ashley McNeile] May 25, 2004 1:58:03.725
Richard Pawson said: "I believe that your events construct merely encourages poor object modelling."
My dear fellow, you can't just make an assertion like that and expect to be taken seriously! What is your reasoning, please!
Richard Pawson also said: "You cite the example of a bank transfer as an 'event' that impacts two bank accounts. A bank transfer should be an object in its own right."
A number of respected OO domain modelling approaches encourage the identification of Events, for instance: JSD, Syntropy and Catalysis. All of these approaches allow that a single event may impact multiple objects. Of course, in an OO paradigm, events are ultimately implemented as objects themselves. There is no evidence or suggestion that I know of that this leads to poor object modelling.