A Framework for Evaluating Model-Driven Self-adaptive Software Systems

In the last few years, Model Driven Development (MDD), Component-based Software Development (CBSD), and context-oriented software have become interesting alternatives for the design and construction of self-adaptive software systems. In general, the ultimate goal of these technologies is to be able to reduce development costs and effort, while improving the modularity, flexibility, adaptability, and reliability of software systems. An analysis of these technologies shows them all to include the principle of the separation of concerns, and their further integration is a key factor to obtaining high-quality and self-adaptable software systems. Each technology identifies different concerns and deals with them separately in order to specify the design of the self-adaptive applications, and, at the same time, support software with adaptability and context-awareness. This research studies the development methodologies that employ the principles of model-driven development in building self-adaptive software systems. To this aim, this article proposes an evaluation framework for analysing and evaluating the features of model-driven approaches and their ability to support software with self-adaptability and dependability in highly dynamic contextual environment. Such evaluation framework can facilitate the software developers on selecting a development methodology that suits their software requirements and reduces the development effort of building self-adaptive software systems. This study highlights the major drawbacks of the propped model-driven approaches in the related works, and emphasise on considering the volatile aspects of self-adaptive software in the analysis, design and implementation phases of the development methodologies. In addition, we argue that the development methodologies should leave the selection of modelling languages and modelling tools to the software developers.

I. INTRODUCTION
There is a growing demand for developing applications with aspects such as context awareness and self-adaptive behaviours. context awareness [1] means that the system is aware of its context, which is its operational environment. Hirschfeld et al. [2] considered context to be any information that is computationally accessible and upon which behavioural variations depend. A self-adaptive application adjusts its behaviour according to context conditions arising during execution. A self-adaptive application modifies its own structure and behaviour in response to changes in its operating environment [3].
In recent years, a significant number of model-driven architecture approaches were proposed for the construction of contextdependent and self-adaptive applications. The Object Management Group (OMG) presented Model Driven Architecture (MDA) as a set of guidelines for building software systems based on the use of the MDD methodology [4]. MDA focuses primarily on the functionality and behaviour of a distributed application or system deployed across many platforms. In MDA, the functionality and behaviour are modelled once and only once. Thus, MDA defines the notions of a Computation Independent Model (CIM), Platform Independent Model (PIM) and Platform Specific Model (PSM). CIM describes the software requirements in computational free fashion. A PIM describes the parts of a solution that do not change from one platform to another, and a PSM includes descriptions of parts that are platform dependent [4].
This article contributes to the knowledge by providing an evaluation framework for most popular model-driven approaches that were proposed to support the development of self-adaptive software systems. Such evaluation framework can facilitate software developers on selecting the best development approach that suits their needs and the software requirements. This article is structured as follows: the self-adaptive software and their self-* properties are defined in Section II. Section III provides a detailed description of model-driven approaches that were proposed for facilitating the development of self-adaptive software systems. Section IV proposes an evaluation framework for analysing and evaluating those model-driven approaches. Section V illustrates the evaluation results, followed by the conclusions of this study.

II. SELF-ADAPTIVE SOFTWARE
Mobile computing infrastructures make it possible for mobile users to run software systems in heterogeneous and resourceconstrained platforms. Mobility, heterogeneity, and device limitations create a challenge for the development and deployment of mobile software. Mobility induces context changes to the computational environment and therefore changes to the availability of resources and services. This requires software systems to be able to adapt their functionality/behaviour to the context changes [5]. This class of software systems are called context-dependent/self-adaptive applications, which have the ability to modify their own structure and behaviour in response to context changes in the environment where they operate [3]. Self-adaptive software offers the users with context-dependent and context-independent functionality. Context-independent functionality (also called base functionality) refers to software functionality whose implementation is unaffected by the context changes. For example, the map view and user login forms in mobile map application are context-free functionality (i.e. context changes would not change their functionality). The context-dependent functionality refers to software functionality, which exhibits volatile behaviour when the context changes. Self-adaptive software can be seen as a collaboration of individual features spanning the software modules in several places [2], and they are sufficient to qualify as heterogeneous crosscutting in the sense that different code fragments are applied to different program parts [6]. Before encapsulating crosscutting context-dependent behaviours into a software module, the developers must first identify the behaviours in the software requirements. This is difficult to achieve because, by their nature, context-dependent behaviours are entangled with other behaviours, and are likely to be included in multiple parts (scattered) of the software modules [7]. Using intuition or even domain knowledge is not necessarily sufficient for identifying their volatile behaviour; instead, a formal procedure is needed for analysing and separating their individual concerns [8].
Implementing a self-adaptive software system in a resource-poor environment faces a wide rang of variance in platforms' specifications and Quality of Services (QoS) [9]. Mobile devices have different capabilities in terms of CPU, memory, and network bandwidth [10]. Everything from the devices used and resources available to network bandwidths and user context can change extremely at runtime [11].
In general, model-driven architecture has several challenges such as maintaining the correspondence between architectural models and software implementation in order to ensure that architecture-based adaptation is appropriately executed. The second issue is providing the necessary facilities for implementing the software in wide-range of platforms. An appropriate way to study those challenges is to classify them on the basis of adaptation features that they support and how they manage software variability in the model level [12]. To this aim, the following sections describe several model-driven approaches proposed for facilitating the engineering self-adaptive software system.

III. MODELLING SELF-ADAPTIVE SOFTWARE
In the classical view of object-oriented software development, the modular structure for software systems has rested on several assumptions. These assumptions may no longer characterize the challenge of constructing self-adaptive software systems that are to be executed in mobile computing environments [13]. The most important assumptions in object-oriented development methodologies are that the decision to use or reuse a particular component/object is made at the time the software is developed. However, the development of a variety of modern self-adaptive software architectures such as mobile/ubiquitous computing, and component-based and context-oriented software has emphasized on deferring these decisions about component selection until runtime. This might increase the software capabilities in terms of variability, adaptability, and maintainability, and increase the anticipatory level of the software by loading a particular component/service that can handle unforeseen context changes dynamically.
Supporting the development and execution of self-adaptive software systems raises numerous challenges. These challenges include: 1) the development processes for building them, 2) the design space, which describes the design patterns and the best practices of designing their building blocks, i.e. component model or code fragments, 3) the adaptation mechanism that describes the best adaptation action that can be used under the limited resources of the computational environment.
In general, the development self-adaptive systems faces several challenges such as maintaining the correspondence between architectural models and system implementation in order to ensure the adaptation action is appropriately executed. The second issue is providing the necessary configuration that suits the deployment platforms. An appropriate way to study the challenges is to classify them on the basis of adaptation features that they support and how they manage software variability in the architecture level [12]. In the following sections, several approaches that target engineering self-adaptive systems are discussed.

