Extended Traits for Model-Driven Software Development Vahdat Abdelzad School of Electrical Engineering and Computer Science University of Ottawa, Ottawa, Canada v.abdelzad@uottawa.ca Abstract—Software reuse is an important key in developing inheritable units; posing challenges, the solution of which are software systems in a short time with low cost and fewer errors. some of my research triggers. Traits were introduced to provide fine-grained reusable elements so as to avoid the issues of various forms of inheritance. In spite II. RELATED WORK of being powerful, traits are not used much in software development, mostly because of neither being available in general Nathanael et al. [23,24] introduced the concept of traits in purpose programming languages nor at the modeling level. In dynamically-typed class-based languages. They are reusable addition, traits suffer from not having control over their clients, sets of pure methods that serve as elements from which classes which result in a lack of reusability and incorrect usage can be built. The simplest traits can merely define required and respectively. In this paper, we propose applying traits to model provided methods. These kinds of traits are called stateless driven software development. Traits are extended with modeling traits because they do not directly specify attributes, and all elements such as associations, state machines, and constraints for data access must be through methods known as ‘glue’ code or a higher level of abstraction. In addition, template parameters accessors. The formal definition of traits and their basic are integrated with associations in order to increase genericity properties were defined in [10,25]. Stateful traits [3,4] were and level of abstraction. Traits will be extended with required interfaces to enable structural control over their clients. These introduced to avoid the issue of incompleteness in stateless features will be implemented in Umple which provides textual traits. Incompleteness causes classes to have a significant modeling of software systems. amount of boilerplate glue code when they use traits. This issue Index Terms— Traits, Modeling, UML, Software Development, is resolved through allowing instance variables to be defined Umple. directly in traits. Typed trait inheritance is explored in [16,17] in which an I. THE PROBLEM STATEMENT extension called Featherweight-trait Java (FTJ) has been developed for Featherweight Java (FJ) [14]. The goal of that It is accepted that software reuse is a key for developing project was to introduce typed trait-based inheritance to bring a software systems with minimum cost and errors. Inheritance is simple type system that typechecks traits when they are one of the popular techniques in this direction. However, there imported in classes. are some issues regarding using various forms of inheritance Traits in Java was explored in [19,21] as well. In that like multiple inheritance and mixins [8,11,22,26]. Traits were research, the idea was to explore how it is possible to resolve introduced to resolve those by providing a fine-grained barriers of reuse in Java through traits. IDE support based on mechanism that can be applied freely to any level of Eclipse for this implementation was developed in [20], in inheritance hierarchy [24]. A trait, in its original form, is a which a programmer can move freely between views of the group of pure methods that serves as a building block for system with or without its traits. classes. However, most developers are not able to use traits in their software development process. This happens because Emerson et al. [18] suggested an implementation for Java traits are not available in mainstream programming languages according to their study over java.io libraries. In their research, such as C++ and Java, or modeling languages like UML. traits are represented as stateless Java classes. Required Therefore, there is a greater amount of duplication than they methods are defined as abstract methods. Classes representing otherwise might exist in software systems. traits can be used with other classes so as to have composite classes. As described by their implementation, a class can be Meanwhile, model-driven technologies have started to have used both through inheritance and through composition. an important influence on the development community, Another attempt in this direction resulted in AspectJ [15,28] although slowly. In particular, state machines and associations, being utilized to mimic traits [9]. This mechanism could are modeling abstractions that bring new opportunities for implement most characteristics of traits, but it was not able to reuse, and can be manipulated by inheritance for an even provide a full coverage regarding conflict resolution. greater degree of reusability. Various issues with inheritance are exposed, however, when these new abstractions become XTRAITx as a language for pure trait-based programming was introduced in [6]. The research achieves complete compatibility and interoperability with Java platform without reducing flexibility of traits. Furthermore, it provides an languages. They can be applied to traits so as to put restrictions incremental adaptation of traits in existing Java projects based on elements (such as provided methods, associations, and so upon Eclipse. In the implementation, classes get the role of on). Constraints must follow special rules to enable trait object generators and types while traits only play the role of composition and so they can be used by classes with conflicting units of code reuse and are not types. constraints. This proposal requires a deep analysis (like that Application of traits in software product line (SPL) has needed for state machines. been investigated in [5]. Traits are used along with records [7] E. Code generation to model the variability of the state part of products explicitly. In their approach, class-based inheritance is ruled out and We are developing our work in the context of Umple [1,2], classes are constituted only by composition of traits, interfaces, which has comprehensive code generation from models, with and record. several targeted programming languages. Umple incorporates As can be seen, the main thrust of all the above work is both code and model; a given program can consist primarily of either to add traits to specific programming languages or to use traditional code, or primarily of abstract model elements. Our them in new domains. There has so far been no attempt to traits mechanism will operate as a model transformation increase genericity of traits or to make them work in a model- operating on both traditional code and model elements, prior to driven context. Our research aims to take steps in that direction the invocation of code generation from the model elements. As and resolve a variety of challenges that are uncovered along the a result traits will become available in programming languages way. like C++ and Java. In our transformation we focus on programming languages which do not support traits at all. For III. THE PROPOSED SOLUTION programming languages which support traits explicitly or The extensions proposed by this research cover several implicitly, it is better to have another transformation dimensions and work together to provide better overall mechanism which directly maps modeling elements (traits) to modeling and language flexibility, which can result in better specific structure/keywords in the languages. In this way, we reusability. These are explained in the following sections. can achieve much better traceability between models and the generated code. We should indicate that our transformation A. Required Interfaces mechanism can also be used for those languages if we are not Traits use the notion of ‘required methods’ to specify what interested in getting benefits of those structures and keywords. classes can use them. There is nothing to prevent them from being used in situations in which classes have the same method IV. PRELIMINARY WORK names with different purposes. Our initial work shows that We have implemented the some parts of our work in required methods plus required interfaces can put restrictions Umple, a textual modeling language that permits embedding of on clients of traits and thus avoid traits being used incorrectly. programming concepts into models. It is following syntactic Required interfaces provides a solution ensuring traits will be conventions of C-family languages, and adding constructs to used correctly with minimum errors. such languages. The primary top-level entities are classes, interfaces and traits (which resulted from this research). Each B. Associations such entity is declared using a keyword (‘class’, ‘interface’, or Associations are key elements in modeling and increase the ‘trait’) followed by the name of the entity and then matching level of abstraction; generating code from associations can braces surrounding a series of elements. The elements inside considerably reduce the amount of implementation code that the top-level constructs can include attributes (declared in a needs writing. Having associations in traits poses a number of manner similar to variables, but implying additional challenges that we have addressed in this research. To ensure semantics), methods (declared as in other C-family languages), modularity, specifying association ends must be done through associations, constraints, isA directives (for generalization), template parameters. Our objective is to enable traits to be used stereotypes, and state machines. Indeed, we have decided to go freely to specify different kinds of relationship patterns. with Umple because it has comprehensive code generation for C. State Machines several programming languages, provides a textual syntax which brings more expressiveness, supports state machines and In order to increase readability of trait functionality constraint along with the code generation for them, and finally (especially at the modeling level) and to provide abstract has been developed in our own team. Moreover, it should be elements in traits, we are also working on enabling state expressed that our proposed extensions are not just applicable machines to be included in traits. This will provide a way of in Umple and they can be used in other modeling languages, reusing state machines at the modeling level. Although this for example, UML through stereotypes. To achieve our goal, should create a powerful mechanism, we will need to find a we first implemented traditional features of traits and their straightforward way to manage conflict in trait composition and conflict resolution methods. This included required and enable renaming states, removing transitions, and so on. provided methods, renaming and removing provided methods, D. Constraints and finally trait composition. We also added a new mechanism which allowed changes to visibility of provided methods. Since Constraints provide a straightforward mechanism that is there is no support for traits in general-purpose programming being used increasingly in modeling and certain programming languages such as Java and C++, we developed a model transformation, which implements traits with basic elements in In the first round of the process, we discovered methods these languages. In fact, this transformation permits one to use which have the same signature and body. Each method was traits at the modeling level without worries about their considered as a trait and then the required methods were implementation within these languages. recognized. The benefit of doing in this way is to first uncover We implemented required interfaces, associations, and fine-grained traits and then, when needed, to compose them template parameters with their constraints mechanism. The into composite traits. In order to guarantee to have correct implementation includes their definitions, conflict resolutions, future clients for traits, the interfaces of each class were static type checking, and model transformations. Furthermore, explored. If they were crucial for the method, we considered we introduced a preliminary version for state machines and them as required interfaces. constraints in traits. We still need to further investigate Next, we found methods which had a) the same number and composition and conflict resolution mechanisms in the context order of parameters but different types, and b) the same body. of traits, associations in traits, and their provided methods. This We again applied the same process, which is assigning each will become more critical when they are mixed with template method to a trait and discovering the required methods and parameters. required interfaces. Based on the differences in types, template parameters were added to the traits. Afterwards, the names of V. EVALUATION different types were substituted for template parameters. When The following two sections Planned and Progress describe special restrictions were recognized needed for binding the our evaluation process. values of template parameters, they were applied to parameters. The results showed having better reusable elements, reduction A. Planned in the risk of errors due to duplication, improvement of the We have planned two phases to evaluate our research. In understandability of the system, and somehow code volume the first phase, we are applying our approach to several large reduction. open source systems implemented in Java or Umple. The Despite the fact we got an improvement, we have not yet objective are to determine how much improvement will be been able to extract state machines and other modeling achieved in terms of lines of code (LOC), how traits behave at elements. Therefore, we are planning to apply our approach to the modeling level, and whether or not we can have full two more systems and then we will start developing two functional systems based on traits at the modeling level. This systems from scratch. will allow us to determine whether or not there is a reusability issue in current software systems that can be solved by our VI. POTENTIAL APPLICATIONS approach. It also helps us recognize real behavior of traits at the The features proposed open new opportunities for traits to modeling level and prove the application of our proposal. be used in different applications. The first is developing The second phase of evaluation is to develop a system from libraries based on traits for the most-used functionality. For scratch, with extensive use of traits. This will allow us to instance, the functionality related to reading from and writing determine the effectiveness of our work in model-driven to files are used in the majority of software systems. These software development. appear as simple methods with routine commands inside. Our main output of the evaluation phase is to prove the Typically, they are implemented in classes (often as static usability of traits along with our extended features at the methods) and used in other classes. There is an issue regarding modeling level and also to confirm that a system can be having those methods in classes which already have completely developed based on traits at the modeling level superclasses. In this case, we have to import those classes and without worries about implementation challenges. Usefulness write wrappers for their methods. This takes effort and creates of traits has already been proved and we expect to have the performance issues because of the overhead of wrappers. By same benefits and even more while we are working at the having those methods in traits, we are able to use them directly modeling level. Some of criteria which are going to be in classes and even can change their visibilities and give them evaluated are number of reusable elements, granularity of different names if needed. Potential performance issues will be elements, modularity of the system, line of codes, number of resolved because the methods will be considered as native classes, traits, and their methods, and understandability of methods of the classes. At the current state of our research, we design. are investigating how we can find and extract such useful B. Progress reusable traits. The second opportunity is related to developing a So far we have completed the majority of phase one. We repository for design patterns. Extended traits with template started searching for opportunities to add traits to systems the parameters, required interfaces, and associations bring a Umple compiler and JHotDraw [27]. The latter had already mechanism by which we can apply patterns directly to been converted to Umple. These systems have 39782 and candidate classes. The structure of patterns is encapsulated in 77647 Umple LOC respectively. An off-the-shelf tool named traits in terms of associations. The dynamics of associations is CodePro Analytix [29] was used to detect duplicated code. given by template parameters. The proper classes that can be Afterwards, a manual process was utilized to consider used as patterns are checked by required interfaces of traits. We converting them to traits. plan to conduct research like that conducted when investigating implementing potential design patterns by aspect-oriented future research, we want to develop a library of reusable programming [13]. patterns using traits as a basis. We also want to apply an The third opportunity is associated with software product extended version of our work to facilitate work in software lines. Traits are fine-grained elements that can also become product lines and explore variability based on traits. more coarse-grained though composition. They can be applied to any level of inheritance hierarchy as well. Traits serve as a REFERENCES mechanism for conflict resolution, which can be used for [1] Badreddin, O., Forward, A., and Lethbridge, T.C.Model oriented configuration in software product lines (SPLs.) In other words, programming: an empirical study of comprehension. we think of having configurable artifacts in terms of traits and Proceedings of the 2012 Conference of the Center for Advanced applying them freely in an SPL. When needed, we can remove Studies on Collaborative Research, IBM Corp. (2012), 73–86. and rename functionality. This potential and new extended [2] Badreddin, O., Forward, A., and Lethbridge, T.C.Exploring a features in the modeling level may provide a strong Model-Oriented and Executable Syntax for UML Attributes. Software Engineering Research, Management and Applications, configuration mechanisms for SPLs. We have made a small Studies in Computational Intelligence 496, (2013), 33–53. move in this direction by allowing change the visibilities of [3] Bergel, A., Ducasse, S., Nierstrasz, O., and Wuyts, R.Stateful provided methods. This is not applicable for conflict resolution traits. Advances in Smalltalk, Proceedings of 14th International but is useful for SPLs. We plan to move in this direction after Smalltalk Conference (ISC 2006), LNCS, (2007), 66–90. completing our work on full traits with modeling extensions [4] Bergel, A., Ducasse, S., Nierstrasz, O., and Wuyts, R.Stateful such as state machines and constraints. traits and their formalization. Computer Languages, Systems & Structures 34, 2-3 (2008), 83–108. VII. THE EXPECTED CONTRIBUTION [5] Bettini, L., Damiani, F., and Schaefer, I.Implementing software The expectation at the end of this PhD research is to have product lines using traits. the ACM Symposium on Applied full traits at the modeling level. We expect to be able to use Computing, (2010), 2096–2102. such modeling elements easily in traits and to generate code for [6] Bettini, L. and Damiani, F.Pure trait-based programming on the them. We also expect to get positive results for the applications Java platform. Proceedings of the 2013 International mentioned in Section VI with much more focus on variability Conference on Principles and Practices of Programming on the and separation of concerns. Java Platform Virtual Machines, Languages, and Tools, ACM The plan for the remaining time of this research is to Press (2013), 67–78. investigate completely the use of state machines in traits and [7] Bono, V., Damiani, F., and Giachino, E.Separating type, also implement them in Umple. Afterwards, we integrate behavior, and state to achieve very fine-grained reuse. constraints into traits and explore how it can affect the design Electronic proceedings of Formal Techniques for Java-like of systems. When we are done with these features and have Programs (FTfJP), (2007). fully-functional model-based traits, we design and implement a [8] Bracha, G. and Cook, W.Mixin-based inheritance. ACM functional system from scratch based on our proposed ideas. SIGPLAN Notices 25, 10 (1990), 303–311. We also planned to explore how many designed patterns [9] Denier, S.Traits Programming with AspectJ. RSTI-L’objet 11, 3 described in GoF [12] can be implemented by traits. (2005), 69–86. [10] Ducasse, S., Nierstrasz, O., Schärli, N., Wuyts, R., and Black, VIII. PUBLICATIONS A.P.Traits: A Mechanism for Fine-grained Reuse. ACM Transactions on Programming Languages and Systems 28, 2 The first paper related to this research has been submitted to (2006), 331–388. the journal Software and System modeling and we passed the [11] Duggan, D. and Techaubol, C.-C.Modular mixin-based first review. It includes details of the work with more examples inheritance for application frameworks. ACM SIGPLAN Notices and the results of the first phase of evaluation. 36, 11 (2001), 223–240. IX. ACKNOWLEDGMENT [12] Gamma, E., Helm, R., Johnson, R., and Vlissides, J.Design patterns: elements of reusable object-oriented software. I would like to thank my supervisor Timothy Lethbridge, Addison-Wesley Longman Publishing Co., Inc., 1995. for the encouragement and advice provided throughout my [13] Hannemann, J. and Kiczales, G.Design pattern implementation time. I have been extremely lucky to have a supervisor who in Java and aspectJ. ACM SIGPLAN Notices; the 17th ACM cared so much about my work and responded to my questions SIGPLAN conference on Object-oriented programming, systems, so promptly. languages, and applications; 37, 11 (2002), 161–173. [14] Igarashi, A., Pierce, B.C., and Wadler, P.Featherweight Java: a X. CONCLUSION AND FUTURE WORK minimal core calculus for Java and GJ. ACM Transactions on In this paper, we explained our research towards extending Programming Languages and Systems 23, 3 (2001), 396–450. traits so they can be used in model driven software [15] Kiczales, G., Lamping, J., Mendhekar, A., et al.Aspect-oriented development. In particular we are working on adding state programming. the European Conference on Object-Oriented machines, associations, and constraints in traits. We have Programming (ECOOP), Springer-Verlag LNCS 1241, (1997), already completed the integration of template parameters with 220–242. associations and also required interfaces in traits in order to [16] Liquori, L. and Spiwack, A.Featherweight-trait Java: A trait- have genericity and well-controlled traits respectively. As based extension for FJ. (2004), 27. [17] Liquori, L. and Spiwack, A.FeatherTrait: A Modest Extension of [23] Schärli, N., Ducasse, S., Nierstrasz, O., and Black, A.Traits : Featherweight Java. ACM Transactions on Programming Composable Units of Behavior. Beaverton, USA; Bern, Languages and Systems 30, 2 (2008), 1–32. Switzerland, 2002. [18] Murphy-Hill, E.R., Quitslund, P.J., and Black, A.P.Removing [24] Schärli, N., Ducasse, S., Nierstrasz, O., and Black, A.P.Traits: duplication from java.io. Companion to the 20th annual ACM Composable Units of Behaviour. ECOOP 2003 – European SIGPLAN conference on Object-oriented programming, systems, Conference on Object-Oriented Programming, volume 2743 of languages, and applications, ACM Press (2005), 282–291. Lecture Notes in Computer Science, Springer Berlin Heidelberg [19] Quitslund, P.J. and Black, A.P.Java with Traits — Improving (2003), 248–274. Opportunities for Reuse. Proceedings of the 3rd International [25] Schärli, N., Nierstrasz, O., Ducasse, S., Roel, W., and Black, Workshop on MechAnisms for SPEcialization, Generalization A.Traits : The Formal Model. Technical Report CSE-02- and inHerItance (ECOOP ), (2004), 45–49. 013,CSETech, Software Composition Group, University of [20] Quitslund, P.J., Murphy-Hill, E.R., and Black, A.P.Supporting Bern, Switzerland, 2003. Java traits in Eclipse. Proceedings of the 2004 OOPSLA [26] Snyder, A.Encapsulation and inheritance in object-oriented workshop on eclipse technology eXchange, ACM Press (2004), programming languages. ACM SIGPLAN Notices 21, 11 (1986), 37–41. 38–45. [21] Quitslund, P.J.Java Traits — Improving Opportunities for [27] JHotDraw 7. 2004. http://www.randelshofer.ch/oop/jhotdraw/. Reuse. Technical Report CSE-04-005, OGI School of Science & [28] AspectJ. 2014. https://www.eclipse.org/aspectj/. Engineering Oregon Health & Science University, 2004. [29] CodePro Analytix. 2014. https://developers.google.com/java- [22] Sakkinen, M.Disciplined inheritance. European Conference on dev-tools/codepro/doc/. Object-Oriented Programming (ECOOP), (1989), 39–56.