📄 extremecatalysis.html
字号:
<head><title>Extreme Catalysis</title></head><body><h1><img src="logo.gif"> Extreme Catalysis</h1>A few months ago, it struck me as odd that I was fascinated with both <a href="ExtremeProgramming.html">ExtremeProgramming</a> and the <a href="http://c2.com/cgi/wiki?CatalysisMethodology">CatalysisMethodology</a> of <a href="http://c2.com/cgi/wiki?DesmondDeSouza">DesmondDeSouza</a> and <a href="http://c2.com/cgi/wiki?AlanWills">AlanWills</a>. What in the world could they have in common? Jokingly, I said to myself that my life's work could be the exploration of <a href="ExtremeCatalysis.html">ExtremeCatalysis</a>! Could there be a more contradictory phrase?
<p><a href="ExtremeProgramming.html">ExtremeProgramming</a> emphasizes testing, communication and several other practices that speed development and make it reliable. Catalysis emphasizes rigorous specification to aid the development of reusable components. <a href="ExtremeProgramming.html">ExtremeProgramming</a> does not look specificially towards reusability. However, my observation is that <a href="UnitTests.html">UnitTests</a> can act as specifications of external behavior. Their focus is a bit different than the practices in <a href="http://c2.com/cgi/wiki?DesignByContract">DesignByContract</a>. If we follow this line of reasoning, we could look at <a href="ExtremeReuse.html">ExtremeReuse</a> practices.
<p><a href="ExtremeCatalysis.html">ExtremeCatalysis</a> is a very tongue-in-cheek phrase. If <a href="ExtremeProgramming.html">ExtremeProgramming</a> and Catalysis could be unified, we'd have a GrandUnifiedMethodology<a href="http://c2.com/cgi/wiki?edit=GrandUnifiedMethodology">?</a>. That'd be something to chew on. Regardless, it is interesting to see the same thing approached from opposite sides.
<p><p>-- <a href="http://c2.com/cgi/wiki?MichaelFeathers">MichaelFeathers</a>
<hr>
I don't think its contradictory. I use something like it in practice. A lot of extreme ideas apply to analysis and design as well, even when you don't mix it with programming. Conversely, Catalysis ideas might help scale <a href="ExtremeProgramming.html">ExtremeProgramming</a>.
<p>-- <a href="http://c2.com/cgi/wiki?AamodSane">AamodSane</a>
<p>Surely the major issue here is with the expense of refactoring all those
<a href="http://c2.com/cgi/wiki?CatalysisMethodology">CatalysisMethodology</a> diagrams/models. What happens when you refactor?
How do you cope with change?
<p>--<a href="http://c2.com/cgi/wiki?DafyddRees">DafyddRees</a>
<p>Specifications stabilize far faster than code, and don't need as
much refactoring because they are simpler.
Also, specifications, unlike code, can be described using
a series of refinements starting from the very abstract and
adding detail. Your most abstract specification can describe
the big picture; successive refinements split areas of concerns
and add more detail.
The split between levels acts like an encapsulation barrier.
Changes near the bottom need not filter to the top.
On the occasions that they do, they indicate serious mistakes.
<p>Appropriate programming style helps capture "refinement" in code,
but not with the ease of doing refinements in a specification.
See also <a href="http://c2.com/cgi/wiki?AllThoseDiagrams">AllThoseDiagrams</a>.
<p><em>That's fair enough, perhaps I shouldn't have said "all" those diagrams ;-)</em> --<a href="http://c2.com/cgi/wiki?DafyddRees">DafyddRees</a>
<p><em>Refactoring specifications is exactly as easy as refactoring code if you never compile or test the code. If you do compile or test, you have to expend a bit more effort with code, but you've also learned something that you could never learn from a specification: whether your thinking was faulty or not.</em>
<p>True enough, but remember that specs can be more concise, because
you can totally disregard implementation. That said,
you can "compile" your specs to varying degrees - from
simple typechecking of OCL (Object Constraint Language), to programming
them more or less directly in functional and logic languages.
It is even cooler if your language includes refinement as a first-class
structure (I can't recollect an example just yet). -- Aamod Sane
<hr>
<p><em>Specifications, unlike code, can be described using a series of refinements starting from the very abstract and adding detail.</em>
<p>Please explain in what ways code cannot be described using a series of refinement, starting from the very <em>simple</em>/abstract and adding detail. --<a href="RonJeffries.html">RonJeffries</a>
<p>See <a href="http://c2.com/cgi/wiki?SpecVsCode">SpecVsCode</a> -- <a href="http://c2.com/cgi/wiki?AamodSane">AamodSane</a>
<p>Of course code can be described in that way. The problem is that we typically only keep the lowest level of abstraction as our code base. Sometimes we attempt to preserve the abstractions artificially using "high level" classes or what-have-you (that then invoke the lower-level stuff), but mainstream programming environments just don't provide facilities that allow you to keep all the historic levels of abstraction, so that you can squint your eyes and see the big picture. This is usually the role of "design documentation". And we know what happens to that... -- <a href="http://c2.com/cgi/wiki?JohnDaniels">JohnDaniels</a>
<p><hr>
<p>As I see it, appropriate tools are the main prerequisite to make <a href="ExtremeCatalysis.html">ExtremeCatalysis</a> work. One of those would be a programming language that truly allows to use code as the canonical representation of the design. Such a language would need the means to express design elements, such as classes, associations, collaborations directly; a flexible and powerful macro system seems to be the key (my proposed candidate for language that may live up to this is <a href="http://c2.com/cgi/wiki?DylanLanguage">DylanLanguage</a>). Then there's a need for tools that work on the code at higher levels of abstraction: say, point one end of an association at a different class or change its cardinality. -- <a href="http://c2.com/cgi/wiki?MichaelSchuerig">MichaelSchuerig</a>
<p><p><hr>
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 <a href="ExtremeProgramming.html">ExtremeProgramming</a>. I've tried combinations of them with some clients and some success. A set of tests <em>is</em> 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.
<p>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.
<p>If UML is good for anything, it's for presenting partial views of a program.
<p>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.
<p>Tests are useful models for the behavioral abstractions, (1) and (2). The others need something else --- UML collaboration diagrams for example.
<p>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.)
<p>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:
<p><UL><li> It's easier to say x@pre (OCL for "the previous value of x") than to write the bit of code that stores it.
<li> It's easier to write an invariant than to decide all the operations that might affect it, where it should be tested.
<li> It's easier to write "forall..." than write a loop.
<li> It's easier to see the relationships between types and queries in a diagram than in the text of interface definitions.
<p></UL>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.
<p>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.
<p><p><PRE> -- <a href="http://c2.com/cgi/wiki?AlanCameronWills">AlanCameronWills</a></PRE><hr><a href="http://c2.com/cgi/wiki?edit=ExtremeCatalysis">EditText</a> of this page (last edited August 4, 2000)<br><a href="http://c2.com/cgi/wiki?FindPage&value=ExtremeCatalysis">FindPage</a> by browsing or searching<p><font color=gray size=-1>This page mirrored in <a href="index.html">ExtremeProgrammingRoadmap</a> as of March 31, 2001</font></body>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -