A Programação Orientada a Aspectos (POA) é uma técnica de desenvolvimento que apoia a separação de interesses transversais. Na POA, adendos são aplicados a pontos de junção do sistema por meio de uma construção especial chamada descritor de conjuntos de junção (ou simplesmente conjunto de junção). Esse mecanismo apoia a modularização de comportamentos transversais, entretanto, como as interações adicionadas não ficam explícitas no código-fonte, é difícil assegurar que estão corretas. Para lidar com esse problema, nesta tese é proposta uma abordagem rigorosa de teste estrutural de integração para programas orientados a aspectos. É definido um modelo de fluxo de controle e de dados baseado no bytecode Java chamado Grafo Def-Uso baseado em conjuntos de junção (ou PointCut-based Def-Use graph, PCDU) que modela as regiões de execução de um programa escrito em AspectJ que são afetadas por um conjunto de junção. Sobre este modelo são definidos três critérios de teste: todos-nós-baseados-em-conjunto-de-junção, todas-arestas-baseadas-em-conjunto-de-junção e todos-usos-baseados-em-conjunto-de-junção, que requerem a cobertura de todos os comandos, condicionais e pares def-uso no contexto de cada ponto de junção selecionado. Para automatizar o uso do modelo e critérios propostos, é implementada uma ferramenta chamada JaBUTi/PC-AJ. Além disso, para validar a abordagem proposta, são conduzidos estudos teóricos e experimentais que procuram avaliar os critérios tanto do ponto de vista do custo de aplicação quanto do ponto de vista da eficácia em encontrar defeitos. Os estudos oferecem indícios da aplicabilidade e da eficácia dos critérios para encontrar defeitos diretamente relacionados com a POA / Aspect-Oriented Programming (AOP) is a promising development technique that supports separation of crosscutting concerns. In AOP, advice is applied to join points in the system through a special construct called pointcut. This mechanism supports the modularization of crosscutting behavior; however, since the added interactions are not explicit in the source code, it is hard to ensure their correctness. To tackle this problem, this thesis proposes a rigorous structural testing approach for aspect-oriented programs. A control and data flow model based on Java bytecode the PointCut-based Def-Use Graph (PCDU) that models execution regions of a program affected by a pointcut is proposed. On top of this model three testing criteria are defined: all-pointcut-based-advice-nodes, all-pointcut-based-advice-edges, and all-pointcut-based-advice-uses, that require exercising all statements, branches and def-use pairs of each advice at the context of each affected join point. To automate the use of the proposed model and criteria, a tool named JaBUTi/PC-AJ is implemented. Moreover, to validate the proposed approach, both theoretical and experimental studies are presented. These studies provide evidence of the applicability and efficacy of the proposed criteria

A Programação Orientada a Aspectos (POA) é uma técnica de desenvolvimento que apoia a separação de interesses transversais. Na POA, adendos são aplicados a pontos de junção do sistema por meio de uma construção especial chamada descritor de conjuntos de junção (ou simplesmente conjunto de junção). Esse mecanismo apoia a modularização de comportamentos transversais, entretanto, como as interações adicionadas não ficam explícitas no código-fonte, é difícil assegurar que estão corretas. Para lidar com esse problema, nesta tese é proposta uma abordagem rigorosa de teste estrutural de integração para programas orientados a aspectos. É definido um modelo de fluxo de controle e de dados baseado no bytecode Java chamado Grafo Def-Uso baseado em conjuntos de junção (ou PointCut-based Def-Use graph, PCDU) que modela as regiões de execução de um programa escrito em AspectJ que são afetadas por um conjunto de junção. Sobre este modelo são definidos três critérios de teste: todos-nós-baseados-em-conjunto-de-junção, todas-arestas-baseadas-em-conjunto-de-junção e todos-usos-baseados-em-conjunto-de-junção, que requerem a cobertura de todos os comandos, condicionais e pares def-uso no contexto de cada ponto de junção selecionado. Para automatizar o uso do modelo e critérios propostos, é implementada uma ferramenta chamada JaBUTi/PC-AJ. Além disso, para validar a abordagem proposta, são conduzidos estudos teóricos e experimentais que procuram avaliar os critérios tanto do ponto de vista do custo de aplicação quanto do ponto de vista da eficácia em encontrar defeitos. Os estudos oferecem indícios da aplicabilidade e da eficácia dos critérios para encontrar defeitos diretamente relacionados com a POA / Aspect-Oriented Programming (AOP) is a promising development technique that supports separation of crosscutting concerns. In AOP, advice is applied to join points in the system through a special construct called pointcut. This mechanism supports the modularization of crosscutting behavior; however, since the added interactions are not explicit in the source code, it is hard to ensure their correctness. To tackle this problem, this thesis proposes a rigorous structural testing approach for aspect-oriented programs. A control and data flow model based on Java bytecode the PointCut-based Def-Use Graph (PCDU) that models execution regions of a program affected by a pointcut is proposed. On top of this model three testing criteria are defined: all-pointcut-based-advice-nodes, all-pointcut-based-advice-edges, and all-pointcut-based-advice-uses, that require exercising all statements, branches and def-use pairs of each advice at the context of each affected join point. To automate the use of the proposed model and criteria, a tool named JaBUTi/PC-AJ is implemented. Moreover, to validate the proposed approach, both theoretical and experimental studies are presented. These studies provide evidence of the applicability and efficacy of the proposed criteria

