For automated program repairs (APR), the cost of the patch generation process will be reduced if automatically-generated test suites can be used. Automatic test-case generation techniques often take classes as input. This study aims at identifying which classes should be given as input for the aforementioned technique. In this study, we investigate the relationship between the test suites that detected failures and the actual classes that had bugs fixed by developers. We observe the cases where test suites do not identify the classes fixed by developers as a cause of failures. We also find that these cases occur when the classes fixed by developers are on the traces generated by test suites' exercises. Based on this finding, we examine the impact of the automatically generated test-suites on the performance of APR. We demonstrate, taking into account all the classes exercised by the failed test cases, that the total number of generated patches decreases but the number of correct patches increases.

The debugging support for beginner programmers has been an active research area in recent years. However, instead of directly supporting their debugging, training such programmers to be intermediate programmers by using exercises to debug programs is overlooked. In this training, it is important to prepare the programs including bugs that capture the tendency of beginner programmers. Therefore, we focused on Learning-Mutation, which learns the bugs using machine translation from buggy programs and fixed programs, and automatically induces bugs into programs. In this study, we applied Learning-Mutation to the programs written by beginner programmers at Kyushu University. By comparing the induced bugs by Learning-Mutation with the actual bugs by such programmers, we evaluated whether Learning-Mutation can be used to support the exercises by preparing the programs including bugs. As a result, the induced bugs are similar to the actual bugs, and the patterns of bugs that are forgetting semicolons and undeclaring variables or functions accounted for more than 36% when the number of tokens was small. On the other hand, as the number of tokens increased, the number of incorrect expressions increased. Furthermore, although there are bugs that are difficult to generate, beam search relieves this difficulty.

近年のIT社会の発展によってIT人材の不足が深刻になり，プログラム自動生成を含むソフトウェア開発の自動化が求められている．多くの研究が行われているなかで，プログラム自動生成をより実用的なものとするために，自動生成の過程でソースコード検索器を使用している研究がある．その研究では，求めるソースコードに木構造が近いと推測される類似解答ソースコードを検索し，自動生成の雛形としている．この手法を用いることで，プログラミングコンテストAtCoderの解答ソースコードの自動生成において，検索を行わない場合と比較して自動生成できた件数が増加したと報告されている．本研究では，木編集距離を学習に用いたソースコード検索器に着目した．ソースコード検索器の性能に影響を与える要因を実証的に調査することで，プログラム自動生成の精度向上への知見を得ることを目指す．調査では，検索精度に影響を与える要因として，深層学習モデルの構造，ソースコードの入力形式，問題の複雑度の3つを対象とし，AtCoderの問題を使用して検索精度の比較を行った．調査の結果，類似解答ソースコード検索においてTransformerのエンコーダ部分の使用は有効であることが期待できること，AtCoderの問題に対して抽象構文木のベクトル表現の使用は有効であるとはいえないこと，問題の複雑度は検索精度に影響を与えることを示した．
Automatic program generation is an active research topic in software engineering. To make automatic program generation more practical, a prior study applies source code search to the method of automatic program generation. In that study, source codes whose tree structures may be close to the desired source code developers require are searched and used as a template for the method. They reported that the method with source code search increases the number of generated source codes compared to the method without source code search. In this study, we use source code search using the tree edit distance. By empirically investigating the factors that affect the performance of source code search, we aim to improve the accuracy of automatic program generation. We focused on three factors that affect the search accuracy: the structure of the deep learning model, the input format of the source code, and the complexity of the problem. We compared the search accuracy on the AtCoder problems. We found that the encoder part of Transformer is promising for source code search, the use of vectorized representation of abstract syntax trees is less effective for the AtCoder problems, and the complexity of the problem affects the search accuracy.

© 2018 IEEE Computer Society. All Rights Reserved. It is desirable for software companies to assess the quality of open source software (OSS) in order to avoid degradation of product quality due to the quality of OSS. In this study, we conduct a questionnaire survey to understand which quality are required by developers for OSS in each development type and assess the quality of OSS when considering the results of the questionnaire survey. We target the OSS systems used in the development projects of Fujitsu Kyushu Network Technologies Limited. When comparing the questionnaire result with each development type, with five questions, there is a difference of 20% or more in proportion that "Important" or "Somewhat important" is answered. We set the weight for each evaluation item based on the questionnaire for each development type, and as a result of evaluating 6 OSS systems, we find that our approach detects 7 items from 12 items that developers evaluated as risky.

© 2018 IEEE Computer Society. All Rights Reserved. In this paper, we investigate the possibility and effectiveness of the approach to generating bug-fixing patterns extracted from Stack Overflow, which is a question and answer web site for programming. To do so, we collect 984,533 posts with the Android tag in Stack Overflow and extract top 10,000 ones related to the tag. Results show that (1) there are 28 posts that would be able to generate bug-fixing patterns, (2) there are 42 posts that are useful to fix bugs, and (3) those 42 posts include bug fixing patterns that are not supported by a previous study (PAR: Pattern-based Automatic program Repair).

Uncertainty can appear in all aspects of software development: Uncertainty in requirements analysis, design decisions, implementation and testing. If uncertainty can be dealt with modularly, we can add or delete uncertain concerns to/from models, code and tests whenever these concerns arise or are fixed to certain concerns. To deal with this problem, we developed iArch-U, an IDE (Integrated Development Environment) for managing uncertainty modularly in all phases in software development. In this paper, we introduce an overview of iArch-U. The iArch-U IDE is open source software and can be downloaded from GitHub.

To identify problems in a software development process, we have been developing an automated measurement tool called TaskPit, which monitors software development tasks such as programming, testing and documentation based on the execution history of software applications. This paper introduces the system requirements, design and implementation of TaskPit; then, presents two real-world case studies applying TaskPit to actual software development. In the first case study, we applied TaskPit to 12 software developers in a certain software development division. As a result, several concerns (to be improved) have been revealed such as (a) a project leader spent too much time on development tasks while he was supposed to be a manager rather than a developer, (b) several developers rarely used e-mails despite the company's instruction to use e-mail as much as possible to leave communication records during development, and (c) several developers wrote too long e-mails to their customers. In the second case study, we have recorded the planned, actual, and self reported time of development tasks. As a result, we found that (d) there were unplanned tasks in more than half of days, and (e) the declared time became closer day by day to the actual time measured by TaskPit. These findings suggest that TaskPit is useful not only for a project manager who is responsible for process monitoring and improvement but also for a developer who wants to improve by him/herself.

