Journal of Information Technology and Computer Science

Volume 4, Number 3, Desember 2019, pp. 222-232

Journal Homepage: www.jitecs.ub.ac.id

Design Pattern Evaluation on A RESTful API Wrapper:

A Case Study of Software Integration with An Internet
Payment Gateway using Model-Driven Architecture

Lindung Parningotan Manik1,2, Hani Febri Mustika1, Arida Ferti Syafiandini1

1 Research Center for Informatics, Indonesian Institute of Sciences, Bandung, Indonesia
2 STMIK Nusa Mandiri, Jakarta, Indonesia

{lindung.manik, hanifmustika, afsyafiandini}@gmail.com

Received 13 May 2019; accepted 29 November 2019

Abstract. A proper use of design patterns has proven to be very useful in the
development of robust applications over time. In this paper, the design patterns
are introduced in the early stage of the software development where model-driven
architecture is used as the engineering approach. A RESTful internet payment
gateway API (Application Programming Interface) wrapper is selected as the
case study. At the beginning, Platform Independent Model (PIM) is created as
the domain model. After that, the PIM is transformed into the Platform Specific
Model (PSM). Before converting the PSM into the source code, three design
patterns such as builder, observer, and factory pattern are added into the model.
To evaluate the impacts of implementation, static analysis is used to examine the
generated code before and after adding the design patterns. The result shows that
the design decision increases cohesion, complexity, coupling, inheritance, and
size metrics of the source codes.

1 Introduction
Nowadays, digitization of the business processes makes internet applications and
technologies connected through the cloud growing enormously. Industry 4.0 era pushes
stakeholders including governments, manufacturers, and business owners to integrate
their applications within the organization, or even with the external organizations. A
REST (Representational State Transfer) API (Application Programming Interface) is
one of the ways to make these online integrations happen in the cloud. These APIs
allow two or more software programs to communicate between each other.
A RESTful API is an API based on the REST technology which is often used in a
web services development. It uses HTTP defined by RFC 2616 protocol to GET, PUT,
POST, and DELETE data. Since HTTP calls are stateless, REST is very useful in cloud
applications. REST also leverages less bandwidth, making it more suitable for internet
usage. The API describes the proper way for a developer to write a software requesting
services or receiving responses from other applications.
An API wrapper is a software package that contains clean functions to access the
API. This wrapper could be written in any programming languages. It takes time to
implement the API in a language, to figure out the right way to access the REST
endpoints and to retrieve the response data. Once the API wrapper is written, it could
 Lindung Parningotan Manik et al., Design Pattern Evaluation on... 223

be shared among other developers to ease their pain when they must implement the
same API in the same programming language.
In this paper, model-driven architecture is used as the software design approach
for the development of the API wrapper. One of internet payment gateway API is
selected as the case study. The main research goal is to evaluate the design patterns that
could be used in the early stage of the API wrapper development. Design pattern is a
best practice solution to a commonly occurring problem in software engineering [1].
Since Gang of Four standardized the design patterns for the first time [2], more and
more object-oriented software apply them until now. Design patterns have some
benefits on software maintainability [3], expandability [4], and modularity [5]. In this
research, five software metrics, such as cohesion, complexity, coupling, inheritance,
and size metric are evaluated to analyze the impacts of the design decisions.

2 State-of-the-art
Model Driven Architecture (MDA) developed by the Object Management Group
(OMG) is a framework for software development using a system modeling language
which is defined by [6]. MDA aims to enhance portability by separating business and
application logic from underlying platform technology. The primary components of
MDA technologies are the Platform Independent Model (PIM) which describes the
structure or function of a system and the Platform Specific Model (PSM) which defines
specific implementation.
Software development in the MDA starts with a PIM of an application’s or
integrated system’s business functionality and behavior, constructed using a modeling
language based on OMG’s MetaObject Facility (MOF), Unified Modeling Language
(UML), or Common Warehouse Metamodel (CWM). This model remains stable as the
technology evolves. MDA has the capability to define templates that map
transformations from a PIM to a PSM and then to a working implementation on any
platform, including Web Services, .NET, CORBA, Java, and others.