Uma abordagem de teste estrutural de integração contextual para programas OO e OA escritos em Java e AspectJ é apresentada. A finalidade dessa abordagem é descobrir defeitos que possam existir nas interfaces entre uma determinada unidade (método ou adendo) e todas as outras que interagem diretamente com ela, bem como descobrir defeitos que possam ocorrer na hierarquia de chamadas dessas unidades. Para programas OO, esse tipo de teste envolve testar a interação entre métodos; já para programas OA, o teste estrutural de integração nível um (como também pode ser chamado) deve considerar as interações método-método, método-adendo, adendo-adendo e adendo-método. Para efetuar o teste estrutural de integração nível um deve-se considerar todo o fluxo de execução (fluxo de controle e de dados) que ocorre entre uma unidade chamadora e as unidades que interagem diretamente com ela. Para isso é definido o grafo Def-Uso IN1P, que é uma abstração formada pela integração dos grafos Def-Uso Orientado a Aspectos (AODU) da unidade chamadora e das unidades que ela chama ou que a afeta. Além disso, são propostos três critérios para derivar os requisitos de teste, dois baseados em fluxo de controle (todos-nós-integrados-N1 e todas-arestas-integradas-N1) e um baseado em fluxo de dados (todos-usos-integrados-N1). A ferramenta JaBUTi/AJ foi estendida para dar apoio à abordagem de teste de integração proposta. Exemplos são apresentados para ilustrar o uso da ferramenta para o teste de profundidade um e também seu uso no contexto de uma abordagem que leva em consideração também o teste de unidades e o teste baseado em conjuntos de junção / A Contextual structural integration testing for OO and OA programs written in Java and AspectJ is presented. The purpose of this approach is to discover faults that may exist in the interfaces between a particular unit (method or advice) and all others that interact directly with it, as well as to discover defects that may occur in the call hierarchy of these units. In OO programs, this type of test involves testing the interaction among methods. For OA programs, the structural integration testing at the depth of one (as it can also be called) should consider the method-method, method-advice, advice-advice and advice-method interactions. To perform structural integration testing at the depth of one level the whole execution flow (control and data flow) that occurs among a caller unit and the units that interact directly with it it must be considered. The IN1P Def-Use graph has been defined as an abstraction formed by the integration of the Aspect-Oriented Def-Use (AODU) graphs of the caller unit and of the units that it calls or affects it. Also, three criteria to derive test requirements are proposed, two of which are based on control flow all-integrated-nodes-N1 and all-integrated-edges-N1 and one is based on data flowall-integrated-uses-N1. The tool JaBUTi/AJ was extended to support the proposed integration testing approach. Examples are presented to illustrate the use of the tool for depth 1 testing as well as its use in the context of an approach that also takes into account unit testing and pointcut-based testing

