Architectural Styles And Xp

How does SystemMetaphor, as described in ExtremeProgramming, fit with ArchitecturalStyles? Seeing names like LinesStationsBinsParts does little to describe to me the system metaphor. I, for one, find unfamiliar names (which might work well for that particular team) not particularly useful when discussing XP with those new to the concept or XP. I compare this to where we were before the GOF book was widely accepted. -- HankRoark

I don't think LinesStationsBinsParts quite fits into the same hierarchy, although it may be a form of DataFlow?. As an outsider, I find LinesStationsBinsParts (plus the page of explanation) tells me more than DataFlow?. It's at a more useful level of abstraction. ArchitecturalStyles is saying whether something is plant or animal or mineral; LinesStationsBinsParts is saying whether it is a tiger or a bunny rabbit. -- DaveHarris

How does SystemMetaphor, as described in ExtremeProgramming, fit with ArchitecturalStyles?

The system metaphor is finer-grained than the styles discussed in ArchitecturalStyles. In particular, a case could be made that LinesStationsBinsParts is an example of Data Flow. It is almost certainly the case that Kent and I were the only people on the project who even knew what Data Flow was. There's a good chance that we still are, except that there's this team of people who built one.

The C3 system stores each Person's information and payments in objects (including Bins and Parts) in GemStone. So C3 is Data Centered as defined on the styles page.

C3 is written in Smalltalk. Smalltalk programs send messages to objects, get results back. Isn't that Call and Return? Or is it Independent Components?

SystemMetaphor generation is a simpler thing. It consists of thinking of a collection of objects that might do the job. It's done by analogy:

"Payroll is like a production line. Inputs come in and they are assembled into a paycheck."

"Payroll is like a PEZ dispenser ..."

"Payroll is like the candy line on the Lucy show ..."

There's no discussion in XP about picking overall architecture, e.g. 3-tier etc. Also no discussion about how to apply the classic patterns ala GOF. Part of the simplicity fetish, I guess. We'd better think about that ... -- RonJeffries

So, what you are saying is that the SystemMetaphor is more a description of the logical view of the system (see 4+1 View Model of Architecture, by Philippe Kruchten: http://www.rational.com/sitewide/support/whitepapers/dynamic.jtmpl?doc_key=350). Hence, LinesStationsBinsParts would be the logical view for the C3 project.

With that in mind, how does XP address the remaining three views described by Kruchten: process, development, and physical? The plus one view, scenarios, seems to match up nicely with UserStories.

Also, since an architectural style is used to achieve certain qualities (both those observable and not observable at runtime) in a system, how, within XP, did you manage to make sure those qualities were satisfied? Or is it the case that the style you ended up with just happened during the course of good XP?

-- HankRoark

''I'm not familiar with Kruchten's views but will look at the paper if/when I have time. Meanwhile you could ask more specific questions to find what we did.

Regarding what I'm guessing "physical" might be, we paid no attention whatsoever to the fact that we were implementing in VisualWorks and running in GemStone for months. We moved the code to GemStone by making a portability layer in GS, plus using a very few programming conventions to deal with GS's [then] very real incompatibilities of concept with real Smalltalk. When it was time to move to GS (i.e. it was the next Worst Thing) we just moved it and adjusted the code. Someday we expect that we'll change the system so that dynamic objects are created and run in VW for speed while the persistent stuff stays in GS. We'll just change the system so that can happen. We don't expect a lot of trouble because well-factored code is easy to change.

Since XP doesn't do lots of architecture or planning ahead, it might seem like good structure "just happens". What really happens is that we keep the system well-factored, and when it is time to solve some problem, we solve it thoughtfully and put the solution in wherever (in N-space) it goes. -- RonJeffries

I think, if I ask the enough of the right questions, I will find my own answer.

Exactly, and that's the only answer that matters.

When, in the XP process, did you decided to use GemStone? What motivated you to use GemStone?

GemStone had been selected in the original incarnation, so it was just a given when we did the restart. However, if you are programming in Smalltalk and need persistence, it's a natural choice, at least if you have as much money as an auto company and the patience of Job.

Also, when and why did you decided to use the SmalltalkLanguage and/or an object-oriented language? What drove that decision? -- HankRoark

This too was done before the restart. The then manager wanted to get into objects and do them right. They looked into the available alternatives, which at that time came down to C++, Smalltalk, and also-rans like Eiffel*. Java didn't exist at that time. Those were the days ...

Even today, however, I'd prefer Smalltalk/GemStone to Java/Anything, for a model-intensive application like payroll. All the active enterprise beans in the world won't write any of our 2000 classes for us. -- RonJeffries

So, the decision to use objects was driven by the desire of a manager to do objects? What drove him to want to use objects (reusability, maintainability, flexibility, etc.?)? What were the qualities of GemStone that made it desirable (functionality, performance, usability, etc.?)? (Ron, I think I am almost to the answer :-) -- HankRoark