Rutas de señalización en AR

Current cloud application modeling languages cannot be extended or reused to im- plement CadaML, as they do not support modeling a data architecture of cloud applications and particularly multi-tenancy therein. Thus, CadaML requires a novel

meta-model which is derived from the domain model that captures concepts and ter- minology of di↵erent cloud storage types and their partitioning schemes. In order to design ameta-model, firstly, the relationships betweenCadaMLand existing modeling languages are identified. Then, the design of CadaML is specified in accordance with the requirements imposed in Section 3.1.2. Finally, a meta-model and semantics of CadaML are produced.

3.4.1

Language Exploitation versus Language Invention

A modeling language can be designed by either exploiting an existing language or inventing a new one [91]. In the former, a modeling language is based on an existing language where notations and semantic concepts of the existing language are used, restricted or extended. In the latter, a modeling language is created with no commonality with existing modeling languages.

Both of these design patterns have advantages and drawbacks. In particular, when a language exploits an existing one, thenotations and concepts are consistent with the host language with provided compiling and parsing. Though, the modeling

language is constrained by the host language. On the other hand, creating a new modeling language is more flexible in terms of deciding language concepts, termi- nology, and structure. However, a meta-model of the language must be defined, as well as a compiler to parse and process the meta-model, and to map the meta-model

to the expected semantics.

Because none of the existing modeling languages that are described in Sec- tions 2.3 and 2.4 support modeling a data architecture of cloud applications, there is no way to designCadaML based on concepts of these modeling languages. Therefore, it is decided to implement CadaML as an independent modeling language. This, in turn, requires a meta-model that covers the domain concepts and terminology that are deemed necessary based on the analysis in Section 3.3.

3.4.2

Design Specification

After the relationship to existing languages has been determined, the design of CadaML must be specified before implementation. The design specification can be distinguished betweeninformal and formal designs [91]. In the informal design, the specification is typically written in natural language. Subsequently in the formal design, the specification is produced in a form of ameta-model.

Theinformal design is easier to perform compared to theformal design, though it can contain imprecisions that cause problems in the implementation phase. In contrast, formal specification of both meta-model and semantics can capture prob- lems before implementation. Furthermore, formal design is commonly implemented by tools that significantly reduce implementation e↵ort. As a result, formal design

is applied to formulate meta-model and semantics for CadaML.

3.4.3

CadaML

Meta-model

At the heart of a graphical DSL is the definition of a meta-model that captures concepts and relationships of the problem domain. Based on the formal design

specification, a meta-model is commonly specified using a meta-modeling language. Most of the current meta-modeling languages are provided as a part of a framework or tool suite that supports development and deployment of modeling languages. There are a few widely exploited frameworks that are described and compared in Section 3.5.1.

As a result of thorough consideration and analysis of existing frameworks, and requirements regarding a meta-modeling language specified in Section 3.1.2, the

meta-model of CadaML is defined in Ecore2 _{model that is depicted in Figure 3.3.} The meta-model is derived from the domain model presented in Section 3.3.4, and it

Figure 3.3: CadaML meta-model in UML class diagram.

is divided into three parts that cover domain concepts and the interrelations there in of a) relational databases; b) non-relational databases; and c) blob storage.

The main element of the meta-model is DatabaseDiagram that represents a di- agram in a graphical editor where a cloud data layer architect or developer (here- after modeler) designs a data architecture. A diagram may include SQL Database,

NoSQL Database and Object Storage.

Relational databases are expressed by SQL database. SQL Partition of a rela- tion database is classified according to partitioning schemes that were described in Section 3.3.2. A SQL database is composed of tables and their relationships that are represented by SQL table and SQL reference, respectively. A SQL table con- sists of fields, and each field has name, data type and isPrimaryKey parameters where the last parameter defines whether the field is a primary key. In addition,

autoGeneratePrimaryKey parameter allows to automatically generate primary key values of a table by the application. The source and target parameters of SQL ref- erence refer to tables in a relationship, and reference key indicates to a foreign key in a target table. Where multiplicity between tables are expressed by source table

and target table parameters.

NoSQL Database represents non-relational databases with its partitioning schemes, and it consists of tables (i.e., instances of NoSQL table) and their interrelations. A NoSQL table is a collection of properties, where a property is a fundamental data element with name and data type. A NoSQL table must have a partition key and a row key with their data types (i.e., STRING or NUMERIC), where

partitionKeyAutoGenerated parameter to true. In the meantime, the relationships among tables are represented by NoSQL reference, wheresource table andtarget ta- ble parameters refer to multiplicity (i.e., ZERO,ONE, andMANY) between tables.

Object Storage is associated with Blob storage type. In blob storage, data is stored in buckets. A developer can specify partition of a bucket to one of the described in Section 3.3.2 partitioning schemes. Object represents a blob that is persisted in a bucket. An object is a set of attributes, where each attribute has

name, data type and isKey parameters. The isKey parameter determines whether an attribute is a key that will be associated with the object. A key for a blob can be automatically generated by setting autoGenerateKey parameter of an object to

true. An object can be in relationships with other objects which are expressed by

object reference. The source and target parameters refer to blobs in a relationship, while multiplicity between blobs are expressed by source object and target object

parameters.

It can be clearly seen from Figure 3.3 that reference elements (i.e., SQLRef- erence, NoSQLReference, and ObjectRefernce) in each storage type have the same attributes and relationships with storage elements. This formulates a recurring pat- tern that could be refactored using the concepts of inheritance. However, we decided to create a separate reference element for each storage type for the following two rea- sons: (i) mitigate the representation and comprehensibility of the meta-model; and (ii) minimize the complexity of implementing model validation and code generation capabilities.