A. Model Driven Development and AOP
Carton et al. [8] proposed the Theme/UML, a model driven approach supported by aspect-oriented programming in an attempt to model various crosscutting concerns of context-aware applications at an early stage of the software development. Theme/UML provides a systematic means to analyse the requirements' specification in order to identify base and crosscutting concerns, and the relationships between them. However, to the best of our knowledge, there is no similar approach that can help the developers to analyse and understand the context-dependent behaviours in the requirements, design and implementation of the self-adaptive applications.
The Theme/UML approach was based on the use of the Meta Object Facility (MOF) extension and the ECORE [14]. The MOF meta model for the development of context-aware mobile applications proposed by de Farias et al. [15] was structured according to the core and service views of the software system. This approach provides a contextual model that is independent from the application domain. However, it does not provide high-level abstraction of the software models, which express conceptual characteristics of the context-dependent behaviours. From a software developer's perspective, it does not take into account architectural or deployment issues, because it is based on the service-oriented architectures. In addition, it has focused on the model-to-model transformation for generating the software composition. Such approach adds substantial overhead over the development for writing and configuring the MOF scripts. The Theme/UML methodology limits the development of selfadaptive applications to a very specific framework that supports the AspectJ and Eclipse Modelling Framework (EMF) [16]. Extending this paradigm for another platform requires a specific compiler that supports Aspect-Oriented Programming (AOP) and toolset that follow the EMF.
Plastic is another development approach, which uses the MDD paradigm for developing and deploying adaptable applications, implemented in Java language [5]. The Plastic development process focuses on the model verification and validation and service composition of java service stubs. The methodology shows a very interesting feature of runtime model verification and validation mechanism. Unfortunately, the generated software is tightly coupled with the target deployment platform and cannot be used with a standard development process supported by a standard object-oriented language other than the JAVA and AspectJ languages. However, the two-paradigm Theme/UML and Plastic face challenges with regard to the model manipulation and management. These challenges arise from problems associated with (1) defining, analysing, and using model transformations, (2) maintaining traceability links between model elements to support model evolution and round-trip engineering, (3) maintaining consistency among viewpoints, (4) tracking versions, and (5) using models during runtime [17].

B. A-MUSE
An MDA-based approach for behaviour modelling and refinement is introduced by Daniele et al. [18]. Daniele et al. proposed the Architectural modelling for Service Enabling in Freeband (A-MUSE) approach, which focuses on the decomposition of the PIM model into three levels; each level is used to automate a behavioural model transformation process. Daniele et al. [18] applied their approach to a Mobile System Domain Specific Language (DSL) (called M-MUSE). Therefore, the platform independent design phase has been decomposed into the service specification and platform-independent service design steps. The platform-independent service design model should be a refinement of the service specification, which implies correctness and consistency, particularly of behavioural issues, which have to be addressed in the refinement transformation. However, when trying to realize this refinement transformation, a gap between service specification and platform-independent service design was wide, so that correctness and consistency were hard to guarantee in a single refinement transformation. The authors approach this problem by proposing multiple rounds of transformation between the PIM and PSM, which requires the developers to switch simultaneously between the PIM, PSM and the service specifications several times.

C. CAMEL
Context Awareness modelling Language (CAMEL) is an MDD-based approach proposed by Sindico and Grassi [19]. The approach uses a domain-specific language called JCOOL, which provides a metamodel for context sensing with the supports of the context model designed using the JCOOL meta model. However, Sindico and Grassi implemented the context binding as the associate relationship between context value and context entity. On the other hand, context-driven adaptation refers to a structure or behaviour elements, which are able to modify the behaviour based on context values. The structural or behavioural insertion is accomplished whenever a context value changes; it uses AOP inter-type deceleration, where the behavioural insertion is accomplished by means of an AOP advice method to inject a specific code into a specific joinpoint.
The CAMEL paradigm provides insufficient details with regard to the underlying component model or the application architecture. The authors used their former domain-specific language to support the Context-Oriented Programming (COP) approach proposed by Hirschfeld et al. [2]. Moreover, CAMEL has no formal MDD methodology that possesses a generic life cycle that a developer can use. Irrespective of these problems, JCOOL is specific to an AOP framework called the Simple Middleware Independent LayEr (SMILE) [20]. SMILE platform used for distributed mobile applications [20]. The model approach in JCOOL supports only ContextJ, which is an extension of the Java language proposed by Appeltauer et al. [21]. The CAMEL methodology requires the software to be re-engineered whenever a new context provider is introduced into the context model. The developers must build a complete context model for the new values and maintain the underlying JCOOL DSL and the Unified Modelling Language (UML) model. The CAMEL methodology has adapted AOP and the EMF to produce a context-oriented software similar to the layered approach proposed by Hirschfeld et al. [2]. This makes CAMEL limited to the EMF tool support and the ContextJ language [22]. From our point of view CAMEL tightly coupled the software with modelling language, modelling tool and the target deployment platform.

D. MUSIC MDD
The MUSIC development methodology [23] adapts a model-driven approach to construct the application variability model. In MUSIC, applications are built using a component framework, with component types as variation points. The MUSIC middleware is used to resolve the variation points, which involves the election of a concrete component as a realization for the component type. The variability model defines the component types involved in the application's architecture and describes their different realizations. This comprises either a description of collaborating component types and rules for a composite realization, or a reference to a concrete component for an atomic realization. To allow the realization of a component type using external services, the variability model also includes a service description, which is used for service discovery.
The software architecture in MUSIC is a pluggable architecture for self-adaptive applications. It proposes middleware featuring a generic and reusable context management system. The architecture supports context variation and resource utilization by separating low-level platform-specific context from higher-level application-specific concerns. The resource utilization is improved through intelligent activation and deactivation of context-related plug-ins based on the needs of the active application. The MUSIC middleware architecture defines multiple components that interact with each other to seamlessly enable self-adaptive behaviour in the deployed applications. These components include context management, adaptation reasoner, and a plug-in life-cycle management based on the Open Services Gateway initiative framework (OSGI) [24].
At runtime, a utility function is used to select the best application variant; this is the so-called 'adaptation plan'. The utility function is defined as the weighted sum of the different objectives based on user preferences and QoS. Realistically, it is impossible for the developer to predict all possible variations of the application when unanticipated conditions could arise. In addition, mobile computing devices have limited resources for evaluating the many application variations at runtime and can consume significant amounts of device resources. As an outcome, the benefit gained from the adaptation is negated by the overhead required to achieve the adaptation [12].

E. Paspallis MDD
Paspallis [25] introduced a middleware-centric development of context-aware applications with reusable components. Essentially, his work is based on the MUSIC platform [26]. According to Paspallis, an MDA-based context-aware application is built by separating the concerns of the context provider from those of the context consumer. For each context provider, a plug-in or bundle is planned and designed during the design phase. At runtime, a utility function is used to consider the context state and perform decision-making process. Once the plug-in is selected to be loaded into the application, middleware support performs dynamic runtime loading of the plug-in.
However, it is impossible for the developers to predict all the context providers that might produce context information at runtime. In addition, using this methodology means that the developer is required to design a separate plug-in architecture for each context provider, which is proportional to the available number of context providers. Additionally, this methodology does increase the development effort as each plug-in requires a separate development process.

F. U-Music MDD
Khan [27] proposed U-MUSIC methodology. U-MUSIC adapts a model-driven approach to constructing self-adaptive applications and enabling component model-based, unanticipated adaptation. However, the author has modified the MUSIC methodology to support semi-anticipated adaptation; also called planning-based adaptation, which enables the software to adapt among foreseeable context changes. U-MUSIC enables developers to specify the application variability model, context elements, and data structure. The developers are able to model the component functionalities and quality of service (QoS) properties in an abstract, platform-independent way. In U-MUSIC, dynamic decision-making is supported by the MUSIC middleware mentioned above. However, this approach suffers from a number of drawbacks. First, it is well-known that correct identification of the weight for each goal is a major difficulty for the utility function. Second, the approach hides conflicts between multiple goals in its single, aggregate objective function, rather than exposing the conflicts and reasoning about them. It would be optimistic to assert that the process of code generation from the variability models can become completely automatic or that the developer's role lies only in application design.