A/B testing is the experiment strategy, which is often used on web or mobile application development. In A/B testing, a developer has to implement multiple variations of application, assign each variation to a subset of the entire user population randomly, and analyze log data to decide which variation should be used as a final product. Therefore, it is challenging to keep the application code clean in A/B testing, because defining variations of software or assigning user to each variation needs the modification of code. In fact there are some existing tools to approach this problem. Considering such a context of A/B testing research, we propose the solution based on the interface Archface-U and AOP (Aspect Oriented Programming) which aims to minimize the complication of code in A/B testing.

A/B testing is a widely-used experiment strategy, in which a developer implements multiple variations, runs them in parallel, and analyzes their effects. It is needed to assign each variation to users or sessions in A/B testing. By using AOP (Aspect Oriented Programming), the assigning operation and the features of a software can be implemented separately. Here we propose the solution of automated A/B testing. Variations are expressed declaratively in Archface-U, an interface which expresses candidates for implementation. In the expression, assignment ratio is described with the annotations, which realize a declarative description of the entire A/B testing strategy. Based on the description, we generate an aspect which automate the assigning operation in A/B testing.

Unlike traditional defect prediction models that identify defect-prone modules, Just-In-Time (JIT) defect prediction models identify defect-inducing changes. As such, JIT defect models can provide earlier feedback for developers, while design decisions are still fresh in their minds. Unfortunately, similar to traditional defect models, JIT models require a large amount of training data, which is not available when projects are in initial development phases. To address this limitation in traditional defect prediction, prior work has proposed cross-project models, i.e., models learned from other projects with sufficient history. However, cross-project models have not yet been explored in the context of JIT prediction. Therefore, in this study, we empirically evaluate the performance of JIT models in a cross-project context. Through an empirical study on 11 open source projects, we find that while JIT models rarely perform well in a cross-project context, their performance tends to improve when using approaches that: (1) select models trained using other projects that are similar to the testing project, (2) combine the data of several other projects to produce a larger pool of training data, and (3) combine the models of several other projects to produce an ensemble model. Our findings empirically confirm that JIT models learned using other projects are a viable solution for projects with limited historical data. However, JIT models tend to perform best in a cross-project context when the data used to learn them are carefully selected.

Background: Substantial research in the software evolution field aims to recover knowledge about development from the project history that is archived in repositories, such as a Version Control System (VCS). However, the data that is archived in these repositories can be analyzed at different levels of granularity. Although software evolution is a well-studied phenomenon at the revision-level, revisions may be too fine-grained to accurately represent development tasks. Aim: In this paper, we set out to understand the impact that the revision granularity has on co-change analyses. Method: We conduct an empirical study of 14 open source systems that are developed by the Apache Software Foundation. To understand the impact that the revision granularity may have on co-change activity, we study work items, i.e., logical groups of revisions that address a single issue. Results: We find that work item grouping has the potential to impact co-change activity, since 29% of work items consist of 2 or more revisions in 7 of the 14 studied systems. Deeper quantitative analysis shows that, in 7 of the 14 studied systems: (1) 11% of largest work items are entirely composed of small revisions, and would be missed by traditional approaches to filter or analyze large changes, (2) 83% of revisions that co-change under a single work item cannot be grouped using the typical configuration of the sliding time window technique and (3) 48% of work items that involve multiple developers cannot be grouped at the revision-level. Conclusions: Since the work item granularity is the natural means that practitioners use to separate development tasks, future software evolution studies, especially co-change analyses, should be conducted at the work item level.

This paper extends our previous study (letter paper), which quantifies the difficulty of program comprehension based on brain activation measured by NIRS (Near Infra-Red Spectroscopy) during source code reading. We performed controlled experiments with 20 subjects. 3 of 20 subjects could not complete the measurement. We found that: (1) 16 of 17 shows strong brain activation during reading of obfuscated program (binomial test, p < 0:01) and (2) subjective evaluation of difficulty is correlated with brain activation (Spearman's correlation coefficient=0.46, p < 0:01).

Analogy-based effort estimation (ABE) is a commonly used software development effort estimation method. The processes of ABE are based on a reuse of effort values from similar past projects, where the appropriate numbers of past projects (k values) to be reused is one of the long-standing debates in ABE research studies. To date, many approaches to find this k value have been continually proposed. One important reason for this inconclusive debate is that different studies appear to produce different conclusions of the k value to be appropriate. Therefore, in this study, we revisit 8 common approaches to the k value being most appropriate in general situations. With a more robust and comprehensive evaluation methodology using 5 robust error measures subject to the Wilcoxon rank-sum statistical test, we found that conflicting results in the previous studies were not mainly due to the use of different methodologies nor different datasets, but the performance of the different approaches are actually varied widely.

Open Source Software (OSS) is vital to both end users and enterprises. As OSS systems are becoming a type of infrastructure, long-term OSS projects are desired. For the survival of OSS projects, the projects need to not only retain existing developers, but also attract new developers to grow. To better understand how projects retain and attract contributors, our preliminary study aimed to measure the personnel attraction and retention of OSS projects using a pair of population migration metrics, called Magnet (personnel attraction) and Sticky (retention) metrics. Because the preliminary study analyzed only 90 projects and the 90 projects are not representative of GitHub, this paper extend the preliminary study to better understand the generalizability of the results by analyzing 16,552 projects of GitHub. Furthermore, we also add a pilot study to investigate the typical duration between releases to find more appropriate release duration. The study results show that (1) approximately 23% of developers remain in the same projects that the developers contribute to, (2) the larger projects are likely to attract and retain more developers, (3) 53% of terminal projects eventually decay to a state of fewer than ten developers and (4) 55% of attractive projects remain in an attractive category.

To prioritize quality assurance efforts, various fault prediction models have been proposed. However, the best performing fault prediction model is unknown due to three major drawbacks: (1) comparison of few fault prediction models considering small number of data sets, (2) use of evaluation measures that ignore testing efforts and (3) use of n-fold cross validation instead of the more practical cross-release validation. To address these concerns, we conducted cross-release evaluation of 11 fault density prediction models using data sets collected from 2 releases of 25 open source software projects with an effort-aware performance measure known as Norm(P-opt). Our result shows that, whilst M5 and K* had the best performances; they were greatly influenced by the percentage of faulty modules present and size of data set. Using Norm(P-opt) produced an overall average performance of more than 50% across all the selected models clearly indicating the importance of considering testing efforts in building fault-prone prediction models.

Practical guidelines on what code has better quality are in great demand. For example, it is reasonable to expect the most complex code to be buggy. Structuring code into reasonably sized files and classes also appears to be prudent. Many attempts to determine (or declare) risk thresholds for various code metrics have been made. In this paper we want to examine the applicability of such thresholds. Hence, we replicate a recently published technique for calculating metric thresholds to determine high-risk files based on code size (LOC and number of methods), and complexity (cyclomatic complexity and module interface coupling) using a very large set of open and closed source projects written primarily in Java. We relate the threshold-derived risk to (a) the probability that a file would have a defect, and (b) the defect density of the files in the high risk group. We find that the probability of a file having a defect is higher in the very high-risk group with a few exceptions. This is particularly pronounced when using size thresholds. Surprisingly, the defect density was uniformly lower in the very high-risk group of files. Our results suggest that, as expected, less code is associated with fewer defects. However, the same amount of code in large and complex files was associated with fewer defects than when located in smaller and less complex files. Hence we conclude that risk thresholds for size and complexity metrics have to be used with caution if at all. Our findings have immediate practical implications: the redistribution of Java code into smaller and less complex files may be counterproductive.

Software development is a cyclic process of integrating new features while introducing and fixing defects. During development, commits that modify source code files are uploaded to version control systems. Occasionally, these commits need to be reverted, i.e., the code changes need to be completely backed out of the software project. While one can often speculate about the purpose of reverted commits (e.g., the commit may have caused integration or build problems), little empirical evidence exists to substantiate such claims. The goal of this paper is to better understand why commits are reverted in large software systems. To that end, we quantitatively and qualitatively study two proprietary and four open source projects to measure: (1) the proportion of commits that are reverted, (2) the amount of time that commits that are eventually reverted linger within a codebase, and (3) the most frequent reasons why commits are reverted. Our results show that 1%-5% of the commits in the studied systems are reverted. Those commits that are eventually reverted linger within the studied codebases for 1-35 days (median). Furthermore, we identify 13 common reasons for reverting commits, and observe that the frequency of reverted commits of each reason varies broadly from project to project. A complementary qualitative analysis suggests that many reverted commits could have been avoided with better team communication and change awareness. Our findings made Sony Mobile's stakeholders aware that internally reverted commits can be reduced by paying more attention to their own changes. On the other hand, externally reverted commits could be minimized only if external stakeholders are involved to improve inter-company communication or requirements elicitation.

Nowadays, a flexible, lightweight variant of the code review process (i.e., the practice of having other team members critique software changes) is adopted by open source and pro-prietary software projects. While this flexibility is a blessing (e.g., enabling code reviews to span the globe), it does not mandate minimum review quality criteria like the formal code inspections of the past. Recent work shows that lax reviewing can impact the quality of open source systems. In this paper, we investigate the impact that code reviewing practices have on the quality of a proprietary system that is developed by on Mobile. We begin by replicating open source analyses of the relationship between software quality (as approximated by post-release defect-proneness) and: (1) code review coverage, i.e., the proportion of code changes that have been reviewed and (2) code review participation, i.e., the degree of reviewer involvement in the code review process. We also perform a qualitative analysis, with a survey of 93 stakeholders, semi-structured interviews with 15 stakeholders, and a follow-up survey of 25 senior engineers. Our results indicate that while past measures of review coverage and participation do not share a relationship with defect-proneness at Sony Mobile, reviewing measures that are aware of the Sony Mobile development context are associated with defect-proneness. Our results have lead to improvements of the Sony Mobile code review process.

To prioritize software quality assurance efforts, fault prediction models have been proposed to distinguish faulty modules from clean modules. The performances of such models are often biased due to the skewness or class imbalance of the datasets considered. To improve the prediction performance of these models, sampling techniques have been employed to rebalance the distribution of fault-prone and non-fault-prone modules. The effect of these techniques have been evaluated in terms of accuracy/geometric mean/F1-measure in previous studies; however, these measures do not consider the effort needed to fix faults. To empirically investigate the effect of sampling techniques on the performance of software fault prediction models in a more realistic setting, this study employs Norm(Popt), an effort-aware measure that considers the testing effort. We performed two sets of experiments aimed at (1) assessing the effects of sampling techniques on effort-aware models and finding the appropriate class distribution for training datasets (2) investigating the role of balanced training and testing datasets on performance of predictive models. Of the four sampling techniques applied, the over-sampling techniques outperformed the under-sampling techniques with Random Over-sampling performing best with respect to the Norm(Popt) evaluation measure. Also, performance of all the prediction models improved when sampling techniques were applied between the rates of (20-30)% on the training datasets implying that a strictly balanced dataset (50% faulty modules and 50% clean modules) does not result in the best performance for effort-aware models. Our results also indicate that performances of effort-aware models are significantly dependent on the proportions of the two types of the classes in the testing dataset. Models trained on moderately balanced datasets are more likely to withstand fluctuations in performance as the class distribution in the testing data varies.

This paper studies how a developer uses crash reports sent from users in order to encourage the users to send the crash reports. This paper could contribute to what the developers understand the fault occurrence in user environment more precisely (for developers) and what the faults that users suffer would be preferentially addressed (for users). We analyze the relationship between the frequency of the crash reports in a crash repository and the probability of linkages of the crash reports and issue reports in Bugzilla. The results using the dataset collected from Firefox show some findings such as 1) 63% of crash reports are linked to issue reports and 2) 90% of the linked crash reports are linked to issue reports up to the 1,000 crash reports.

It is often observed that the majority of the development work of an Open Source Software (OSS) project is contributed by a core team, i.e., a small subset of the pool of active developers. In fact, recent work has found that core development teams follow the Pareto principle roughly 80% of the code contributions are produced by 20% of the active developers. However, those findings are based on samples of between one and nine studied systems. In this paper, we revisit prior studies about core developers using 2,496 projects hosted on GitHub. We find that even when we vary the heuristic for detecting core developers, and when we control for system size, team size, and project age: (1) the Pareto principle does not seem to apply for 40%-87% of GitHub projects; and (2) more than 88% of GitHub projects have fewer than 16 core developers. Moreover, we find that when we control for the quantity of contributions, bug fixing accounts for a similar proportion of the contributions of both core (18%-20%) and non-core developers (21%-22%). Our findings suggest that the Pareto principle is not compatible with the core teams of many GitHub projects. In fact, several of the studied GitHub projects are susceptible to the "bus factor," where the impact of a core developer leaving would be quite harmful.

Uncertainty in programming is one of the challenging issues to be tackled, because it is error-prone for many programmers to temporally avoid uncertain concerns only using simple language constructs such as comments and conditional statements. This paper proposes ucJava, a new Java programming environment for conquering uncertainty. Our environment provides a modular programming style for uncertainty and supports test-driven development taking uncertainty into consideration.