Fig. 1 Model-driven architecture transformation [7]

MDA facilitates the development of a system in abstraction and simplifies

implementation of that system across a variety of platforms. The MDA has been
successfully implemented in various business domain such as accounting system [8],
embedded system [9], cancer research [10], human language technologies [11], also
more recently enterprise e-health system [12] and Zakat calculation [13]. MDA may
provide 10-20% efficiency improvement of existing systems engineering efforts once
the methodology is understood and successfully adapted [14].
However, MDA could not apply the design patterns automatically either when
transforming the PIM to the PSM or when converting the PSM into the code. Software
designer should add it manually according to the needs since a design pattern is not a
finished design that can be transformed directly into the code. It is a template of solving

p-ISSN: 2540-9433; e-ISSN: 2540-9824

224 JITeCS Volume 4, Number 3, Desember 2019, pp 222-232
a problem that can be used in many different situations. Twenty three design patterns
that are specified in [2] can be categorized into three main types. They are creational,
behavioral, and structural pattern. Despites of their advantages, the abuse, misuse, or
overuse of the design patterns could lead into creating bigger problems rather than
solving the actual problems.

3 Case Study
In this paper, software development of integrating a mobile commerce application
with an internet payment gateway provider is selected as the case study. The actor that
uses the payment gateway service in the form of API is called as the merchant. It needs
the service since the payment gateway facilitates its customer various payment methods
such as credit card, online bank transfer, or e-money. By using the services, the
merchants could increase their transaction number since their customer has various
options while paying the transaction order. The merchants also can minimize the
burdens since they do not need to implement the payment methods one by one.
An internet payment gateway is an instant payment service where the payment
occurs in the provider webpage portal. With this service, the customer of the merchant
will be redirected to a provider webpage upon checkout to complete the payment by
selecting available payment methods. Besides creating order, the payment gateway
service provider also serves other features for the merchants such as:
1. Query order status request, to check the status of a payment transaction.
2. Refund request, to refund a settled transaction.
3. Cancel request, to cancel a transaction regardless of its settlement status.
4. Query refund status request, to check the status of an order refund.
uc Primary Use Cases

Payment Gateway System

Create Order
Refund Order

Cancel Order

Merchant

Query Refund

Query Order

Fig. 2 Use-case diagram of the case study

In terms of the security, merchant and payment gateway provider normally use
cryptographic keys (private and public key pair) in agreed format when exchanging
messages. As mentioned before, it would be very helpful if an API wrapper package
could be shared to the merchant application developers in order to minimize the

p-ISSN: 2540-9433; e-ISSN: 2540-9824

 Lindung Parningotan Manik et al., Design Pattern Evaluation on... 225

integration efforts. The merchants could use the package as the library in their software
when they need to connect the applications with the same payment gateway provider
and must implement the API in the same programming language.

4 Design
This chapter explains the design of the PIM and the PSM that accommodates the
requirements in the case study. Implementation of the design patterns are also discussed
accordingly.

4.1 Platform Independent Model

In the domain of the API wrapper, several entities are created in the model such
as BusinessApi, BusinessSpi, RestApiClient, and IpgConfig. The BusinessApi refers
to interfaces or services hosted or implemented by the payment gateway, in which
merchant act as the client (API caller) and payment gateway is the service provider. In
this case, the BusinessApi uses a RestApiClient to post a request and to get a response.
Meanwhile, BusinessSpi (service provider interface) refers to interfaces that are
intended to be implemented or extended by the merchant. For example, the callback
services implemented by merchant client, for which payment gateway provider is the
caller and the merchant acts as the service provider. The client and the service provider
exchange request and response messages in certain format (either XML or JSON)
during sd
theUse
APICase
or the SPI call.
Model

Merchant Payment Gateway

API()

SPI()

Fig. 3 Differentiation between API and SPI

