Advanced Factoring

Refactoring is a powerful tool, but there are other techniques which speed development much better than the typical pay as you go refactoring style.

At a workshop in Madrid last summer, StephanKline? presented work on a modeling language he had developed. The goal of the language was to serve as a tool for unifying the OpenModelingLanguage? (OML) and the UnifiedModelingLanguage (UML). He used Smalltalk in an example late in his statement. Throughout the example he made some profound observations about the role of refactoring in development. However, it does take a bit of explanation for them to make sense.

Dr. Kline's work grew out of the observation that both UML and OML are defined through the use of meta-metamodels. But, in neither case was the work complete (particularly in the case of UML, where UML was used to describe itself). Both languages draw a strong separation between classes and objects, or types and instances. To make a meta-metametamodel for UML and OML, Dr. Kline required more fluidity.

He started with the notion that both types and instances are Semantic Templates Unifying Fields and Functions. This forms a cute acronym: STUFF. His position is that reality is made up of STUFF (Stuff) that has both specification and instance characteristics (we can also note that Stuff can be used as both a class name and a method name). In essence, the world consists of instances that are prototypes and instances that are representations of prototypes.

Dr. Kline demonstrated that his approach is both more fundamental and more versatile than other modeling approaches. For instance, it appears that there is one simple model that can be used to describe all systems. So far it does not have a name, however, we can call it the Stuff model. It can be described briefly. Imagine a box on a diagram that is labeled Stuff. On that box there are two lines which connect the Stuff box to itself. One is the type-of relationship and the other is the instance-of relationship. Dr. Kline pointed out that the diagram not only describes the core of UML and OML, but it can also describe an airline reservations system, a lottery, in fact just about any system. Any differences between the systems modeled by the same model can be considered implementation details.

Although the Stuff model is sufficient for most systems, often one must model using two boxes. Imagine a diagram containing a box labeled Customer and another labeled System. A line emanates from the Customer box and points towards the System box but does not touch it. This rendering is rather like an association in UML. It differs in that it is connected on only one end. This syntax indicates that the Customer believes that the System exists. The System may or may not exist, but it is still modeled since it has existence in the Customer's mind. This syntax can be quite useful in many development projects.

It should be evident to the reader by now that if design and analysis are kept at the appropriate level in this language, code generation is straightforward. This is the case. In fact, code generation for the Stuff model has been implemented in some CaseTools. The code is provably correct. C++ was chosen over Smalltalk as the target language for a very simple reason: when one uses this language one never has to refactor.

More information on AdvancedFactoring can be found in StephanKline?'s paper: A Prototype Representation Instance Language for Object Oriented Lingual Systems.

The paper is online at http://www.umad.edu/compsci/sk/af.html.

Good stuff. I notice it is not quite midnight yet here in Norway, even though we changed to daylight savings last Sunday...

I can't get the URL to work, so I can't read the paper. But I find the whole thing completely unbelievable. Refactoring has nothing to do with programming language or formal system. Back when I spent all my time proving theorems, I refactored them all the time. Good writers refactor their books. Should you model a system with a simple model or a detailed one? It is usually better to start with the simpler model and then switch if you decide it is too simple; this is a kind of refactoring.

My favorite quote by Frank Lloyd Wright is "The most important tools of the architect are the erasor in the drawing room and the sledge hammer on the construction set". In this he agrees with Alexander's attitude toward replacing one thing with another. Alexander is now into "structure preserving transformation", which is another name for refactoring if I ever heard one.

If mathematicians, writers, and architects refactor, why should programmers be any different?

-- RalphJohnson

--- KentBeck pointed out to me that the initials of the paper are APRILFOOL. No wonder it didn't make sense!

I left in my proof that refactoring is always necessary, since it is a good argument and someone might need it.

-- RalphJohnson

I was going to write this up elaborately and submit it to a magazine earlier this year, but I ran out of time. I was inspired by an article that AndrewKoenig introduced years ago called "A Proposal Regarding Invisible Logic.." The article makes the case that programmers ought be able to overload whitespace in C++ just as they are able to overload operators. It was hilarious. Andrew has another very good joke article in this April's JournalOfObjectOrientedProgramming.

The original idea for this did not have anything to do with factoring. I added the factoring slant because I figured that it was more apt to be widely read on Wiki if it claimed to be about factoring than if it claimed to be about metamodeling. -- Anon.

--- Actually, I did not write the "A Proposal Regarding Invisible Logic" article - just the introduction. The introduction does, however, contain some metalinguistic clues as to the actual origin of the text. -- AndrewKoenig

The part about one diagram describing "just about any system" reminds me of a company meeting we had a few years back. One developer went up to the whiteboard, drew a circle in the middle and few other circles, labeled them and connected them with lines, and then described the system he was developing. Then the next developer went up, erased the labels and replaced them with new labels, and then described his system. This cycle repeated four more times. The only apparent differences between our systems were the labels and a few connections.

That's what I call reuse!

I have a similar experience. Fortunately for us, even though the white board drawings are nearly identical (except the labels), we are able to keep the implementations pure: they are completely encapsulated from each other. --EricHerman

Pro-active prevention of code reuse is an excellent attribute for any system. By enforcing strict logical isolation of all solution components, business logic and functional integration occur only in the data tier. As distinct from standard fat-middle 3-tier architectures, all the variability and sources of truth – business rules for workflow state, channel, business stage, roles and logical constraints per feature – are normalized and represented by schemas, seed data, and StoredProcedures written in SQL. This unparalleled flexibility allows data-driven response to changes in regulatory requirements, business practice, and product marketing without expensive code testing.

CategoryJoke