Submitted by JOSIANE SANTOS DE OLIVEIRA (josianeso) on 2018-04-25T16:10:27Z No. of bitstreams: 1 Maicon dos Santos_.pdf: 3747706 bytes, checksum: ef8b81f35d6d19fc23c56bfba79044c5 (MD5) / Made available in DSpace on 2018-04-25T16:10:27Z (GMT). No. of bitstreams: 1 Maicon dos Santos_.pdf: 3747706 bytes, checksum: ef8b81f35d6d19fc23c56bfba79044c5 (MD5) Previous issue date: 2018-01-18 / Nenhuma / Engenharia reversa de código desempenha um papel fundamental em várias atividades de Engenharia de Software, tais como geração de modelos a partir de código legado e recuperação de funcionalidades (ou features) de sistemas. No contexto de Linha de Produto de Software (LPS), por exemplo, um produto de software é formado por um conjunto de features que são constantemente alteradas para acomodar mudanças de regras de negócio. Consequentemente, o modelo (por exemplo, diagrama de classes da UML) que representa toda LPS precisa ser modificado para refletir as atualizações realizadas. Neste contexto, várias ferramentas têm sido propostas nas últimas décadas, por exemplo, Astah e ArgoUML. Porém, as ferramentas (e suas técnicas) não dão suporte à engenharia reversa orientada a features, são imprecisas no que se refere à completude dos diagramas gerados, bem como exige um alto esforço para atualização dos modelos pois são manuais ou semiautomáticas. Para mitigar esta problemática, este trabalho propõe a TechREF, uma técnica de engenharia reversa orientada a features. De forma automática, a TechREF captura o fluxo de execução do código associado a uma feature, identifica as informações estruturais e comportamentais do código, e gera diagramas de classes UML, bem como persiste tais diagramas. A TechREF foi avaliada através de um estudo de caso tendo cenários reais de engenharia reversa. Esta avaliação buscou verificar o esforço e a corretude das atividades que serão realizadas no experimento com o uso dos modelos orientados a features. / Reverse code engineering plays a key role in various Software Engineering activities, such as model generation from legacy code and retrieval of system features. In the context of Software Product Line (LPS), for example, a software product is composed of a set features that are constantly changed to accommodate changes in business rules. Consequently, the model (for example, UML class diagram) that represents the entire LPS needs to be modified to reflect the updates made. In this context, several tools have been proposed in the last decades, for example, Astah and ArgoUML. However, the tools (and their techniques) do not support feature-oriented reverse engineering, are imprecise in terms of the completeness of the generated diagrams, as well as requiring a high effort to update the models because they are manual or semiautomatic. To mitigate this problem, this paper proposes TechREF, a reverse engineering technique oriented to features. Automatically, TechREF captures the execution flow of code associated with a feature, identifies the structural and behavioral information of the code, and generates diagrams of UML classes, as well as persists such diagrams. TechREF was evaluated through a case study having real reverse engineering scenarios. This evaluation sought to verify the effort and correctness of the activities that will be carried out in the experiment with the use of the models oriented to features.

Made available in DSpace on 2016-06-02T19:05:46Z (GMT). No. of bitstreams: 1 3276.pdf: 2803726 bytes, checksum: df932fa4f96049ba4e039732b3b37e42 (MD5) Previous issue date: 2010-09-17 / Universidade Federal de Minas Gerais / GRN (Gestão de Recursos de Negócio Business Resource Management) pattern language provides a set of patterns in analysis level to support the development of applications which deal with rental, purchase, sale and maintenance transactions of a good or service. GRENJ-OO is an object-oriented (OO) application framework built to support the instantiation of Java applications in the GRN domain. GRENJ-OO instantiates applications that include in their architecture all framework variabilities. The units of this framework, which implement each GRN pattern and their variants, are highly coupled between them, because there are concern tangling and concern scattering related to each one of those patterns. So, the aspect-orientation (OA) techniques were used in each pattern to minimize those problems and a new framework version was obtained, called GRENJ-OA. The improvements of separation of concerns, the coupling reduction, the cohesion increasing and the reduction of the number of lines of code of the majority of the patterns implemented in GRENJ-OA was the result reached after performing a quantitative evaluation based on separation of concerns, coupling, cohesion and size metrics. From the approach used to modularize this framework is introduced the Framework Product Line concept, that consists in a product line which their products are frameworks instead of software applications. From the GRENJ-OO modularization was also possible to extract a process that can be applied to modularize frameworks. This process aims to transform a framework in a Framework Product Line. / A linguagem de padrões GRN (Gestão de Recursos de Negócio) fornece um conjunto de padrões em nível de análise que apóiam o desenvolvimento de aplicações que tratam de transações de aluguel, compra, venda e manutenção de um bem ou serviço. GRENJ-OO é um framework de aplicação orientado a objetos (OO) construído para apoiar a instanciação de aplicações no domínio da GRN na linguagem Java. O framework GRENJ-OO instancia aplicações que incluem em sua arquitetura todas as variabilidades do framework. As unidades desse framework, que implementam cada padrão da GRN e suas variantes, estão altamente acopladas entre si, em virtude da existência de entrelaçamento e espalhamento de interesses relacionados a cada um desses padrões. Assim, a orientação a aspectos (OA) foi utilizada em cada um dos padrões a fim de minimizar esses problemas e uma nova versão do framework foi obtida, denominada GRENJ-OA. A melhoria dos níveis de separação de interesses, a redução do acoplamento, o aumento da coesão e redução do número de linhas de código da maioria dos padrões implementados no GRENJ-OA foram os resultados obtidos após a realização de uma avaliação quantitativa com base em métricas de separação de interesses, acoplamento, coesão e tamanho. A partir da abordagem utilizada na modularização desse framework, é introduzido o conceito de Linha de Produtos de Frameworks, que consiste em uma linha de produtos na qual seus produtos são frameworks, ao invés de aplicações de software. Com a modularização do GRENJ-OO também foi possível extrair um processo, que pode ser aplicado na modularização de frameworks. Esse processo tem o objetivo de transformar um framework em uma Linha de Produtos de Frameworks.