G. CAUCE
CAUCE proposed as a model-driven development approach [28]. The authors defined an MDA approach that focuses on three layers of models. The first layer confirms to the computational independent model for capturing the conceptual properties of the applications. The second layer defines three complementary points of view of the software systems. These views include deployment, architecture and communication. The third layer focuses on converting the conceptual representation of the contextaware application into a software representation using a multi model transformation. The Atlas Transformation Language (ATL) is used to interpret the model and convert them into a set of models conforming to the platform independent model. The final model is transformed using the MOF Script language based on the EMF paradigm [14]. The CAUCE methodology focuses more on the CIM by splitting this layer into three layers of abstraction, which confirms to the tasks, social and space meta models. The task model focuses on modelling a set of tasks and the relationships among them that any entity in the system is able to perform. The social metamodel defines the social environment of the entities in the system and is directly related to the entity task and entity information that identify of the context-aware application behaviour. The space metamodel defines the physical environment of the entities in the system. Therefore, this metamodel is directly related to the physical conditions, infrastructure and location characteristics of the context-aware applications.
However, the CAUCE methodology provides a complete development process for building context-aware applications. Despite that, CAUCE is limited to specific modelling tool and language, in this case the UML is integrated with EMF. The generated application can only be implemented using Java language as it is supported by the ATL and MOF Script languages. However, it is impossible for the developers to adapt CAUCE for building heterogeneous and distributed mobile applications, which might have multiple deployment platforms and requires variant implementation languages.

H. ContextUML
Generally, UML profiles and metamodels are used to extend the UML language semantics. ContextUML was one of the first approaches that targeted the modelling of the interaction between context and web service applications [29]. ContextUML was extended by Prezerakos et al. [30], using aspect-oriented programming and service-oriented architecture to fulfil the user's needs. However, contextUML used a UML metamodel that extended the regular UML by introducing appropriate artifacts that used to create context-aware applications. contextUML produces a class diagram, which corresponds to the context class and to specific services. They mitigate the UML relationship and dependency to express the interaction between the context information and the respective services. A means of parameter injection and service manipulation are used to populate specific context-related parameters in the application execution loop.
However, the UML profiles and metamodels lack from several features required for modelling the self-adaptive software system. Ignoring the heterogeneity of the context information, they based their claims on the nature of the context values, which can fluctuate and evolve significantly at runtime. It is not feasible to this study how the behaviour is modelled when multiple context values have changed at the same time.

I. COCA-MDA
Accodring to the Context-Oriented Component-based Applications Model-Driven Architecture (COCA-MDA) approach, the software self-adaptability and dependability can be achieved by dynamically composing software from context-oriented modules based on the context changes rather than composing the software from functional-oriented modules. Such composition requires the design of software modules to be more oriented towards the context information rather than being oriented towards the functionality. The principle of context orientation of software modules was proposed in the COCA-MDA [31]. COCA-MDA proposes a decomposition mechanism of software based on the separation between context-dependent and context-independent functionality. Separating the context-dependent functionality from the context-independent functionality enables adaptability and dependability of software systems with the aid of middleware technology. The middleware can adapt the software behaviour dynamically by composing interchangeable context-dependent modules based on context changes. COCA-MDA proposes that software self-adaptability is achieved by having both an adaptive middleware architecture and a suitable decomposition strategy, which separates the context-dependent functionality from the context-independent functionality of the software systems.
COCA-MDA was proposed as a generic and standard development paradigm towards constructing self-adaptive software from context-oriented components, which enables a complete runtime composition of the context-dependent behaviours and provides the software with capabilities of self-adaptability and dependability in mobile computing environment. The contextoriented component model encapsulates the implementation of the context-dependent parts in distinct architectural units, which enables the software to adjust its functionality and/or behaviour dynamically. This differs from the majority of existing work, which seek to embed awareness of context in the functional implementation of applications. The context-oriented software is developed using a COCA-MDA. Afterwards, the context-oriented software is manipulated at runtime by a COCA-middleware that performs a runtime behavioural composition of the context-dependent functionality based on the operational context. The self-adaptive software dependability is achieved through the COCA-middleware capability in considering its own functionality and the adaptation impact/costs. A dynamic decision-making based on a policy framework is used to evaluate the architecture evolution and verifies the fitness of the adaptation output with the application's objectives, goals and the architecture quality attributes.
The COCA-MDA follows the principles of OMG model-driven architecture. In MDA, there are three different viewpoints of the software: the Computation Independent View (CIV), the Platform Independent View (PIV), and the Platform Specific View (PSV). The CIV focuses on the environment of the system and the requirements for the system, and hides the details of the software structure and processing. The PIV focuses on the operation of a system and hides the details that are dependent on the deployment platform. The PSV combines the CIV and PIV with an additional focus on the details of the use of a specific platform by a software system [4]. COCA-MDA partitioning the software into three viewpoints: the structure, behaviour, and enterprise viewpoints. The structure viewpoint focuses on the core component of the self-adaptive application and hides the context-driven component. The behaviour viewpoint focuses on modelling the context-driven behaviour of the component, which may be invoked in the application execution at runtime. The enterprise viewpoint focuses on remote components or services, which may be invoked from the distributed environment. The COCA-MDA provides the developers with the ability to specify the adaptation goals, actions, and causes associated with several context conditions using a policy-based framework. For each COCA-component, the developers can embed one or more Decision PoLicys (DPLs) that specify the architecture properties. The DPL is described by a state-machine model based on a set of internal and external variables and conditional rules. The rules determine the true action or else an action based on the variable values. The action part of the state diagrams usually involves invoking one or more of the component's layers. A single layer is activated if a specific context condition is found, or deactivated if the condition is not found.
The use of COCA-MDA for building self-adaptive applications for indoor wayfinding for individuals with cognitive impairments was proposed in [32]. Evaluating the COCA-MDA productivity among the development cost and effort using The Constructive Cost Model II (COCOMO II) [33] was demonstrated in [34] . This article focuses on evaluating the features of COCA-MDA against the above mentioned approaches as shown in the following section.

IV. FEATURE ANALYSIS AND COMPARATIVE STUDY OF MDA-BASED APPROACHES
From the software developer's perspective, it is vital to know the features of the development paradigm, which might be used in constructing a self-adaptive application. Feature evaluation of the development methodology can assist the developers in selecting among the proposed methodologies in the literature for achieving adaptability and dependability of the software systems. Improving the development of self-adaptive software systems using model driven approach has attained several research efforts. The target was in general to introduce software with adaptability and variability while focusing on reducing the software complexity and optimising the development effort.
The examination of software system performance, dependability and availability is of greatest importance for tuning software system in conjunction with several architecture quality attributes. Such performance analysis was considered by the modelling Specification and Evaluation Language (MOSEL) [35]. The system modelling using MOSEL illustrates how easily it can be used for modelling real-life examples from the fields of computer communication and manufacturing systems. However, extending the MOSEL language towards the modelling and performance evaluation of self-adaptive software system can estimate several quality attributes of model-based architecture and provides early results about how efficient is the adaptation action.
Kitchenham et al. in [36] proposed the DESMET method, which evaluates software development methodologies using an analytical approach. Asadi et al. have adapted the DESMET method to analyse several MDA-approaches. The authors adapted several evaluation criteria that can be used to compare MDA methodologies based on MDA-related features and MDA-based tool features [37].
However, Calic et al. [38] proposed an evaluation framework to evaluate MDA-based approaches in terms of four major criteria groups, as follows: I) MDA-related features: The degree to which the proposed methodologies are compliant with OMG's MDA specification [4]. II) Quality: Evaluation of the overall quality of the MDA-based approaches including their efficiency, robustness, understandability, ease of implementation, completeness, and ability to produce the expected results [36]. III) Usability: Simplicity of use and ease of implementation by the developer, which covers clear information about the impact of the methodology on the development effort [39], [40]. IV) Productivity: The quality of benefits derived from using the methodology and its impact on the development time, complexity of implementation, code quality, and cost effectiveness [38]. Calic at al. [38] presents the COPE tool, to evaluate the MDA productivity by automate the coupled evaluation of metamodels and model by recording the coupling history in an history model.
Lewis et al. [41] have evaluated the impact of MDA on the development effort and the learning curve of the MDA-based development tools based on their own experiences. The authors concluded that the real potential behind MDA is not completely employed either by current tools or by the proposed MDA approaches in the literature. In addition, the developers have to modify the generated code such that it is suitable for the target platform. The MDA tools can affect the level of maintenances required for the generated codes. In the same way, the developer's level of understanding of MDA tasks and their familiarity with the target platform have direct impacts on MDA productivity.
The COCOMO II [33] emerged as software cost estimation model, which considers the development methodology productivity. The productivity evaluates the quality of benefits derived from using the development methodology, in terms of its impact on the development time, complexity of implementation, code quality, and cost effectiveness [38]. COCOMO II allows estimation of the effort, time, and cost required for software development. The main advantage of this model over its counterparts such as the Software Life-cycle Management (SLIM) model [42] and the System Evaluation and Estimation of Resources Software Estimation Model (SEER-SEM) [43] is that COCOMO II is an open model with various parameters which effect the estimation of the development effort. Moreover, the COCOMO II model allows estimation of the development effort in Person-Months (PM) and the Time to Develop (TDEV) a software application. A set of inputs such as software scale factors (SF) and 17 effort multipliers is needed. A full description of these parameter is given in the COCOMO II model definition manual, which can be found in [33]. An example of an evaluation of MDA approaches with COCOMO II can be found in [44].
In this research, we intend to use an evaluation framework that can test and qualify the ability of MDA-based approaches to produce the expected results [36] in terms of dynamic adaptation in general, and self-adaptability, in specific. These features are evaluated in the following sections.

A. Existence of MDA-related Features
MDA features refers to the degree to which the proposed methodologies are compliant with the OMG's MDA specifications; these specifications can be divided into the support of CIM, PIM, PSM, model validation, and transformation [4]. In terms of MDA features, we adapt the criteria proposed by Asadi and Ramsin [37], which highlights the methodology's conformance to the original OMG standard, as shown in Table I. Feature analysis can be performed in two ways: scale form and narrative form. The scale form attaches the methodology complaint to a specific feature, which is divided into three ranks, from A to C, as shown in each table. The narrative form captures whether the methodology covers a specific feature based on the level of involvement.

B. Tool-related feature analysis
The major challenges that developers face when attempting to realize the MDD vision is the selection of a modelling language and modelling tool. Modelling languages challenges arise from concerns associated with providing support for creating and using an appropriate modelling abstraction for analysing and designing the software [17]. A second challenge posed by Asadi and Ramsin [37], that each development methodology generates more specific technical details that suit the underlying modelling language or modelling tool they used, as each tool requires a learning curve, and it might have some limitation with regard to the platform and the number of implementation languages they support [41]. This implies that a MDD approach should be decoupled from using a specific tool or modelling language. The developers have to be free on selecting the tool(s) that fits their needs and the software under development.
On the other hand, MDD approaches should focus more on describing standard development processes without relaying on a specific technology or platforms like EMF and ECORE. In terms of the tools the methodology used, the features that highlight the methodology dependency on the modelling languages and tools are shown in Table II.

C. Quality of the MDA-based Approaches
Quality refers to the overall quality of the MDA-based approaches, including their efficiency, robustness, understandability, ease of implementation, completeness, and ability to produce the expected results [36]. However, in this research, we have focused on the ability of the MDA-based approaches to provide the expected results that support the adaptability of the generated software, whether these results are derived from the code or the architecture. Moreover, we have split these criteria into four groups: requirements engineering, unanticipated awareness, context model, and modelling context-dependent behavioural variations.
1) Requirements Engineering of Context-dependent Behavioural Variations: Requirements engineering refers to the causes of adaptation, other than the functional behaviour of the self-adaptive system. Whenever the system captures a change in the context, it has to decide whether it needs to adapt. The MDA-based approaches in the related work were evaluated regarding whether they support the modelling of context requirements as a specific feature and whether they support the requirements' engineering in general, as shown in Table III. In addition, the methodology's ability to analyse and models the context-dependent behaviour variations requires the MDD supports at three levels. The first is the requirement analysis at the computational independent model. The second is the representation of these requirements by means of UML objects at the platform independent model and platform specific model. The third is the representation of the context-dependent behaviour as runtime objects, which are a code representation of these requirements [45]. However, the evaluation of these criteria is shown in Table III. 2) Unanticipated Awareness: This feature captures whether a context change can be predicted ahead of time [46]. Anticipation can be classified into three degrees: foreseen, foreseeable, and unforeseen changes. Foreseen refers to the changes that are handled in the implementation code. Foreseeable refer to the context changes that were predicted at the software design. Unforeseen refers to the changes that are not modelled at the design or the implementation stage, but are to be handled at runtime [47]. The evaluation criteria are shown in Table IV with their related scale form.

3) Context Model:
This captures the ability of the methodology to incorporate the context information using the 'separation of concerns' technique between the context information model and the business logic. The first criterion focuses whether the methodology supports/uses the separation of concerns in the development processes. The second criterion refers to the ability to bind the context source to the context provider, as proposed by Sen and Roman [48] and Broens et al. [49] and Paspallis [50]. The binding mechanism enables the developers to map each context cause to the affected architectural units. The binding mechanism also enables the application to determine which part has to manage the context changes, by means of the adaptation mechanism.
The evaluation criteria for the context model are shown in Table V.

4) Modelling
Context-dependent Behaviour: These criteria refer to the ability of the model to capture the impact of context changes on the self-adaptive application's behaviour. However, Hirschfeld et al. [2] classified these changes into three kinds of variations: actor dependent, system dependent, and environment dependent behavioural variations. These behavioural variations requires a separation between their concerns, by separating the context handling from the concern of the application business logic. In addition, a separation between the application-dependent parts from the application-independent parts can support behavioural modularization of the application, thereby simplifying the selection of the appropriate parts to be invoked in the execution, whenever a specific context condition is found. The behavioural modelling criteria are shown in Table VI.  Tables I, II, III, IV, V, and VI, we find that the discussed methodologies in the related work suffer from several critical failings in terms of their conformance to the OMG's guidelines for MDA methodology [4].

Based on the analysis results shown in
First, it is well known that correct identification of the weight of each goal is a major difficulty for the utility functions as shown in the MUSIC, U-MUSIC and Paspallis methodologies.
Second, these approaches hide conflicts among multiple adaptation goals by combining them into a single, aggregate objective function, rather than exposing the conflicts and reasoning about them. On the other hand, it would be optimistic to assert that the process of code generation from models can become completely automatic or that the developer's role lies only in application design, as discussed in the above with regard to CAMEL and A-MUSE.
Third, it is impossible for the developers to predict the possible application variations, which will extend the application behaviour when unanticipated conditions arise, this applied to all methodologies mentioned in the above.
In addition, mobile devices have limited resources for evaluating many application variations at runtime, which might consumes significant amounts of the allocated resources. As a result, the benefits gained from the adaptation are negated by the overhead required to achieve the adaptation. Fourth, the previously mentioned methodologies produce an architecture with a tight coupling between the context provider and the context consumer, which may cause the middleware to notify multiple components about multiple context changes. Finally, all the methodologies seem to generate an architecture that is tightly coupled with the target platform for deployment and the modelling tools they used.
In addition, the developers have to explicitly predict the final composition of the software and the possible variations of the application, whether at the platform independent model or through the model transformation. Moreover, the developers have to modify the generated code to be suitable for deployment on the target platform and to be integrated with the middleware implementation, which is in the best case made a hug gap between the middleware designer and the application developer. Understandings the modelling tasks and the target platform configurations have limited software developers from employing MDA-approaches in several platforms.

VI. CONCLUSIONS
With the current state-of-the-art, it is possible to design a system that could adapt its behaviour. However, any adaptation would either have to be pre-defined at design time, or would have to be a reflective response to some monitored parameters, perhaps by using the available techniques of model-driven architecture. An effective pre-defined responses would be dependent on the requirements analyst anticipating and enumerating of all the possible environmental states and the corresponding behaviour required. A drawback of the reflective response is that the relationship between the adaptation and the objective goal would be at best implicit, making the verification of goal satisfaction hard or even impossible. The MDD-based approaches proposed in the literature suffer from a number of drawbacks. First, it would be optimistic to assert that the process of model transformation and code generation from the software models can become completely automatic and that the developer's role lies only in application design. Second, it is impossible for the developer to predict all possible variations of the application when unanticipated conditions will arise. In addition, mobile devices have limited resources for evaluating many application variations at runtime and can consume significant amounts of device resources. As result, the benefit gained from the adaptation is negated by the overhead required to achieve the adaptation. Third, each development methodology generates more specific technical details that suit the underlying implementation language or modelling tool they used. We found that COCA-MDA is more capable to meet the requirements of self-adaptive systems and allows the software developers to adapt it in wide range of execution platforms.


Modification of the Norwegian Traffic Light States as the Method to Reduce the Travel Delay

Traffic lights have a vital role as regulatory systems to control the vehicles flowed in urban networks. This research is based on the real case. The traffic lights are installed at a massive intersection of an urban network consisting of four sections. The systems control implements the modification of the Norwegian traffic lights states. The behavior of traffic lights states were modeled using Petri net method. For the model verification and validation, the invariants and simulation were applied. The purpose of the implementation of this control system was to reduce travel delays. The intersection performance level was good while the average travel delay on all sections was low. The method used for the testing was the comparison of the simulation results due to the settings that apply the standard system to the imitation of the reality of the system using modifications of the Norwegian traffic lights states. The control system was able to reduce the travel delays slightly. The average of Level of Service (LoS) index of the roads for all sections was at level D. It improved the performance of the intersection, but not yet significant. In addition to setting traffic lights, the presence of flyovers is urgent to improve travel delays.

Introduction
Generally, one of the traffic lights functions is to separate the different vehicle traffic flows and prevent the conflicts [1]. Its implementation offers the safety of travel and efficiency [1]. But on the contrary, its improper use will lead to heavy congestion, inefficient travel, inconvenience, and high travel delays [2].
This research is done in connection with an intersection that has massive size. It consits of four sections with the horizontal geometric grade. It is the left-hand vehicle traffic.
For reducing the travel delay, the traffic lights states apply the modification of the Norwegian traffic lights states. This paper investigates its significance when compared to a standard system. As we all know, travel delay is an indicator of the performance of the vehicle traffic passing on the road network [3].
The intersection is the gateway from the northern city of Madiun -Indonesia. Its scheduling of the traffic light applies a fixed time strategy. Due to the massive size, the intersection requires a relatively long time interval to clear the intersection of the vehicle traffic flow. It is done when all red signal. Its purpose is to ensure that no conflict occurs [3].
Whether traffic lights of the modification of Norwegian traffic lights are an efficient method to reduce travel delays? This method is desirable to achieve the aim for improving the performance of the intersection as the challenge of this research.
Commonly, the standard traffic lights have three states [4]. The states of Norwegian traffic lights are green, yellow, red, yellow-red both light up simultaneously and turn to green again become a traffic light cycle [5], [6]. The modification of the Norwegian traffic lights has four states too. They are green, the first yellow, red, the second yellow, and return to the green signal again as the initial state.
In this paper, the traffic lights behavior was modeled by Discrete Event Systems (DES). The system can formulate the sequences of events occurring at the set time intervals [7]. One of DES's manifestations is Petri Net [7]. It can be a sequence of events design on traffic lights [8]. Petri net model can also be attached with time (TPPN / Time Place Petri Net) [8]. The model system can offer representations of conflict situations from various resources, synchronization of events or schedules, and multiple constraints that should be prioritized [9], [10].
Many previous researchers have done the study on the dynamics of system behavior using Petri net. Y. S. Huang, et al. [1], studied the intelligent transportation systems. It is the modular design of urban traffic-lights control. The systems are based on the synchronized timed petri nets. D.
Computer Science and Information Technology 7(1): 22-30, 2019 23 Adzkiya [7] built the model of the behavior of traffic lights and the simulations using Petri nets. M. Dotoli M. and M. P. Fanti [11] reviewed the model of urban traffic network through Petri net with time and color.
In the following is the research about travel delays. R. Kurniawan and R. A. Al-Hasibi [2], with their research entitled the concept of adaptive traffic control. It is synchronized to the road density to minimize the duration of the waiting time. M.B. Asih and I. Muthohar [12] suggested removing activity and obstacles such as vehicles parking on the roadside. While roadside activity was high, road capacity became low. Therefore, the travel delay became high due to the high saturation level of the road. Congestion can reduce traffic comfort, safety, travel speeds of road users, and add travel delay as well as raising the vehicle operating costs. A. Narendra and A. Budiwirawan [13] studied a method for reducing travel delays by building a mid-way block and traffic signs. The results seem insignificant when applied to an intersection in the city of Semarang. F. Kurniawan, et al., [14] developed the systems that can modify the green time interval of each section of the intersection based on the traffic volume. The appropriate green time interval time of the traffic light can improve the performance of the intersection. Papageorgiou et al., [15] reviewed the road traffic control strategies. The study of T. Tristono [16] about the traffic vehicles delay on a signalized intersection. It was integrated into the railway doorstop.

Research Methods
This research uses Petri net with Place-Time for the modeling method of the behavior of traffic lights. Each state of the traffic light is equipped with the time interval or duration. The traffic lights design the models settings for the traffic of a massive intersection at Madiun city. The traffic lights apply the modification of the Norwegian traffic lights states for the reduction method of the travel delays.

Basic Petri Net, Its Properties, and P-Time Petri Net
A Petri Net is a graph installed in its directions and weights. The 4-pair of elements of the basic/ classical Petri net are places, transitions, arcs, and tokens [9]. Places for presenting the events/ states. Transitions have a function for firing, which is to change events/ states. Place is presented with circle/ ellipse and transition by box/ square. The formal definition of the Petri net structure [10] is written below. Definition 1. A Petri net structure N = (P, T, Pre, Post). It consists of 4-pairs elements. P and T are sets of the finite elements of places and transitions, respectively. P = {p1, p2, p3,. . . pn}, T= {t1, t2, t3,. . . tm}. Pre: (PxT) → N+ is the input function that defined by the directed arch from place to transition. Post: (TxP) → N+ is the output function that defined by the directed arch from the transition to the place which N+ is a non-negative integer.

Definition 2.
A basic Petri net is PN = (N, Mo). N is a Petri net, and Mo is its initial value.
The dynamic behavior of a Petri net is represented by the marking path from Mo to Mz. The marking sequence is declared with firing the enable transitions. The transition t ∈T is said to be enabled while all input places p∈P have at least the number of tokens equal to the weight of the arc connecting places p to transition t, (M(p)≥Pre (p,t); p∈P).
Several desired functional properties are used for verification and validation Petri net states. This proves that the design of an absolute model is correct. Several of the main properties of Petri Net are, i.e., reachability, reversibility, boundedness, safeness, and liveness [9], [10]. Firing of transitions resulting in a possible marking sequence accomplished with a change of token distribution. The marking of Mz is said to be reachable from Mo if there is a fire sequence that builds a path from Mo to Mz. This is stated by Mz∈R(N,Mo). The Petri net design is reversible when it is possible to return to the original state. A Petri net (N, Mo) is k-bounded if the number of tokens in each place will not exceed k for any marking that can be reached from Mo, which k is positive integers. Petri net (N, Mo) is safe while it is 1-bounded [10]. Petri net (N, Mo) is live for every Mz that can be reached from Mo. The liveness on a Petri net is a guarantee that has no deadlocks [10].
Events that are modeled on the states of Petri net can have an interval time interval by adding the duration of the event to each place [8].

Definition 3.
A P-Time Petri net is a pair (PN; Ip). PN is a Petri net with the initial state, and Ip is the time function defined as Ip : P → (ℚ +⋃ 0) (ℚ +⋃ ∞).
The time interval Ip=[ , β] connecting with 0 ≤ ≤ β. It is the static time interval to express the duration while a token in a place P is available for firing by a transition. Before and after β, the existence of a token is nonavailable or it namely as a dead token. The value is the minimum date, and β is the maximum date. A fixed time interval of a signal of the traffic lights has occurred while the minimum date is equal to the maximum date.

Petri Net Traffic Lights Model
This is the four-phases of Petri net traffic lights model of an intersection. It implements modifications of the Norwegian traffic lights system. The standard traffic signals are lit up with a fixed sequence as a loop cycle. In general, traffic signals are green, yellow, and red [4]. In traffic signaling with the Norwegian system, it has one more stage, which is a red-yellow signal that simultaneously lights up in the traffic signaling with modifications of the Norwegian system turning the fourth 24 Modification of the Norwegian Traffic Light States as the Method to Reduce the Travel Delay stage into yellow color only. It happens after the red signal ends. The proper application of the yellow signal method has been proven to reduce travel delays [4]. The red-yellow method or yellow signals after the red signal informs the driver that the red traffic signal will end soon. The drivers are allowed to start the movement of the vehicle soon. Typically, this method is applied to signaling at an intersection that does not use a seven-segment board to present the remaining red signal time intervals. In this case, the signalized intersection has applied modifications of the Norwegian system. Therefore, there is no sevensegment board.

Invariants
Traffic control signals must have the error-free of the features, no deadlocks, no scheduling for conflicting vehicle movements, can serve all phases, and should be able to return to initial state [7]. Petri net model verification and validation applies invariants and simulations as the event graphs. The invariant formula presents the marking of the place of Petri net model. It is "1" or "0" only, those mean turn on or off, respectively. Place controls are not included in the invariants.
Invariant (2) indicates no conflicting vehicle movements. When there is a token in place Ri, there must be a token in one of the three places Gj, Yj, or Rj while i, j=1,2,3,4 and i Invariant (3) is attached with an intermediation place S that represents for all red signals.

Traffic Lights Schedule
The traffic light simulation illustrates the scheduling of each signal in all phases with the timing of the events.
In Table 1. is the traffic light schedule for each phase. The high vehicle volumes at sections 2 and 3 are served using the longer green intervals of time than others. All red signals for all sections are six seconds. For a small intersection, all red signals are three seconds. The long intervals of all red signals have the potential to increase travel delays significantly. When the number of phases is smaller than four, this also has implications for travel delays. However, this can be a cause of conflict in the movement of vehicle flow.

Travel Delays
The control of the vehicles stream of an intersection uses traffic signals resulting in the waiting time for vehicles arriving at the time d  Cited from [3] 26 Modification of the Norwegian Traffic Light States as the Method to Reduce the Travel Delay

Modification of the Norwegian Traffic Lights States
The traffic signals always lit up in a sequence of the state as a loop cycle. The standard road signs feature usually change from green as the initial state, yellow, red and return to green signal [4]. The green signal of standard traffic signal means that the drivers could start driving. The yellow signal indicates that the drivers ready to stop because the signals will turn red immediately. The red signal gives the information that the drivers must stop [4].
The Norwegian traffic signals have one additional stage, i.e., red-yellow that active simultaneously. This stage suggests the driver to get ready start driving. By using this method, hopefully, it can reduce the time delay of traveling of vehicles queue although it does not use seven-segment as countdown timers for presenting the time stop remaining [4]. The modification of the Norwegian traffic lights changes the red-yellow stage into a signal yellow color only after the red signal passed.

Results and Discussion
While the peak hours, the vehicle arrival volume of the southern section is about 1,200 PCU/ hour and other sections each volume is about 2,000 PCU/ hour. Except for the southern sections, the traffic of vehicles are dominated by heavy vehicles such as intercity buses, dump trucks, trailer trucks. About 45% and 25% of vehicles from the north and west sections do the LTOR (Left Turn On Red), respectively. It means their travel delay is zero.
The PCU (Passenger Car Unit) is a vehicle measurement standard metric passing by on the road by comparing them to a single passenger car [3], [4]. The vehicles are categorized into Low Vehicle (LV) is 1 PCU, Heavy Vehicle (HV) is 1.3 -3 PCU, Motorcycle (MC) is 0.4, and non-motorized vehicles are ignored.