Uncertainty can appear in all aspects of software development: uncertainty in requirements analysis, design decisions, implementation, and testing. As the research on uncertainty is so young, there are many issues to be tackled. Modularity for Uncertainty is one of them. If uncertainty can be dealt with modularly, we can add or delete uncertain concerns to/from models, code, and tests whenever these concerns arise or are fixed to certain concerns. To deal with this challenging issue, we propose a modularization mechanism for uncertainty. Agile methods embrace change to accept changeable user requirements. On the other hand, our approach embraces uncertainty to support exploratory development. This paper sets out a focused research agenda for uncertainty in terms of the new modularity vision.

DSL (Domain-Specific Language) is one of the important approaches for software abstraction. In the past decades, DSLs have been provided by expert engineers familiar with domain knowledge and programming language processors. It is not easy for ordinary programmers to construct DSLs for their own purposes. To deal with this problem, we propose a language workbench called Argyle that can automatically generate a DSL by only specifying a set of functions needed to the DSL and an execution platform supported by the DSL. Argyle is based on software product lines and consists of the following two steps: 1) development of the core assets for constructing a family of DSLs and 2) DSL configuration using these core assets. To demonstrate the effectiveness of our approach, we developed a prototype DSL for supporting MSR (Mining Software Repositories), the most active research field in software engineering.

In most software development projects, design models tend to contain uncertainty, because all of the design concerns cannot be captured at the early development phase. It is preferable to be able to check consistency or traceability among design models and programs even if they contain uncertain concerns. To deal with this problem, we propose the notion of uncertainty-aware Archface, an interface mechanism exposing a set of architectural points that should be shared between design and code. We can explicitly describe uncertainty in design models or programs by specifying uncertain architectural points.

This paper proposes an abstraction-aware reverse engineering method in which a developer just makes a mark on an important code region as if he or she draws a quick sketch on the program list. A support tool called iArch slices a program from marked program points and generates an abstract design model faithful to the intention of the developer. The developer can modify the design model and re-generate the code again while preserving the abstraction level and the traceability. Archface, an interface mechanism between design and code, plays an important role in abstraction-aware traceability check. If the developer wants to obtain a more concrete design model from the code, he or she only has to make additional marks on the program list. We can gradually transition to model-driven development style.

Prior research suggests that predicting defect-inducing changes, i.e., Just-In-Time (JIT) defect prediction is a more practical alternative to traditional defect prediction techniques, providing immediate feedback while design decisions are still fresh in the minds of developers. Unfortunately, similar to traditional defect prediction models, JIT models require a large amount of training data, which is not available when projects are in initial development phases. To address this flaw in traditional defect prediction, prior work has proposed cross-project models, i.e., models learned from older projects with sufficient history. However, cross-project models have not yet been explored in the context of JIT prediction. Therefore, in this study, we empirically evaluate the performance of JIT cross-project models. Through a case study on 11 open source projects, we find that in a JIT cross-project context: (1) high performance within-project models rarely perform well
(2) models trained on projects that have similar correlations between predictor and dependent variables often perform well
and (3) ensemble learning techniques that leverage historical data from several other projects (e.g., voting experts) often perform well. Our findings empirically confirm that JIT cross-project models learned using other projects are a viable solution for projects with little historical data. However, JIT cross-project models perform best when the data used to learn them is carefully selected.

For Open Source Software (OSS) projects, retaining existing contributors and attracting new ones is a major concern. In this paper, we expand and adapt a pair of population migration metrics to analyze migration trends in a collection of open source projects. Namely, we study: (1) project stickiness, i.e., its tendency to retain existing contributors and (2) project magnetism, i.e., its tendency to attract new contributors. Using quadrant plots, we classify projects as attractive (highly magnetic and sticky), stagnant (highly sticky, weakly magnetic), fluctuating (highly magnetic, weakly sticky), or terminal (weakly magnetic and sticky). Through analysis of the MSR challenge dataset, we find that: (1) quadrant plots can effectively identify at-risk projects, (2) stickiness is often motivated by professional activity and (3) transitions among quadrants as a project ages often coincides with interesting events in the evolution history of a project.

We focus on effort estimation based on the effort for early phase activities, and built effort estimation models using early phase effort as an explanatory variable, and compared the estimation accuracies of these models to the effort estimation models based on software size. In addition, we built estimation models using both early phase effort and software size. In our experiment, we used ISBSG dataset, which was collected from software development companies, and regarded planning phase effort and requirement analysis effort as early phase effort. The result of the experiment showed that when both software size and sum of planning and requirement analysis phase effort were used as explanatory variables, the estimation accuracy was most improved (Average Balanced Relative Error was improved to 75.4% from 148.4%).

This paper rethinks both modularity and compilation in the light of abstraction between design and implementation. We propose a new compilation approach called abstractionaware verifying compiler, in which abstraction is the target of compilation. Both a design model and its code are inputted as the first-class software modules to the compiler.

A Abstraction has been an important issue in software engineering. However, it is not easy to design an architecture reflecting the intention of developers and implement the result of a design as a program while preserving an adequate abstraction level. To deal with this problem, we provide iArch, an IDE (Integrated Development Environment) for supporting abstraction-aware traceability between design and code. The iArch IDE is based on Archface, an architectural interface mechanism exposing a set of architectural points that should be shared between design and code. An abstraction level is determined by selecting architectural points.

There exists two types of developers in Open Source Software (OSS) projects: 1) Committers who have permission to commit edited source code to the Version Control System (VCS), 2) Developers who contribute source code but cannot commit to the VCS directly. In order to develop and evolve high quality OSS, projects are always in search of new committers. OSS projects often promote strong developers to become committers. When existing committers find strong developers, they propose their promotion to a committer role. Delaying the committer-promotion might lead to strong developers departing from an OSS project and the project losing them. However early committer-promotion comes with its own slew of risks as well (e.g., the promotion of inexperienced developers). Hence, committer-promotion decisions are critical for the quality and successful evolution of OSS projects. In this paper, we examine the committer-promotion phenomena for two OSS projects (Eclipse and Firefox). We find that the amount of activities by future committers was higher than the amount of activities by developers who did not become committers). We also find that some developers are promoted to a committer role very rapidly (within a few month) while some of developers take over one year to become a committer. Finally, we develop a committer-identification model to assist OSS projects identifying future committers.

This paper proposes a new style of product line engineering methods. It focuses on constructing embedded systems that take into account the contexts such as the external physical environments. In current product line development projects, Feature Analysis is mainly conducted from the viewpoint of system configurations: how hardware and software components are configured to constitute a system. In most cases, contexts are not considered explicitly. As a result, unexpected and unfavorable behavior might emerge in a system if a developer does not recognize any possible conflicting combinations between the system and contexts. To deal with this problem, this paper provides the notion of a context-dependent product line, which is composed of the system and context lines. The former is obtained by analyzing a family of systems. The latter is obtained by analyzing features of contexts associated to the systems. The system and context lines contain reusable core assets. The configuration of selected system components and contexts can be formally checked at the specification level. In this paper, we show a development process that includes the creation of both product line assets as well as context assets. (C) 2012 Elsevier B.V. All rights reserved.

We propose a new modularity vision to integrate design modeling with programming. A system consists of not only program code but also design models. However, design models such as UML diagrams have been treated as not modules but complementary documents. This paper provides a novel idea that treats a design model as a first-class software module termed design module. A system cannot be complied without design modules. A developer has to create and modify not only program modules but also design modules. To realize design modules, we introduce Archface, an architectural interface mechanism. Archface exposes architectural points shared between design and code. Archface plays a role as a design interface for a design module and as a program interface for a program module. Arch-face type system automatically checks the consistency between design and code. Our approach can integrate research on design modeling with research on programming in terms of modularity. Additional costs are not needed to introduce design modules, because Archface descriptions can be generated from a model editor and Archface is just an extension of the notion of program interfaces. That is, we can substitute Archface for traditional program interfaces. © 2013 IEEE.

The Mining Software Repositories (MSR) field reveals knowledge for software development by analyzing data stored in repositories such as source control and bug trace systems. In order to reveal the knowledge, MSR researchers need to perform complicated procedures iteratively. To help the complex work of MSR practitioners, we study the construction of domain specific languages (DSLs) for MSR. We have conducted feature-oriented domain analysis (FODA) on MSR and developed a DSL based on the feature model. In this paper, we expand our previous work and propose to construct not a single DSL but a DSL family. A DSL family consists of a series of DSLs with commonality in their domain but suitable to specific applications of MSR. To readily construct these DSLs, we use Alloy to encode the feature model. Our encoding includes not only the DSL features and their relations but also some composition rules that can be used to generate the syntax of DSLs. Based on this, we can automatically derive the language elements to construct DSLs suitable to specific purposes of MSR. Copyright 2013 ACM.

Context-awareness plays an important role in developing flexible and evolvable applications such as self-* systems (e.g., self-adaptive, self-healing, and self-management systems). However, it is not easy to design and implement such a context-aware system, because its software architecture is dynamically changed. That is, software components constituting a system and their connection structure can be dynamically changed. As a result, it is hard to check whether or not a design model is correctly implemented and its context-dependent behavior is faithful to the design. To deal with this problem, we introduce Archface4COP, an architectural interface mechanism for COP (Context-Oriented Programming). Archface4COP exposes architectural points shared between UML-based design models and code written in COP languages. Architectural points represent COP-specific events such as layer in, layer out, layered message send, and layered message receive. These points are important to represent an abstract structure of software architecture focusing on context-awareness. We can verify whether or not a design model and its code can co-evolve each other by checking an Archface4COP interface. Copyright 2013 ACM.

Defect prediction models are a well-known technique for identifying defect-prone files or packages such that practitioners can allocate their quality assurance efforts (e.g., testing and code reviews). However, once the critical files or packages have been identified, developers still need to spend considerable time drilling down to the functions or even code snippets that should be reviewed or tested. This makes the approach too time consuming and impractical for large software systems. Instead, we consider defect prediction models that focus on identifying defect-prone (&amp
risky&amp
) software changes instead of files or packages. We refer to this type of quality assurance activity as &amp
Just-In-Time Quality Assurance,&amp
because developers can review and test these risky changes while they are still fresh in their minds (i.e., at check-in time). To build a change risk model, we use a wide range of factors based on the characteristics of a software change, such as the number of added lines, and developer experience. A large-scale study of six open source and five commercial projects from multiple domains shows that our models can predict whether or not a change will lead to a defect with an average accuracy of 68 percent and an average recall of 64 percent. Furthermore, when considering the effort needed to review changes, we find that using only 20 percent of the effort it would take to inspect all changes, we can identify 35 percent of all defect-inducing changes. Our findings indicate that &amp
Just-In-Time Quality Assurance&amp
may provide an effort-reducing way to focus on the most risky changes and thus reduce the costs of developing high-quality software. © 1976-2012 IEEE.

The mining software repositories (MSR) analyze data stored in software repositories and discover meaningful information to support software development. However, MSR is complex due to conducting large scale data collection with various repositories. To help practitioners perform MSR analysis, one possible way is to apply the approaches of software product line (SPL) to the MSR domain to understand variability and commonality for the domain, and to construct domain specific languages (DSLs) because DSLs have high readability to reduce the complexity of the procedure of MSR. In this paper, we construct a SQL-based DSL to support MSR and provide a systematic approach to conduct Feature-Oriented Domain Analysis (FODA) for MSR towards the construction of the DSL. We provide the syntax of the DSL and explain how to locate language elements of the DSL to the four-layer structure used in FODA.

Many research projects on software estimation use software size as a major explanatory variable. However, practitioners sometimes use the ratio of effort for early phase activities such as planning and requirement analysis, to the effort for the whole development phase of the software in order to estimate effort. In this paper, we focus on effort estimation based on the effort for early phase activities. The goal of the research is to examine the relationship of early phase effort and software size with software development effort. To achieve the goal, we built effort estimation models using early phase effort as an explanatory variable, and compared the estimation accuracies of these models to the effort estimation models based on software size. In addition, we built estimation models using both early phase effort and software size. In our experiment, we used ISBSG dataset, which was collected from software development companies, and regarded planning phase effort and requirement analysis effort as early phase effort. The result of the experiment showed that when both software size and sum of planning and requirement analysis phase effort were used as explanatory variables, the estimation accuracy was most improved (Average Balanced Relative Error was improved to 75.4% from 148.4%). Based on the result, we recommend that both early phase effort and software size be used as explanatory variables, because that combination showed the high accuracy, and did not have multicollinearity issues. © 2013 IEEE.

AspectM, an aspect-oriented modeling (ADM) language, provides not only basic modeling constructs but also an extension mechanism called metamodel access protocol (MMAP) that allows a modeler to modify the metamodel. MMAP consists of metamodel extension points, extension operations, and primitive predicates for navigating the metamodel. Although the notion of MMAP is useful, it needs tool support. This paper proposes a method for implementing a MMAP-based AspectM support tool. It consists of model editor, model weaver, and model verifier. We introduce the notion of edit-time structural reflection and extensible model weaving. Using these mechanisms, a modeler can easily construct domain-specific languages (DSLs). We show a case study using the AspectM support tool and discuss the effectiveness of the extension mechanism provided by MMAP. As a case study, we show a UML-based DSL for describing the external contexts of embedded systems.