Uma abordagem de teste estrutural de integração contextual para programas OO e OA escritos em Java e AspectJ é apresentada. A finalidade dessa abordagem é descobrir defeitos que possam existir nas interfaces entre uma determinada unidade (método ou adendo) e todas as outras que interagem diretamente com ela, bem como descobrir defeitos que possam ocorrer na hierarquia de chamadas dessas unidades. Para programas OO, esse tipo de teste envolve testar a interação entre métodos; já para programas OA, o teste estrutural de integração nível um (como também pode ser chamado) deve considerar as interações método-método, método-adendo, adendo-adendo e adendo-método. Para efetuar o teste estrutural de integração nível um deve-se considerar todo o fluxo de execução (fluxo de controle e de dados) que ocorre entre uma unidade chamadora e as unidades que interagem diretamente com ela. Para isso é definido o grafo Def-Uso IN1P, que é uma abstração formada pela integração dos grafos Def-Uso Orientado a Aspectos (AODU) da unidade chamadora e das unidades que ela chama ou que a afeta. Além disso, são propostos três critérios para derivar os requisitos de teste, dois baseados em fluxo de controle (todos-nós-integrados-N1 e todas-arestas-integradas-N1) e um baseado em fluxo de dados (todos-usos-integrados-N1). A ferramenta JaBUTi/AJ foi estendida para dar apoio à abordagem de teste de integração proposta. Exemplos são apresentados para ilustrar o uso da ferramenta para o teste de profundidade um e também seu uso no contexto de uma abordagem que leva em consideração também o teste de unidades e o teste baseado em conjuntos de junção / A Contextual structural integration testing for OO and OA programs written in Java and AspectJ is presented. The purpose of this approach is to discover faults that may exist in the interfaces between a particular unit (method or advice) and all others that interact directly with it, as well as to discover defects that may occur in the call hierarchy of these units. In OO programs, this type of test involves testing the interaction among methods. For OA programs, the structural integration testing at the depth of one (as it can also be called) should consider the method-method, method-advice, advice-advice and advice-method interactions. To perform structural integration testing at the depth of one level the whole execution flow (control and data flow) that occurs among a caller unit and the units that interact directly with it it must be considered. The IN1P Def-Use graph has been defined as an abstraction formed by the integration of the Aspect-Oriented Def-Use (AODU) graphs of the caller unit and of the units that it calls or affects it. Also, three criteria to derive test requirements are proposed, two of which are based on control flow all-integrated-nodes-N1 and all-integrated-edges-N1 and one is based on data flowall-integrated-uses-N1. The tool JaBUTi/AJ was extended to support the proposed integration testing approach. Examples are presented to illustrate the use of the tool for depth 1 testing as well as its use in the context of an approach that also takes into account unit testing and pointcut-based testing

