This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Naked Objects
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
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.
Previous Topic
