A Software Tool for Maintaining File and Macro Build Dependencies

An upgraded version of the generator BCVEGPY2.0 for hadronic production of [formula omitted] meson and its excited states

Unified builds are a simple but effective technique to reduce the build time of large software projects. Unified builds generate large compiler tasks by bundling multiple source files into one, resulting in a significant reduction in build time through removal of redundant work incurred by shared headers. However, unified builds have a negative effect on incremental builds because each compiler task gets larger. An ad-hoc unification strategy causes an excessive slowdown in incremental builds. A rough report from WebKit says the worst slowdown is 20% (6s → 7s), but our investigation shows it is as high as 479% (19s → 110s). In this paper, we investigate the characteristics of unified builds to find a sweet spot, which generates compiler tasks that reduce the full build time without increasing the incremental build time. An in-depth analysis of WebKit reveals 1) source files with higher header similarity should be unified, 2) source files that have significant differences in compile times should not be unified, and 3) source files that are not frontend-intensive should not be unified. Our case study shows the total build time is reduced by 2.66%, and the worst slowdown falls from 479% to 129%. These findings will be of help in deriving a more intelligent strategy of unification and give a basis for discussions on future build systems, compilers, and module systems that cooperatively generate efficient compiler tasks.

In C-alike programs, the source code is separated into header files and source files. During the software evolution process, both these two kinds of files need to adapt to changing requirement and changing environment. This paper studies the coevolution of header files and source files of C-alike programs. Using normalized compression distance that is derived from Kolmogorov complexity, we measure the header file difference and source file difference between versions of an evolving software product. Header files distance and source files distance are compared to understand their difference in pace of evolution. Mantel tests are performed to investigate the correlation of header file evolution and source file evolution. The study is performed on the source code of Apache HTTP web server.

The capability of an enterprise to innovate and promptly and effectively respond to change requests coming from both internal and external drivers has nowadays become a measure of the competitiveness of the enterprise in all business sectors. Innovation often implies modifying the enterprise business processes and, as a consequence, requires the evolution of the enterprise software systems. In this context, the workshop on Evolution of Software Systems in a Business Context (ESSBC), held in Budapest, Hungary, as part of the IEEE Software Technology and Engineering Practice workshop series (STEP 2005), aimed at discussing experiences and research outcomes and identifying research issues in supporting the evolution of enterprise software systems to reach innovation goals

The most current trends in the evolution of software development process are closely related with the increasing complexity of software systems. This motivates software engineers and system developers to find an alternative solution for software system design and development. In this case, the manner offered by OMG’s initiative, the Model Driven Architecture namely, represents a model-driven approach to software development. It also considers the further evolution of CASE tools, bringing their functionality to the next level. This paper investigates the variety of the CASE tools developed under an impact of MDA growing progress. The differences between Model Driven Architecture and Model Driven Development in the context of automatic capabilities for software development are also discussed in the paper. The example of possibility to define a set of tools proposed as a tool chain for development of software systems under the framework of MDA, the projection of two-hemisphere approach for object-oriented software development into authors’ developed component model of MDA is offered in the paper.

Production of a large-scale software system involves quite a few software components. It is very common to develop such software components in a distributed environment consisting of multiple computer systems connected by computer networks. In order to support effective software development in a distributed environment, a mechanism to combine a large number of components, which are distributed over the network, into a single system in a systematic way is quite essential. Object Make is a tool that automates the building process of software systems consisting of software components that are stored in the file systems of distributed computer systems, as if they are stored in a single file system. Software developers are not required to transfer these remote components to their own local computer systems explicitly, even if the computer systems do not share a common file system. The paper gives an overview of the distributed software build process for large-scale software systems using Object Make.

In this chapter we’ll cover Dart’s libraries, what libraries are, and how to create your own libraries. We’ll show you how to package functions, classes, or constants into a library for later use. Then we’ll see how to create more complex libraries, conformed by multiple source files, and how to re-export a library so that it shows or hides some namespaces.

In this paper we propose a virtual file system, which provides global declarations in source programs as virtual files to programmers. Global declarations means objects which declare identifiers in external scope, such as function definition and variable declaration. On SPDFS, programmers can edit virtual files directly by their favorite editors. Changes to declarations in a virtual file are to be applied to real source files automatically. SPDFS can also provide a set of relevant declarations distributed in different source files as a virtual file. Relevancy of declarations in this paper means references among declarations. SPDFS retrieves declarations which are referred by or refer to the target declaration and combine them in a virtual file. The depth of references can be specified in a file path by programmers. SPDFS reduces the amount of source programs which programmers need to read for editing and the amount of programmers' works for searching relevant declarations. We show an implementation of SPDFS using the portal file system on FreeBSD. The portal file system invokes commands for reading and writing a virtual file respectively. These commands work as user-land process. Because no modification of kernel is required, it is easy to customize the behavior of SPDFS. We also show the effectiveness of SPDFS by comparing numbers of lines of source programs which programmers need to read for editing.