Uma abordagem de teste estrutural de integração par-a-par para programas OO e OA escritos em Java e AspectJ é apresentada. A finalidade dessa abordagem é descobrir defeitos que possam existir na interface entre os pares de unidades que se relacionam em um programa. Para programas OO este tipo de teste envolve testar a interação entre os pares de métodos. Já para programas OA, o teste estrutural de integração par-a-par envolve testar a interação entre os seguintes pares de unidades: método-método, método-adendo, adendo-método e adendo-adendo. Para efetuar o teste estrutural de integração par-a-par deve-se considerar todo o fluxo de execução (fluxo de controle e de dados) que ocorre entre a unidade chamadora e a unidade chamada. Para isso é definido o grafo Def-Uso Par-a-Par (PWDU) que é uma abstração formada pela integração dos grafos Def-Uso Orientado a Aspectos (AODU) da unidade chamadora e da unidade chamada. Além disso, são propostos três critérios para derivar requisitos de teste para pares de unidades. Dentre eles, dois critérios são baseados em fluxo de controle: todos-nós-integrados e todas-arestas-integradas; e um critério é baseado em fluxo de dados: todos-usos-integrados. Uma ferramenta que apóia o teste estrutural de unidade de programas OO e OA escritos em Java e AspectJ, chamada JaBUTi/AJ, foi estendida para dar apoio à abordagem de teste de integração proposta. Exemplos de usos são discutidos para explicar a aplicação da abordagem / A pairwise integration structural testing approach for OO and AO programs implemented with Java and AspectJ is presented. The purpose of this approach is to find faults that may exist in the interface between the pairs of units that relate in a program. For OO programs this type of testing involves testing the interaction among pair of methods. For AO programs, the pairwise integration structural testing involves testing the interaction among the following pairs of units: method-method, method-advice, advice-method and advice-advice. To perform the pairwise integration structural testing, all the execution flow (control and data flow) that happens between the caller and the called unit must be considered. For this, it is defined the PairWise Def-Use graph (PWDU) that is an abstraction formed by the integration of the Aspect-Oriented Def-Use (AODU) graphs of the caller and called unit. Additionally, three new criteria to derive test requirements for pairs of units are proposed. Amongst them, two criteria are based on control flow: all-integrated-nodes and all-integrated-edges; and one criterion is based on data flow: all-integrated-uses. A tool that supports unit structural testing of OO and AO programs implemented with Java and AspectJ, called JaBUTi/AJ, was extended in order to support the proposed integration testing approach. Examples are discussed in order to explain the application of the approach

O Paradigma Orientado a Objetos tem sido atualmente a abordagem dominante de desenvolvimento de software. Contudo, ela sofre da Tirania da Decomposição Dominante, pois não permite uma modularização adequada da implementação relativa a interesses estruturais. Como consequência, a implementação relativa a cada interesse estrutural fica espalhada pelos módulos do programa e entrelaçada com a implementação relativa a outros interesses estruturais. Outras abordagens de desenvolvimento de software, como o Desenvolvimento de Software Orientado a Aspectos com AspectJ e a Separação Multidimensional de Interesses em Hiperespaços com Hyper/J e CME, atingem sucesso moderado em oferecer mecanismos que permitem superar as deficiências do Paradigma Orientado a Objetos. No entanto, tais abordagens também possuem deficiências e omissões que devem ser reparadas para que elas possam se tornar utilizáveis em contextos típicos de desenvolvimento de software complexo. Este trabalho especifica uma nova abordagem, denominada Desenvolvimento de Software Orientado a Temas (DSOT), que tem como objetivo superar algumas deficiências das abordagens anteriores por meio de mecanismos que permitem a manipulação da implementação de cada interesse estrutural de forma separada e a manipulação da implementação de cada tipo de dado de forma separada. Além disso, DSOT possui operadores que são ortogonais, isto é, podem ser utilizados de forma combinada ou separada, para efetuar a composição de módulos do programa. Mostra-se o modelo conceitual do DSOT e descrevese um estudo de caso que consiste no desenvolvimento de um programa para demonstrar mais concretamente como o DSOT funciona na prática. Não se demonstra a superioridade do DSOT para o caso geral, mas os resultados alcançados evidenciam que o DSOT é uma abordagem promissora que merece ser investigada mais aprofundadamente em pesquisas futuras / The Object-Oriented Paradigm has currently been the dominant approach for developing software. However, it suffers from the Tyranny of the Dominant Decomposition, as it does not support a suitable modularization to the implementation relative to structural concerns. As a consequence, the implementation relative to each structural concern is scattered throughout the program modules and tangled with the implementation relative to other structural concerns. Some software development approaches, such as Aspect-Oriented Software Development with Aspect and Multidimensional Separation of Concerns in Hyperspaces with Hyper/J and CME, achieve moderate success in offering mechanisms that make it possible to overcome the deficiencies of the Object-Oriented Paradigm. However, such approaches also possess deficiencies and ommissions that must be corrected in order for them to get usable in typical complex software development contexts. This work specifies a new approach, named Theme- Oriented Software Development (TOSD), which aims at overcoming some deficiencies from previous approaches through mechanisms that support the handling of implementation for every structural concern separately and the handling of implementation for every data type separately. Moreover, TOSD contains operators which are orthogonal, that is, they can be used separately or as a combination, in order to perform composition of the program modules. We show the conceptual model of TOSD and describe a case study which consists in the development of a program to demonstrate more concretely how TOSD works in practice. We do not demonstrate the superiority of TOSD for the general case, but the results we have obtained suggest that TOSD is a promissing approach which deserves a deeper investigation in future research

