ACM SICSOFT Software Engineering Notes vol 27 no 1 January 2002 Page 35 designer's intentions clear - the "why" of the design, some- thing which Alex says is very hard to do and often neglected - by reference to a design pattern which has commonly known intentions. Cynthia: A simplified version of the "why", of course, as know-how can only be imperfectly articulated. But where were we up to? Gulliver: That was four. The fifth use is to provoke thought. I liked Alex's phrase, that a pattern is an invitation to per- form a thought experiment. The process of thinking about whether or not to use a pattern or something like it helps lateral thinking; it gives you a tentative solution to consider. Alex: Right. There's still a lot we don't agree on and many avenues we haven't explored! But at least, we all agree that the way people often talk about pattern use is over-simplified. As Cynthia keeps saying, everything in a pattern is necessarily abstracted and simplified, and that has serious drawbacks as well as benefits. But we've agreed that there are several ways people use patterns other than just reusing knowledge. And it's important to remember that even a little value may be enough to get an organisation ahead of its competitors. Gulliver: The only thing that seems obvious to me is that you two understand this much more clearly than I do. Trouble is, you understand different things, leaving me the challenge of the differences! Let me try an analogy. Up there in bottles at the bar are 250 good solutions. I don't know which are the best, but I do know that if we'd chosen three different malts we'd be having a different experience now - and we wouldn't necessarily be enjoying ourselves any the less. All: [raising glasses] Slainte! Product Line Variability Support by FORM and Mecano Model Integration Francisco Josd Garc{a Computer Science Department University of Salamanca (Spain) e-mail: fgarcia~usal.es Juan-Antonio ]3arras Agriculture Department Castilla y Ledn Council (Spain) e-mail: j uan-antonio, barras~cag.j cyl.es Miguel A.ngel Laguna Computer Science Department University of Valladolid (Spain) e-mail: mlaguna~infor.uva.es Jos4 Manuel Marquds Computer Science Department University of Valladolid (Spain) e-mail: jmmcQinfor.uva.es Abstract A product line definition must cover several systems, for this reason additional requirements are included as product line assets during domain engineering. Generic assets are pre- sented to cover all components the product line instances are built .from, and their corresponding composition rules. These generic assets embrace common and variable product aspects supporting the variability in product line definition and in- stantiation. This paper is devoted to present the problem of handling prod- uct line variability in every life-cycle stage by the integra- tion of the ideas of the domain engineering method FORM (Feature-Oriented Reuse Method) and the Mecano Model, which defines a coarse-grained reusable element structure. Keywords: Software product line; Product line variability; Domain Engineering; FORM; Mecano Model; Coarse-grained asset; Traceability; Reusability. Introduction A systematic and institutional approach to reuse is needed to achieve the promised benefits of this discipline [Gri96], avoid- ing the ad-hoc reuse practices, whose benefits don't impact very much in the global organization. Domain Engineering (DE) appears as an evolution of the sys- tematic software reuse based on models where the software architectures play an outstanding role. The Domain Engi- neering purpose is the development of the reusable assets to build specific domain software application from. Product lines are one of the most successful forms for Do-