![Arxiv:2105.00534V1 [Cs.SE] 2 May 2021 Solutions](http://data.docslib.org/img/10fe2912f6141fdca97d3b15873bb6f8-1.webp)
Metadata Interpretation Driven Development
J´ulioG.S.F. da Costaa,d, Reinaldo A. Pettac,d, Samuel Xavier-de-Souzaa,b,d,
aGraduate Program of Electrical and Computer Engineering bDepartamento de Engenharia de Computa¸c˜aoe Automa¸c˜ao cDepartamento de Geologia dUniversidade Federal do Rio Grande do Norte, Natal, RN, Brazil, 59078-900
Abstract Context: Despite decades of engineering and scientific research efforts, sep- aration of concerns in software development remains not fully achieved. The ultimate goal is to truly allow code reuse without large maintenance and evo- lution costs. The challenge has been to avoid the crosscutting of concerns phe- nomenon, which has no apparent complete solution. Objective: In this paper, we show that business-domain code inscriptions play an even larger role in this challenge than the crosscutting of concerns. We then introduce a new methodology, called Metadata Interpretation Driven Develop- ment (MIDD) that suggests a possible path to realize separation of concerns by removing functional software concerns from the coding phase. Method: We propose a change in the perspective for building software, from being based on object representation at the coding level to being based on ob- ject interpretation, whose definitions are put into layers of representation other than coding. The metadata of the domain data is not implemented at the level of the code. Instead, they are interpreted at run time. Results: As an important consequence, such constructs can be applied across functional requirements, across business domains, with no concerns regarding the need to rewrite or refactor code. We show how this can increase the (re)use of the constructs. Furthermore, the execution of a single interpreter, due to its semantic disconnection from the domain, suggests that it can simultaneously serve different business domains. Conclusions: Although high-reuse software construction is considered a rela- tively mature field, changes in the software services scenario demand relevant arXiv:2105.00534v1 [cs.SE] 2 May 2021 solutions. The emergence of new software architectures, such as serverless com- puting, reinforces the need to rethink software construction. This approach is presented as a response to this need. Keywords: Separation of Concerns, Reuse, Traceability, Crosscutting of Software Concerns, Serverless
Email address: [email protected] (Samuel Xavier-de-Souza)
Preprint submitted to Information and Software Technology May 4, 2021 1. Introduction
Separation of Concerns (SoC) is a term coined by Djikstra in 1974 [1]. The context was the software crisis that the industry and academia had to overcome. The costs associated with management and development of software became in- creasingly complex because of the unstructured manner that they were built. The challenge was therefore to implement strategies that could allow the man- agement of projects and the construction of software in a rational, structured and economically viable way. Regardless of the purpose for which the built software is provided, the structuring principle that arose from this challenge was componentization, as a strategy to guide the separation of concerns. Since the advent of componen- tization, much has been invested to improve the process of building software and its associated artifacts. The result is the emergence of paradigms and methodologies among which we can mention: Structured Development; Object Oriented Programming (OOP); Subject Orientated Programming (SOP) [2]; Aspects Oriented Programming (AOP) [3]; Multi-Dimensional Separation of Concerns (MSoC) [4]; Higher-order Hierarchies (HoH) [5]; Modular Adaptive Programming (MAP) [6]; Design Patterns [7];Model Driven Development [8]; Software Product Lines (SPL) [9]; others that can be found here [10]. Despite the investment for development of above paradigms, their success when used together or separately has been up to now relatively limited [11]. In this regard, Jalender et al. [12] claim that componentization is the principle that synthesizes a desperate need of the software industry and, because of that, it will be fulfilled. The relevance and urgency tones suggested by the authors are understandable, but even with the development and usage of such method- ologies, the following software problems remain: the high impact of changes; the remaining weakness of the traceability among artifacts; and the low rate of artifact reuse [13, 14, 15, 16].
1.1. Criticism to Actual Programming Paradigms and Programming Tools The need for lower costs of the software evolution makes this research area very active. Rezende [14] and de Vasconcelos et al. [17] estimates that up to 90% of all costs associated to the life cycle of software is concentrated in activities of maintenance or evolution. It is therefore no wonder that this issue have been so seriously researched and that so many solutions have already been proposed. Assuming that OOP is the most relevant paradigm implemented to help componentization, the research in this area can be basically classified into two main axes. The first axis is about the criticism to the form of how the OOP paradigm assimilates and represents real-world phenomena [2, 18, 19]. The second is about how the OOP coding tools implement the notion of relationship [20, 21, 22, 23]. In the first axis, the main criticism to OOP is that objects treat all theirs attributes and behavior as if they were intrinsic to the modeled phenomenon. However, very little of real-world attributes related to a phenomenon may be considered intrinsic. Any phenomena can have a multitude of possibilities of
2 being assimilated by a subject who observes them. In short, phenomena are relative and complex [19, 2]. This causes difficulties to modify software arti- facts that require some adaptation when circumstances change in its business domain. In general, this happens because the software artifacts are built ac- cording to a unique perspective, not covering thus all possible meanings of a given phenomenon. The more recent approaches that attempt to rectify this weakness include: SOP [2]; MDSoC [4]; HoH [5]; and MAP [6]. In the second axis, the goal is to investigate how the OOP coding tools im- plement relationships. In this regard, Pearce & Noble [20], Bierman & Wren [21] and Osterbye [22] emphasize that the notion of relationship is very well captured and expressed at the highest levels of abstraction by the currently available tools. However, at the level of implementation, the notion of relationship is not well captured in order to facilitate reuse by the OOP languages. The consequence is a series of difficulties for the construction of software, preventing the code to be sufficiently decoupled to be reused efficiently. In order to address this difficulties, AOP is one of the main solutions that have emerged as ways to perform decoupling of software concerns – particu- larly, separation between functional and non-functional concerns, as proposed by Kiczales [3]. According to them, two concerns crosscut each other when they must have a different composition and yet be coordinated. The phenom- ena of scattering and crosscutting cause, respectively, decreasing cohesion and increasing coupling among components, which is especially not desirable due to consequences in software maintenance and evolution. Despite its accomplishments, AOP has not yet became a consensus in both academia and industry. For example, Pohl et al. [24] discourage adoption of the technology in the products of the SAP company. Other authors state that AOP fails to provide significant improvements to make systems easier to main- tain when compared to systems constructed with pure OOP [25, 26]. And, Steimann [27] states that the use of AOP is paradoxical because its realization contradicts two relevant requirements of the construction of software compo- nents: the capacity to develop them independently from each other; and the legibility/intelligibility of their artifacts. Regarding the independent development of the artifacts, as highlighted by Sullivan and Murphy [28], adding an AOP layer implies dealing with the diffi- culty of traceability between the artifacts, which becomes a reason for pressure to increase costs. This independent manipulation makes the software mainte- nance and evolution process quite complicated, as it naturally favors a lack of synchronism between artifacts [29]. On another perspective of lack of synchronism, motivated by the peculiar dy- namics of changes in software requirements and the need for controlling costs in the software construction process [17], a new field of research emerges. Namely, the quest for tools whose objective is to intelligently forecast the cost of the software construction process [30, 31]. Unsurprisingly, in light of what has been discussed, this is symptomatic and certainly driven by need for building soft- ware at low costs. However, this continues to be done by adding more layers of methodology and/or technologies to the process and artifacts, which in turn
3 implies in a potential cost increase. For the sake of scope, we do not go further in this aspect of the discussion. Finally, and more suited to the interest of this article, software has n- dimensional concerns. It is not a bi-dimensional construct. Separating con- cerns between functional and non-functional is relevant, but it is not enough. It is necessary to separate the n-dimensions that constitute the software, says Tarr [4], for example. We stress that to face this challenge—decoupling the m functional dimensions that exists in software—the industry has been adopting the construction of software from a microservice architecture perspective [32]. However, although it mitigates the problem, it does not end the question.
1.2. Proposition In the light of the criticism presented in the previous subsection, we propose a paradigmatic approach for software development named Metadata Interpre- tation Driven Development (MIDD). The objectives are:
• promote low impact of changes on evolution of functional software require- ments;
• decrease pressure for traceability between models and code documents; • increase the rate of artifact reuse, especially code; and • contribute to increasing the stability and scalability of software services. In order to achieve that, the proposed approach promotes the modeling of data artifacts to the category of first class artifacts. These artifacts become then necessary not only for the understanding of the domain, but also and more im- portantly for the operation of the software system. In this approach, the models are consumed during the operation of the software, skipping the implementa- tion of the artifacts that represent them. The models are consumed by model interpreters in order to present the realization of the contracted expectations to the system user. Here are, finally, the two cornerstones that guide the process of building software according to the proposed approach: meta-metadata and metadata interpretation. While working with metadata is not uncommon, we believe that metadata interpretation, as we are proposing, is a novel approach to increase the separation of concerns in software systems.
1.3. Paper Organization The rest of this paper follows with the Section 2 presenting the formulation of two problems tackled by our approach. Following, Section 3 contains the description of the proposed approach. Then, in Section 4, we point out the main contributions of this work and the possible research needs that may unfold from it.
4 2. Formulation of the Main Problems
In the next two Subsections we present the main problems related to the construction of software that our approach intends to solve. For illustration of these problems, we present a software model for management of car rental offices and, later, another model for book lending management.
2.1. Problems Related to the Realization of Relationships among Concerns Consider the modeling of a car rental system as presented in Fig. 1. It synthesizes the information that the rentals are realized by the establishment of relationships among instances of Client, Vehicle and RentalOffice. One business rule required here is that one Rental should have an expiring date and a number of contracted days. Given an expiring date, the rental is finished when the number of contracted days has passed. Another business restriction is that there can be no repetition of registered vehicles, registered clients, and rental offices. Finally, the last restriction forbids renting to clients without driver’s license. This first modeling would not be considered good enough given the previ- ously mentioned paradigms and the tools that implement them. In this regard, it is important to note that each domain-data class modeled, representing the basic concerns, have services or concerns implementations in common, namely business rules concerning: uniqueness verification; persistence service; and data- view service. There are, thus, at the levels of modeling and coding, unnecessary repetition of information of instructional/operational nature. Much of the in- structions that are in common methods, e.g. persist() and uniqueness(), are unnecessarily repeated. Only the nature of the data on which these methods are applied are different. Furthermore, the replications involve the scattering of these concerns for all classes that implement them. This scattering results in a system with a high degree of coupling among their parts, which is an undesirable characteristic for the software. This problem is discussed by Kiczales et al. [3]. The authors coin the term that synthesizes the reason why these problems occur: tyranny of the dominant decomposition. According to them, this phenomenon occurs because almost only the data concerns are taken into account over the others at the moments of analysis, design and coding of the concerns. It is argued that it is necessary to give equal importance to all concerns which comprise the construction of software. Otherwise, serious difficulties in terms of maintenance and evolution of systems need to be dealt with. An alternative design to our example that seeks to resolve the problem of unnecessary repetition is presented in Fig. 2. Note the factoring of concerns that was applied in order to decrease the degree of crosscutting and spreading of concerns at modeling and coding levels. The concerns of Persistence, View and BusinessRules were removed from the classes that implement the data concerns and placed, each one, in classes that implement them in their specificities. This collaborate to increase the cohesion of the artifacts that implement each of the concerns, whatever they are.
5 Figure 1: Software modeling of a car rental management system.
6 Figure 2: Alternative modeling of a car rental management system decomposed on concerns: view, persistence, data, control and business rules.
7 Different from treating persistence, transaction, view, timing, audit and even data as software concern, treating business rules as such is somewhat controver- sial. Some authors recognize the weakening that this represents to the principles of object oriented programming, but claim that business rules must be removed from the classes that implement the data concerns and put into their own sep- arate implementation, with their required emphasis [33, 34, 35], i.e. business rules must be regarded as software concerns like the others are. This should be done in order to harvest the benefits of increasing the ability to evolve and increasing the degree of maintainability of the software. Despite the fact that some degree of separation of concerns has already be reached, it is important to note that there are still scattering and crosscutting of concerns at the level of code. Because of this, it is difficult to establish associa- tion among classes, and, therefore, among concerns, in the tools that implement OOP. In this regard, Cibran et al. [34, 35] state that the decomposition required to remove all crosscutting of concerns is not possible to be accomplished through the use of mechanisms such as the available object oriented programming lan- guages. Figs.3-5 exemplify this. Fig. 3 and Fig. 4 show one possible and reasonable implementation of the Data, View and Control concerns while relating them with the data concerns: Customer, Vehicle and RentalOffice. The figures omit irrelevant lines of code in order to emphasize the concerns that crosscut each other. Furthermore, ap- plying the same reasoning, note that there are other crosscutting of concerns, e.g. between view and control concerns and between control and business rules concerns, besides the crosscutting that happens among them and all data con- cerns. In order to solve the coding phenomena of crosscutting, the AOP paradigm [3], in conjunction with others layers of technologies, such as Design Patterns [7], makes a two-dimensional separation of concerns, i.e. a separation between con- cerns that implement non-functional requirements and concerns that implement functional requirements. This is done in the AOP paradigm by creating a new code formalism: the aspectual language. It manages to reduce problems related to crosscutting between the data concerns—called basis concerns—and all other concerns—called aspects. However, there are still problems concerning crosscut- ting in implementations of data concerns [4]. Fig. 5 intends to demonstrate that. The work of Tarr et al. [4] contextualize this problem and proposes an approach called Multi Dimensional Separation of Concerns (MDSoC). They highlight that is necessary to think about strategies that recognize and decouple distinct data concerns—the data components—in order to achieve a higher degree of code reuse. About these strategies, we stress the works by Albano et al. [36], Gott- lob et al. [37], Kristensen and Østerbye [38] and Halpin [39]. The fundamental thinking in these works is to make extensions to the object oriented paradigm that relax the manner how it ontologically represents real-world phenomena.
2.2. Problems Related to the OOP Paradigm Let us assume that the developers of the Information System (IS) for the previous car rental offices have been hired to construct an IS for a school. In
8 public class View { Vehicle vehicle; Client client; ... public void showDisp1ay() { formBuilder(client); formBuilder(vehicle); ... } public Form formBuilder(Client client) { Form form = new Form(); form.setTit1e("Client"); //... FormItem name = new FormItem(); name.setTitle("Name"); name.setWidth("140px"); name.setType(Type.InputText); name.setDefault(name.getValue()); form.addItem(name); //... FormItem identity = new FormItem(); identity.setTitle("Identity"); identity.setWidth("90px"); identity.setType(Type.InputText); identity.setDefault(identity.getvalue()); form.addItem(identity); //... return form; } public Form formBuilder(Vehicle vehicle) { //... return form; } ... }
Figure 3: A short description about the implementation of the view concern in order to exemplify how it crosscut the data concern. performing the software requirements analysis, they realize that the part of the school IS concerning the lending of library books has the same operating principle as the IS designed and built for car rental offices. However, even if the entire procedure of operations are similar, it is not possible to simply withdraw this operating principle from the car rental system and insert it as part of the school system. Changes are necessary in the definition of data concerns and care needs to be taken with possible changes in the other concerns crosscut there in. These modifications are necessary because the implementation should be able to adequately represent the space of the phenomena related to the context of book lending. A possible way to do that would be, for example, to have the concept of vehicle replaced by the notion of the book; customer changed by student; and rental store replaced by library. The notion of lending could be maintained, however, some modifications on the business rules could also occur.
9 public class Control { private Vehicle vehicle; private Client client; private RentalOffice rentalOffice; private Rental rental; ... public request(Vehicle vehicle, int op) { ... switch (op) { caseCREATE:{ if (BusinessRules.uniqueness(vehicle)) { Persistence.save(vehicle); } break; } caseDELETE:{ ... break; } } ... } public request(Client client, int op) { ... } ... }
Figure 4: A short description about the implementation of the control concern in order to exemplify how it crosscut the data and business rules concerns. public class Client { public String name; public String identity; public Set
public Client client; public Vehicle vehicle; public RentalOffice rentalOffice; }
Figure 5: A short implementation of data concerns in order to exemplify how data con- cerns crosscut each other, such as Client and Rental and such as Rental, Vehicle, and RentalOffice.
For example, the rule that limits who can borrow (rent) a book (car) could be removed. Basically, two possible paths arise here in order to solve this problem in the
10 most efficient and scalable way. In the first, the concepts in common remain and the divergent ones are removed from the original implementation, creating a new implementation for the domain in question. The second design option is to factor the business domain of book lending and car rental in a more abstract domain, such as rent of goods and services, which is what they actually have in common. In this new design, the data concern Vehicle would be a specializa- tion of GoodsAndService and Client a specialization of Renter, as depicted in Fig. 6. The latter path is the commonly preferred design because it seeks to pre- serve what in principle is considered intrinsic among several possible instances of the rent-of-goods-and-services business domain. However, it increases the com- plexity of the domain model and, as already mentioned, keeping models and code synchronized is now a challenge and therefore a problem for the software industry. Still, this seems like the best path. The most relevant difficulty here, in addition to significantly alter the orig- inal car rental model, is the need to make significant changes also at the code level. When new data concerns arise, new relationships among these concerns are demanded and so, consequently, the difficulties of maintaining relation- ships discussed in Subsection 2.1 also arise. All effort is then concentrated on making changes in the implementation—the code that represents the new model. Thus, the documentation becomes naturally outdated relatively to the demanded changes that are implemented only at the level of code. Such negli- gence to the documentation contributes decisively to decrease the productivity desired through the reuse of these artifacts [12, 29]. Someone could claim that the professionals involved in building the car rental IS—analysts and designers—have not been able to predict other possible uses for the software structure. However, methods that leverage the ability to make this prediction is an area that needs more research. The so called oracle hypothesis is a key element in the success of reuse and domain engineering [15]. It requires from analysts the ability to predict the future, or the ability to contemplate, in the processes of analysis, the maximum predictability about how the system construction can be applied to different contexts, which is not always possible. Nevertheless, there are cases where this requirement for a predictive domain analysis can be used with some satisfactory degree of efficiency. This is the case, for example, of business domains that are already mature and stable. In these cases, it is recommended the use of the Software Product Lines (SPL) paradigm, whose process methodology takes into account factorization of domains in order to achieve efficiency in terms of reuse through prediction of possible uses of the constructed software components [9]. Given the problematic held here, in the next Section finally, we present the proposed approach: Metadata Interpretation Driven Development. For the two IS models discussed here, we present how this new approach circumvents the circumstanced problems in order to present better possibilities of reuse for the constructed artifacts.
11 Figure 6: A factorization of the data models for rental office and library into a data model for rent of goods and services that abstracts both business domains.
12 3. Metadata Interpretation Driven Development
Northover et al. [11], reinforced by de Vasconcelos [17], state that the chal- lenge of building software is to be able to accommodate upon design the changes coming from the most varied sources of pressure—whether they are technolog- ical, economic, social, or even ideological—at whatever moments they arise. However, even if we recognize this pressure for modifying the definition of things—names and meanings—in a business domain, we still need to capture these things, requiring some level of stability of their names and meanings in order to properly compute them, as pointed out by Rayside and Campbell [19]. And here we could identify a dilemma: to conciliate the fluidity of the mean- ings on real-world things with the inflexibility of their representation on the computing-world data structures. This is the cornerstone for a series of reflec- tions on the philosophical aspects of software engineering and for the contribu- tions of this work.
3.1. A Philosophical Motivation Giguette [40], Northover et al. [11] and Rayside and Campbell [19] argue about the necessity of a more philosophical investigation of the reality phe- nomena in order to make professionals more capable and efficient to construct software systems. They state categorically that the OOP paradigm is based on Plato’s philosophy, more specifically, all of them relates object orientation to the notion of ideal form developed in the Plato’s ideas. In this regard, Giguette [40] writes: “According to Plato, each real-world object is an approximation of its ideal form. A particular tree is an instance of the Tree form, which defines the characteristics all trees have in common. Plato might say that a Java class is similar to a platonic form, because it generalizes all possible class instances“. Rayside and Campbell [19] attempt to understand the paradigm of building object oriented software by the understanding of the Aristotelian philosophy. For the authors, both Aristotle and Plato were engaged in solving a central problem of the Greek philosophy: how to reconcile the intelligibility of the real world with the fact that things are changing? Exactly the same type of question that an analyst or a software developer needs to make before enterprising in the construction of software. Aristotle’s answer regarding the intelligibility of things is in the existence of a universal character in them, something that transcends the uniqueness of an individual and reaches everyone in a given scope. Aristotle uses the concepts of genus and species to argument about the intelligibility of things despite the changes. For him, a species represents the intelligible form of singularities clas- sified from it, whereas the genus represents the more abstract and transcendent intelligible form. This is exactly the principle in the object oriented program- ming paradigm: the classification of things in terms of classes and objects, or in terms of genus and species.
13 Confronting what is said in the works of Rayside and Campbell [19], Giguette [40] and Northover et al. [11] with the actual forms of software development, we per- ceive that the spreading of the coupling among software concerns is difficult to be removed at the level of code. For us, in view of what is said by these authors, we suggest that the diffi- culty in removing the coupling between the various concerns, which constitute the classes of objects in a software construction, is related to the fact that we never achieve the ideal form of the phenomena. Everything we achieve with the investigation of any phenomenon is always an approximate representation of a possible ideality. That is how it is when the ontological and/or relational definitions of an object is inscribed in the code of the classes that represents it. What one have at that moment is, at most, a good possible abstraction of the concept that, at some other time and circumstance of observation, may change due to what was not previously observed. Therefore, the reason for the root of software evolution costs remains clear: concepts change, so codes change. In the proposed Metadata Interpretation Driven Development, operating with genus, at meta-metadata level rather than at metadata level, mitigates the effect caused by the problem of coupling between the software concerns. In this new approach, there is no longer the need to implement, at the code level, each genus of data concerns identified in a given data business domain. Only the genus interpretation is implemented. By doing that, we eliminate the spread of coupling between data concerns with each other and other concerns. For a better understanding, Fig. 7 illustrates the relationship between genus- species as implemented in the OOP paradigm in the form of class-object, Fig. 7(a); and as implemented in the proposed approach, with metadata interpretation, Fig. 7(b). Fig. 7(a) should be familiar to software developers since there is an evi- dent use of classes shaping the meaning of the objects that are instantiated from them. In Fig. 7(b), we shift the implementation to the meta-metadata level, which requires, from then on, the ability to interpret the metadata level that describes the data domain. This means that we eliminate data-definition inscriptions in the software code. In the following Subsection, we present how the models discussed in Sec- tions 2.1 and 2.2 can be implemented according to the MIDD approach by shifting the implementation to the meta-metadata level.
3.2. Realizing MIDD The MIDD approach demands data models to be constructed at a level of abstraction other than the coding. For example, they can be constructed in terms of a modeling language like Unified Modeling Language (UML), or even in terms of other language that matters for the focused business domain. Data models of the domain become essential artifacts to the operation of the software system because the information about the data concerns are not translated to the code level. This information is now interpreted by the other concerns, non functional for example.
14 Genus Species of Genus
Student
Student Student Student name: String name: Maria
Class Class Instances
(a)
Genus Species of Genus
Vehicle: Genus
Book: Genus Genus Student: Genus
meta metadata metadata
(b)
Figure 7: Relationship genus-species. (a) Objects as instances of Class. (b) Species as instances of Genus. Here, we emphasize the classification relationship between an abstraction and its instances of realization.
Fig. 7(b) and Fig. 8 outline together how the data domain is treated in our proposition. The approach waives the implementation of all data classes, e.g. Student, Vehicle and Book. Therefore, it is important that all other software concerns are implemented in the perspective of interpretation of the metadata that is captured in the business domain model, possibly by means of a formal modeling language. This approach deviates considerably from the conventional process of implementation/coding software concerns. It is required that the concerns are able to deal with the metadata interpretation so that they can realize the contracted non-functional expectations of the given software system. Notice that our proposal does not suggest any modification in the form of OOP
15 phenomenology to model real-world phenomena. Instead, its phenomenology paradigm is what defines how the interpreter should operate. And it does it without additional layers of tools in the construction process, like AOP. In the following Subsection, we examine what happens with the concerns of control, view and persistence at the code level, comparing their form with the form presented in Subsection 2.1.
3.3. Instantiate MIDD We stress that what is described in this Subsection is put as a proof of concept implementation at the following repository: https://gitlab.com/ lappsufrn/MIDD. It has a MIDD implementation made in Java language with a documentation that describes its installation and usage. The process of instantiating a meta-metadata (or a genus) structure is per- formed in two actions: the capture of the species in terms of its metadata for which we desire computation; and the association of these metadata to their structuring support, i.e. the meta-metadata (or genus) implementation. Fig. 9 and Fig. 10 illustrate the implementation of this process. Fig. 9 presents a possible implementation for the meta-metadata and meta- data structures relate to genus and species. These are the structuring support at the implementation level that is supposed to assume at runtime the form of any data species that the application business domain requires. In order to initialize or instantiate the species implementation from the genus, the model is needed. Besides the need to present the structuring support for the realization of the species, it is important to synthetically present the mechanism of generating species that are consumed by other software concerns. This mechanism, the SpeciesFactory class, is shown in Fig. 10. The purpose of the species factory is to obtain the set of metadata that describes such data species in the data model, in an appropriate format, to envelop the data and make it available for consumption by the other software concerns, like as persistence, view, and transaction. This is done by the capture and interpretation of the metadata specified by the modeling language used for building the business domain model. So far, we presented the mechanism of assimilation of metadata that defines how species are captured and modeled in the domain model and how they are assimilated to be used in the system. Now, through Fig. 11 and Fig. 12, we present the issues related to the scattering of crosscutting between data and view concerns and between data and control concerns. Instead of multiple calls to similar methods applied to different domain species, e.g. formBuilder(vehicle), formBuilder(client), or repetition of similar instructions for configuration of display components for user input, e.g. name.setTitle(’’Name‘‘), identity.setTitle(’’Identity‘‘), customer.setTitle(’’Customer‘‘), in this new approach, these codes are invoked only once in the code. Fig. 11 and Fig. 12 attempts to elucidate this. The reader is invited to compare theses with Fig. 3 and Fig. 4 in order to establish a first comparison between the two
16 Figure 8: Details of the proposed approach. Data concerns are removed from the code level.
17 public interface Species { public String getName(); public Set
public class Genus implements Species { //EntityDescription: possibly anUML class def public Genus(EntityUMLDescription entityDesc) { //... } public String getName() { //... } public Set
public class Attribute { public Attribute(EntityDescription entityDesc) { //... } public String getNane() { //... } public String getTitle() { //... } public String getWidth() { //... } //... } } }
Figure 9: The metadata that describe the species is assimilated on genus instantiation. Here Species and Genus are metadata and meta-metadata structures that at runtime translate the metadata into a data concern. approaches. Note the lack of repetition of instructions regarding the view and control concerns in the new approach. However, there appears a new software concern: the capture and generation of data species via interpretation of domain models. The development effort that arises from this new concern is compensated by the reduction of the effect of scattering of concerns that are transversal to data concerns, as discussed in Section 2.1. There is also the benefit of having achieved lower pressure from the need to establish a larger degree of traceability between what denotes data classes in the model documents and the equivalent implementation of these classes in the code artifacts of the software. These benefits are achieved through programming that is oriented to metadata interpretation instead of being object oriented in domain. Since the concerns of persistence, vision, control and business rules no longer
18 public class SpeciesFactory { // Model is possiblyaUML class diagram artifact public Set
Figure 10: SpeciesFactory is the mechanism that realize the metadata that describes the data concern onto the meta-metadata genus and species in order to be interpreted among other concerns —view, persistence, business rules, etc. have to deal with data species one by one, signing their definition in code, their services can be implemented in a simplified way, as to perform them in code, for example, eliminating repeated operations. Thus, it is possible to perceive a contribution in the improvement on the degree of manageability and maintain- ability of the code. Therefore, the effort of factoring the business data domains of car rental and book lending in order to better build the model for maximizing code reuse, as earlier discussed in Subsection 2.2, is no longer relevant for this approach. Building the concerns that crosscut data as interpreters works adequately for the modeling proposed in Fig. 2, as well for the modeling in Fig. 6, or even for a third modeling that would specifically represent only the data domain of book lending. Perceive that the discussion about how to design components here, at data concern dimension, becomes irrelevant at code level. Lastly, the models become here prevalent for the proper functioning of the system. It is important for the class hierarchy to represent well the data domain in order to leverage a better reuse of the captured intelligence. Naturally, the more appropriately the data nature is discerned and the more factorization there is realized, the better is the maintenance work related to the models.
4. Final Remarks The effort spent over a few decades to improve processes and tools to satisfy the demand for good software components—as cohesive and uncoupled as possi-
19 public class View { ... public void showDisplay(Set
Form form = new Form(); form.setTitle(species.getName());
while (Attribute attr : species.getAttributes()) { FormItem item = new FormItem(); item.setTitle(attr.getTitle()); item.setName(attr.getName()); item.setWidth(attr.getWidth());
switch (attr.getViewFormat()) { case Type.Text : { item.setType(Type.TextBox); } case Type.Select : { item.setType(Type.SelectBox); } } form.addItem(item); } ... return form; } ... }
Figure 11: The view concern implemented as a metadata interpreter. ble with high rates of reuse—still seems to be insufficient. Thus, approaches that promote the minimization of the onus of software processes are highly desirable regardless of whether these reductions are coming from the implementation, the maintenance, or the evolution of software systems. We have pointed out that the main barrier to achieve the desired separation of concerns comes from the data-definition inscriptions in the software code, more than from the phenomenon of crosscutting of concerns, since it is a phe- nomenon that is impossible, up to now, to be solved. The most frequently adopted paths to overcome the crosscutting of concerns are domain factoriza- tion and Aspects Orientated Programming (AOP). However, there are criticisms sustaining that both paths still have significant limitations to achieve better sep- aration, as discussed in Section 2. Given the necessity of effective techniques and the limitations of the exist- ing paradigms, our contribution to the field of separation of software concerns
20 public class Control { ... public request(Species species, int op) { ... switch (op) { caseCREATE:{ if (BusinessRules.uniqueness(species)) { Persistence.save(species); } break; } caseDELETE:{ ... break; } } ... } ... }
Figure 12: The control concern implemented as a metadata interpreter. consists on the present investigation and the proposed approach. We suggest that a possible path to realize separation of concerns is to remove functional software concerns from the implementation of the software system, as much as possible. We propose that the metadata of the domain data should not be implemented at the coding level. Instead, they should be interpreted. In this regard, we appeal to the Aristotelian concepts of genus and species in order to discuss a strategy that weakens the crosscutting of concerns. The strategy consists of shifting the software implementation from the metadata level to the meta-metadata level. This implies that the software needs to be developed from the ability to interpret the set of metadata that describes the data domain for which it operates. This results in a software system that is assembled ad hoc for any domain data, eliminating the need to worry about data factoring in the search for re- lated components or microservices. Furthermore, the execution of a single in- terpreter, due to its semantic disconnection from the domain, suggests that it can simultaneously serve different business domains. These characteristics suggest opportunities to be investigated in relation to the use of instances of multi-tenant software services—in the context of computational clouds. We reinforce, to promote a broader understanding of everything that has been exposed, that a proof-of-concept implementation of a MIDD interpreter in available in the following repository: https://gitlab.com/lappsufrn/MIDD. Along with the code, made in the Java language, the instructions are available to instantiate and test the MIDD interpreter. Finally, we understand that there is a lot to be investigated w.r.t. the proposed approach. For instance, which are the impacts that this approach
21 brings to the actual software modeling approaches and tools? which are the gains and limitations that such approach has compared to actual strategies that are employed to realize separation of concerns? The answers to such questions are the subject of future work as it escapes the introductory scope of this work.
5. Acknowledgments
The authors would like to thank Andr´eH. Siqueira and Zalkind L.D. Rocha for the inspirational discussions. Funding: This work was supported by Coordena¸c˜aode Aperfei¸coamento de Pessoal de N´ıvel Superior—Brazil (CAPES)—Finance Code 001.
[1] E. W. Dijkstra, On the role of scientific thought, in: Selected writings on computing: a personal perspective, Springer, 1982, pp. 60–66. [2] W. Harrison, H. Ossher, Subject-oriented programming: A critique of pure objects, SIGPLAN Not. 28 (10) (1993) 42–54. doi:10.1145/165854. 165932. [3] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Lo- ingtier, J. Irwin, Aspects oriented programming, in: ECOOP’97 — Object- Oriented Programming, Vol. 1241 of Lecture Notes in Computer Science, Springer Berlin Heidelberg, 1997, pp. 220–242. doi:10.1007/BFb0053381. [4] P. Tarr, H. Ossher, W. Harrison, S. M. Sutton, Jr., N degrees of separa- tion: Multi-dimensional separation of concerns, in: Proceedings of the 21st International Conference on Software Engineering, ICSE ’99, ACM, New York, NY, USA, 1999, pp. 107–119.
[5] E. Ernstm, Higher-order hierarchies, in: ECOOP 2003 – Object-Oriented Programming, Vol. 2743 of Lecture Notes in Computer Science, Springer Berlin Heidelberg, Darmstadt, Germany, 2003, pp. 303–328. doi:10.1007/ 978-3-540-45070-2\_14. [6] T. Skotiniotis, Modular adaptive programming, Master’s thesis, Northeast- ern University, Boston, Massachusetts, USA (2010). [7] E. Gamma, R. Helm, R. Johnson, J. M. Vlissides, Design Patterns: Ele- ments of Reusable Object-Oriented Software, Addison-Wesley Professional, 1994.
[8] S. Beydeda, M. Book, V. Gruhn, Model-Driven Software Development, Springer Berlin Heidelberg, 2005. [9] K. C. Kang, V. Sugumaran, S. Park, Applied Software Product Line Engi- neering, CRC Press, 2009.
22 [10] B. Kitchenham, O. Pearl Brereton, D. Budgen, M. Turner, J. Bailey, S. Linkman, Systematic literature reviews in software engineering – a systematic literature review, Information and Software Technology 51 (1) (2009) 7–15, special Section - Most Cited Articles in 2002 and Regular Re- search Papers. doi:https://doi.org/10.1016/j.infsof.2008.09.009. URL https://www.sciencedirect.com/science/article/pii/ S0950584908001390 [11] M. Northover, D. Kourie, A. Boake, S. Gruner, A. Northover, Towards a philosophy of software development: 40 years after the birth of software engineering, Journal for General Philosophy of Science 39 (11) (2008) 85– 113. doi:10.1007/s10838-008-9068-7. [12] B.Jalender, A.Govardhan, P.Premchand, Breaking the boundaries for soft- ware component reuse technology, International Journal of Computer Ap- plications 13 (6) (2011) 107–119. [13] B. JALENDER, A. GOVARDHAN, P. PREMCHAND, A pragmatic ap- proach to software reuse, Journal of Theoretical and Applied Information Technology 14 (2) (2010) 87–96. [14] D. A. Rezende, Engenharia de Software e Sistemas de Informa¸c˜ao,Bras- port, Rio de Janeiro, Brasil, 2005. [15] W. B. Frakes, K. Kang, Software reuse research: Status and future, IEEE transactions on Software Engineering 31 (7) (2005) 529–536. doi:10.1109/ TSE.2005.85. [16] T. Vale, I. Crnkovic, E. S. de Almeida, P. A. da Mota Silveira Neto, Y. C. Cavalcanti, S. R. de Lemos Meira, Twenty-eight years of component-based software engineering, J. Syst. Softw. 111 (2016) 128–148. [17] J. B. de Vasconcelos, C. Kimble, P. Carreteiro, A.´ Rocha, The application of knowledge management to software evolution, International Journal of Information Management 37 (1) (2017) 1499–1506. [18] B. B. Kristensen, K. Osterbye, A conceptual perspective on the comparison of object-oriented programming languages, ACM SIGPLAN Notices 31 (2) (1996) 42–54. doi:10.1145/226060.226068. [19] D. Rayside, G. T. Campbell, An aristotelian understanding of object- oriented programming, in: Proceedings of the 15th ACM SIGPLAN Con- ference on Object-oriented Programming, Systems, Languages, and Ap- plications, OOPSLA ’00, ACM, New York, NY, USA, 2000, pp. 337–353. doi:10.1145/353171.353194. [20] D. J. Pearce, J. Noble, Relationship aspects, in: Proceedings of the 5th International Conference on Aspect-oriented Software Development, AOSD ’06, ACM, New York, NY, USA, 2006, pp. 75–86. doi:10.1145/1119655. 1119668.
23 [21] G. Bierman, A. Wren, First-class relationships in an object-oriented lan- guage, in: ECOOP 2005 - Object-Oriented Programming, Vol. 3586 of Lecture Notes in Computer Science, Springer Berlin Heidelberg, 2005, pp. 262–286. doi:10.1007/11531142\_12. [22] K. Osterbye, Associations as a language construct, in: Technology of Object-Oriented Languages and Systems, 1999. Proceedings of, 1999, pp. 224–235. doi:10.1109/TOOLS.1999.779015. [23] B. B. Kristensen, Complex associations: Abstractions in object-oriented modeling, SIGPLAN Not. 29 (10) (1994) 272–286. doi:10.1145/191081. 191120. [24] C. Pohl, A. Charfi, W. Gilani, S. G¨obel, B. Grammel, H. Lochmann, A. Rummler, A. Spriestersbach, Ading aspect-oriented software develop- ment in business application engineering, in: 7th International Conference on Aspect-Oriented Software Development, AOSD’08, Brussels, Belgium, 2008.
[25] A. Przybylek, Systems evolution and software reuse in object-oriented pro- gramming and aspect-oriented programming, in: Objects, Models, Compo- nents, Patterns, Vol. 6705 of Lecture Notes in Computer Science, Springer Berlin Heidelberg, 2011, pp. 163–178. doi:10.1007/978-3-642-21952- 8\_13. [26] A. Przybylek, Impact of aspect-oriented programming on software mod- ularity, in: Software Maintenance and Reengineering (CSMR), 2011 15th European Conference on, IEEE, 2011, pp. 369–372. doi:10.1109/CSMR. 2011.55. [27] F. Steimann, The paradoxical success of aspect-oriented programming, SIGPLAN Not. 41 (10) (2006) 481–497. doi:10.1145/1167515.1167514. [28] G. Murphy, D. Notkin, K. Sullivan, Software reflexion models: bridging the gap between design and implementation, Software Engineering, IEEE Transactions on 27 (4) (2001) 364–380. doi:10.1109/32.917525. [29] Y. Wand, R. Weber, Toward a theory of the deep structure of informa- tion systems, University of British Columbia, Faculty of Commerce and Business Administration (1990). [30] S. Bilgaiyan, S. Sagnika, S. Mishra, M. Das, A systematic review on soft- ware cost estimation in agile software development., Journal of Engineering Science & Technology Review 10 (4). [31] J. Hryszko, L. Madeyski, Assessment of the software defect prediction cost effectiveness in an industrial project, in: Software Engineering: Challenges and Solutions, Springer, 2017, pp. 77–90.
24 [32] P. Di Francesco, I. Malavolta, P. Lago, Research on architecting microser- vices: trends, focus, and potential for industrial adoption, in: 2017 IEEE International Conference on Software Architecture (ICSA), IEEE, 2017, pp. 21–30. [33] M. D’Hondt, W. Meuter, R. Wuyts, Using reflective logic programming to describe domain knowledge as an aspect, in: Generative and Component- Based Software Engineering, Vol. 1799, Springer Berlin Heidelberg, Erfurt, Germany, 2000, pp. 16–23. [34] M. A. Cibran, M. D’Hondt, V. Jonckers, Aspects-oriented programming for connecting business rules, in: Proceedings of the 6th International Confer- ence on Business Information Systems, Vol. 6, 2003, pp. 1–6. [35] M. A. Cibr´an,Connecting high-level business rules with object-oriented applications: An approach using aspect-oriented programming and model- driven engineering, Ph.D. thesis, Vrije Universiteit Brussel (June 2007).
[36] A. Albano, R. Bergamini, G. Ghelli, R. Orsini, An object data model with roles. doi:10.1.1.104.4721. [37] G. Gottlob, M. Schrefl, B. R¨ock, Extending object-oriented systems with roles, ACM Trans. Inf. Syst. 14 (3) (1996) 268–296. doi:10.1145/230538. 230540. [38] B. B. Kristensen, K. Østerbye, Roles: conceptual abstraction theory and practical language issues, Theory and Practice of Object Systems 2 (3) (1996) 143–160. doi:10.1002/(SICI)1096-9942(1996)2:3<143::AID- TAPO2>3.0.CO;2-X. [39] T. Halpin, Object-role modeling (orm/niam), in: P. Bernus, K. Mertins, G. Schmidt (Eds.), Handbook on Architectures of Information Systems, International Handbooks on Information Systems, Springer Berlin Heidel- berg, 2006, pp. 81–103. doi:10.1007/3-540-26661-5\_4. [40] R. Giguette, Building objects out of plato: Applying philosophy, symbol- ism, and analogy to software design, Commun. ACM 49 (10) (2006) 66–71. doi:10.1145/1164394.1164396.
25