Open source software projects (OSS) receive a large number of bug reports from various contributors and developers alike, where many planned to be fixed by OSS developers. Given the next release cycle information, OSS users can be more effective and flexible in planning and to fix the bugs that are not to be fixed in the next release. It is therefore vital for OSS users to learn which bugs the OSS developers will fix, unfortunately such information may not be readily available, nor there is a prediction framework exists to serve such an important purpose. In this study, we would like to answer the question 'Will this bug be fixed by the next release?', this is addressed by building a bug fixing prediction model based on the characteristics of a bug-related metric and by incorporating the progress of bug fixing measures such as status, period and developer metrics to provide aggregated information for the OSS users. The proposed model calculates the deviance of each variable to analyze the most important metrics, and it has been experimented using a case study with Eclipse platform. Result shows a bug fixing prediction model using both base metrics and state metrics provide significantly better performance in precision (139%) and recall (114\%) than the standard model using only base metrics. © 2012 IEEE.

The mining software repositories (MSR) field integrates and analyzes data stored in repositories such as source control and bug repositories to provide support to practitioners. In order to provide useful information to practitioners, MSR researchers need to perform tasks iteratively, these tasks include extracting data from repositories, transforming them into specific data formats, and loading them into the statistical analysis tool. These tasks require a significant amount of man hours to implement and execute according to the requirements of the researchers. This paper proposes an external domain-specific language (DSL) called QORAL to facilitate the performance of multiple iterations and environment development. The results from a questionnaire used to evaluate QORAL indicate that it is easy to understand and modify source code. © 2012 IEEE.

COP (Context-Oriented Programming) languages such as ContextJ* enable programmers to describe the context-aware behavior elegantly. The primary system behavior can be separated from the context-aware behavior. On the other hand, unfortunately, it becomes difficult to debug the programs due to the complexity of COP execution and the dependence between objects and contexts. To deal with this problem, this paper proposes CJAdviser, SMT-based debugging support for ContextJ*. In CJAdviser, the execution trace of a ContextJ* program is converted to a context dependence graph that can be analyzed by the SMT solver Yices. Using CJAdviser, we can check a variety of object-context dependencies.

Context-awareness plays an important role in developing flexible and adaptive systems. However, it is not easy to design and implement such a context-aware system, because its system configuration can be dynamically changed. This paper proposes UML4COP, a UML-based design method for COP (Context-Oriented Programming). UML4COP is a DSML (Domain-Specific Modeling Language) for designing context-aware systems. In UML4COP, each context is modeled separately and a system design model at a certain period of time is composed by merging associated contexts. Copyright © 2012 ACM.

It is not easy to design software architecture reflecting the intention of developers and implement the result of design as a program while preserving the architectural correctness and adequate abstraction level. Archface, an architectural interface mechanism, plays a role as an ADL at the design phase and as a programming interface at the implementation phase. Design and code can co-evolve with Archface at the center of the development process. This paper proposes a verifiable architectural interface that can check the traceability between design and code. For this checking, we use an SMT (Satisfiability Modulo Theories) solver, a tool for deciding the satisfiability of logical formulas. Adopting our approach, we can construct MDD tools supporting adequate abstraction level when they generate code, recover a design model from code, and check the traceability between a design model and its code. © 2012 IEEE.

AOP can be applied to not only modularization of crosscutting concerns but also other kinds of software development processes. As one of the applications, this paper proposes a design traceability mechanism originating in join points and pointcuts. It is not easy to design software architecture reflecting the intention of developers and implement the result of design as a program while preserving the architectural correctness. To deal with this problem, we propose two novel ideas: Archpoint (Architectural point) and Archmapping (Archpoint Mapping). Archpoints are points for representing the essence of architectural design in terms of behavioral and structural aspects. By defining a set of arch-points, we can describe the inter-component structure and the message interaction among components. Archmapping is a mechanism for checking the bidirectional traceability between design and code. The traceability can be verified by checking whether archpoints in design are consistently mapped to program points in code. For this checking, we use an SMT (Satisfiability Modulo Theories) solver, a tool for deciding the satisfiability of logical formulas. The idea of archpoints, program points, and their selection originates in AOP. © 2012 ACM.

Most requirements elicitation methods do not explicitly provide a systematic way for deciding the boundary of the usage context that should be taken into account because it is essentially difficult to decide which context element should be included as the system requirements. If a developer explores the context boundary in an ad-hoc manner, the developer will be faced with the frame problem because there are unlimited context elements in the real world where the target system exists. There are many application domains that should take into account the frame problem: security, safety, network threats, and user interactions. To deal with this problem, this paper proposes a new type of requirements analysis method for exploring the context boundary using guide words, a set of hint words for finding a context element affecting the system behavior. The target of our method is embedded systems that can be abstracted as a sensor-and-actuator machine exchanging the physical value between a system and its context. In our method, only the value-context elements, a kind of value objects, are extracted as the associated context elements. By applying the guide words, we can explore only a sequence of context elements affecting the data value and avoid falling into the frame problem at the requirements analysis phase.

The Mining Software Repositories (MSR) field integrates and analyzes data stored in repositories such as source control and bug repositories to support practitioners. Given the abundance of repository data, scaling up MSR analyses has become a major challenge. Recently, researchers have experimented with conventional techniques like a super-computer or cloud computing, but these are either too expensive or too hard to configure. This paper proposes to scale up MSR analysis using "general-purpose computing on graphics processing units" (GPGPU) on off-the-shelf video cards. In a representative MSR case study to measure co-change on version history of the Eclipse project, we find that the GPU approach is up to a factor of 43.9 faster than a CPU-only approach.

Most requirements elicitation methods do not explicitly provide a systematic way for deciding the boundary of the usage context that should be taken into account because it is essentially difficult to decide which context element should be included as the system requirements. If a developer explores the context boundary in an ad-hoc manner, the developer will be faced with the frame problem because there are unlimited context elements in the real world where the target system exists. There are many application domains that should take into account the frame problem: security, safety, network threats, and user interactions. To deal with this problem, this paper proposes a new type of requirements analysis method for exploring the context boundary using guide words, a set of hint words for finding a context element affecting the system behavior. The target of our method is embedded systems that can be abstracted as a sensor-and-actuator machine exchanging the physical value between a system and its context. In our method, only the value-context elements, a kind of value objects, are extracted as the associated context elements. By applying the guide words, we can explore only a sequence of context elements affecting the data value and avoid falling into the frame problem at the requirements analysis phase.

