Using Software Categories for the Development of Generative Software Pedram Mir Seyed Nazari and Bernhard Rumpe Software Engineering, RWTH Aachen University, Aachen, Germany Keywords: Model-driven Development, Code Generators, Software Categories. Abstract: In model-driven development (MDD) software emerges by systematically transforming abstract models to concrete source code. Ideally, performing those transformations is to a large extent the task of code generators. One approach for developing a new code generator is to write a reference implementation and separate it into handwritten and generatable code. Typically, the generator developer manually performs this separation — a process that is often time-consuming, labor-intensive, difficult to maintain and may produce more code than necessary. Software categories provide a way for separating code into designated parts with defined dependencies, for example, “Business Logic” code that may not directly use “Technical” code. This paper presents an approach that uses the concept of software categories to semi-automatically determine candidates for generated code. The main idea is to iteratively derive the categories for uncategorized code from the dependencies of categorized code. The candidates for generated or handwritten code finally are code parts belonging to specific (previously defined) categories. This approach helps the generator developer in finding candidates for generated code more easily and systematically than searching by hand and is a step towards tool-supported development of generative software. 1 INTRODUCTION model, the generator developer creates the reference implementation. Next, it has to be determined which Models are at the center of the model-driven devel- code parts need to be or can be generated and which opment (MDD) approach. They abstract from tech- ones should remain handwritten. Finally, the transfor- nical details, facilitating a more problem-oriented de- mations are defined to transform the reference model velopment of software. In contrast to conventional to the aforementioned generated code. general-purpose languages (GPL, such as Java or C), Often, the third step, i.e., ’separation of hand- the language of models is limited to concepts of a written and generated code’ is not explicitly men- specific domain, namely, a domain-specific language tioned in the literature. This separation is implicit (DSL). To obtain an exectuable software application, part of the last step, i.e., ’creation of transformations’, code generators systematically transform the abstract since the transformations are only created for code models to instances of a GPL (e.g., classes of Java). that ought to be generated. However, the separation However, code generators are software themselves of handwritten and generated code ought to be distin- and need to be developed as well. There are different guished as a step on its own, since it is not always development processes for code generators. One that obvious which classes need to be generated. is often suggested (e.g., (Kelly and Tolvanen, 2008) In general, every class can be generated, espe- and (Schindler, 2012)) is shown in Fig. 1. cially when using template-based generators. In an The approach includes four steps. First, a refer- extreme case, a class can be fully copied into a tem- ence model is created, which ultimately serves as in- plate containing only static template code (and, thus, put for the generator. Depending on this reference is independent of the input model). This is not de- sired, following the guideline that only as much code Creation of Creation of Separation of Creation of should be generated as necessary (Stahl et al., 2006), Reference Model Reference Impl. HW and Gen Code Transformations (Kelly and Tolvanen, 2008), (Fowler, 2010). Opti- result result result result mally, most code is put into the domain framework Handwritten Reference Reference Code Templates Model Impl. Templates (or domain platform), increasing the understandabil- Generated Templates Code ity and maintainability of the software. The gener- Figure 1: Typical development steps of a code generator. ated code then only configurates the domain frame- 498 Mir Seyed Nazari P. and Rumpe B.. Using Software Categories for the Development of Generative Software. DOI: 10.5220/0005328204980503 In Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2015), pages 498-503 ISBN: 978-989-758-083-3 Copyright c 2015 SCITEPRESS (Science and Technology Publications, Lda.) UsingSoftwareCategoriesfortheDevelopmentofGenerativeSoftware work for specific purposes (Rumpe, 2012). CardGameGUISwing refines One important criterion for a code generator to be reasonable is the existence of similar code parts, ei- CardGameGUI SheepsHead ther in the same software product or in different prod- ucts (e.g., software product lines). Typically, genera- Swing CardGame tion candidates are similar code parts that are also re- lated to the domain. For example, in a domain about 0 cars, the classes Wheel and Brake would be more likely generation candidates than the domain indepen- Figure 2: Software categories for virtual SheepsHead (Siedersleben, 2004) (shortened). dent and thus unchanged class File. This, of course, is the case, since the information for the generated categories, such as persistence, gui and application. code is obtained by the input model which, in turn, Therefore, (Siedersleben, 2004) suggests using soft- is an instance of a DSL that by definition describes ware categories for finding appropriate components. elements of a specific domain. Of course, the logi- In the following this idea is demonstrated by an ex- cal relation to the domain is not a necessary criterion, ample.1 because if the DSL is not expressive enough, the gen- erated code is additionally integrated with handwrit- Suppose that a software system for the card game ten code. Nevertheless, the generated code often has Sheepshead should be developed. The following cat- some bearing on the domain. egories then could be created (see Fig. 2): In most cases, the generator developer manually • 0 (Zero): contains only global software that is separates handwritten code from generated code. This well-tested, e.g., java.lang and java.util of process can be time-consuming, labor-intensive and the JDK. may impede maintenance. Furthermore, when using • CardGame a domain framework, this separation is insufficient, : contains fundamental knowledge since the handwritten code needs to be separated into about card games in general. Hence, it can be used handwritten code for a specific project and handwrit- for different card games. ten code concerning the whole domain. This sepa- • SheepsHead: Contains rules for the the ration also impacts the maintenance of the software Sheepshead game, e.g., whether a card can (Stahl et al., 2006). To address this problem, software be drawn. categories, as presented in (Siedersleben, 2004), are • CardGameGUI: determines the design of the card suited. game, independent of the used library, e.g., that The aim of this paper is to show how soft- the cards should be in the middle of the screen. ware categories can be exploited to categorize semi- automatically classes and interfaces of an object- • CardGameGUISwing: extends Swing by illustra- oriented software system. The resulting categoriza- tion facilities for cards. tion can be used for determining candidates for gen- • Swing: contains fundamental knowledge about erated code, supporting the developer performing this Java Swing. separation task. This paper is structured as follows: Sec. 2 intro- An arrow in Fig. 2 represents a refinement rela- duces software categories and the used terminology. tion between two categories. Classes that are in a cat- In Sec. 3, these software categories are adjusted for egory C1 that refines another category C2 may use generative software. Sec. 4 presents the allowed de- classes of this category C2. The other way around pendencies derived by the previously defined software is not allowed. Every category - directly or indi- categories. The general categorization approach is ex- rectly - refines the category 0 (arrows in Fig. 2). plained in Sec. 5 and exemplified in Sec. 6. Sec. 7 Hence, software in 0 can be used in every cate- outlines further possible dependencies. Finally, Sec. gory without any problems. CardGame is refined 8 concludes the paper. by SheepsHead and CardGameGUI which means that code in these categories can also use code in CardGame. Note that a communication between CardGameGUI and SheepsHead is not allowed di- 2 SOFTWARE CATEGORIES rectly, but rather by using CardGame or 0 interfaces. Since the category CardGameGUISwing refines both Software systems, especially larger ones, consist of a number of components that interact with each other. 1The example is taken from (Siedersleben, 2004) and re- The components usually belong to different kinds of duced to only the aspects required to explain our approach. 499 MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment AT DT the sake of readability, we do not explicitly mention interfaces, albeit what applies to classes applies to in- A T D T terfaces as well. 0 DG (a) (b) 0‘ 3 CATEGORIES FOR Figure 3: Software categories (a) in general (Siedersleben, GENERATIVE SOFTWARE 2004) and (b) adjusted for generative software. While (Siedersleben, 2004) aims for finding compo- CardGameGUI and Swing, it is a mixed form of these nents from the defined software categories,