This paper works on the general design of tracking ships system software structure with an eye to the complexity of information source of maritime tracking, and illustrates the design technique, methods and application examples in its realization. In this paper, a separation of system software function from specific data format is proposed to adapt to the difference in data structure resulting from each tracking ships unique equipment position and parameters. The difference in data structure is represented by parameters. The format information passed by parameter files is recorded by equipment sequence structure. A parameter program configuration is utilized and through real-time tracking data the allocation of system software is finished. The system can automatically adapt to data of different structure and treat all formats without rectifying software. The application software system designed in this conception has been used till today without major adjustments in its main structure. All changes can be adjusted via data files and in this way realizes adaptive processing.

Welcome to the International Conference on Software and Systems Process (ICSSP) held in Zurich, Switzerland, on June 2nd and 3rd, 2012. Having grown from a Software Process Workshop in 2005 to the International Conference on Software Process (ICSP) in 2007, and finally to the International Conference on Software and Systems Process (ICSSP) in 2011, this conference series has established its place in the software engineering community as a respected conference focusing on research and practice related to software and systems development process. Software and software systems development use processes as one major means for achieving and ensuring the quality of the final product. This leads to specific challenges regarding software processes such as simplicity, adaptability, standard conformance, the coordination of multiple domains and lifecycles, etc. Processes from other domains (e.g., health care, manufacturing, business, aerospace, automotive systems, and others) face similar challenges. Yet, they share interesting similarities with and differences to software processes. The question is: How can we in the software domain learn from other domains to meet our software process engineering challenges? The ICSSP conferences hence connect the traditional software and systems process community with outside views and insights, broadening its scope of software development processes to system development and explicitly including processes of other domains such as health care, business, and manufacturing. By sharing process development theories and practices from such domains, ICSSP 2012 is investigating novel solutions to today's process challenges. Correspondingly, the main theme of ICSSP 2012 is Beyond Software and Software Systems Processes, signaling our goal of learning from domains other than the traditional software process community.

A software system often consists of thousands of source files, which must be translated into thousands of intermediate files, which eventually must be translated into some small number of library and executable files. Collectively, these steps compose its build process. A large software system can be difficult to build. The steps can be numerous and complex. Of course, there are a variety of tools to assist us (e.g. MAKE), but their languages emphasize the specification of low-level details (e.g. compiler names and options), rather than high-level attributes (e.g. host/target platforms and required subsystems). This paper describes a new domain-specific language for specifying the composition and construction of a software system, where the emphasis is on high-level attributes. A specification is processed by a pipeline of fairly simple tools to produce a set of makefiles, which are then processed by MAKE in the usual way.

The paper presents the developed approach and software system for the Data Mining of public channels and groups in the Telegram messenger, for which emotionally colored vocabulary is identified in the texts and the emotional assessment is calculated in relation to objects, processes, events, phenomena, i.e., the opinion of the author is formed. The opinions of the authors are divided into two types: direct opinion and comparison, and the tonality receives three main assessments: positive, negative, neutral. The software system is implemented in the Python using the Dostoevsky library. RuSentiment dataset was used for training. The software system evaluates public opinion based on the analysis of comments in public channels and groups, for which the software system searches for comments and analyzes them, generates results as graphs and statistical values. The developed software system was tested for certain search parameters, which showed the practical applicability of the solution. The software system evaluates the crowd reaction to a post or evaluate how they relate to any fact based on the comments under the post in Telegram.

Understanding architectural characteristics of software components that constitute distributed systems is crucial for maintaining and evolving them. One component framework heavily used for developing component-based software systems is Microsoft's COM+. In this paper we particularly concentrate on the analysis of COM+ components and introduce an iterative and interactive approach that combines component inspection techniques with source code analysis to obtain a complete abstract model of each COM+ component. The model describes important architectural characteristics such as transactions, security, and persistency, as well as creating and use dependencies between components, and maps these higher-level concepts down to their implementation in source files. Based on the model, engineers can browse the software system's COM+ components and navigate from the list of architectural characteristics to the corresponding source code statements. We also discuss the Island Hopper application with which our approach has been validated.

Code clones have to be made explicit and be managed in software maintenance. Researchers have developed many clone detection tools to detect and analyze code clones in software systems. These tools report code clones as similar code fragments in source files. However, clone-related maintenance tasks (e.g., refactorings) often involve a group of code clones appearing in larger syntactic context (e.g., code clones in sibling classes or code clones calling similar methods). Given a list of low-level code-fragment clones, developers have to manually summarize from bottom up low-level code clones that are relevant to the syntactic context of a maintenance task. In this paper, we present a clone summarization technique to summarize code clones with respect to their common syntactic context. The clone summarization allows developers to locate and maintain code clones in a top-down manner by type hierarchy and usage dependencies. We have implemented our approach in the Clonepedia tool and conducted a user study on JHotDraw with 16 developers. Our results show that Clonepedia users can better locate and refactor code clones, compared with developers using the Clone Detective tool.

The collaboration relationships between header files in the source code of Linux kernels are analyzed by constructing a weighted Header File Collaboration Network (HFCN): each node represents a header file; two nodes are connected if corresponding header files are both included in the same source file at least once; also the link weight is assigned to evaluate the intensity of co-inclusion of two header files. Through using appropriate non-weighted and weighted quantities, structural properties of two kinds of HFCN networks(HFCN-I and HFCN-II) are characterized and analyzed. The study of Linux kernels from the viewpoint of complex networks can provide a better description of the organizational principles and evolving mechanism of complex software systems.