Context-awareness plays an important role in developing flexible and adaptive software. However, it is not easy to write context-aware programs because context cannot be treated as a module in the traditional programming languages. COP (Context-Oriented Programming) languages such as ContextJ * enable programmers to describe the context-aware behavior elegantly. The primary system behavior can be separated from the context-aware behavior. On the other hand, unfortunately, it becomes difficult to debug the programs due to the complexity of COP execution and the dependence between objects and contexts. To deal with this problem, this paper proposes CJAdviser, SMT-based debugging support for ContextJ*. In CJAdviser, the execution trace of a ContextJ* program is converted to a context dependence graph that can be analyzed by the SMT (Satisfiability Modulo Theories) solver Yices. Using CJAdviser, we can check a variety of object-context dependencies such as "Do two objects A and B exist in the Context X at the same time?". In CJAdviser, SMT is applied to not static analysis but dynamic analysis because many context-aware properties are determined at run time.

Many embedded systems not only affect their context through actuators but also are affected by the context through sensors. It is important to provide a context-dependent development method for constructing safe and reliable embedded systems. However, most of the current requirements analysis methods do not explicitly provide a systematic way for deciding the boundary of the context that should be taken into account because it is essentially difficult to decide which context element should be included as the targets of requirements analysis. If a developer explores the context boundary in an ad-hoc manner, he or she will be faced with the frame problem because there are unlimited context elements in the real world where the target system exists. To deal with this problem, this paper proposes a context-dependent requirements analysis method called CAMEmb ( Context Analysis Method for Embedded systems) in which only the value-context elements are extracted as the associated context elements. Applying the guide words provided by CAMEmb, we can explore only a sequence of context elements directly or indirectly affecting the data value observed or controlled by the system sensors and actuators. Other context elements not affecting the system observation and control are not taken into account because these context elements do not affect the system behavior. Using CAMEmb and lightweight formal tools, we can explore the context boundary that guarantees the expected system behavior. We developed CAMEmbModeler, a support tool consisting of a CAMEmb-based modeling editor and a model compiler that transforms system and context models into the design model reflecting the context boundary.

In this paper, we present a replicated study to predict fault-prone modules with code clone metrics to follow Baba's experiment [1]. We empirically evaluated the performance of fault prediction models with clone metrics using 3 datasets from the Eclipse project and compared it to fault prediction without clone metrics. Contrary to the original Baba's experiment, we could not significantly support the effect of clone metrics, i.e., the result showed that F1-measure of fault prediction was not improved by adding clone metrics to the prediction model. To explain this result, this paper analyzed the relationship between clone metrics and fault density. The result suggested that clone metrics were effective in fault prediction for large modules but not for small modules. © 2011 IEEE.

We propose PM (Project Management) patterns to prevent schedule delays caused by changes in requirement, on empirical studies Changes or late elicitation of requirements dun rig the deign. coding and test processes are one of the most serious risks, which may delay project schedules However. changes and late elicitation of requirements are usally accepted dun rig development processes Therefore the PM methods for preventing schedule delays caused by changes and late e lie I tat ion of requirements dun its development processes are an important area of study In this study. we examined the actual conditions of various projects which succeeded in preventing schedule delays resulting from changes and late elicitation of requirements during development processes We were able to extract various typical PM techniques for preventing these schedule delays The techniques, known as "PM patterns" were also applied to other projects The patterns were arranged on a two-dimensional framework We discuss a framework of PM patterns aimed at solving the problems caused by changes in requirements.

This paper proposes a new style of product line engineering methods. It focuses on constructing embedded systems that take into account the contexts such as the external physical environments. In the current product line engineering, the feature analysis is mainly conducted from the viewpoint of system configurations: how hardware and software components are configured to constitute a system. In most cases, contexts are not considered explicitly. As a result, unexpected and unfavorable behavior might emerge in a system if a developer does not recognize any possible conflicting combinations between the system and contexts. To deal with this problem, this paper provides the notion of a context-dependent product line, which is composed of the system and context lines. The former is obtained by analyzing a family of systems. The latter is obtained by analyzing features of contexts associated to the systems. In the proposed method, each feature is described using VDM++. The configuration of selected system components and contexts can readily be checked with VDM++ Toolset.

Reusability is important especially in Web application development because Web applications tend to be rapidly developed and frequently modified. There are several studies to improve the reusability by adapting modular techniques in software engineering. However, the reusability brought by previous studies is restricted to limited Web applications because the techniques are deeply depended on the specific framework or architecture. In this paper, we propose an approach of defining reusable components for multiple Web applications using a domain-specific aspect-oriented (AO) mechanism based on an abstraction model common to all Web applications. As a case study to confirm the effectiveness of the approach, we present four practical examples of reusable aspect components and apply them to two real-sized open source Web applications. The result of the case study shows the domain-specific AO mechanism is an effective platform to implement reusable functionalities common to many Web applications.

Aspect-oriented programming (AOP) is a technique for modularizing crosscutting concerns (CCCs). A variety of CCCs can be found in typical Web applications. Most CCCs are scattered over Web-specific events such as page requests. AOWP, a PHP-based AOP framework, provides Web-specific aspect instantiations for dealing with session management and pointcut & advice mechanisms for capturing Web-specific events. CCCs in Web applications can be clearly modularized by introducing AOWP.

In open systems, certain unfavorable situations due to unanticipated user behavior may be seen, which results in a violation of cross-cutting policy. This paper proposes a runtime monitoring method to check such problems. Since there is a large gap, a certain link is needed between the policy and runtime execution method. We employ a two-step checking approach; an offline symptom checking and a runtime monitoring. The ingredient to tie the two steps is a Linear-time Temporal Logic formula for the cross-cutting policy to look at.

We propose a new domain-specific aspect-oriented programming (AOP) mechanism for Web application development. A variety of crosscutting concerns such as access control and performance tuning are found in typical Web applications, but it is not easy to concisely modularize the concerns as aspects in current AOP languages because they do not provide pointcut mechanisms for directly handling events in the Web controller layer. To deal with this problem, we propose a Web-specific AOP mechanism called AOWP and a PHP-based AOWP framework. Using this framework, a programmer can easily address Web-specific crosscutting concerns triggered by Web-specific events, including page requests, page transitions, and session management events.