As a concrete example, a merchant needs to request creating order API when the
customer wants to use the payment service and the payment gateway provider will give
transaction identifier response in the return. After the customer finish the payment
process (either using credit card, online bank transfer, or e-money) in the payment
gateway provider webpage portal, the payment gateway provider call the order finished
SPI to give the merchant a transaction status either success or failed. The same occurs
with the refund order service since it is also an asynchronous flow.
Merchant has key attributes that are associated with the payment gateway system
such as the client identifier and the private key. It’s application usually also has other
technical configurations such as timeout connection time, connection pool size, and
environment type. The IpgConfig entity holds these configuration attributes. Typically,

p-ISSN: 2540-9433; e-ISSN: 2540-9824

 226 JITeCS Volume 4, Number 3, Desember 2019, pp 222-232
there are two types of environment when merchants start integrating their applications
with a payment gateway application. The payment gateway providers normally serve
sandbox and production environment. Sandbox is safe environment that mimics the real
setting, where merchants can develop and test the features of their applications before
its released to go live to the public. Thus, EnvironmentType enumeration is created to
accommodate this situation. This entity holds some final or unchangeable properties
(constants) about the payment gateway information such as the Uniform Resource
Location
class PIM (URL) and the public key.

BusinessApi BusinessSpi

+ client: RestApiClient + ipgConfig: IpgConfig

+ cancelOrder(Request): Response + handleOrderFinishedNotification(Request)

+ createOrder(Request): Response + handleRefundFinishedNotification(Request)
+ queryOrder(Request): Response
+ queryRefund(Request): Response
+ refund(Request): Response

+client
«enumeration»
Env ironmentType
RestApiClient
SANDBOX
+ ipgConfig: IpgConfig PRODUCTION

+ post(Class<T>, Request<? extends RequestMessage>): Response<T> Attributes

+ url: String
+ publicKey: String
T > RequestMessage
+environmentType
Request

+ requestMessage: T +ipgConfig
+ipgConfig

T > ResponseMessage
Response
+ responseMessage: T
IpgConfig
+ clientId: String
+ connectTimeout: int
+ environmentType: EnvironmentType
+ maxConnectionPoolSize: int
+ privateKey: String
+ socketTimeout: int

Fig. 4 Platform independent model

4.2 Platform Specific Model

When transforming the PIM in Fig. 4 to the PSM in Fig. 5, the MDA tool adds
some specific implementations in the selected platform. In this case study, Java
programming language is selected as the specific implementation platform. As can be
seen, the notable transformation rule is the properties encapsulation. The attributes’
modifiers in the PIM are converted from public to private by adding the getter’s and
the setter’s methods. Besides that, the constructor methods are also added in each class.
At this point, the Java codes could be generated automatically from the PSM by using
the MDA tool.

p-ISSN: 2540-9433; e-ISSN: 2540-9824

 Lindung Parningotan Manik et al., Design Pattern Evaluation on... 227
class PSM

BusinessApi BusinessSpi

- client: RestApiClient - ipgConfig: IpgConfig

+ cancelOrder(Request): Response + handleOrderFinishedNotification(Request): void

+ createOrder(Request): Response + handleRefundFinishedNotification(Request): void
+ queryOrder(Request): Response «constructor»
+ queryRefund(Request): Response + BusinessSpi(IpgConfig)
+ refund(Request): Response
«constructor»
+ BusinessApi(RestApiClient)
«enumeration»
Env ironmentType
+client
SANDBOX
PRODUCTION
RestApiClient
Attributes
- ipgConfig: IpgConfig - url: String {readOnly}
- publicKey: String {readOnly}
+ post(Class<T>, Request<? extends RequestMessage>): Response<T>
«constructor» «constructor»
+ RestApiClient(IpgConfig) ~ EnvironmentType(String, String)
«property get»
+ getUrl(): String
+ getPublicKey(): String
T > RequestMessage
+environmentType
+ipgConfig +ipgConfig
Request

- requestMessage: T IpgConfig

