Object Teams Final 0.7.0
On a day like this (2010/07/07), it should be evident what is better than one or a few stars: a strong team!
But when you look at what happens in your software at runtime, all you see is a soup of individuals (called objects) running around all over the place (remember: standard module systems do not create boundaries around runtime objects!).
In all humbleness, are you surprised to learn that it was a German invention back in 2002, that objects should team up?
This is the first release after the move of the project from objectteams.org to Eclipse.org, at what point it is time to express a big thank you to all who helped along the way, Mentors, EMO, Legal, the Tools-PMC, and – of course – the many Contributors. This is: a team-effort!
Now you might say: that’s a pretty scattered team: some people at the Eclipse Foundation in Ottawa, some students in Berlin, people from Austin, and where-not. But that’s actually the point about a team: you start from a set of individuals who initially do not necessarily have any particular relationship. Then you create a team where each individual takes one particular role. This means you further specialize these existing individuals (you don’t want a team of 11 goal keepers, would you? Even with a Manual Neuer giving a perfect forward pass, it takes a Miroslav Klose to make the goal). And then you unite all members of the team towards a common goal, giving the team a new identity, so that team acts like one.
Still, each team member brings into the team the strengths of his particular background, meaning: the individuals do not completely disappear, but some properties of the individuals shine through when they play their roles in the team.
Now, what’s that got to do with software?
Given you already have a core of an application implemented, and now it’s your task to implemented one or two more user stories on top of the existing code. You look at the existing classes and mark those that in some way or other are related to what you need to implement. One user story relates to all classes marked red, another one to those marked greenish etc (and do expect overlap):
How do you implement the user story that involves all the red classes, such that the new implementation sits in a nice new module that concentrates on only this one task/user story?
Consider the red entities as plain individuals, they don’t know about the new task they should contribute to. Also keep in mind, that not all instances of those red classes will participate in the new user story. What we need to do is: specialize a few of those individuals so they can play particular roles wrt the new task and unite those roles within a new team.
If you live in flat-land, this is tremendously difficult, but if you’re able to just add one more dimension to the picture …
… the solution is very straight forward:
- The implementation of the red user story is a strong, cohesive team
- Its members are roles specialized in their particular sub-tasks.
- Each role relates (↓) to one individual from the application core and specializes what is already given towards what the team requires.
- How exactly each role relates to its base is declared using two kinds of atomic bindings: callout and callin method bindings (see, e.g., this post).
- These roles only affect the system as long as the team context is active, and activation happens per team instance (with options for fine-tuning).
- Other teams may be formed for other purposes / user stories (see the greenish team)
- Even if you start already with this 3-D picture, with Object Teams you can always add one more dimension to your architecture, if needed.