Sunday, March 29th, 2009
Context is in the air. Today, I stumbled via @frankgerhardt upon an article by Trygve Reenskaug (father of the Model-View-Controller paradigm, for those not familiar with his work) and Jim Coplien about a new architecture paradigm:
“The DCI Architecture: A New Vision of Object-Oriented Programming”
by Trygve Reenskaug and Jim Coplien
The article focuses on how to model Use Cases. They advise against using classes, but rather propose to put behavior in algorithms that are expressed in terms of roles rather than classes. Their approach is broken up into data, context and interaction.
- The data that is stored in domain objects that are rooted in domain classes;
- The context that assigns running objects, on demand, to their roles in a scenario;
- The interactions that describe end-user algorithms in terms of the roles.
Thus, data and interaction are brought together in a specific context. The article goes on to further talk about nested contexts, and how traits can be used to implement their paradigm. They say that “if a role is an analysis concept (from the mind of the end user), then a trait is a general design concept that represents the role.”
I am not yet sure how their use of context fits into my attempt towards a taxonomy of context. Clearly their context is compositional and dynamic. Even though they discuss whether roles are to be injected into classes at compile time or dynamically at run time, the actual instantiation of a context, ie which object are mapped to which roles, is always dynamically established. (At least as far as I understood their approach.) Given the assignment of roles to objects their context affect both sender and receiver of messages.
Even though the DCI paradigm can be used to model external context, there is (to my relieve) no magic mechanism in place that switches context behind the programmers back, as many other proposals for context-oriented programming do. I am happy see the notion of context being approached from a compositional view, clearly breaking down what context means in both terms of analysis and design, rather than referring to blurry terms such as the weather and room temperature. Or even worse, telling me that the very meaning of context still has to be defined :)
Some further, more personal, notes and remarks:
- “Even Smalltalk, whose initial vision of objects and a dynamic run-time environment was truly visionary, fell victim to the class compromise,” provides me with a new incentive to look at prototype-based systems, such as Self, and to explore new compositional abstractions built from object fragments and aliases, as I have started doing with Cells and Protalk. For example, how would a system look like whose main abstraction are traits rather than classes?
- “There is another key learning: that domain classes should be dumb. [...] We must separate simple, stable data models from dynamic behavioral models,” reminds me of one of my initial visions for Fame (a now abandoned project) that was to turn Fame models into a typed subspace within a Squeak image. The idea there was to have this type model in your Smalltalk image, and then check the type annotations given in the source code not at compile time but rather generate runtime assertions. Which is, by the way, what I as a 2nd semester student thought that Java’s type system would do. I recall how shocked I was to learn that type checks are performed at compile time only!
- And finally, I wonder how the composition of a system into dumb classes and smart interaction contextes is going to match the grouping of the system’s vocabulary (ie identifier names, etc) by topics. We know that classes and topics do not align well, will DCI do a better job? As long as current structural abstractions fail to capture the user’s mental model of a system, which is what Trygve Reenskaug and Jim Coplin’s article argues, any visualization based on structure alone must fail to address the developer’s model as well. And this reinforces my conviction that the vocabulary- and thus domain-based layout of Software Cartography is the way to go in software visualization.