- clientId: String
«property get»
+ CONNECT_TIMEOUT: int = 5000 {readOnly}
+ getRequestMessage(): T
- connectTimeout: int = CONNECT_TIMEOUT
«constructor» - environmentType: EnvironmentType
+ Request() + MAX_CONNECTION_POOL_SIZE: int = 16 {readOnly}
«property set» - maxConnectionPoolSize: int = MAX_CONNECTION_...
+ setRequestMessage(T): void - privateKey: String
+ SOCKET_TIMEOUT: int = 30000 {readOnly}
- socketTimeout: int = SOCKET_TIMEOUT

T > ResponseMessage «property get»

+ getClientId(): String
Response + getConnectTimeout(): int
+ getEnvironmentType(): EnvironmentType
- responseMessage: T + getMaxConnectionPoolSize(): int
+ getPrivateKey(): String
«property get» + getSocketTimeout(): int
+ getResponseMessage(): T
«constructor»
«constructor» + IpgConfig(String, EnvironmentType, String)
+ Response() + IpgConfig(String, EnvironmentType, String, int)
«property set» + IpgConfig(String, EnvironmentType, String, int, int)
+ setResponseMessage(T): void + IpgConfig(String, EnvironmentType, String, int, int, int)

Fig. 5 Platform specific model

4.3 Design Patterns

There are rooms for improvement before converting the PSM into the codes. For
instance, design patterns could be introduced in the PSM in order to refine the software
design. However, as stated before, design patterns must be implemented manually since
MDA tool cannot recognize what patterns should be applied for such cases. In this part,
the implementations of several design patterns such as builder, observer, and factory
pattern are discussed.

4.3.1 Builder Design Pattern

The builder pattern, which is a creational design pattern, separates the construction
of a complex object from its representation. In this case study, the builder pattern could

p-ISSN: 2540-9433; e-ISSN: 2540-9824

 228 JITeCS Volume 4, Number 3, Desember 2019, pp 222-232
be implemented in creating the IpgConfig object. It is very useful when the object
contains a lot of attributes. In case of creating the IpgConfig object, the mandatory
parameters are a client identifier, an environment type, and a private key. Meanwhile,
the optional parameters are a connected timeout, a maximum connection pool size, and
a socket timeout. In the original class, there are at least four constructor methods to
accommodate this situation. This condition is also called as the telescoping constructor,
which
class Class is considered as an anti-pattern.
Model

Before applying builder pattern After applying builder pattern

IpgConfig IpgConfig

- clientId: String - clientId: String {readOnly}

+ CONNECT_TIMEOUT: int = 5000 {readOnly} - connectTimeout: int {readOnly}
- connectTimeout: int = CONNECT_TIMEOUT - environmentType: EnvironmentType {readOnly}
- environmentType: EnvironmentType - maxConnectionPoolSize: int {readOnly}
+ MAX_CONNECTION_POOL_SIZE: int = 16 {readOnly} - privateKey: String {readOnly}
- maxConnectionPoolSize: int = MAX_CONNECTION_... - socketTimeout: int {readOnly}
- privateKey: String
+ SOCKET_TIMEOUT: int = 30000 {readOnly} «property get»
- socketTimeout: int = SOCKET_TIMEOUT + getClientId(): String
+ getConnectTimeout(): int
«property get» + getEnvironmentType(): EnvironmentType
+ getClientId(): String + getMaxConnectionPoolSize(): int
+ getConnectTimeout(): int + getPrivateKey(): String
+ getEnvironmentType(): EnvironmentType + getSocketTimeout(): int
+ getMaxConnectionPoolSize(): int «constructor»
+ getPrivateKey(): String - IpgConfig(Builder)
+ getSocketTimeout(): int
«constructor»
+ IpgConfig(String, EnvironmentType, String) «static»
+ IpgConfig(String, EnvironmentType, String, int) IpgConfig::Builder
+ IpgConfig(String, EnvironmentType, String, int, int)
+ IpgConfig(String, EnvironmentType, String, int, int, int) - clientId: String
+ CONNECT_TIMEOUT: int = 5000 {readOnly}
- connectTimeout: int = CONNECT_TIMEOUT
- environmentType: EnvironmentType
+ MAX_CONNECTION_POOL_SIZE: int = 16 {readOnly}
IpgConfig config = new IpgConfig - maxConnectionPoolSize: int = MAX_CONNECTION_...
.Builder("id",EnvironmentType.SANDBOX,"key") - privateKey: String
.setMaxConnectionPoolSize(8) + SOCKET_TIMEOUT: int = 30000 {readOnly}
.createIpgConfig(); - socketTimeout: int = SOCKET_TIMEOUT

