Jim & Ila, Suppose that I have a model built on Archetype available for code generation. Sounds like a good idea for RAD. However, can I customize the available model, tweak the pattern detail and get the code generation working still? Thanks, Srikanth
Yes - we discuss model configuration in detail in chapter 3. The archetype patterns are specifically designed to be configurable (customizable). Archetype patterns configurability comes via two mechanisms:
Optional features (attributes, operations, classes) in the patterns
Pleomorphism - a pattern may have different forms adapted to specific business contexts.
Archetype patterns may also have associated pattern configuration rules that specify what combinations of optional features generate semantically well-formed patterns. For example, any configuration of the Money archetype pattern that contains the Money archetype must also contain the Currency archetype as Money is an amount of a Currency. This rule can be expressed in a pattern configuration rule. Pattern configuration is a big topic!
This might also help - it is about the differences between archetype patterns and design patterns. It is from an interview I am going to give on CGN:
Jim: The key differences are summarized below: Archetype patterns are about analysis, requirements and (more broadly) ontological issues. Design patterns are largely about design issues. Archetype patterns are solutions to ontological and domain problems such as �What is an Order and how does it interact with Customers and Products�. Design patterns are technical solutions to specific technical problems. Archetype patterns explicitly support pattern variation. We call this �pleomorphism�. It is the recognition that a pattern, such as the Product archetype pattern, may need to take different forms (pleomorphs) depending on its business context. Archetype patterns explicitly support pattern configurability. Suppose you only need to use part of a pattern. Archetype patterns have optional features that tell you what parts of the pattern are optional and what parts are mandatory in order to preserve the pattern semantics. Archetype patterns can have pattern configuration rules that express semantic constraints between optional pattern features. For example, suppose you want to use the Money archetype from the Money archetype pattern but not the other bits such as the Payment archetype, CurrencyConverter archetype etc. An example of a pattern configuration rule is �If you include the Money archetype, then you must also include the Currency archetype as Money is an amount of a Currency�. As soon as you allow pattern configurability you need pattern configuration rules to ensure that configuration results in semantically well-formed patterns. In this, the first edition of the book, we don�t present pattern configuration rules for the archetype patterns explicitly except as a short example. We may do so in subsequent editions. Archetype patterns are documented using Literate Modeling. The documentation standard in the original Design Patterns book is excellent for technical patterns to be consumed by technical readers. However, archetype patterns must be comprehensible by both technical and non-technical readers. These non-technical readers might be managers, business domain experts, business architects, etc. Literate Modeling is the best way to achieve such broad level of comprehensibility. Archetype patterns are meta-PIMs (Platform Independent Models) ideal for use as model components in MDA development. Because each archetype pattern is configurable it actually defines a set of possible PIMs that are syntactically and semantically well-formed configurations of the pattern. It also implicitly defines another set of syntactically and semantically ill-formed configurations � but these are not interesting. Each of the well-formed archetype pattern configurations is a PIM in the MDA sense. In contrast, design patterns are neither meta-PIMs, PIMs nor PSMs. Archetype patterns exist in the MDA Domain Facilities layer. In fact, archetype patterns are domain facilities expressed as configurable patterns. Design patterns exist in the Technology layer of the MDA architecture.
I will suppress my every urge. But not this shameless plug: