work for small problems, but it introduces signi?cant accidental complexities when tackling larger problems. Notethattherealchallengehereisnothowtodesignthesystemtotakeap- ticular aspect into account: there is signi?cant design know-how in industry on this and it is often captured in the form of design patterns. Taking into account more than one aspect can be a little harder, but many large scale successful projects in industry provide some evidence that engineers know how di?erent concerns should be handled. The real challenge is reducing the e?ort that the engineerhasto expendwhengrapplingwithmanyinter-dependentconcerns. For example, in a product-line context, when an engineer wants to replace a variant of an aspect used in a system, she should be able to do this cheaply, quickly and safely. Manually weaving every aspect is not an option. Unlike many models used in the sciences, models in software and in lingu- tics have the same nature as the things they model. In software, this provides an opportunity to automatically derive software from its model, that is, to - tomate the weaving process. This requires models to be formal, and the weaving process be described as a program (i. e., an executable meta-model) manipul- ing models to produce a detailed design. The detailed design produced by the weaving process can ultimately be transformed to code or at least test suites. | Transactions on Aspect-Oriented Software Development VI by Robert B. France, Paperback | Indigo Chapters