+ createIpgConfig(): IpgConfig
«constructor»
+ Builder(String, EnvironmentType, String)
«property set»
+ setConnectTimeout(int): Builder
+ setMaxConnectionPoolSize(int): Builder
+ setSocketTimeout(int): Builder

Fig. 6 Builder design pattern implementation

After applying the builder pattern, the number of the constructor methods of the
IpgConfig class is reduced to one. The constructor class modifier is set to private, so
that it cannot be constructed directly. To create the object, the builder static inner class
is introduced. The mandatory parameters of the configurations are needed when
creating the builder object. Then, optional parameters can be set one by one before
creating the IpgConfig object. The builder pattern provides a better control over
instantiation process.

p-ISSN: 2540-9433; e-ISSN: 2540-9824

 Lindung Parningotan Manik et al., Design Pattern Evaluation on... 229

4.3.2 Observer Design Pattern

The observer pattern, which is a behavioral design pattern, defines a one-to-many
dependency between the subject and the objects so that when the subject changes state,
the objects are notified and updated automatically. In this case study, the observer
pattern could be implemented on handling the payment gateway provider notifications,
which is conducted by the BusinessSpi as the subject. Firstly, a SPI observer abstraction
is created. Thus, the classes that inherits it should realize its methods in their own way.
Secondly, a list of the observers is added into the BusinessSpi, so the observers will be
notified and updated when the BusinessSpi receives the notifications.
The example is shown by Fig. 7. There are two classes that inherits the observer,
the OrderDao (data access object) and the CustomerNotifier class. These classes are
added in the observer list of the BusinessSpi. When these classes are notified about the
changes of an order status, the OrderDao will modify the transaction status in the
database and the CustomerNotifier will send an email notification to the customer. By
doing so, the subject and the observers are loosely coupled. The subject does not need
to know about the implementation of the concrete observer class and any new observer
canClass
class be added
Model at any point of time without changing the subject class.

BusinessSpi

- ipgConfig: IpgConfig
- observers: List<SpiObserver>
for (SpiObserver observer : observers) {
observer.onOrderFinished(request); + addObserver(SpiObserver): void
} + BusinessSpi(IpgConfig)
+ handleOrderFinishedNotification(Request): void
+ handleRefundFinishedNotification(Request): void

for (SpiObserver observer : observers) { -observers 0..*

observer.onRefundFinished(request);
} «interface»
SpiObserv er

+ onOrderFinished(Request): void
+ onRefundFinished(Request): void

OrderDao CustomerNotifier

+ onOrderFinished(Request): void + onOrderFinished(Request): void

+ onRefundFinished(Request): void + onRefundFinished(Request): void

Fig. 7 Observer design pattern implementation

4.3.3 Factory Design Pattern

Like the builder pattern, the factory pattern is also a creational design pattern. It
is used to create objects without exposing the instantiation process. In this case study,
the factory pattern could be used when creating the API client object. As can be seen
in the PSM, the RestApiClient is the only class that has responsible in posting a request
to the payment gateway. However, this situation could be changed in the future. For
instance, in the current situation the RestApiClient uses the technology of Apache

p-ISSN: 2540-9433; e-ISSN: 2540-9824

 230 JITeCS Volume 4, Number 3, Desember 2019, pp 222-232
