Monday, October 2, 2006
We anticipated that on Monday we would focus on the “Modeling and Designing Enterprise Applications” track. However, the chair for that track, Martin Fowler, couldn’t attend, so a bunch of the interesting talks for that day didn’t pan out the way we had hoped. Dave Thomas gave the introduction in Martin Flower’s place and shared his skepticism (to put it mildly) about the promise of Domain Specific Languages and their relation to modeling.
Next, we took the opportunity to attend a session by Bertrand Meyer, the Eiffel / Pre-conditions guy. The talk was part of the “Abstractions for Concurrency” track and presented his recent work on easier and more natural support for managing the complexity of concurrency in an OO language, that is, SCOOP: Simple Concurrent Object Oriented Programming (JAOO slides).
The basic idea is to simplify programming for concurrency by only allowing concurrency to happen on at the object instance level while providing means for explicitly controlling synchronous sequences of operations when required. This is definitely an interesting concept and I would like to read up on it further. SCOOP is implemented in Eiffel and some semblance of a working implementation is available here: http://se.ethz.ch/research/scoop/
Here is my (Louis’) personal take on Bertrand Meyer’s presentation:
This was my first opportunity to see Bertrand Meyer present at a conference. He is a very interesting, animated and engaging speaker. I could see that he would make an ideal university prof, frankly I would love to be in one of his classes.
OK, so what is SCOOP all about?
Disclaimer, although I’ve heard quite a bit about Eiffel and understand the basic concepts of design by contract, invariants, pre-conditions and post conditions, I know very little else about Eiffel. That said this is what I understood SCOOP to be.
SCOOP is an extension of Eiffel that provides built in support for concurrent programming. New basic constructs have been incorporated into the language to provide asynchronous and queued access to an object. The mechanism seems to be quite elegant, it strikes me as essentially a broadening of the concept of contract to incorporate what I would loosely call delayed execution contract. So how does one write such a contract? At a very high level, you simply need to do two things:
- at object instantiation time you declare that you want a delayed execution contract to apply to any message that you subsequently send to the object
- the pre-condition invariant for any method that may be accessed asynchronously should be thought of and written in terms of a “wait condition”.
Actually, from Bertrand Meyer’s perspective, the old definition of pre-condition is simply a specicialized type of “wait condition” — in his words (as close as I can recall, anyways) a pre-condition in a sequential program is simply a compiler optimization of a wait condition.
Another nifty feature of SCOOP’s built in support for concurrency is the way that it allows an object to terminate it’s current execution process if it has received a message from another higher priority thread. The object is not required to do so, but it may depending on some other declaration which I believe (??) is associated at the method level.
Admittedly this is all pretty experimental stuff and may turn out to be seriously flawed, but at first glance the asynchronous programming model offered by SCOOP is incredibly simple and elegant. SCOOP is free and available for dowload.
I left the presentation wondering again (because I have wondered the same thing before) why it is that Eiffel has not gone anywhere.
… back to Cesar’s much more enlightening account. Louis
The other highlight on Monday was a double session by Eric Evans on Domain-Driven Design (http://www.domaindrivendesign.org). This presentation went over the basic concepts of his approach to design. The most important concepts were: Ubiquitous Language, Bounded Context, and distillation of the Core Domain. For Louis and I, the discussion raised quite a few questions and provoked lots of discussion and thought. I feel that, on our project, we have made good use of the Ubiquitous Language concept, but that we haven’t really put into practice much of the other ideas from Evan’s book.
In particular, I feel that our next step is to start making use of things like Bounded Context and Core Domain to really insulate the key domain logic in the application. I think we can benefit from putting this into practice right away, and attempt to apply it to our current development effort (one that’s adding a coherent and significantly large and complex set of elements to the domain model).
All in all, this presentation reminded me that on our project, we still have a very difficult time keeping the expression of the domain elements and rules separate from things like infrastructure and application logic. The result is that we are unnecessarily increasing the complexity of the system when the complexity of the domain is itself enough of a handful.
There were two more interesting presentations, one about Event Patterns, prepared by Martin Fowler but presented by someone else from ThoughtWorks in his absence, and another by Erik Dörnenburg (also from ThoughtWorks) on software visualization. The Event Patterns talk was an extension of some ideas Fowler presented last year at OOPSLA and confirmed for Louis and I that we have quite a bit of experience in this problem area.
The software visualization presentation was quite cool. The idea was that it doesn’t take all that much work to produce some very useful visualizations of your code (that big mess of too many packages, classes, and dependencies) by doing some code analysis and transforming the information into a form that can be plotted using GraphViz. In one very simple example, he showed that a Spring config file could be easily transformed into a dependency graph (so obvious it hurts) and in another, he showed how key inter-component and JAR dependencies could be graphed based on information contained in a project’s pile of ant build scripts.
The last speaker of the day was Alistair Cockburn, who gave his “Methodologists are Blue-Green Algae and Methodologies as Swimsuits” speech. This was a very interesting and entertaining talk. He described what he does as a methodological, which is to immerse himself in project teams and study how people actually work on software projects. Some of his insights include:
- there is no one-size-fits-all methodology (agile or otherwise), hence the swimsuit metaphor
- software development is like a game that is both cooperative and goal-based; he compared it to rock climbing, in which a group of people must trust each other and work together in order to reach the top of a cliff
- something interesting about a project management version of the agile alliance: the “Declaration of Interdependence”
- his new book: http://tinyurl.com/famze