While Implements Modification of Norwegian Traffic Lights States and Its Delay Analysis
After the red signal ended, the driver's response to start rerunning their vehicles. On the signaling system using Norwegian system or its modification, the response was relatively the same. They moved forward two seconds faster than those applying standard system signaling.
The intersection has a massive size and long distance between the stop line of the sections. It was the reason for the implementation of the modifications of Norwegian signaling system. The signaling uses modifications of the Norwegian system at small intersections have a high risk. Without the disciplinary behavior of drivers to comply with traffic signs, it may create new threats to the safety of travel.
Based on the existing data, it was simulated travel delays with signaling using both systems, i.e., standard system and modification signaling Norwegian system. Both results were compared.
Based on Table 3, the modification of the Norwegian traffic signal applied three seconds for the yellow time interval after the green state and two seconds to yellow after the red signal passed. The time interval for all red signals using four seconds.
Based on Fig. 6, the black line pattern is the vehicle travel delay at the intersection that implemented standard system traffic signals. On the contrary, the red line pattern is a vehicle travel delay at the intersection using the modification of Norwegian system traffic signals. Total travel delay is the multiplication between the amount and the delay of each vehicle. The horizontal axis is the time in a cycle of the traffic signals.   On the left side is the pattern of the total travel delay when the traffic signal start to turn on red. It is the first queuing vehicle that has a high-value travel delay. It shall wait for the longest time interval. On the right side is the pattern of the total travel delay when the traffic signal activated the green signal. At that time, the vehicles gradually leave the intersection. For the Vehicles that arrive at the intersection when the green traffic signal lit, they have a travel delay close to zero.
The assumption, traffic flow has not been saturated. In general, Travel delay patterned with black lines is higher than the red line pattern, but not significant. The pattern decreases with the trend of the transverse wave model. This relates to a computer simulation which assumes that the vehicle's arrival model has a normal distribution. The arrival of the vehicle is measured in every three seconds based on the vehicle sensor request. The highest frequency is the arrival of vehicles which numbers are close to the average. The number of arrivals of large or small vehicles, both have low frequencies.
Refer to Table 4., the average travel delay for all sections that implement the standard signal system is 38.60 seconds/ PCU and for the intersection that applied the modification of Norwegian traffic signal is 36.15 seconds/ PCU. Both Level of Service (LoS) index were D.
Based on Table 4, Generally, the modification of the Norwegian traffic signal has the smaller average travel delay than the standard system. The differences are not significant and not able to improve the level of service (LoS) index. The LoS score is better in the section that allows the vehicle to turn left even though the traffic signal is red (LTOR). The long time interval of all red signals is an aspect that can cause the travel delay to be high. While a standard traffic signals system, all red takes six seconds and four seconds when applying the modification of Norwegian traffic signal. For the small intersection, the all red time interval of three seconds can be used. The table is not presented. The average travel delay for all the sections that implements the standard signal system is 33.78 seconds/ PCU and for the intersection that applied full of the Norwegian traffic signal is 31.18 seconds/ PCU. Both Level of Service (LoS) index is D. Based on safety reasons. This cannot be derived due to the massive size of the intersection.
It is while the intersection implements three phases of traffic signals without a schedule for the southern section. The average travel delay for all sections that implements the standard signal system is 34.83 seconds/ PCU and for the intersection that applies the modification of Norwegian traffic signal is 32.54 seconds/ PCU. Both Level of Service (LoS) index is D.

Factors that Affect Travel Delays
This paper investigated when both the volume of the vehicle passing and its degree of saturation were constant. Its degree of saturation (DS) was about 0.5. It meant that no remaining unfinished vehicle crossed the intersection when the green signal lighted upon a traffic light cycle.
Based on the results of the study above, the following are the dominant factors that affect travel delays in the above intersection. These factors are (1). The number of vehicles to turn left even though the traffic signal was red (LTOR), (2). The number of traffic lights phases, (3). The time interval of all red signals to clear the intersection of the flow of vehicle movement in different directions, and (4). The implementation of the modification of Norwegian traffic lights.
The number of vehicles those turn left even though the traffic signal is red (LTOR), they have a negative correlation. As their volume increase, the travel delays will decrease. The number of traffic lights phases has a positive correlation. The intersection which has many numbers of phases, the travel delay become higher. The travel delay at the intersection of four-phase traffic lights is higher than the intersection which implements three phases. However, it also depends on the time interval for the green signal in each phase. The time interval of all red signals has a positive correlation. For this massive size, intersection needs six seconds. The implication, the massive size of the intersection has a high travel delay. The modification of Norwegian traffic lights can reduce travel delays better than standard systems.
The reality, according to the experts' observation, the intersection can be categorized as having a medium LoS. However, this cannot be represented in the standard of travel delay measurement.
The best method to improve travel delays is to build a flyover. This is provided for the flow of vehicles coming from the eastern section and going to another section. This only needs to implement three phases. The duration of one traffic light cycle is 93 seconds. The average travel delays for vehicles originating from the south, north, and west sections are 39.53 seconds, 21.00 seconds, and 27.70 seconds, respectively. The Index of the Level of Services (LoS) are C, D, and D, respectively. If the volume of vehicle traffic flows to increase, the existence of the flyover cannot be delayed anymore.

Conclusions
Generally, the implementation of modifications of the Norwegian traffic signal system in both a small intersection and a low of traffic flow can reduce travel delays. However, when compared to standard system traffic signals in both a massive size of the intersection and a heavy traffic flow, the results are not significant. The reason, it has not succeeded in increasing the Level of Service (LoS) score. Refers to the experts of the transportation. It requires the higher LoS Index for the massive intersection. When the situation is urgent, and the traffic volume increases continuously, to improve the travel delay can be by building the flyover.


Evaluating windowing-based continuous S-transform with neural network classifier for detecting and classifying power quality disturbances

Received Oct 7, 2018 Revised Dec 6, 2018 Accepted Dec 13, 2018 The aim of this paper is to evaluate the implementation of windowing-based Continuous S-Transform (CST) techniques, namely, one-cycle and half-cycle windowing with Multi-layer Perception (MLP) Neural Network classifier. Both, the techniques and classifier are used to detect and classify the Power Quality Disturbances (PQDs) into one of possible classes, voltage sag, swell and interrupt disturbance signal. For realizing evaluation, we proposed the methodology that include the PQD generation, the signal detection using windowing-based CST, the features extraction from S-contour matrices, PQD classification using MLP classifier. Then, we perform two type of assessments. Firstly, the accuracy assessment of chosen classifier in relation to three different training algorithms. Secondly, the execution time comparison of the training algorithms. Based on assessment results, we outline several recommendations for future work.

INTRODUCTION
Power quality (PQ) is crucial in provisioning utilities for fulfilling the consumers need [1]. Nowadays, PQ problem has becoming a huge challenge as more consumers are demanding for the power quality. Electrical devices vulnerable to power quality or lack of quality is more suitable to be included in the domain of power appears limited. All electric devices are disposed to have a problem or damage when they are exposed to one or more power quality issues [1]- [7]. Electric motor, generator, computer, communication equipment, or household appliance are the examples of electrical devices that has a high chances to damage when exposed to PQ disturbances (PQDs). To date, the asset quality of power is quite expensive, so there is a need of monitoring systems that can detect PQD activities in order to reduce costs.
To improve the power quality in the system, there is a need to detect the presence of the disturbances, identify the sources of the problems and find the solution to overcome them. In previous research and studies, the researchers typically use multiple approaches to detect and classify the activity of PQDs. Among approaches used in past studies are S-Transform [2]- [5], [8], Wavelet Transform [9], Neural Network, Discrete Fourier Transform (DFT), Fast Fourier Transform (FFT), and Support Vector Machine (SVM), a combination of any of them or others. Most approaches described before supervised PQ problems by changing from one domain to another domain of mathematics which provides additional detailed information.
The main scope of the study is categorized into two parts which are detection of PQ disturbance based on the use of S-Transform mathematical techniques to detect power quality disturbances and Neural Half-Cycle Windowing Technique (HCWT). A mathematical codes are created approaches by using software MATLAB© to find initial period, the final period, the magnitude and duration of the PQ disturbance. Furthermore, this paper will gives a brief summary of an analysis of the PQ disturbances for the detection and classification based on CST for the distribution system by using the method of OCWT and HCWT with MLPNN.

