« Observing JAOO | Main | Remember to tag your photos »
Object Oriented Architecture As It Should Have Been – Agile Architecture
By Rolf Njor Jensen | September 30, 2008
This session – Jim Copliens: Not your Grandfather’s Architecture: Taking Architecture into the Agile World started in the right mood – loads of people coming in and great anticipation. A stuffed session room means great turnout – and as it showed – some even came in vain (Jim will be giving the talk again, wednesday in room 222 at 10:30 AM).
One of the great things about Jim is his passion for the subject – he clearly feels strongly about his profession. Claiming that everything has fallen into place the past couple of months, we will now be able to do object-oriented software the way it was envisioned to be done – thanks to a new (or not so new?) way of thinking about architecture
So he kicks off his session by asking for a show of hands on people doing agile – which turns out to be quite a few – which then makes Jim go on and compare agile with teenage sex – everybody says they’re doing it – but nobody does it very well 
With the icebreaker over and done with, Jim states that XP and Scrum quite leaves out the architecture, and this new and exciting thing he has thought up together with some other people is will let us do agile architecture – and make it possible to make object oriented software the way it was intended to be done. Jim calls this method DCI (data, context, interactions).
Now – having attended this one talk by no means gave me a deep understanding of Jims ideas – for the time being this post will therefore be a recitation of the more memorable quotes and points of the talk. When you have read those (or before), please go see the draft version of Jims new book on this, and maybe even go play with the Baby IDE.
Points that translate into bullets 
- Creating the whole architecture using DCI will take less time than Frank Buschmann uses on an architecture review.
- Architecture consists of two parts – the form (what the system is), which is the inherent domain model (and has nothing to do with the requirements), and the structure (what the system does) -which has everything to do with the requirements.
- Focusing solely on the structure (which predominant agile methods tend to do) obfuscates the form of the system – and gives bad architecture.
- Predominant technology (C# / Java) does not inherently support expressing the form of a system in a OO way
- Java is a toy language
- Refactoring is bad – it is not lean. It is good and necessary when done to keep your software in shape – but avoiding it alltogether is much better. Put in other words, it is not Lean to do a lot of refactoring .
- A good architecture reduces waste and inconsistency – and supports whatever is going on in the domain. A good architecture also gives us habitable code – we want to live there, and the users want to live there, i.e. use the system.
- There is (relatively) static form in the domain – but the structure changes.
- Draw instance diagrams, not class diagrams – users care about objects, not classes.
Jim went on to present his DCI idea – and this is where I think he sets himself apart from the pure technologist vs. pure methodologist presenter. At any time, he dives right into very specific technological issues and problems about e.g. programming language design – but they are motivated by problems and issues in real world and in-use methodologies and practices. Basically he presented a new architectural approach (including classes, methodfull roles (could be traits), methodless roles (could be interfaces in the Java sense)) and identifiers.
I’m quite excited about these ideas – and just having met Jim on the conference floor, I can tell you that he is pretty revved up about it too, claiming that something big has just happened today.
So watch out for that second talk if you missed the first
September 30th, 2008 at 7:59 pm
“which then makes Jim go on and compare agile with teenage sex – everybody says they’re doing it”
I should just clarify he meant sex BETWEEN teenagers, not set WITH teenagers. Probably worth clarifying that!
September 30th, 2008 at 8:47 pm
Haha, I wouldn’t have guessed it to be otherwise. After all there is teenage sex and then there is pedophily (if I spell that correctly). Two different things that have different names.
September 30th, 2008 at 10:15 pm
And I strongly disagreed with Jim about java being a toy language – of course you can do it – the construction is perhaps not as elegant … Anyway, I am looking forward to reading Jims book!
September 30th, 2008 at 11:22 pm
Can anyone sum up what happened at the BoF session afterwards? Sadly I missed it.
October 1st, 2008 at 7:13 pm
More precisely, the sex comment was like this:
Agile is like teenage sex – everyone talks about it, very few are actually doing it, and those who do usually don’t do it very well.
October 1st, 2008 at 9:47 pm
There is already QI4J – an existing Java Framework for this type of programming (composite programming). It was developed by Rickard Öberg.
It is a transitional step to a future language that supports the concepts of composite programming directly (as for instance scala does already in many ways).
Just check it out, there is already a lot of documentation material and release 0.4 is out since two weeks ago.
qi4j.org
Michael
October 5th, 2008 at 4:11 pm
Hej, Rolf — thanks for the nice writeup on the talk! Let me offer a couple of clarifications on all of the above.
First, regarding refactoring: I don’t think I said that you should avoid it altogether. You should leave code cleaner (mere tydeligt) than you found it, but you should not expect refactoring to rescue you from weak architectural practice. Refactoring is about structural improvements that leave the functionality invariant, and it’s difficult to reason about functional invariance when making coordinated changes across architectural units. But it’s something I do, and that good coders should do, when making changes within architectural units.
More importantly, the core DCI concepts and the name itself come from Trygve Reenskaug, father of MVC. I’ve supported Trygve and provided useful input and feedback on DCI over the years — and particularly in recent months — but history should remember him as the patient explorer who brought this idea to life. Sometimes it gets a little difficult to separate who contributed what, but as someone who has worked closely with Trygve on this I want to be clear that the original ideas are his.
The main ideas behind DCI are to support a highly dynamic association between roles and objects that changes with every Use Case scenario; that roles take on the identity (in terms of the binding to self or this) of their associated object when they execute; and that the algorithms derived from end-user Use Cases directly be readable in the source code.
Various languages and frameworks address various of these problems. For example, Scala’s traits cleanly allow one to associate roles with objects and solves the injection problem. Python can very elegantly and directly express the semantics of class composition. C++ can also do the class-gluing in an elegant but static way; it is expressive and efficient, but leads to large configuration management costs in most environments.
Qi4J is an O.K. interim approach to achieve class composition in Java, but it’s not clear whether it in itself supports (or even allows) the DCI notion of dynamic role/instance association. Michael, can you clarify this?
However, none of these approaches lets me reason about the Use Case algorithm solely in terms of roles. No language solution in itself provides a solution to dynamically map roles to objects, though this easily can be encapsulated in Context objects in most languages. Qi4J’s contribution seems to be limited to a set of annotations that allow a Java programmer to express the kind of semantics one gets with traits in Scala (much as Michael says above), but doesn’t say anything about scenario expression or management.
So we still have work to do. Trygve’s Squeak implementation achieves the full vision.
JaOO was a great event for DCI in that it provided a melting pot for Lars Vonk’s Groovy implementation, Serge Beaumont’s Python implementation, Bill Venners’ Scala implementation, some noble attempts in Java by Agata Przybyszewska, the Qi4J input from Michael and Rickard, and lots of other input from lots of other bright people. It was gratifying that most people really get this — enough that there were lots of little groups sitting off in their corners at the conference slinging DCI-like code. This is much more than just a programming technique; it bodes broadly for design and for the highest-level patterns of software architecture. It was gratifying that the folks at JaOO got that (well, maybe one or two people didn’t…) Watch for an article series on artima.com where this new little community will give away its ideas for the greater good. We’re having fun and hope more people join us!
(For those who want to learn more about DCI in detail, get the paper from Trygve’s home page at http://folk.uio.no/trygver/2008/commonsense.pdf).
A Ruby implementation, anyone?
January 10th, 2009 at 7:02 am
I think I can respond to the “notion of dynamic role/instance association” in Qi4j.
If you mean whether you can assign any behavior to any ‘object instance’ in runtime, then the answer is; “No, we have been there and it is a nightmare to troubleshoot such systems. We appreciate type-safety and predictable structure, which variable instance types doesn’t allow.”
However, we recently added (not yet implemented) “Abilities”, where we have recognized that the behavior/interaction is purely defined by the client context, and we have concluded that the object instance must have a particular “Ability” for it to be able to fulfill the context role. So, the Ability is declared as a PartOf the object instance (composite in our terminology), which allows the ability to have non-public access to the guts of the object instance.
So, if I have a composite type called Person, I can “add” an ability, such as Employable, to such Person at assembly time, which a new subsystem can interact with, without affecting Person’s other contexts. And the Employee role will only interface with the Employable ability of the Person.
A final note, we have gotten a lot of flak for choosing to build on top of Java, and not create a new language instead. What people tend to forget is that it takes a few billion dollars of investment to get a language to the level of Java or dotNet, in terms of tools, acceptance, libraries, knowledge-base and developer training. Such practicalities are often forgotten in academic debates, and we have consciously taken a pragmatic approach of getting our ideas out there now and not in 10-15 years. However, we don’t rule out the possibility of Composite Oriented Programming (COP, nothing to do with Coplien
) languages in the future, either from us (the Qi4j team) or from others.
May 8th, 2009 at 4:28 am
[...] http://blog.jaoo.dk/2008/09/30/object-oriented-architecture-as-it-should-have-been-agile-architectur... [...]