O Paradigma Orientado a Objetos tem sido atualmente a abordagem dominante de desenvolvimento de software. Contudo, ela sofre da Tirania da Decomposição Dominante, pois não permite uma modularização adequada da implementação relativa a interesses estruturais. Como consequência, a implementação relativa a cada interesse estrutural fica espalhada pelos módulos do programa e entrelaçada com a implementação relativa a outros interesses estruturais. Outras abordagens de desenvolvimento de software, como o Desenvolvimento de Software Orientado a Aspectos com AspectJ e a Separação Multidimensional de Interesses em Hiperespaços com Hyper/J e CME, atingem sucesso moderado em oferecer mecanismos que permitem superar as deficiências do Paradigma Orientado a Objetos. No entanto, tais abordagens também possuem deficiências e omissões que devem ser reparadas para que elas possam se tornar utilizáveis em contextos típicos de desenvolvimento de software complexo. Este trabalho especifica uma nova abordagem, denominada Desenvolvimento de Software Orientado a Temas (DSOT), que tem como objetivo superar algumas deficiências das abordagens anteriores por meio de mecanismos que permitem a manipulação da implementação de cada interesse estrutural de forma separada e a manipulação da implementação de cada tipo de dado de forma separada. Além disso, DSOT possui operadores que são ortogonais, isto é, podem ser utilizados de forma combinada ou separada, para efetuar a composição de módulos do programa. Mostra-se o modelo conceitual do DSOT e descrevese um estudo de caso que consiste no desenvolvimento de um programa para demonstrar mais concretamente como o DSOT funciona na prática. Não se demonstra a superioridade do DSOT para o caso geral, mas os resultados alcançados evidenciam que o DSOT é uma abordagem promissora que merece ser investigada mais aprofundadamente em pesquisas futuras / The Object-Oriented Paradigm has currently been the dominant approach for developing software. However, it suffers from the Tyranny of the Dominant Decomposition, as it does not support a suitable modularization to the implementation relative to structural concerns. As a consequence, the implementation relative to each structural concern is scattered throughout the program modules and tangled with the implementation relative to other structural concerns. Some software development approaches, such as Aspect-Oriented Software Development with Aspect and Multidimensional Separation of Concerns in Hyperspaces with Hyper/J and CME, achieve moderate success in offering mechanisms that make it possible to overcome the deficiencies of the Object-Oriented Paradigm. However, such approaches also possess deficiencies and ommissions that must be corrected in order for them to get usable in typical complex software development contexts. This work specifies a new approach, named Theme- Oriented Software Development (TOSD), which aims at overcoming some deficiencies from previous approaches through mechanisms that support the handling of implementation for every structural concern separately and the handling of implementation for every data type separately. Moreover, TOSD contains operators which are orthogonal, that is, they can be used separately or as a combination, in order to perform composition of the program modules. We show the conceptual model of TOSD and describe a case study which consists in the development of a program to demonstrate more concretely how TOSD works in practice. We do not demonstrate the superiority of TOSD for the general case, but the results we have obtained suggest that TOSD is a promissing approach which deserves a deeper investigation in future research