Complexity metrics for DMN decision models

Complexity impairs the maintainability and understandability of conceptual models. Complexity metrics have been used in software engineering and business process management (BPM) to capture the degree of complexity of conceptual models. The recent introduction of the Decision Model and Notation (DMN) standard provides opportunities to shift towards the Separation of Concerns paradigm when it comes to modelling processes and decisions. However, unlike for processes, no studies exist that address the representational complexity of DMN decision models. In this paper, we provide an initial set of complexity metrics for DMN models. We gather insights from the process modelling and software engineering fields to propose complexity metrics for DMN decision models. Additionally, we provide an empirical complexity assessment of DMN decision models. For the decision requirements level of the DMN standard 19 metrics were proposed, while 7 metrics were put forward for the decision logic level. For decision requirements, the model size-based metrics, the Durfee Square Metric (DSM) and the Perfect Square Metric (PSM) prove to be the most suitable. For the decision logic level of DMN the Hit Policy Usage (HPU) and the Total Number of Input Variables (TNIV) were evaluated as suitable for measuring DMN decision table complexity.     

Identification of extract method refactoring opportunities for the decomposition of methods

The extraction of a code fragment into a separate method is one of the most widely performed refactoring activities, since it allows the decomposition of large and complex methods and can be used in combination with other code transformations for fixing a variety of design problems. Despite the significance of Extract Method refactoring towards code quality improvement, there is limited support for the identification of code fragments with distinct functionality that could be extracted into new methods. The goal of our approach is to automatically identify Extract Method refactoring opportunities which are related with the complete computation of a given variable (complete computation slice) and the statements affecting the state of a given object (object state slice). Moreover, a set of rules regarding the preservation of existing dependences is proposed that exclude refactoring opportunities corresponding to slices whose extraction could possibly cause a change in program behavior. The proposed approach has been evaluated regarding its ability to capture slices of code implementing a distinct functionality, its ability to resolve existing design flaws, its impact on the cohesion of the decomposed and extracted methods, and its ability to preserve program behavior. Moreover, precision and recall have been computed employing the refactoring opportunities found by independent evaluators in software that they developed as a golden set.     

Transforming and tracing reused requirements models to home automation models

ContextModel-Driven Software Development (MDSD) has emerged as a very promising approach to cope with the inherent complexity of modern software-based systems. Furthermore, it is well known that the Requirements Engineering (RE) stage is critical for a project’s success. Despite the importance of RE, MDSD approaches commonly leave textual requirements specifications to one side.ObjectiveOur aim is to integrate textual requirements specifications into the MDSD approach by using the MDSD techniques themselves, including metamodelling and model transformations. The proposal is based on the assumption that a reuse-based Model-Driven Requirements Engineering (MDRE) approach will improve the requirements engineering stage, the quality of the development models generated from requirements models, and will enable the traces from requirements to other development concepts (such as analysis or design) to be maintained.MethodThe approach revolves around the Requirements Engineering Metamodel, denominated as REMM, which supports the definition of the boilerplate based textual requirements specification languages needed for the definition of model transformation from application requirements models to platform-specific application models and code.ResultsThe approach has been evaluated through its application to Home Automation (HA) systems. The HA Requirement Specification Language denominated as HAREL is used to define application requirements models which will be automatically transformed and traced to the application model conforming to the HA Domain Specific Language.ConclusionsAn anonymous online survey has been conducted to evaluate the degree of acceptance by both HA application developers and MDSD practitioners. The main conclusion is that 66.7% of the HA experts polled strongly agree that the automatic transformation of the requirements models to HA models improves the quality of the HA models. Moreover, 58.3% of the HA participants strongly agree with the usefulness of the traceability matrix which links requirements to HA functional units in order to discover which devices are related to a specific requirement. We can conclude that the experts we have consulted agree with the proposal we are presenting here, since the average mark given is 4 out of 5.     

Automated refactoring to the Null Object design pattern

ContextNull-checking conditionals are a straightforward solution against null dereferences. However, their frequent repetition is considered a sign of poor program design, since they introduce source code duplication and complexity that impacts code comprehension and maintenance. The Null Object design pattern enables the replacement of null-checking conditionals with polymorphic method invocations that are bound, at runtime, to either a real object or a Null Object.ObjectiveThis work proposes a novel method for automated refactoring to Null Object that eliminates null-checking conditionals associated with optional class fields, i.e., fields that are not initialized in all class instantiations and, thus, their usage needs to be guarded in order to avoid null dereferences.MethodWe introduce an algorithm for automated discovery of refactoring opportunities to Null Object. Moreover, we specify the source code transformation procedure and an extensive set of refactoring preconditions for safely refactoring an optional field and its associated null-checking conditionals to the Null Object design pattern. The method is implemented as an Eclipse plug-in and is evaluated on a set of open source Java projects.ResultsSeveral refactoring candidates are discovered in the projects used in the evaluation and their refactoring lead to improvement of the cyclomatic complexity of the affected classes. The successful execution of the projects’ test suites, on their refactored versions, provides empirical evidence on the soundness of the proposed source code transformation. Runtime performance results highlight the potential for applying our method to a wide range of project sizes.ConclusionOur method automates the elimination of null-checking conditionals through refactoring to the Null Object design pattern. It contributes to improvement of the cyclomatic complexity of classes with optional fields. The runtime processing overhead of applying our method is limited and allows its integration to the programmer’s routine code analysis activities.     

Parallel multi-objective artificial bee colony algorithm for software requirement optimization

Requirements Engineering - In incremental software development approaches, the product is developed in various releases. In each release, a set of requirements is proposed for the development....     

Identifying refactoring opportunities in process model repositories

Context

In order to ensure high quality of a process model repository, refactoring operations can be applied to correct anti-patterns, such as overlap of process models, inconsistent labeling of activities and overly complex models. However, if a process model collection is created and maintained by different people over a longer period of time, manual detection of such refactoring opportunities becomes difficult, simply due to the number of processes in the repository. Consequently, there is a need for techniques to detect refactoring opportunities automatically.

Objective

This paper proposes a technique for automatically detecting refactoring opportunities.

Method

We developed the technique based on metrics that can be used to measure the consistency of activity labels as well as the extent to which processes overlap and the type of overlap that they have. We evaluated it, by applying it to two large process model repositories.

Results

The evaluation shows that the technique can be used to pinpoint the approximate location of three types of refactoring opportunities with high precision and recall and of one type of refactoring opportunity with high recall, but low precision.

Conclusion

We conclude that the technique presented in this paper can be used in practice to automatically detect a number of anti-patterns that can be corrected by refactoring.     

Mining early aspects based on syntactical and dependency analyses

Aspect-Oriented Requirements Engineering focuses on the identification and modularisation of crosscutting concerns at early stages. There are different approaches in the requirements engineering community to deal with crosscutting concerns, introducing the benefits of the application of aspect-oriented approaches at these early stages of development. However, most of these approaches rely on the use of Natural Language Processing techniques for aspect identification in textual documents and thus, they lack a unified process that generalises its application to other requirements artefacts such as use case diagrams or viewpoints. In this paper, we propose a process for mining early aspects, i.e. identifying crosscutting concerns at the requirements level. This process is based on a crosscutting pattern where two different domains are related. These two different domains may represent different artefacts of the requirements analysis such as text and use cases or concerns and use cases. The process uses syntactical and dependency based analyses to automatically identify crosscutting concerns at the requirements level. Validation of the process is illustrated by applying it to several systems and showing a comparison with other early aspects tools. A set of aspect-oriented metrics is also used to show this validation.     

TOTEM: Reconciling multi-level modelling with standard two-level modelling

Model driven Engineering (MDE) advocates the active use of models throughout the different software development phases. In MDE, models are described using meta-models, one meta-level above. This approach effectively leaves developers with one single meta-level to create their models. However, there are scenarios where the use of multiple meta-levels results in simpler models with less accidental complexity. Hence, to simplify modelling in these cases, several multi-level modelling approaches and tools have recently emerged to increase the flexibility in modelling. While they provide advanced primitives to simplify modelling, there are possibilities to improve interoperability with mainstream two-level modelling approaches based on the Meta-Object Facility (MOF) standard of the Object Management Group (OMG), and achieve wider adoption.For this purpose, we first characterise the design space of multi-level modelling approaches using a feature model. On such a basis, we provide a detailed comparison of existing multi-level modelling tools, identifying gaps and research opportunities. As a result of this gap analysis, we propose a new approach to multi-level modelling that embeds multiple meta-levels within one meta-model (i.e., encoding objects as classes, and instantiation as inheritance), and a tool – called TOTEM – which implements these concepts. The tool capabilities and its benefits in terms of interoperability with mainstream, standard modelling frameworks are illustrated through an example, as well as with empirical and analytical evaluations.     