HttpClient. As an alternative way, a modern HTTP client, namely OkHttp by Square,
Inc., is added. Thus, the OkHttpApiClient class is created. To improve the software
design, an abstraction of API client, namely ApiClient, is introduced so that the
RestApiClient and the OkHttpApiClient class inherits it. To create the concrete class of
the abstraction, the ApiClientFactory class is needed. The factory design pattern makes
theClass
class source codes more robust, less coupled, and easy to extend.
Model

ApiClient client = ApiClientFactory.createClient(config, 1);

BusinessApi api = new BusinessApi(client);

Application

ApiClientFactory

- ApiClientFactory()
+ createClient(IpgConfig, int): ApiClient

BusinessApi

- client: ApiClient

+ BusinessApi(ApiClient)
if (type==1) {
+ cancelOrder(Request): Response return new RestApiClient(ipgConfig);
+ createOrder(Request): Response }
+ queryOrder(Request): Response if (type==2) {
+ queryRefund(Request): Response return new OkHttpApiClient(ipgConfig);
+ refund(Request): Response }

-client

«interface»
ApiClient

+ post(Class<T>, Request<? extends RequestMessage>): Response<T>

RestApiClient

- ipgConfig: IpgConfig

+ post(Class<T>, Request<? extends RequestMessage>): Response<T>

+ RestApiClient(IpgConfig)

OkHttpApiClient

- ipgConfig: IpgConfig

+ OkHttpApiClient(IpgConfig)
+ post(Class<T>, Request<? extends RequestMessage>): Response<T>

Fig. 8 Factory design pattern implementation

p-ISSN: 2540-9433; e-ISSN: 2540-9824

 Lindung Parningotan Manik et al., Design Pattern Evaluation on... 231

5 Analysis
In this chapter, five software metrics are measured by using static analysis to
investigate the impact of the design patterns implementation. At first, the software
metrics are measured when PSM is directly transformed into the source codes before
(B) applying the design pattern. After (A) implementing the patterns, the metrics are
evaluated again to analyze the differences. The SourceMeter [15] is used to measure
these metrics. The metric categories that are chosen in this research, namely:
1. Cohesion metric, which is represented by the LCOM5 (Lack of Cohesion in
Methods 5), in measuring to what extent the source code elements are coherent in
the system.
2. Complexity metric, which is represented by the WMC (Weighted Methods per
Class), in measuring the complexity of source code elements.
3. Coupling metric, which is represented by the CBO (Coupling Between Object
classes), in measuring the amount of interdependencies of source code elements.
4. Inheritance metric, which is represented by DIT (Depth of Inheritance Tree), in
measuring the aspects of the inheritance hierarchy of the system.
5. Size metric, which is represented by the LLOC (Logical Lines of Code), in
measuring the basic properties of the analyzed system in terms of cardinalities.

Table 1 Metrics measurement before and after applying design pattern

LCOM5 WMC CBO DIT LLOC

B A B A B A B A B A
IpgConfig 0 0 10 7 1 2 0 0 55 34
IpgConfig$Builder - 1 - 5 - 2 - 0 - 31
BusinessSpi 2 1 3 6 3 3 0 0 12 21
BusinessApi 1 1 6 6 8 8 0 0 21 21
RestApiClient 1 1 2 2 5 6 0 1 9 9
ApiClientFactory - 1 - 4 - 3 - 0 - 12

The builder pattern decreases the complexity and the size of the IpgConfig class,
but the coupling increases. It is because a static inner builder is introduced within the
class. As can be seen in the Table 1, if the metrics of the IpgConfig class and the
IpgConfig$Builder class are combined then the builder pattern makes the size and the
complexity of the codes increasing. The observer pattern increases the cohesion of the
BusinessSpi class since the LOM5 value decreases. However, the pattern also makes
the complexity and the size of the class increasing. It is because the observers are
introduced in the class. The factory pattern increases the coupling and the inheritance
of the RestApiClient class because the abstraction and its factory class are introduced.
Moreover, if the RestApiClient and the ApiClientFactory metrics are summed up, then
the pattern also makes the complexity and the size of the source codes increasing.