PQDs SIGNAL GENERATION
The disturbances signal power quality are generated based on mathematical modeling programming in m-file/script of MATLAB© [10]. There are three types of signals involved, namely, sag, swell, and interrupt. The parameters required to generate the signals are the real time of signal duration and amplitude of disturbance signal voltage. Table 1 shows the parameters associated to each type of disturbance.

PQDs Signal Detection using One-Cycle Windowing Technique (OCWT)
The cycles accordance with windowing technique of Continuous S-Transform (CST) is used for PQDs detection and feature extraction. Each cycle of each sample window of interference waveform signal is analyzed accordance with ST contour [3], [4]. The detection of PQD using OCWT is performed for every 20ms (one-cycle) of time duration of signals. The signal must in absolute condition to perform this detection.

PQDs Signal Detection using Half-Cycle Windowing Technique (HCWT)
HCWT represents a half duration of one-cycle for supporting the detection. A half-cycle is determined by 10ms. Thus, by using the same PQDs signal, the HCWT is utilized to limit the scope of the samples from the entire disturbance signal. Then, CST is applied to create the line detection which produces S-contour matrices, as shown in

PQDs Signal Classification using Neural Network classifier
In this paper, Multi-layer Perceptron (MLP) is used as NN classifier to classify from PQ disturbances signal [11], [12]. An MLP comprises of multiple layers of nodes in a directed graph, with each layer fully connected to the next one. Figure 7 shows the structure architecture of MLP for this paper.

RESULTS AND ANALYSIS
For the dataset preparation, 100 dataset is used as inputs to classify the voltage swell in PQDs signal. The inputs are partition into three parts, which are training, validation and testing datasets. Eight hidden layers are used to train the MLPNN and 1000 iteration is set for classification. Furthermore, this paper uses three different types of training algorithms for evaluating the classification performance, which are; Gradient Descent with Momentum and Adaptive LR 'traingdx' [13], Levenberg-Marquardt 'trainlm' [12]- [14] and BFGS Quasi-Newton 'trainbfg' [12], [15].    Table 3 shows the classification of Sample 2 using MLPNN classifier with OCWT. From the PQDs classification, it was found that training algorithm Gradient Descent with Momentum and Adaptive LR 'traingdx' classified 97% of accuracy. Meanwhile for Levenberg-Marquardt 'trainlm', the result of PQDs classification is 99%, while for algorithm BFGS Quasi-Newton 'trainbfg'; it provided 96% of classification accurateness. The 'trainlm' produced the highest accuracy of classification compared to other algorithms. As for voltage swell classification, Levenberg-Marquardt 'trainlm' classified 100% accurate of classification, more higher compared Gradient Descent with Momentum and Adaptive LR 'traingdx' and BFGS Quasi-Newton 'trainbfg' where they produced 97.8% of accuracy percentage.  Table 4 shows the classification of Sample 3 using MLPNN classifier with OCWT. From the PQDs classification, it was found that training algorithm Gradient Descent with Momentum and Adaptive LR 'traingdx' classified 98% of accurate classification. Meanwhile for Levenberg-Marquardt 'trainlm', the PQDs classification is 99%, while for algorithm BFGS Quasi-Newton 'trainbfg'; it provided 98% of accuracy. So, algorithm 'trainlm' produced the higher accuracy of classification compared to other algorithms. As for voltage swell classification, all type of training algorithms produced 100% of accuracy percentage.  Table 5 shows the comparison of accuracy Sample 1 for the classification of PQDs using MLPNN classifier with different training algorithms according to HCWT. From the analysis, training algorithm Gradient Descent with Momentum and Adaptive LR 'traingdx' provided 98% of an accuracy and BFGS Quasi-Newton 'trainbfg' also provided 98% for the classification of PQDs. While classification using Levenberg-Marquardt 'trainlm' algorithm provided the highest accuracy compared the others with 99% of correct classification of PQDs. As for voltage swell classification, all type of training algorithms produced 98% of accuracy percentage. In Table 6 shows the comparison of accuracy Sample 2 for the classification of PQDs using MLPNN classifier with different training algorithms based on CST according to HCWT. From the analysis, training algorithm Gradient Descent with Momentum and Adaptive LR 'traingdx' provided 95% of an accuracy and BFGS Quasi-Newton 'trainbfg' provided 96% for the classification of PQD. While classification using Levenberg-Marquardt 'trainlm' training algorithm provided the highest accuracy compared the others with 97% of correct classification of PQDs. As for voltage swell classification, Levenberg-Marquardt 'trainlm' classified 100% of classification accuracy, more higher compared Gradient Descent with Momentum and Adaptive LR 'traingdx' and BFGS Quasi-Newton 'trainbfg' where they produced 97.8% accuracy. In Table 7 shows the comparison of accuracy Sample 3 for the classification of PQDs using MLPNN classifier with different training algorithms based on CST according to HCWT. From the analysis, training algorithm Gradient Descent with Momentum and Adaptive LR 'traingdx' provided 97% of an accuracy and BFGS Quasi-Newton 'trainbfg' also provided 97% for the classification of PQD. While classification using Levenberg-Marquardt 'trainlm' training algorithm provided the highest accuracy compared the others with 98% of correct classification of PQDs. As for voltage swell classification, Levenberg-Marquardt 'trainlm' classified 97.5% accurate of classification, higher compared Gradient Descent with Momentum and Adaptive LR 'traingdx' and BFGS Quasi-Newton 'trainbfg' where they produced 95% of accuracy percentage.
In regards to the samples as shown in Figure 8, the highest accuracy of classification for individual disturbances is 100% by using CST OCWT for Sample 1, Sample 2 and Sample 3, while classification by using CST HCWT, NN classifier reach 98% for Sample 1, 100% for Sample 2 and 97.5% for Sample 3. On ther hand, Figure 9 shows the comparison in term of the effectiveness operating time taken using different training algorithms to complete the PQDs classification. By using eight nodes of hidden layer for the PQ

CONCLUSION
We have presented the evaluation of the proposed methodology for detecting and classifying of PQD signals. The detection is based on CST with either OCWT or HCWT. Meanwhile, the classification is implemented using MLPNN. Furthermore, S-contour matrices are utilized to extract the relevant features of PQDs that server as a input for evaluating the PQD classification. Three different training algorithms were used to evaluate the accuracy of the PQD classification. The results have shown that, the training algorithm of Levenberg-Marquadt 'trainlm' outperformed others especially for classifying the voltage swell.