Embedded systems such as household electric appliances are required to retain a high standard of quality such as safety and usability. Then, those systems are tested thoroughly. But, this trends leads redesign of those systems and causes bad influences of cost and delivery. Then, we have researched the reasons of exchanging of the specification about some projects for development of embedded software delayed of delivery date. The results of the research shows that the major reason of exchanging of the specifications are mismatch of non-functional requirement of systems and design of the software when the behavior of the systems deviated from correct behavior. Therefore, in this paper, we show a quality management process that focuses non-functional requirements and a methodology for the process. Furthermore, we show an experiment for confirming the effects of the process and methodology.

This paper proposes a conceptual model for analysis method of extracting unexpected obstacles in order to improve the quality of embedded systems. Although embedded software has become increasingly large in scale and complexity, companies are requiring the software to be developed with in shorter periods of time. This trend in the industry has resulted in the oversight of unexpected obstacles and consequently has affected the quality of embedded software. In order to prevent the oversight of unexpected obstacles, we have already proposed two methods for requirements analysis: the Embedded Systems Improving Method (ESIM) using an Analysis Matrix, and a method that uses an Information Flow Diagram (IFD). However, these analysis methods have been developed separately. This paper proposes the conceptual model including both methods, and clarifies abstraction mechanisms of expert engineers for extracting unexpected obstacles of embedded systems. It also describes a case study and discussion of the domain model.

In order to improve the quality of embedded software by finding obstacles unanticipated by software specifications, this paper describes a requirement analysis method based on an Information Flow Diagram and experiments using this method, with discussion. Recently, embedded software has become more large-scale and complicated while the development cycle of the software has typically been shortened. This industry trend compromises the quality of embedded software. In order to improve the quality of the software, unexpected obstacles must be carefully analyzed in the specification and design phases. We propose a diagram-based analysis method to answer this need, and have performed an experiment using the analysis method with an actual product. The results of the experiment made it clear that 1) Novice engineers can construct an Information Flow Diagram under the lead of expert engineers; and 2) The methods by which experts lead novice engineers in the analysis of unexpected obstacles require further refinement.

Aspect-oriented programming (AOP) has the good characteristic called obliviousness that enables a programmer to design a class without considering crosscutting concerns. On the other hand, it is not necessarily easy for the programmer to know the overall behavior of a woven program because weaving modifies the behavior of a method denned in a class. Unexpected errors might be embedded in the woven program. To tackle this problem, we propose WbC (Weaving by Contract), a technique for verifying the correctness of weaving based on contracts. Contracts in WbC consist of pre-conditions, post-conditions, and invariants of weaving. By introducing WbC, we can specify how a program should behave before and after weaving. We also provide a language called COW (COntracl Writing language) for supporting WbC. In COW, a programmer describes contracts by predicate logic that represents the behavior of a program as a property of control and data flow. WbC can restrict weaving to keep the intention of the programmer.

In order to improve the quality of embedded software, this paper proposes an enhancement to the ESIM (Embedded Systems Improving Method) by combining an IFD (Information Flow Diagram) with an Analysis Matrix to analyze unexpected obstacles in the software. These obstacles are difficult to predict in the software specification. Recently, embedded systems have become larger and more complicated. Theoretically therefore, the development cycle of these systems should be longer. On the contrary in practice the cycle has been shortened. This trend in industry has resulted in the oversight of unexpected obstacles, and consequently affected the quality of embedded software. In order to prevent the oversight of unexpected obstacles, we have already proposed two methods for requirements analysis: the ESIM using an Analysis Matrix and a method that uses an IFD. In order to improve the efficiency of unexpected obstacle analysis at reasonable cost, we now enhance the ESIM by combining an IFD with an Analysis Matrix. The enhancement is studied from the following three viewpoints. First, a conceptual model comprising both the Analysis Matrix and IFD is defined. Then, a requirements analysis procedure is proposed that uses both the Analysis Matrix and IFD, and assigns each specific role to either an expert or non-expert engineer. Finally, to confirm the effectiveness of this enhancement, we carry out a description experiment using an IFD.

Separation of concerns is important to reduce the complexity of software design. This paper(1) examines a software development method starting with the feature-oriented modeling method to have VDM-based formal design. In order to overcome the problem that a feature may be scattered over the VDM design description, the notion of the aspect is adapted to propose AspectVDM. The identified features axe concisely represented in AspectVDM to demonstrate modular descriptions of cross-cutting concerns in VDM.

For the representation of the collaborative operations among objects (computational entities), many of the techniques proposed at present treat the collaborative operations only as the concept in analysis and design stages; moreover, the roles carried by the respective objects have the problem of being fixed from the beginning to the end. Based on the environment-adaptive computation model "ε computation" proposed by the authors, in this paper we will study from the language side a description method for the case of collaborative operations in which the group of objects changes their roles dynamically along with the progress of computation. Furthermore, we will present a method for defining the collaborative operations among objects as general collaboration protocol components and reuse them again. ε computation is a model in which the field where the group of objects operates collaboratively is considered as an environment for the individual objects; the object can change its roles and collaboration forms with other objects dynamically by entering the environment or leaving the environment.

Using mobile agent systems, cooperative distributed applications that run over the Internet can be constructed flexibly. However, there are some problems: it is difficult to understand collaborations among agents as a whole, it is difficult to define behaviors of agents because they are influenced by their external context dynamically. So, in general, constructions of cooperative distributed applications based on mobile agent systems are considered as very hard and difficult works.
In this paper, the concept of RoleEP (Role Based Evolutionary Programming) is proposed in order to alleviate these problems. RoleEP provides a systematic evolutionary programming style. In RoleEP. a field where a group of agents collaborate with each other is regarded as an environment and a function that an agent assumes in an environment is defined as a role. Descriptions only concerning to collaborations among agents call be abstracted by environments. An object becomes an agent by binding itself with a role that is defined in an environment, and acquires functions needed for collaborating with other agents that exist in the same environment. Distributed applications based on mobile agent systems. which may change their functions dynamically in order to adapt themselves to their external context, can be constructed by synthesizing environments dynamically.

Several parallel computation models including the Actor Model have been proposed. Since these models have only primitive constructs for parallel computation, it is not easy to build a model in terms of what kind of roles objects in the real world play and how they collaborate with each other. When we create a parallel system model with such frameworks, it is difficult to understand the system behavior as a whole. To solve this problem, we propose a new model, the Producer Model, and its description language Produce/1. In the Producer Model, parallel objects collaborate with each other under the coordination of producer objects. In the Actor Model, objects build network topologies and send messages to each other. On the other hand, in the Producer Model, we distinguish these two kinds of computations, through the execution of the former by producer objects, and of the latter by actor objects. By reading procedures of producer objects, we can understand collaboration among objects easily.