I am one of the authors of the CatalysisMethod, am a fan of Extremeprogramming, and have tried combinations of the ideas with my consultancy clients.


I'm a great believer in the usefulness of modeling (but only to a useful degree in the right places), and I'm also a great fan of ExtremeProgramming. I've tried combinations of them with some clients and some success. A set of tests ''is'' a behavioral model --- something that tells the client useful facts without going into the implementation. So I see XP and Catalysis (and its forerunners) as having similar aims and ideas.

I'm generally disappointed in the way a lot of folks use UML --- just to draw pictures of the code. I'm very unkeen on that --- I think they're missing the point. Tools that translate straight between pictures and program code are IMHO of limited usefulness for large practical systems. If your code is a mess, converting it to pictures won't make it any better; and conversely, UML is an inadequate notation for programming.

If UML is good for anything, it's for presenting partial views of a program. 

Why would I want to write something other than the final code? (1) Because I want to specify behavior before I start coding. (2) Because I want to describe the behavior or protocols common to many components or objects, separately from their various implementations --- for example, integrating enterprise applications; or defining plug-substitutable components; or just doing some neat polymorphic programming. (3) Because I want to discuss an implementation at a high level for the benefit of maintainers. (4) Within a pattern, I want to describe a general template that will be realised in a design.

Tests are useful models for the behavioral abstractions, (1) and (2). The others need something else --- UML collaboration diagrams for example.

But I still would like to use UML+OCL for behavioral models.
(Let's be clear, modeling != pictures. There are pictorial programming languages, and textual modeling languages. Pictures are useful provided you have a clear meaning for them. UML could currently do with some improvement in that area, though we have a fairly specific interpretation of it in Catalysis, and I'm contributing to efforts to improve the UML semantics.)

Why use anything other than programming language? Mostly because tests can be very long, relative to an equivalent piece of notation purpose-built for modeling (which OCL+UML could sorta be seen as, if you squint your eyes and look sideways). They can therefore be difficult to work with rapidly while discussing the design. Specifics:

	* It's easier to say x@pre (OCL for "the previous value of x") than to write the bit of code that stores it.
	* It's easier to write an invariant than to decide all the operations that might affect it, where it should be tested.
	* It's easier to write "forall..." than write a loop.
	* It's easier to see the relationships between types and queries in a diagram than in the text of interface definitions.

Sure, the tests do have to be derived from the OCL+UML. We interpret attributes and associations as read-only functions; every UML type turns into an interface (= pure abstract class); and pre/postconditions etc turn into test monitors. But the OCL+UML is much easier to discuss and show around the corporation. 

And we do have ways of exercising UML models (using 'snapshots'), though only on paper. The objective of incremental development is to cycle with the customer very rapidly: and when we're grabbing the initial requirements, the Catalysis analyst can raise questions about the consistency and holes in all the customer's expressed requirements long before the pure XPer. However, XP overtakes after the high level model is sorted: so there is no point in doing fine-detail models, or tedious long models that write postconditions of get and set operations.


 -- AlanCameronWills

----
CategoryAnalysis
----
see AgileModeling, TestDrivenAnalysisAndDesign