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