Enterprise service bus (ESB) plays an important role in enterprise SOA, and Java business integration (JBI) is the standard for Java based ESBs. As enterprises adopt ESB as the integration hub, how to preserve and leverage existing J2EE assets becomes an important question. While most ESBs allow J2EE applications to be deployed as-is, refactoring these applications allows them to take advantage of many service provided by the ESB platform and prompts service reuse. We will discuss our experience with a major US federal agencypsilas SOA efforts where a legacy J2EE application was refactored to be integrated in a JBI environment. We will also show how infrastructure concerns such quality of services (QoS) were moved from the J2EE application to the JBI container.

A number of papers have investigated the relationships between design metrics and the detection of faults in object-oriented software. Several of these studies have shown that such models can be accurate in predicting faulty classes within one particular software product. In practice, however, prediction models are built on certain products to be used on subsequent software development projects. How accurate can these models be, considering the inevitable differences that may exist across projects and systems? Organizations typically learn and change. From a more general standpoint, can we obtain any evidence that such models are economically viable tools to focus validation and verification effort? This paper attempts to answer these questions by devising a general but tailorable cost-benefit model and by using fault and design data collected on two mid-size Java systems developed in the same environment. Another contribution of the paper is the use of a novel exploratory analysis technique - MARS (multivariate adaptive regression splines) to build such fault-proneness models, whose functional form is a-priori unknown. The results indicate that a model built on one system can be accurately used to rank classes within another system according to their fault proneness. The downside, however, is that, because of system differences, the predicted fault probabilities are not representative of the system predicted. However, our cost-benefit model demonstrates that the MARS fault-proneness model is potentially viable, from an economical standpoint. The linear model is not nearly as good, thus suggesting a more complex model is required.

A growing body of literature suggests that there is an optimal size for software components. This means that components that are too small or too big will have a higher defect content (i.e., there is a U-shaped curve relating defect content to size). The U-shaped curve has become known as the "Goldilocks Conjecture." Recently, a cognitive theory has been proposed to explain this phenomenon and it has been expanded to characterize object-oriented software. This conjecture has wide implications for software engineering practice. It suggests 1) that designers should deliberately strive to design classes that are of the optimal size, 2) that program decomposition is harmful, and 3) that there exists a maximum (threshold) class size that should not be exceeded to ensure fewer faults in the software. The purpose of the current paper is to evaluate this conjecture for object-oriented systems. We first demonstrate that the claims of an optimal component/class size (1) above) and of smaller components/classes having a greater defect content (2) above) are due to a mathematical artifact in the analyses performed previously. We then empirically test the threshold effect claims of this conjecture (3) above). To our knowledge, the empirical test of size threshold effects for object-oriented systems has not been performed thus far. We performed an initial study with an industrial C++ system and repeated it twice on another C++ system and on a commercial Java application. Our results provide unambiguous evidence that there is no threshold effect of class size. We obtained the same result for three systems using four different size measures. These findings suggest that there is a simple continuous relationship between class size and faults, and that, optimal class size, smaller classes are better and threshold effects conjectures have no sound theoretical nor empirical basis.

Article Polymorphism measures for early risk prediction Share on Authors: Saïda Benlarbi Cistel Technology, 210 Colonnade Road, Suite 204, Nepean, Ontario, Canada K2E 7L5 Cistel Technology, 210 Colonnade Road, Suite 204, Nepean, Ontario, Canada K2E 7L5View Profile , Walcelio L. Melo Oracle Brazil and Univ. Católica de Brasilia, SQN Qd. 02- Bl A-Salas 604, Brasilia, DF Brazil 70712-900 Oracle Brazil and Univ. Católica de Brasilia, SQN Qd. 02- Bl A-Salas 604, Brasilia, DF Brazil 70712-900View Profile Authors Info & Claims ICSE '99: Proceedings of the 21st international conference on Software engineeringMay 1999 Pages 334–344https://doi.org/10.1145/302405.302652Online:16 May 1999Publication History 35citation573DownloadsMetricsTotal Citations35Total Downloads573Last 12 Months10Last 6 weeks1 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

