-Software reuse is an important key in developing software systems in a short time with low cost and fewer errors. Traits were introduced to provide fine-grained reusable elements so as to avoid the issues of various forms of inheritance. In spite of being powerful, traits are not used much in software development, mostly because of neither being available in general purpose programming languages nor at the modeling level. In addition, traits suffer from not having control over their clients, which result in a lack of reusability and incorrect usage respectively. In this paper, we propose applying traits to model driven software development. Traits are extended with modeling elements such as associations, state machines, and constraints for a higher level of abstraction. In addition, template parameters are integrated with associations in order to increase genericity and level of abstraction. Traits will be extended with required interfaces to enable structural control over their clients. These features will be implemented in Umple which provides textual modeling of software systems. Index Terms- Traits, Modeling, UML, Software Development, Umple.
It is accepted that software reuse is a key for developing
software systems with minimum cost and errors. Inheritance is
one of the popular techniques in this direction. However, there
are some issues regarding using various forms of inheritance
like multiple inheritance and mixins [
Meanwhile, model-driven technologies have started to have an important influence on the development community, although slowly. In particular, state machines and associations, are modeling abstractions that bring new opportunities for reuse, and can be manipulated by inheritance for an even greater degree of reusability. Various issues with inheritance are exposed, however, when these new abstractions become inheritable units; posing challenges, the solution of which are some of my research triggers.
Nathanael et al. [
Typed trait inheritance is explored in [
Traits in Java was explored in [
Emerson et al. [
XTRAITx as a language for pure trait-based programming
was introduced in [
Application of traits in software product line (SPL) has
been investigated in [
As can be seen, the main thrust of all the above work is either to add traits to specific programming languages or to use them in new domains. There has so far been no attempt to increase genericity of traits or to make them work in a modeldriven context. Our research aims to take steps in that direction and resolve a variety of challenges that are uncovered along the way.
The extensions proposed by this research cover several dimensions and work together to provide better overall modeling and language flexibility, which can result in better reusability. These are explained in the following sections.
Traits use the notion of ‘required methods’ to specify what classes can use them. There is nothing to prevent them from being used in situations in which classes have the same method names with different purposes. Our initial work shows that required methods plus required interfaces can put restrictions on clients of traits and thus avoid traits being used incorrectly. Required interfaces provides a solution ensuring traits will be used correctly with minimum errors.
Associations are key elements in modeling and increase the level of abstraction; generating code from associations can considerably reduce the amount of implementation code that needs writing. Having associations in traits poses a number of challenges that we have addressed in this research. To ensure modularity, specifying association ends must be done through template parameters. Our objective is to enable traits to be used freely to specify different kinds of relationship patterns.
In order to increase readability of trait functionality (especially at the modeling level) and to provide abstract elements in traits, we are also working on enabling state machines to be included in traits. This will provide a way of reusing state machines at the modeling level. Although this should create a powerful mechanism, we will need to find a straightforward way to manage conflict in trait composition and enable renaming states, removing transitions, and so on.
Constraints provide a straightforward mechanism that is being used increasingly in modeling and certain programming languages. They can be applied to traits so as to put restrictions on elements (such as provided methods, associations, and so on). Constraints must follow special rules to enable trait composition and so they can be used by classes with conflicting constraints. This proposal requires a deep analysis (like that needed for state machines.
We are developing our work in the context of Umple [
We have implemented the some parts of our work in Umple, a textual modeling language that permits embedding of programming concepts into models. It is following syntactic conventions of C-family languages, and adding constructs to such languages. The primary top-level entities are classes, interfaces and traits (which resulted from this research). Each such entity is declared using a keyword (‘class’, ‘interface’, or ‘trait’) followed by the name of the entity and then matching braces surrounding a series of elements. The elements inside the top-level constructs can include attributes (declared in a manner similar to variables, but implying additional semantics), methods (declared as in other C-family languages), associations, constraints, isA directives (for generalization), stereotypes, and state machines. Indeed, we have decided to go with Umple because it has comprehensive code generation for several programming languages, provides a textual syntax which brings more expressiveness, supports state machines and constraint along with the code generation for them, and finally has been developed in our own team. Moreover, it should be expressed that our proposed extensions are not just applicable in Umple and they can be used in other modeling languages, for example, UML through stereotypes. To achieve our goal, we first implemented traditional features of traits and their conflict resolution methods. This included required and provided methods, renaming and removing provided methods, and finally trait composition. We also added a new mechanism which allowed changes to visibility of provided methods. Since there is no support for traits in general-purpose programming languages such as Java and C++, we developed a model transformation, which implements traits with basic elements in these languages. In fact, this transformation permits one to use traits at the modeling level without worries about their implementation within these languages.
We implemented required interfaces, associations, and template parameters with their constraints mechanism. The implementation includes their definitions, conflict resolutions, static type checking, and model transformations. Furthermore, we introduced a preliminary version for state machines and constraints in traits. We still need to further investigate composition and conflict resolution mechanisms in the context of traits, associations in traits, and their provided methods. This will become more critical when they are mixed with template parameters.
We have planned two phases to evaluate our research. In the first phase, we are applying our approach to several large open source systems implemented in Java or Umple. The objective are to determine how much improvement will be achieved in terms of lines of code (LOC), how traits behave at the modeling level, and whether or not we can have full functional systems based on traits at the modeling level. This will allow us to determine whether or not there is a reusability issue in current software systems that can be solved by our approach. It also helps us recognize real behavior of traits at the modeling level and prove the application of our proposal.
The second phase of evaluation is to develop a system from scratch, with extensive use of traits. This will allow us to determine the effectiveness of our work in model-driven software development.
Our main output of the evaluation phase is to prove the usability of traits along with our extended features at the modeling level and also to confirm that a system can be completely developed based on traits at the modeling level without worries about implementation challenges. Usefulness of traits has already been proved and we expect to have the same benefits and even more while we are working at the modeling level. Some of criteria which are going to be evaluated are number of reusable elements, granularity of elements, modularity of the system, line of codes, number of classes, traits, and their methods, and understandability of design.
So far we have completed the majority of phase one. We
started searching for opportunities to add traits to systems the
Umple compiler and JHotDraw [
In the first round of the process, we discovered methods which have the same signature and body. Each method was considered as a trait and then the required methods were recognized. The benefit of doing in this way is to first uncover fine-grained traits and then, when needed, to compose them into composite traits. In order to guarantee to have correct future clients for traits, the interfaces of each class were explored. If they were crucial for the method, we considered them as required interfaces.
Next, we found methods which had a) the same number and order of parameters but different types, and b) the same body. We again applied the same process, which is assigning each method to a trait and discovering the required methods and required interfaces. Based on the differences in types, template parameters were added to the traits. Afterwards, the names of different types were substituted for template parameters. When special restrictions were recognized needed for binding the values of template parameters, they were applied to parameters. The results showed having better reusable elements, reduction in the risk of errors due to duplication, improvement of the understandability of the system, and somehow code volume reduction.
Despite the fact we got an improvement, we have not yet been able to extract state machines and other modeling elements. Therefore, we are planning to apply our approach to two more systems and then we will start developing two systems from scratch.
The features proposed open new opportunities for traits to be used in different applications. The first is developing libraries based on traits for the most-used functionality. For instance, the functionality related to reading from and writing to files are used in the majority of software systems. These appear as simple methods with routine commands inside. Typically, they are implemented in classes (often as static methods) and used in other classes. There is an issue regarding having those methods in classes which already have superclasses. In this case, we have to import those classes and write wrappers for their methods. This takes effort and creates performance issues because of the overhead of wrappers. By having those methods in traits, we are able to use them directly in classes and even can change their visibilities and give them different names if needed. Potential performance issues will be resolved because the methods will be considered as native methods of the classes. At the current state of our research, we are investigating how we can find and extract such useful reusable traits.
The second opportunity is related to developing a
repository for design patterns. Extended traits with template
parameters, required interfaces, and associations bring a
mechanism by which we can apply patterns directly to
candidate classes. The structure of patterns is encapsulated in
traits in terms of associations. The dynamics of associations is
given by template parameters. The proper classes that can be
used as patterns are checked by required interfaces of traits. We
plan to conduct research like that conducted when investigating
implementing potential design patterns by aspect-oriented
programming [
The third opportunity is associated with software product lines. Traits are fine-grained elements that can also become more coarse-grained though composition. They can be applied to any level of inheritance hierarchy as well. Traits serve as a mechanism for conflict resolution, which can be used for configuration in software product lines (SPLs.) In other words, we think of having configurable artifacts in terms of traits and applying them freely in an SPL. When needed, we can remove and rename functionality. This potential and new extended features in the modeling level may provide a strong configuration mechanisms for SPLs. We have made a small move in this direction by allowing change the visibilities of provided methods. This is not applicable for conflict resolution but is useful for SPLs. We plan to move in this direction after completing our work on full traits with modeling extensions such as state machines and constraints.
The expectation at the end of this PhD research is to have full traits at the modeling level. We expect to be able to use such modeling elements easily in traits and to generate code for them. We also expect to get positive results for the applications mentioned in Section VI with much more focus on variability and separation of concerns.
The plan for the remaining time of this research is to
investigate completely the use of state machines in traits and
also implement them in Umple. Afterwards, we integrate
constraints into traits and explore how it can affect the design
of systems. When we are done with these features and have
fully-functional model-based traits, we design and implement a
functional system from scratch based on our proposed ideas.
We also planned to explore how many designed patterns
described in GoF [
The first paper related to this research has been submitted to the journal Software and System modeling and we passed the first review. It includes details of the work with more examples and the results of the first phase of evaluation.
I would like to thank my supervisor Timothy Lethbridge, for the encouragement and advice provided throughout my time. I have been extremely lucky to have a supervisor who cared so much about my work and responded to my questions so promptly.
In this paper, we explained our research towards extending traits so they can be used in model driven software development. In particular we are working on adding state machines, associations, and constraints in traits. We have already completed the integration of template parameters with associations and also required interfaces in traits in order to have genericity and well-controlled traits respectively. As future research, we want to develop a library of reusable patterns using traits as a basis. We also want to apply an extended version of our work to facilitate work in software product lines and explore variability based on traits.