6 Conclusion
The implementation of the selected design patterns in this case study increases the
cohesion, the complexity, the coupling, the inheritance, and the size metrics of the
source codes when they are introduced in the early stage of the software development.
However, it could not be concluded if this is a good or a bad thing since the measured
metrics might become tradeoffs to other software quality properties such as flexibility,
maintainability, expandability, reusability, or understandability. More advantages or
disadvantages of applying the design decisions might come later in the long run when

p-ISSN: 2540-9433; e-ISSN: 2540-9824

232 JITeCS Volume 4, Number 3, Desember 2019, pp 222-232
the software evolves over the time. For the future works, there should be a certain
mechanism to judge whether applying a design pattern in such a case will give more
positive or more negative impacts on each of the software quality attributes.

References
[1] M. Fowler, “Patterns [software patterns],” IEEE Softw., vol. 20, no. 2, pp. 56–57, 2003.
[2] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable
Object-oriented Software. Boston, MA, USA: Addison-Wesley Longman Publishing Co.,
Inc., 1995.
[3] P. Hegedüs, D. Bán, R. Ferenc, and T. Gyimóthy, “Myth or Reality? Analyzing the Effect
of Design Patterns on Software Maintainability,” in Communications in Computer and
Information Science, 2012, vol. 340, pp. 138–145.
[4] F. Khomh and Y.-G. Guéhéneuc, “Perception and Reality: What are Design Patterns Good
For?,” 2007.
[5] L. P. Manik and Technische Universiteit Eindhoven (TUE). Stan Ackermans Instituut.
Software Technology (ST), “Modular software architecture for a large complex codebase,”
Technische Universiteit Eindhoven, 2015.
[6] OBJECT MANAGEMENT GROUP, “MDA Guide rev.2.0,” no. June, pp. 1–15, 2014.
[7] T. Černý and M. J. Donahoo, “On separation of platform-independent particles in user
interfaces,” Cluster Comput., vol. 18, pp. 1–14, 2015.
[8] S. Ellegaard Borch, J. Winther Jespersen, J. Linvald, and K. Østerbye, “A Model Driven
Architecture for REA based systems,” 2003.
[9] J. Huang, “The Research of Model-Driven Architecture in the Embedded System,” in
Advanced Development in Automation, Materials and Manufacturing, 2014, vol. 624, pp.
524–527.
[10] R. Calinescu, S. Harris, J. Gibbons, J. Davies, I. Toujilov, and S. B. Nagl, “Model-driven
architecture for cancer research,” in SEFM ’07: Proceedings of the Fifth IEEE
International Conference on Software Engineering and Formal Methods, 2007, pp. 59–68.
[11] A. di Bari, G. Vetere, and K. Tymoshenko, “Towards Model Driven Architectures for
Human Language Technologies,” in Proceedings of the Workshop on Open Infrastructures
and Analysis Frameworks for HLT, 2014, pp. 23–33.
[12] B. Atanasovski et al., “On defining a model driven architecture for an enterprise e-health
system,” Enterp. Inf. Syst., vol. 12, no. 8–9, pp. 915–941, Sep. 2018.
[13] M. Hamlich, A. Mamouni, Y. Raki, A. Marzak, and A. Belangour, “{ZCM} (Zakat
Calculation Model) Models Metamodelling Based on {MDA} (Model Driven
Architecture) Concepts,” {SSRN} Electron. J., 2018.
[14] R. Cloutier, “Model Driven Architecture for Systems Engineering,” Stevens Inst. Technol.
Present. INCOSE Int. Work., 2008.
[15] R. Ferenc, L. Langó, I. Siket, T. Gyimóthy, and T. Bakota, “Source Meter Sonar Qube
Plug-in,” in 2014 IEEE 14th International Working Conference on Source Code Analysis
and Manipulation, 2014, pp. 77–82.

p-ISSN: 2540-9433; e-ISSN: 2540-9824