In this paper we present the results of an empirical study in which we have investigated Machine Learning (ML) algorithms with regard to their capabilities to accurately assess the correctability of faulty software components. Three different families algorithms have been analyzed: divide and conquer (top down induction decision tree), covering, and inductive logic programming (ILP). We have used (1) fault data collected on corrective maintenance activities for the Generalized Support Software reuse asset library located at the Flight Dynamics Division of NASA's GSFC and (2) product measures extracted directly from the faulty components of this library. In our data set, the software quality models generated by both C4.5-rules (a divide and conquer algorithm) and FOIL (an inductive logic programming one) presented the best results from the point of view of model accuracy.

We present the results of an empirical study in which we have investigated machine learning (ML) algorithms with regard to their capabilities to accurately assess the correctability of faulty software components. Three different families of algorithms have been analyzed. We have used (1) fault data collected on corrective maintenance activities for the Generalized Support Software reuse asset library located at the Flight Dynamics Division of NASA's GSFC and (2) product measures extracted directly from the faulty components of this library.

In this paper, we propose a qualitative, inductive method for characterizing and evaluating software maintenance processes, thereby identifying their specific problems and needs. This method encompasses a set of procedures which attempt to determine causal links between maintenance problems and flaws in the maintenance organization and process. This allows for a set of concrete steps to be taken for maintenance quality and productivity improvement, based on a tangible understanding of the relevant maintenance issues in a particular maintenance environment. Moreover, this understanding provides a solid basis on which to define relevant software maintenance models and measures. A case study of the application of this method, called Q-MOPP, is presented to further illustrate its feasibility and benefits. © 1998 John Wiley & Sons, Ltd.

In this paper we characterize and model the cost of rework in a Component Factory (CF) organization.A CF is responsible for developing and packaging reusable software components.Data was collected on corrective maintenance activities for the Generalized Support Software reuse asset library located at the Flight Dynamics Division of NASA's GSFC.We then constructed a predictive model of the cost of rework using the C4.5 system for generating a logical classification model.The predictor variables for the model are measures of internal software product attributes.The model demonstrates good prediction accuracy, and can be used by managers to allocate resources for corrective maintenance activities.Furthermore, we used the model to generate proscriptive coding guidelines to improve programming practices so that the cost of rework can be reduced in the future.The general approach we have used is applicable to other environments.

This paper proposes a comprehensive suite of measures to quantify the level of class coupling during the design of object-oriented systems.This suite takes into account the different 00 design mechanisms provided by the C++ language (e.g., friendship between classes, specialization, and aggregation) but it can be tailored to other 00 languages.The different measures in our suite thus reflect different hypotheses about the different mechanisms of coupling in 00 systems.Based on actual project defect data, the hypotheses underlying our coupling measures are empirically validated by analyzing their relationship with the probability of fault detection across classes.The results demonstrate that some of these coupling measures may be useful early quality indicators of the design 'of 00 systems.These measures are conceptually different from the 00 design measures defined by Chidamber and Kemerer; in addition, our data suggests that they are complementary quality indicators.

Legacy software systems present a high level of entropy combined with imprecise documentation. This makes their maintenance more difficult, more time consuming, and costlier. In order to address these issues, many organizations have been migrating their legacy systems to new technologies. In this paper, we describe a computer-supported approach aimed at supporting the migration of procedural software systems to the object-oriented (OO) technology, which supposedly fosters reusability, expandability, flexibility, encapsulation, information hiding, modularity, and maintainability. Our approach relies heavily on the automatic formation of concepts based on information extracted directly from code to identify objects. The approach tends, thus, to minimize the need for domain application experts. We also propose rules for the identification of OO methods from routines. A well known and self-contained example is used to illustrate the approach. We have applied the approach on medium/large procedural software systems, and the results show that the approach is able to find objects and to identify their methods from procedures and functions.

