=Paper=
{{Paper
|id=Vol-1531/paper6
|storemode=property
|title=Extended Traits for Model Driven Software Development
|pdfUrl=https://ceur-ws.org/Vol-1531/paper6.pdf
|volume=Vol-1531
|dblpUrl=https://dblp.org/rec/conf/models/Abdelzad15
}}
==Extended Traits for Model Driven Software Development==
https://ceur-ws.org/Vol-1531/paper6.pdf
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.