Identifying Extract Class refactoring opportunities using structural and semantic cohesion measures

Approaches for improving class cohesion identify refactoring opportunities using metrics that capture structural relationships between the methods of a class, e.g., attribute references. Semantic metrics, e.g., C3 metric, have also been proposed to measure class cohesion, as they seem to complement structural metrics. However, until now semantic relationships between methods have not been used to identify refactoring opportunities. In this paper we propose an Extract Class refactoring method based on graph theory that exploits structural and semantic relationships between methods. The empirical evaluation of the proposed approach highlighted the benefits provided by the combination of semantic and structural measures and the potential usefulness of the proposed method as a feature for software development environments.     

Identifying refactoring opportunities in object-oriented code: A systematic literature review

ContextIdentifying refactoring opportunities in object-oriented code is an important stage that precedes the actual refactoring process. Several techniques have been proposed in the literature to identify opportunities for various refactoring activities.ObjectiveThis paper provides a systematic literature review of existing studies identifying opportunities for code refactoring activities.MethodWe performed an automatic search of the relevant digital libraries for potentially relevant studies published through the end of 2013, performed pilot and author-based searches, and selected 47 primary studies (PSs) based on inclusion and exclusion criteria. The PSs were analyzed based on a number of criteria, including the refactoring activities, the approaches to refactoring opportunity identification, the empirical evaluation approaches, and the data sets used.ResultsThe results indicate that research in the area of identifying refactoring opportunities is highly active. Most of the studies have been performed by academic researchers using nonindustrial data sets. Extract Class and Move Method were found to be the most frequently considered refactoring activities. The results show that researchers use six primary existing approaches to identify refactoring opportunities and six approaches to empirically evaluate the identification techniques. Most of the systems used in the evaluation process were open-source, which helps to make the studies repeatable. However, a relatively high percentage of the data sets used in the empirical evaluations were small, which limits the generality of the results.ConclusionsIt would be beneficial to perform further studies that consider more refactoring activities, involve researchers from industry, and use large-scale and industrial-based systems.     

构件软件的回归测试复杂性度量

基于构件的软件构建方法目前被广泛使用在软件开发中,用于减少软件开发的工程成本和加快软件开发进度.在软件维护过程中,由于构件更新或者新版本的发布,基于构件的系统会受到影响,需要进行回归测试.对于指定的软件修改需求,维护者可以实施不同的修改手段.不同的修改手段会导致不同的回归测试复杂性,这种复杂性是软件维护成本和有效性的重要因素.目前的研究没有强调构件软件的回归测试复杂性问题.基于修改影响复杂性模型和度量,提出一种回归测试的复杂性度量框架.该度量框架包括两个部分:基于图的模型和形式化度量计算.该度量可以有效表示构件软件分别在构件和系统层面的回归测试复杂性因素,可视化地体现复杂性变化.然后根据模型,提出具体的度量计算方式.最后,通过实验研究,针对同一个构件软件的相同修改需求,利用若干个实验组进行独立修改实施,然后比较回归测试的复杂性.实验结果表明,所提出的度量方式是可行和有效的.     

Automated refactoring to the Strategy design pattern

ContextThe automated identification of code fragments characterized by common design flaws (or “code smells”) that can be handled through refactoring, fosters refactoring activities, especially in large code bases where multiple developers are engaged without a detailed view on the whole system. Automated refactoring to design patterns enables significant contributions to design quality even from developers with little experience on the use of the required patterns.ObjectiveThis work targets the automated identification of refactoring opportunities to the Strategy design pattern and the elimination through polymorphism of respective “code smells” that are related to extensive use of complex conditional statements.MethodAn algorithm is introduced for the automated identification of refactoring opportunities to the Strategy design pattern. Suggested refactorings comprise conditional statements that are characterized by analogies to the Strategy design pattern, in terms of the purpose and selection mode of strategies. Moreover, this work specifies the procedure for refactoring to Strategy the identified conditional statements. For special cases of these statements, a technique is proposed for total replacement of conditional logic with method calls of appropriate concrete Strategy instances. The identification algorithm and the refactoring procedure are implemented and integrated in the JDeodorant Eclipse plug-in. The method is evaluated on a set of Java projects, in terms of quality of the suggested refactorings and run-time efficiency. The relevance of the identified refactoring opportunities is verified by expert software engineers.ResultsThe identification algorithm recalled, from the projects used during evaluation, many of the refactoring candidates that were identified by the expert software engineers. Its execution time on projects of varying size confirmed the run-time efficiency of this method.ConclusionThe proposed method for automated refactoring to Strategy contributes to simplification of conditional statements. Moreover, it enhances system extensibility through the Strategy design pattern.     

An experimental search-based approach to cohesion metric evaluation

In spite of several decades of software metrics research and practice, there is little understanding of how software metrics relate to one another, nor is there any established methodology for comparing them. We propose a novel experimental technique, based on search-based refactoring, to ‘animate’ metrics and observe their behaviour in a practical setting. Our aim is to promote metrics to the level of active, opinionated objects that can be compared experimentally to uncover where they conflict, and to understand better the underlying cause of the conflict. Our experimental approaches include semi-random refactoring, refactoring for increased metric agreement/disagreement, refactoring to increase/decrease the gap between a pair of metrics, and targeted hypothesis testing. We apply our approach to five popular cohesion metrics using ten real-world Java systems, involving 330,000 lines of code and the application of over 78,000 refactorings. Our results demonstrate that cohesion metrics disagree with each other in a remarkable 55 % of cases, that Low-level Similarity-based Class Cohesion (LSCC) is the best representative of the set of metrics we investigate while Sensitive Class Cohesion (SCOM) is the least representative, and we discover several hitherto unknown differences between the examined metrics. We also use our approach to investigate the impact of including inheritance in a cohesion metric definition and find that doing so dramatically changes the metric.     

Analyzing the understandability of Requirements Engineering languages for CSCW systems: A family of experiments

ContextA collaborative system is a special kind of software whose users can perform collaboration, communication and collaboration tasks. These systems usually have a high number of non-functional requirements, resulting from the users’ need of being aware of other users with whom to collaborate, that is, the workspace awareness.ObjectiveThis paper aims at evaluating two Requirements Engineering languages i^* and CSRML (an extension of i^*) in order to determine which is the most suitable one to specify requirements of collaborative systems, taking into account their special characteristics regarding collaboration and awareness.MethodWe performed a family of experiments comprising an original experiment and two replicas. They were performed by 30, 45 and 9 Computer Science students, respectively, from Spain and Argentina. These subjects filled in two understandability questionnaires once they analyzed the requirements models of two systems: an e-learning collaborative system and a conference review system with some collaborative aspects support. Both models were specified by using the evaluated languages.ResultsThe statistical analysis of the family of experiments showed that the understandability was higher for the models specified with CSRML than for those specified with i^*, especially for collaborative aspects. This result was also confirmed by the meta-analysis conducted.ConclusionsCSRML surpasses i^* when modeling collaborative systems requirements models due to the specific expressiveness introduced to represent collaboration between users and awareness and the new resorts to manage actors and roles.     

Deriving software architectural models from requirements models for adaptive systems: the STREAM-A approach

Some quality attributes are known to have an impact on the overall architecture of a system, so that they are required to be properly handled from the early beginning of the software development. For example, adaptability is a key concern for autonomic and adaptive systems, which brings to them the capability to alter their behavior in response to changes on their surrounding environments. In this paper, we propose a Strategy for Transition between Requirements and Architectural Models for Adaptive systems (STREAM-A). In particular, we use goal models based on the i* (i-Star) framework to support the design and evolution of systems that require adaptability. To obtain software architectures for such systems, the STREAM-A approach uses model transformations from i* models to architectural models expressed in Acme. Both the requirements and the architectural model are refined to accomplish the adaptability requirement.     

An evaluation of timed scenario notations

There is a general consensus on the importance of good Requirements Engineering (RE) for achieving high quality software. The modeling and analysis of requirements have been the main challenges during the development of complex systems. Although semi-formal, scenario driven approaches have raised the awareness and use of requirement engineering techniques, mostly because of their intuitive representation. Scenarios are a well established approach to describe functional requirements, uncovering hidden requirements and trade-offs, as well as validating and verifying requirements.The ability to perform quantitative analysis at the requirements level supports the detection of design errors during the early stages of a software development life cycle, and helps reduce the cost of later redesign activities. In order to achieve this goal, non-functional aspects and in particular time-related aspects have to be incorporated at the software requirement phase. This is essential in order to correctly model and analyze time dependent applications at early stages in system development.The widespread interest in time modeling and analysis techniques provides the major motivation for our paper. The objective of the article is to provide readers with sufficient knowledge about existing timed scenario approaches to guide them in making informed decisions to when and how time aspects can be incorporated in their development process. In order to support this process, we present a comprehensive classification, evaluation and comparison of time-based scenario notations. In order to evaluate these existing notations, we introduce a set of eleven time-related criteria and apply them to categorize and compare forty seven scenario construction approaches.     

User requirements modeling and analysis of software-intensive systems

The increasing complexity of software systems makes Requirements Engineering activities both more important and more difficult. This article is about user requirements development, mainly the activities of documenting and analyzing user requirements for software-intensive systems. These are modeling activities that are useful for further Requirements Engineering activities. Current techniques for requirements modeling present a number of problems and limitations. Based on these shortcomings, a list of requirements for requirements modeling languages is proposed. The proposal of this article is to show how some extensions to SysML diagrams and tables can fulfill most of these requirements. The approach is illustrated by a list of user requirements for a Road Traffic Management System.     

Automating feature model refactoring: A Model transformation approach

Context: Feature model is an appropriate and indispensable tool for modeling similarities and differences among products of the Software Product Line (SPL). It not only exposes the validity of the products’ configurations in an SPL but also changes in the course of time to support new requirements of the SPL. Modifications made on the feature model in the course of time raise a number of issues. Useless enlargements of the feature model, the existence of dead features, and violated constraints in the feature model are some of the key problems that make its maintenance difficult.Objective: The initial approach to dealing with the above-mentioned problems and improving maintainability of the feature model is refactoring. Refactoring modifies software artifacts in a way that their externally visible behavior does not change.Method: We introduce a method for defining refactoring rules and executing them on the feature model. We use the ATL model transformation language to define the refactoring rules. Moreover, we provide an Alloy model to check the feature model and the safety of the refactorings that are performed on it.Results: In this research, we propose a safe framework for refactoring a feature model. This framework enables users to perform automatic and semi-automatic refactoring on the feature model.Conclusions: Automated tool support for refactoring is a key issue for adopting approaches such as utilizing feature models and integrating them into the software development process of companies. In this work, we define some of the important refactoring rules on the feature model and provide tools that enable users to add new rules using the ATL M2M language. Our framework assesses the correctness of the refactorings using the Alloy language.     

A serious game for teaching the fundamentals of ISO/IEC/IEEE 29148 systems and software engineering – Lifecycle processes – Requirements engineering at undergraduate level

In the context of software engineering education, there is a recurrent demand for new approaches and techniques that support the application and transfer of knowledge to real-life situations with the aim of encouraging a more active learning among students. In particular, serious games have recently become an important learning resource for teaching the fundamentals of software process standards at undergraduate level. However, poor effort has been made to create a serious game that supports the teaching of the ISO/IEC/IEEE 29148:2011 Systems and Software Engineering – Lifecycle Processes – Requirements Engineering, an international standard that specifies the required processes that are to be implemented by requirements engineering for systems and software products (including services) throughout the lifecycle. With this in mind, a serious game called “Requengin” has been developed to provide undergraduate students with an interactive learning environment to facilitate the introduction of ISO/IEC/IEEE 29148:2011. The main objective of the game is to strengthen the comprehension and application of the main processes of the standard and some related requirements engineering techniques. Requengin was designed to simulate an academic library where players must apply the requirements engineering processes with the aim of changing the traditional management system by a software system while they receive, at the same time, preliminary training in ISO/IEC/IEEE 29148:2011. The results obtained by empirical evaluation indicate that Requengin could potentially contribute to an improvement in students’ acquisition of knowledge about ISO/IEC/IEEE 29148:2011, while also improving levels of motivation.     

Metrics for measuring the consistencies of requirements with objectives and constraints

Requirements engineering (RE) is essential to succeed in software projects. That is, it is important to elicit sound requirements for proper performing of RE. If some requirements are inconsistent with a given objectives and constraints, these requirements may hinder the performance of RE. For this reason, it is necessary to pre-check the consistency of requirements. We propose the metrics for evaluating requirements by considering given objectives and constraints. Our metrics are validated by two sample scenarios: “Payroll and Roster Planning of Hospital” and “Noise Source Location System.” At the result, we expect that these metrics would be helpful when selecting a set of consistent requirements.