This paper presents the results of a study in which we empirically investigated the suite of object-oriented (OO) design metrics introduced in (Chidamber and Kemerer, 1994). More specifically, our goal is to assess these metrics as predictors of fault-prone classes and, therefore, determine whether they can be used as early quality indicators. This study is complementary to the work described in (Li and Henry, 1993) where the same suite of metrics had been used to assess frequencies of maintenance changes to classes. To perform our validation accurately, we collected data on the development of eight medium-sized information management systems based on identical requirements. All eight projects were developed using a sequential life cycle model, a well-known OO analysis/design method and the C++ programming language. Based on empirical and quantitative analysis, the advantages and drawbacks of these OO metrics are discussed. Several of Chidamber and Kemerer's OO metrics appear to be useful to predict class fault-proneness during the early phases of the life-cycle. Also, on our data set, they are better predictors than "traditional" code metrics, which can only be collected at a later phase of the software development processes.

One important component of a software process is the organizational context in which the process is enacted.This component is ofien missing or incomplete in current process modeling approaches.One technique for modeling this perspective is the Actor-Dependency (AD) Model.This paper reports on a case study which used this approach to analyze and assess a large software maintenance organization.Our goal was to identifi the approach's strengths and weaknesses while providing practical recommendations for improvement and research directions.The AD model was found to be very useful in capturing the important properties of the organizational context of the maintenance process, and aided in the understanding of the flaws found in this process.However, a number of opportunities for extending and improving the AD model were identified.Among others, there is a need to incorporate quantitative information to complement the qualitative model.

Software process evolution corresponds to the act of improving the existing prescriptive software process models in a controlled and supported way. As software processes change constantly, it is therefore necessary to support one or more methods for assisting environment administrators in improving models. Changes are made in order to adapt software process models to new requirements, correct inconsistencies encountered in the course of execution, and modify, add or remove certain constraints. This article shows how software process evolution as supported in Tempo, a process-oriented software engineering environment where software processes are formally described in an object-oriented process schema. In Tempo, a process schema is comprised of descriptions of software agents, software products and software processes. A new approach is presented which supports the dynamic evolution of software process descriptions. In this approach, software process change is the result of tailoring the behavior of software objects manipulated during software process enaction.>

After years using of Adele, a configuration management system, it became apparent that it lacks activity-related concepts and mechanisms like work environment control, user coordination and synchronization, method and tool control, etc. It was also clear that considerable work is required to adapt a Software Engineering Environment (SEE) to user requirements. Using this experience, Adele 2 has beeen implemented to provide a general support for defining and managing dynamic aspects of a SEE and facilitate the building of new SEEs. This paper describes, using an example (work space control), the concepts and mechanisms involved. We show how close integration of an activity manager with a software engineering database fulfills the basic requirements and how a high level task manager coupled to a configuration manager can be developed.

Abstract Software maintenance is responsible for approximately 80% of the total cost of software. In order to reduce maintenance costs by improving both software productivity and quality, several software engineering environments have been built. In this paper, we present the main characteristics of Adele system, showing how this system is able to take account of software maintenance problems. We concentrate on the ability of this system to accept the specification of project‐specific policies and how these policies can be enforced automatically. We illustrate this with examples which with software maintenance. The second example is presented in the annexe and shows an example of cooperative work in an aerospace company. We conclude this article by presenting the lessons learned using our approach and our projects for the future.

TEMPO, a process-centered software engineering environment, assists in cooperative work by means of an approach based on a communication model. The executable formalism used to define software engineering activities is described, and it is shown how constraints related to the use of objects in these activities are expressed using the role concept. The communication model is then presented. Thanks to this model, strategies governing the cooperation between various software processes are specified by the concept of active, programmable connections. A connection is a communication channel that links two roles. Message exchange is controlled using TECA (temporal event-condition-action) rules, executed by a trigger mechanism. These allow for the programming of synchronization strategies between processes, propagating the effects of an executed action on one or more connection points. The temporary modes of TECA rules allow for transactions of long duration, because these can be used to reason on past activities. Coherence control of objects handled by activities of long duration is performed by the work environments. The union between connections and work environments makes it possible to support the cooperating processes and object sharing between processes.>