Design‐code traceability for object‐oriented systems

Traceability is a key issue to ensure consistency among software artifacts of subsequent phases of the development cycle. However, few works have so far addressed the theme of tracing object oriented (OO) design into its implementation and evolving it. This paper presents an approach to checking the compliance of OO design with respect to source code and support its evolution. The process works on design artifacts expressed in the OMT (Object Modeling Technique) notation and accepts C++ source code. It recovers an “as is” design from the code, compares the recovered design with the actual design and helps the user to deal with inconsistencies. The recovery process exploits the edit distance computation and the maximum match algorithm to determine traceability links between design and code. The output is a similarity measure associated to design‐code class pairs, which can be classified as matched and unmatched by means of a maximum likelihood threshold. A graphic display of the design with different green levels associated to different levels of match and red for the unmatched classes is provided as a support to update the design and improve its traceability to the code.     

Design-code traceability recovery: selecting the basic linkage properties

Traceability ensures that software artifacts of subsequent phases of the development cycle are consistent. Few works have so far addressed the problem of automatically recovering traceability links between object-oriented (OO) design and code entities. Such a recovery process is required whenever there is no explicit support of traceability from the development process. The recovered information can drive the evolution of the available design so that it corresponds to the code, thus providing a still useful and updated high-level view of the system.

Automatic recovery of traceability links can be achieved by determining the similarity of paired elements from design and code. The choice of the properties involved in the similarity computation is crucial for the success of the recovery process. In fact, design and code objects are complex artifacts with several properties attached. The basic anchors of the recovered traceability links should be chosen as those properties (or property combinations) which are expected to be maintained during the transformation of design into code. This may depend on specific practices and/or the development environment, which should therefore be properly accounted for.

In this paper different categories of basic properties of design and code entities will be analyzed with respect to the contribution they give to traceability recovery. Several industrial software components will be employed as a benchmark on which the performances of the alternatives are measured.     

基于开发者协作关系和信息检索的需求跟踪系统

目前自动化需求跟踪的研究广泛使用文本信息检索技术。然而信息检索会遗漏一些文本不相似但是实际相关的软件制品,导致自动化跟踪的精度不高。针对上述问题,提出利用开发者协作关系来进行优化,研发了基于开发者协作关系和信息检索的需求跟踪系统。该系统在进行需求跟踪时,首先用信息检索推荐与需求文本上相似的代码,然后从代码提交日志中挖掘开发者协作关系,根据开发者协作关系再推荐相关代码,用户根据两次推荐的结果确定正确的需求代码跟踪关系。试验结果表明该系统能够找到信息检索遗漏的需求跟踪关系,能够提高自动化跟踪的准确性,节省跟踪时间。     

Traceability-centric model-driven object-oriented engineering

ContextObject-oriented (OO) development method is a popular paradigm in developing target systems. However, the current practices of OO analysis and design (OOAD) and implementation largely rely on human developers’ experience and expertise, making it possible less efficient and more error-prone. Hence, there is room for improving the development efficiency while preserving high quality of programs.ObjectiveModel-driven development (MDD) is a promising approach to developing programs by machine-assisted model transformation, saving human efforts and reducing the possibility of introducing program faults. Hence, it is appealing to apply key disciplines of MDD in developing OO programs.MethodIn this paper, we propose a comprehensive framework for applying MDD on OO program engineering in a rigorous and formal fashion. The framework consists of: (1) a hybrid engineering model of human and machine, (2) meta-models of OOAD artifacts, (3) traceability map with trace links, and (4) transformation rules.ResultsWe identified five platform independent models and two platform specific models, and defined formal representations for them. We identified 16 traceability links and accordingly 16 transformation rules among the eight artifacts. Through the case study, we showed that our work is feasible and applicable. We assessed our work and concluded that our work is sound, complete, and extendable. Our work established the foundation toward automatic generation of OO programs based on the traceability framework.ConclusionIt is concluded that it is essential to identify the OOAD artifacts, traceability links, and transformation rules for automatic generation of OO programs. It is also important to understand the human involvement nature in MDD and to explicitly treat them in the model transformation.     

VbTrace: using view-based and model-driven development to support traceability in process-driven SOAs

In process-driven, service-oriented architectures, there are a number of important factors that hinder the traceability between design and implementation artifacts. First of all, there are no explicit links between process design and implementation languages not only due to the differences of syntax and semantics but also the differences of granularity. The second factor is the complexity caused by tangled process concerns that multiplies the difficulty of analyzing and understanding the trace dependencies. Finally, there is a lack of adequate tool support for establishing and maintaining the trace dependencies between process designs and implementations. We present in this article a view-based, model-driven traceability approach that tackles these challenges. Our approach supports (semi-)automatically eliciting and (semi-)formalizing trace dependencies among process development artifacts at different levels of granularity and abstraction. A proof-of-concept tool support has been realized, and its functionality is illustrated via an industrial case study.     

Diagnosing and correcting design inconsistencies in source code with logical abduction

Correcting design decay in source code is not a trivial task. Diagnosing and subsequently correcting inconsistencies between a software system’s code and its design rules (e.g., database queries are only allowed in the persistence layer) and coding conventions can be complex, time-consuming and error-prone. Providing support for this process is therefore highly desirable, but of a far greater complexity than suggesting basic corrective actions for simplistic implementation problems (like the “declare a local variable for non-declared variable” suggested by Eclipse).We present an abductive reasoning approach to inconsistency correction that consists of (1) a means for developers to document and verify a system’s design and coding rules, (2) an abductive logic reasoner that hypothesizes possible causes of inconsistencies between the system’s code and the documented rules and (3) a library of corrective actions for each hypothesized cause. This work builds on our previous work, where we expressed design rules as equality relationships between sets of source code artifacts (e.g., the set of methods in the persistence layer is the same as the set of methods that query the database). In this paper, we generalize our approach to design rules expressed as user-defined binary relationships between two sets of source code artifacts (e.g., every state changing method should invoke a persistence method).We illustrate our approach on the design of IntensiVE, a tool suite that enables defining sets of source code artifacts intensionally (by means of logic queries) and verifying relationships between such sets.     

Incremental Maintenance of Software Artifacts

Software is multidimensional, but the tools that support it are not. This lack of tool support causes the software artifacts representing different dimensions to evolve independently and to become inconsistent over time. In order to properly support the evolution of software, one must ensure that the different dimensions evolve concurrently. We have built a software development tool, CLIME that uses constraints implemented as database queries to ensure just this. Our approach makes the tool responsible for detecting inconsistencies between software design, specifications, documentation, source code, test cases, and other artifacts without requiring any of these to be a primary representation. The tool works incrementally as the software evolves, without imposing a particular methodology or process. It includes a front end that lets the user explore and fix current inconsistencies. This paper describes the basis for CLIME, the techniques underlying the tool, the interface provided to the programmer, the incremental maintenance of constraints between these artifacts, and our experiences     

Automatically identifying changes that impact code-to-design traceability during evolution

An approach is presented that automatically determines if a given source code change impacts the design (i.e., UML class diagram) of the system. This allows code-to-design traceability to be consistently maintained as the source code evolves. The approach uses lightweight analysis and syntactic differencing of the source code changes to determine if the change alters the class diagram in the context of abstract design. The intent is to support both the simultaneous updating of design documents with code changes and bringing old design documents up to date with current code given the change history. An efficient tool was developed to support the approach and is applied to an open source system. The results are evaluated and compared against manual inspection by human experts. The tool performs better than (error prone) manual inspection. The developed approach and tool were used to empirically investigate and understand how changes to source code (i.e., commits) break code-to-design traceability during evolution and the benefits from such understanding. Commits are categorized as design impact or no impact. The commits of four open source projects over 3-year time durations are extracted and analyzed. The results of the study show that most of the code changes do not impact the design and these commits have a smaller number of changed files and changed less lines compared to commits with design impact. The results also show that most bug fixes do not impact design.     

Model driven code checking

Model checkers were originally developed to support the formal verification of high-level design models of distributed system designs. Over the years, they have become unmatched in precision and performance in this domain. Research in model checking has meanwhile moved towards methods that allow us to reason also about implementation level artifacts (e.g., software code) directly, instead of hand-crafted representations of those artifacts. This does not mean that there is no longer a place for the use of high-level models, but it does mean that such models are used in a different way today. In the approach that we describe here, high-level models are used to represent the environment for which the code is to be verified, but not the application itself. The code of the application is now executed as is by the model checker, while using powerful forms of abstraction on-the-fly to build the abstract state space that guides the verification process. This model-driven code checking method allows us to verify implementation level code efficiently for high-level safety and liveness properties. In this paper, we give an overview of the methodology that supports this new paradigm of code verification.