Adam Trendowicz

Jürgen Münch
email: muench@iese.fraunhofer.de

Ross Jeffery
email: rossj@cse.unsw.edu.au

State of the Practice in Software Effort Estimation: A Survey and Literature Review

Keywords: software, project management, effort estimation, survey, state of the practice, state of the art

Effort estimation is a key factor for software project success, defined as delivering software of agreed quality and functionality within schedule and budget. Traditionally, effort estimation has been used for planning and tracking project resources. Effort estimation methods founded on those goals typically focus on providing exact estimates and usually do not support objectives that have recently become important within the software industry, such as systematic and reliable analysis of causal effort dependencies. This article presents the results of a study of software effort estimation from an industrial perspective. The study surveys industrial objectives, the abilities of software organizations to apply certain estimation methods, and actually applied practices of software effort estimation. Finally, requirements for effort estimation methods identified in the survey are compared against existing estimation methods.

Introduction

Rapid growth in the demand for high-quality software and increased investments in software projects show that software development is one of the key markets worldwide. The average company spends about 4 to 5 percent of its revenues on information technology, with those that are highly IT-dependent -such as financial and telecommunications companies -spending more than 10 percent [START_REF] Charette | Why Software Fails [Software Failure[END_REF]. A fast changing market demands software products with ever more functionality, higher reliability, and higher performance. In addition, in order to stay competitive, senior managers increasingly demand that IT departments deliver more functionality and quality with fewer resources, and do it faster than ever before [START_REF] Jørgensen | Combining Quantitative Software Development Cost Estimation Precision Data with Qualitative Data from Project Experience Reports at Ericsson Design Center in Norway[END_REF]. Together with the increased complexity of software, the global trend towards shifting development from single contractors to distributed projects has led to software companies needing a reliable basis for making make-or-buy decisions. Finally, software development teams must strive to achieve all these objectives by exploiting the impressive advances in continuously changing (and often immature) technologies.

In this situation, software planning and management seem to be an essential and, at the same time very difficult task. Dozens of well-known software disasters [START_REF] Charette | Why Software Fails [Software Failure[END_REF] are the most visible examples of problems in managing complex, distributed software systems. Independent of such experiences, many software organizations are still proposing unrealistic software costs, work within tight schedules, and finish their projects behind schedule and budget (46%), or do not complete them at all (19%) [START_REF] Standish | CHAOS Chronicles[END_REF]. Finally, even if completed within a target plan, overestimated projects typically expand to consume whatever more resources were planned, while the functionality and quality of underestimated projects is cut to fit the plan.

To address these and many other issues, considerable research has been directed at building and evaluating software effort estimation methods and tools [START_REF] Briand | Resource Modeling in Software Engineering[END_REF][START_REF] Trendowicz | Software Effort Estimation -Overview of Current Industrial Practices and Existing Methods[END_REF]. For decades, estimation accuracy was a dominant prerequisite for accepting or declining a certain effort estimation method. Yet, even though perhaps very accurate, it does not guarantee project success. Software decision makers have recently had to face this problem and find an estimation method that, first, is applicable in the context of a certain organization and, second, contributes to the achievement of organizationspecific objectives. Therefore, in order to accept or decline a certain estimation method, two major criteria should be met. The necessary acceptance criterion is that the software organization is able to fulfill the application prerequisites of a certain method, such as needed measurement data or required involvement of human experts. The sufficient acceptance criterion, on the other hand, refers to the method's contribution to organizational objectives. As reported in this paper, besides accuracy, estimation methods are expected to support a variety of project management activities, such as risk analysis, benchmarking, or process improvement.

In this article, we survey industrial objectives with respect to effort estimation, the abilities of software organizations to apply certain estimation methods, and effort estimation practices actually applied within the software industry. The remainder of the paper is organized as follows: Section 2 defines common sources of effort estimation problems. Section 3 outlines the study design. Section 4 summarizes current industrial practices with respect to software effort estimation, followed (Section 5) by a comparative evaluation of existing effort estimation methods concerning their suitability to meet certain industrial requirements. Finally, Section 6 concludes the results of the study presented in this paper and provides further research directions.

Sources of Deficits in Software Effort Estimation

As with any other process or technology, software effort estimation is expected to meet certain objectives and requires certain prerequisites to be applied. A problem occurs where the applied estimation method is not in line with the defined objectives and/or the available resources. Specifically, we identify two major sources of effort estimation problems in the software industry, which may be addressed by the following questions:

• What is provided by a method? The estimation method provides less than required for the achievement of organizational objectives, e.g., it provides only a point estimate and thus hardly any support for managing project risks if the estimate is lower than the available budget. • What is required by a method? The estimation method requires more resources than currently available in the organization, e.g., it requires more measurement data than actually available in the organization.

Study Design

The study presented in this paper consisted of two elements: (1) a review of related literature and (2) a survey performed among several software companies.

Study Objectives

The objective of the study was the analysis of the current industrial situation regarding software effort estimation practices (state of the practice). In particular, the following aspects were focused on:

• Effort estimation objectives: industrial objectives (expectations) with respect to effort estimation methods; • Effort estimation abilities: ability of software companies to apply a certain estimation approach, e.g., by providing necessary resources; • Effort estimation methods: effort estimation methods actually applied at software companies. In addition, existing estimation methods are analyzed concerning how they meet industrial needs and abilities regarding software effort estimation (state of the art).

Information Sources

The study presented in this paper is based on two sources of information:

• Literature Review: Literature published in the public domain such as books, journals, conference proceedings, reports, and dissertations. • Industrial Surveys: Information gained during two series of industrial surveys (S1 and S2) performed at 10 software organizations. The survey results presented in this chapter include both surveys, unless explicitly stated otherwise.

Literature Review

The design of the review is based on the guidelines for systematic reviews in software engineering proposed, for instance, in [START_REF] Brereton | Lessons from Applying the Systematic Literature Review Process within the Software Engineering Domain[END_REF][START_REF] Jørgensen | A Systematic Review of Software Development Cost Estimation Studies[END_REF]. It was performed as follows (Fig. 1):

Fig. 1 Overview of the literature review process 1. Identifying information sources: We identified the most relevant sources of information with respect to the study objectives. Initially, they included the most prominent software engineering journals and conference proceedings1 . 2. Defining search criteria: We limited the review scope by two criteria: relevancy and recency. Relevancy defined the content of the reviewed publications. We focused on the titles that dealt with software effort estimation and related topics such as development productivity. Recency defined the time frame of the reviewed publications. Since software engineering is one of the most rapidly changing domains, we decided to limit our review to papers published after the year 1995. The analysis of industrial practices encompassed an even narrower scope, namely publication after the year 2000.

Automatic search:

We performed an automatic search through relevant sources of information using defined search criteria (Table 1). This search included a search for specific keywords in the publications' title, abstract, and list of keywords (if provided). We used generic search engines such as INSPEC (http://www.iee.org/publish/inspec/) and specific engines associated with concrete publishers such as IEEE Xplore (http://ieeexplore.ieee.org/Xplore/dynhome.jsp). 4. Initial review: We initially reviewed the title, abstract, and keywords of the publications returned by the automatic search with respect to the defined criteria for inclusion in the final review. 5. Full review: A complete review of the publications accepted during the initial review was performed. This step was followed by a manual search and review (if accepted) of referenced relevant publications that had not been found in earlier steps of the review. In total, 380 publications were reviewed in the study.

Manual search:

In accordance with the recommendations presented in [START_REF] Jørgensen | A Systematic Review of Software Development Cost Estimation Studies[END_REF], we complemented the results of the automatic search with relevant information sources by doing a manual search through references found in reviewed papers as well as using a generic web search engine (http://www.google.com).

Industrial Surveys

During the years 2005-2008, we performed a series of industrial surveys aimed at analyzing current industrial practices with respect to modeling (estimation and measurement) software development effort and productivity. In this paper, we present the aggregated results of the two most recent surveys and one industry workshop. The early survey (S1) focused on effort estimation practices as well as closely related productivity and size measurement practices. The survey encompassed 7 software organizations. The recent survey (S2) focused specifically on effort estimation practices. It included such particular issues as objectives of estimation, estimation process, as well as inputs and outputs of estimation. The survey was performed in 2 software companies, with one of them being represented by 7 different development groups. In addition, we include the results of an effort estimation workshop we performed in 2007 in the software business unit of a large international provider of software systems (embedded domain). During the workshop, we asked the 7 participants about their estimation objectives, the estimation methods currently applied, and organizational capabilities with respect to effort modeling. • The size of the organization considered in the survey in terms of number of employees. We distinguish Small (less than 50 employees), Medium (between 50 and 200 employees), and Large (more than 200 employees).

• The type of involved organizations was mainly software suppliers. In one case, the company provided independent verification and validation services (IV&V). • The involved roles mainly included middle-level management and consultants: software developers (SD), project managers (PM), quality engineers (QE), quality managers (QM), and group/division managers (DM). • The application type of typical products considered in the context of the involved organizations ranged from financial via medical, automotive, and industrial automation to safety-critical systems. • The domain of the organization includes mainly information systems (MIS) and embedded software (EM). Information systems covered mainly financial systems, whereas embedded software covered such application areas as medical, automotive, telecommunication, and industrial automation.

Study Limitations

A major limitation of the study is the limited availability of information sources. The small sample of respondents in the industrial surveys might not be representative of the population of the software industry. Yet, since the results of the survey largely conform with the results of the literature review and our informal experiences gained during multiple industrial collaborations, we conclude that the results presented in this paper represent current trends in software effort estimation theory and practice.

State of the Industrial Software Effort Estimation Practice

The industrial practices surveyed in this paper include: (1) objectives of effort estimation, (2) capabilities to meet prerequisites for applying a certain estimation method, and (3) effort estimation methods currently applied in the software industry.

Objectives of Effort Estimation

Fig. 2 presents a summary of effort estimation objectives identified in the study. In the case of several objectives, there is a noticeable discrepancy between what is presented in the related literature and what we observed during industrial surveys.

From the perspective of study limitations, the availability of information sources may have resulted in data samples that are not representative of the whole software industry. In practice, there are, however, several other sources of variance in the results presented in Fig. 2. Traditional effort estimation objectives, such as planning and tracking the software project, or reducing project management overhead, are so common (and thus considered so "obvious") that they are typically not indicated if not asked for explicitly. Although the most recent literature focused most probably on the new objectives that have traditionally not been considered by the software industry until now, the survey also explicitly asked about traditional effort estimation objectives. Finally, we believe that the industrial surveys show some of the most recent trends that were not observed by the authors of the reviewed literature. Our personal experience confirms, for example, the increasing importance of process/productivity improvement objectives. Based on the review of related literature and the results of the industrial surveys, we identified the 7 most common objectives regarding effort estimation methods: 1. Project planning & tracking. The effort estimation method should support effective project planning by providing reliable and exact estimates at various levels of project granularity. There are two different ways of project planning dependent on the project type. In the context of fixed-price projects, effort estimation provides the basis for planning software functionality (how much functionality can be developed at a specified quality level and within a fixed budget). In the context of fixed-product projects, effort estimation provides a basis for planning software project schedule and cost (how much time and cost are required for developing software with a specified functionality and quality). 2. Process improvement. The effort estimation method should support the understanding and improvement of effort-and productivity-related development processes. 3. Project management overhead. The effort estimation method should minimize management overhead, i.e., the cost of applying and maintaining an estimation method (e.g., model building, application, and maintenance). 4. Negotiating project costs. The effort estimation method should support the communication and negotiation process (justifying development costs) in the context of software procurement between the stakeholders involved (project managers, management, customers, etc.). 5. Risk management. The effort estimation method should support management of project risks. This includes reciprocal integration of effort estimation and risk management, i.e., effort estimation uses the outputs of risk management (identified project risks having an impact on estimated effort) and provides input to risk management (cost-related risks). Moreover, the method should explicitly cover estimation uncertainty (i.e., accept uncertain/incomplete inputs and provide evaluation of the output's uncertainty).

6. Productivity improvement. The effort estimation method should support the identification of factors that have the greatest influence on development productivity. Achievement of objective 1 usually implicates productivity improvement, at least from a long-term perspective; yet productivity might be improved without improving related processes, e.g., by assigning more skilled people to the project instead of improving training processes. 7. Project benchmarking. The effort estimation method should support benchmarking of software projects with respect to development effort and productivity. Comparing software projects regarding productivity and effort between different organizations is especially important nowadays in the context of rapidly growing global development (out-sourcing, off-shoring, etc.) in order to support make-or-buy decisions and select/manage software suppliers. 8. Change management. The effort estimation method should be easy to reapply along the software development life cycle in order to support managing changes in project scope, such as modified (non-)functional software requirements.

Effort Estimation Capabilities

The results of the industrial surveys and the literature review indicate that software organizations represent a very wide range of estimation capabilities. Estimation budget: Due to extensive project pressure, software organizations do not typically assign sufficient manpower for estimation that is adequate to the approach applied. Depending on the specific domain, software organizations spend between 2% and 15% (on average 6%) of the entire project budget, which is typically not sufficient for applying estimation methods based on the judgment of multiple human experts. Expert involvement: At the same time, respondents highlighted insufficient resources for estimation as one of the major problems that reduce the applicability and effectiveness of project effort prediction. In practice, software organizations are very unwilling to spend the effort of human experts on estimation tasks when they are responsible for other activities in a software project (Fig. 3). In consequence, estimation is typically performed by people lacking the appropriate expertise and/or with tight resources (e.g., insufficient budget designated for estimation).

Quantitative project data: On the other hand, software organizations typically do not have enough reliable project data to employ data-driven estimates and relieve human estimators. We observed (Fig. 4) that most of the time, the historical data a software organization can typically base estimates on does not exceed 10 projects. Even when the required amount of data has been collected, they are often not driven by specific objectives and often suffer from very low quality (inconsistency, incompleteness, etc.). The declared ratio of missing data ranges between 20% and 30%. Moreover, on average, 10-20% of the projects in the data repository can be described as exceptional projects that are not likely to be repeated (data outliers). One of the surveyed organizations, for example, collected measurement data from around 600 projects; yet, due to significant inconsistency and incompleteness, it was practically useless for estimation purposes (although great effort had been invested to validate and preprocess the data). This shows how important it is to define a proper, goal-oriented measurement program before data collection begins. Another interesting observation is that the quality and quantity of available data does not seem to be related to the specific reference process models used with an organization. A CMMI-L3 or -L5 organization may, for instance, have problems with collecting the minimal amount of useful project data, whereas an ISO9000 organization may already have a number of business-relevant measures collected for dozens of projects in their data repository. One of the factors responsible for insufficient data availability [START_REF] Macdonell | Comparing Local and Global Software Effort Estimation Models -Reflections on a Systematic Review[END_REF][START_REF] Mendes | Replicating Studies on Cross-vs Single-company Effort Models Using the ISBSG Database[END_REF] is the rapid technological advancement in the software engineering domain. Software organizations focusing on large projects, such as those in the space domain, might never be able to collect a sufficient amount of up-to-date data.

Applied Effort Estimation Methods

Quite surprising in the light of available manpower seems to be the observation that a vast majority of software organizations employ effort estimation based on expert assessment (Fig. 5). The industrial surveys showed that 9 out of 10 surveyed companies employed estimation based on human judgment. This remains in line with observations made for over a decade, where about 60% to 85% of software projects rely exclusively upon expert estimates [START_REF] Moløkken-Østvold | Expert Estimation of the Effort of Web-Development Projects: Why Are Software Professionals in Technical Roles More Optimistic Than Those in Non-Technical Roles[END_REF][START_REF] Moløkken-Østvold | A Review of Surveys on Software Effort Estimation[END_REF]. Ad-hoc estimates are, however, rare and predictions are typically obtained through a group meeting where several experts follow a structured estimation process (such as that implemented in the Delphi method [START_REF] Boehm | Software Cost Estimation with COCOMO II[END_REF]) to come up with a final effort prediction. One of the major reasons is distrust of data-driven methods, which is the result of the lack of substantial evidence in favor of those methods [START_REF] Moløkken-Østvold | Expert Estimation of the Effort of Web-Development Projects: Why Are Software Professionals in Technical Roles More Optimistic Than Those in Non-Technical Roles[END_REF]. Moreover, they are often perceived as complicated to use, and thus requiring significant overhead. Therefore, if used at all, only simple data-driven methods such as linear regression based on the effort and size of already finished projects are applied -often in combination with expert judgment [START_REF] Moløkken-Østvold | A Survey on Software Estimation in the Norwegian Industry[END_REF].

Effort estimation method

Percentage of survey responses Experts estimate software size (usually through a work breakdown structure), for instance, in combination with the average development productivity of already completed projects to come up with the effort prediction (Effort = Size / AverageProductivity). A simple combination of the individual results of expert-and data-based estimates typically does not seem to provide significant improvement compared to expert estimates alone [START_REF] Moløkken-Østvold | A Survey on Software Estimation in the Norwegian Industry[END_REF]. Finally, the use of more sophisticated methods, such as COCOMO [START_REF] Boehm | Software Cost Estimation with COCOMO II[END_REF] or decision trees [START_REF] Breiman | Classification and Regression Trees[END_REF], remains marginal.

Detailed Requirements regarding Software Effort Estimation Methods

An investigation of industrial objectives and abilities regarding effort estimation as well as an analysis of detailed comments given by study respondents led us to define a detailed list of requirements that should be considered when selecting a particular estimation method:

1. Expert involvement: The method does not require extensive expert involvement, i.e., it requires a minimal number of experts, limited involvement (effort) per expert, and minimal expertise. 2. Required data: The method does not require large amounts of measurement data of a specific type (i.e., measurement scale) and distribution (e.g., normal). 3. Robustness: The method is robust to low-quality data inputs, i.e., incomplete (e.g., missing data), inconsistent (e.g., data outliers), redundant, and collinear data. 4. Flexibility: The method is free from a specific estimation model and provides context-specific outputs.

Complexity:

The method has limited complexity, i.e., it does not employ many techniques, its underlying theory is easy to understand, and it does not require specifying many sophisticated parameters. 6. Support level: There is comprehensive support provided along with the method, i.e., complete and understandable documentation, and a useful software tool. 7. Handling uncertainty: The method supports handling the uncertainty of the estimation (i.e., inputs and outputs). 8. Comprehensiveness: The method can be applied for estimating different kinds of project activities (e.g., management, engineering) on various levels of granularity (e.g., project, phase, and task). 9. Availability: The method can be applied during all stages (phases) of the software development lifecycle. 10. Empirical evidence: There is comprehensive empirical evidence supporting the theoretical and practical validity of the method. 11. Informative power: The method provides complete and understandable information that supports the achievement of numerous estimation objectives (e.g., effective effort management). In particular, it provides context-specific information regarding relevant effort factors, their interactions, and their impact on effort. 12. Reliability: The method provides the output that reflects the true situation in a given context. In particular, it provides accurate, precise, and repeatable outputs. 13. Portability: The method provides estimation outputs that are either applicable in other contexts without any modification or are easily adaptable to other contexts. These requirements may be further quantified, e.g., using a Likert-scale with respect to their value and importance, and used within multi-criteria decision support [START_REF] Paschetta | A Multicriteria-based Methodology for the Evaluation of Software Cost Estimation Models and Tools[END_REF] for selecting the best suitable effort estimation method within a specific project context.

Overview of Existing Software Effort Estimation Methods

Existing effort estimation methods basically differ with respect to the type of inputs they require and the form of the estimation model they provide. With respect to input data, we differentiate between three major groups: data-intensive, expert-based, and hybrid methods (combining available data and expert knowledge in order to come up with estimates). An analysis of existing estimation methods with respect to industrial objectives and derived requirements indicates a few leading methods that meet most of the requirements; although no single method satisfies all requirements [START_REF] Trendowicz | Software Effort Estimation -Overview of Current Industrial Practices and Existing Methods[END_REF].

The major point against data-intensive methods is that they require large data sets. This is not the typical industrial situation (even in high-maturity, process-oriented organizations), which is rather characterized by sparse, incomplete, and inconsistent data. Moreover, these methods are often complicated to use, and have not actually proven to be superior to expert-based methods. Among the data-intensive methods, some require past project data for building customized models (define-your-ownmodel approaches), others provide an already defined model, where factors and their relationships are fixed based on a set of multi-organizational project data (fixed-model approaches). The major advantage of fixed-model approaches is that they, theoretically, do not require any historical data to be applied. Those methods might be especially attractive in the IV&V context, where very sparse (if any) data are typically available. Yet, in practice, fixed models, such as COCOMO [START_REF] Boehm | Software Cost Estimation with COCOMO II[END_REF], are developed for a specific context and are, by definition, only suited for estimating the types of projects for which the fixed model was built. The applicability of such models for the IV&V context is, in practice, very limited. In order to improve their performance, a significant amount of organization-specific project data would be required for calibrating the generic model. In that case, the usefulness of the fixed-model approaches for IV&V effort estimation would not differ much from the define-yourown-model approaches, which require a significant amount of reliable, contextspecific data to build customized effort models. Application of the define-your-ownmodel methods is further limited by the additional requirements of specific methods. Parametric approaches, such as regression [START_REF] Sentas | L: Software Productivity and Effort Prediction with Ordinal Regression[END_REF], for instance, make several assumptions about underlying project data (completeness, normal distribution, etc.) that are rarely met in the software domain. Non-parametric methods originating from the machine learning domain, such as artificial neural networks (ANN) [START_REF] Boetticher | An Assessment of Metric Contribution in the Construction of a Neural Network-Based Effort Estimator[END_REF] or Decision Trees [START_REF] Breiman | Classification and Regression Trees[END_REF], make practically no assumptions about the data but are quite sensitive to their parameter configuration, and there is usually little universal guidance regarding how to set those parameters. Thus, finding appropriate parameter values requires some preliminary experimentation.

In contrast to data-intensive methods, expert-based estimation does not require any project measurement data. However, it is widely criticized due to large overheads and the requirement for seasoned experts each time the estimation needs to be performed. Moreover, the reliability of the outputs it provides largely depends on the expertise and individual preferences of the human experts involved. Moreover, since the rationale underlying the final estimates is not modeled explicitly, expert-based estimation, by itself, provides hardly any support for effective decision making (risk management, process improvement, negotiations, etc.). Even though experts identify the factors influencing development effort, we find that they typically tend to largely disagree on them and omit relevant factors while selecting irrelevant ones.

Recently, a few hybrid methods have been proposed to cope with the deficits of data-intensive and expert-based estimation. One of the main objectives of hybrid estimation is to reduce the amount of both measurement data and human expertise by combining those two sources of information. In consequence, more reliable estimates should be obtained with reduced overhead. Empirical applications [START_REF] Mendes | A Comparison of Techniques for Web Effort Estimation[END_REF][START_REF] Trendowicz | Development of a Hybrid Cost Estimation Model in an Iterative Manner[END_REF] report on higher estimation accuracy and stability of hybrid methods when compared to those based solely on data or experts. Moreover, methods that employ explicit causal effort modeling [START_REF] Mendes | A Comparison of Techniques for Web Effort Estimation[END_REF][START_REF] Trendowicz | Development of a Hybrid Cost Estimation Model in an Iterative Manner[END_REF] have proven to greatly contribute to the achievement of a variety of organizational objectives, such as risk management or process/productivity improvement. Yet, the causal effort model, from which an effort model is derived, is typically developed based either solely on experts or on data. This still requires either significant involvement of experienced human experts or large amounts of highquality data. Moreover, the reliability of a causal model based on homogeneous sources of information is typically limited. We found, for example, that domain experts, driven by their subjective preferences, tend to omit relevant causal effects (i.e., effort drivers and their causal interactions) while choosing irrelevant ones.

Summary and Further Work Directions

In this paper, we analyzed industrial trends with respect to software effort estimation. In particular, we were interested in what the objectives of effort estimation are, what the industrial capabilities for applying certain estimation strategies are, and finally, which of the existing methods are actually employed within the software industry.

To summarize our findings, there is a growing need for supporting various project and process management activities, such as risk management, project negotiations, or process improvement. Effort estimation methods that grew upon traditional planning objectives usually focus on providing an accurate point estimate without giving much insight into organization-specific causal effort dependencies, in particular into the most relevant factors contributing to project effort. In consequence, even though accurate estimates can be provided, there is hardly any support for decision making in situations where the estimate exceeds the available budget. Moreover, software organizations, even high-maturity ones, do not have sufficient resources to apply existing estimation methods, which typically require either extensive involvement of seasoned domain experts or large amounts of high-quality measurement data. In consequence, estimation performed with insufficient resources (manpower) by multiple human experts is still a common industrial practice. Even though quantitative methods are applied, they are rather simple and often based on sparse and unreliable data. In this situation, hybrid methods that combine data analysis with expert judgment and provide a transparent, context-specific model of causal effort dependencies seem to offer a potential remedy. Inclusion of subjective elements, such as an expert's opinion, in analytical models potentially allows for a significant reduction in the number of irrelevant variables considered in a model, as well as accounting for factors that are difficult to measure. Yet, the few hybrid methods that have been proposed so far base the development of an explicit causal effort model either on measurement data or on human judgment. In consequence, they inherit the major weaknesses of data-driven and expert-based estimation.

The discrepancy between what is needed by the software industry and what is actually provided by the research community indicates that further research should, in general, focus on providing estimation methods that keep up with current industrial needs and abilities. In particular, methods that integrate analysis of sparse data with minimal involvement of human experts in order to come up with causal effort models should be investigated.

Fig. 2 .

 2 Fig. 2. Summary of objectives regarding software effort estimation

Fig. 3 .

 3 Fig. 3. Roles involved in the estimation process (survey S2)

Fig. 4 .

 4 Fig. 4. Historical project data available in the software industry

Fig. 5 .

 5 Fig. 5. Effort estimation methods applied in the software industry

Table 1 .

 1 Query defined for the purpose of automatic search ((Software OR Project) AND (Effort OR Cost OR Estimation OR Prediction) IN (Title OR Abstract OR Keywords)) AND (Date >= 1995 AND Date <= 2008)

Table 2 .

 2 Overview of the industrial survey characteristics

	Id	Size Org. Type Involved	App. Type	Domain
	S1.1 L	Supplier	DM, PM	Finance	MIS
	S1.2 L	Supplier	QM, QE, PM	Automation Systems MIS
	S1.3 L	Supplier	PM, PM, QE	Finance	MIS
	S1.4 L	Supplier	PM, PM, QE	Finance	MIS
	S1.5 L	Supplier	PM	Finance	MIS
	S1.6 S	Supplier	DM, PM, PM	Finance	MIS
	S1.7 S	Supplier	PM, PM, QM	Finance	MIS
	S2.1 L	Supplier	7 x PM	Medical, Automotive EM
	S2.2 S	IV&V	QE	Space	EM
	W1 S	Supplier	DM, 2 x SD, 2 x QE, 2 x PM Automation Systems EM

Table 2

 2 presents an overview of the survey characteristics. For each survey, the following characteristics are included:

For a detailed list of the information sources considered in the study, please refer to[START_REF] Trendowicz | Software Effort Estimation -Overview of Current Industrial Practices and Existing Methods[END_REF].


Valentino Vranić
email: vranic@fiit.stuba.sk

Michal Bebjak
email: mbebjak@gmail.com

Radoslav Menkyna

Peter Dolog
email: dolog@cs.aau.dk

Developing Applications with Aspect-Oriented Change Realization

Keywords: change, aspect-oriented programming, generally applicable changes, domain specific changes, change interaction

An approach to aspect-oriented change realization is proposed in this paper. With aspect-oriented programming changes can be treated explicitly and directly at the programming language level. Aspect-oriented change realizations are mainly based on aspect-oriented design patterns or themselves constitute pattern-like forms in connection to which domain independent change types can be identified. However, it is more convenient to plan changes in a domain specific manner. Domain specific change types can be seen as subtypes of generally applicable change types. This relationship can be maintained in a form of a catalog. Further changes can actually affect the existing aspect-oriented change realizations, which can be solved by adapting the existing change implementation or by implementing an aspect-oriented change realization of the existing change without having to modify its source code. Separating out the changes this way can lead to a kind of aspect-oriented refactoring beneficial to the application as such. As demonstrated partially by the approach evaluation, the problem of change interaction may be avoided to the large extent by using appropriate aspect-oriented development tools, but for a large number of changes, dependencies between them have to be tracked, which could be supported by feature modeling.

Introduction

To quote a phrase, change is the only constant in software development. Change realization consumes enormous effort and time. Once implemented, changes get lost in the code. While individual code modifications are usually tracked by a version control tool, the logic of a change as a whole vanishes without a proper support in the programming language itself. By its capability to separate crosscutting concerns, aspect-oriented programming enables to deal with change explicitly and directly at programming language level. Changes implemented this way are pluggable and-to the great extent-reapplicable to similar applications, such as applications from the same product line.

Customization of web applications represents a prominent example of that kind. In customization, a general application is being adapted to the client's needs by a series of changes. With each new version of the base application all the changes have to be applied to it. In many occasions, the difference between the new and old application does not affect the structure of changes, so if changes have been implemented using aspect-oriented programming, they can be simply included into the new application build without any additional effort.

We have already reported briefly our initial efforts in change realization using aspect-oriented programming [START_REF] Bebjak | Evolution of web applications with aspectoriented design patterns[END_REF]. In this paper, we present our improved view of the approach to change realization and the change types we discovered. Section 2 presents our approach to aspect-oriented change realization. Section 3 introduces the change types we have discovered so far in the web application domain. Section 4 discusses how to deal with a change of a change. Section 5 describes the approach evaluation and identifies the possibilities of coping with change interaction with tool support. Section 6 discusses related work. Section 7 presents conclusions and directions of further work.

Changes as Crosscutting Requirements

A change is initiated by a change request made by a user or some other stakeholder. Change requests are specified in domain notions similarly as initial requirements are. A change request tends to be focused, but it often consists of several different-though usually interrelated-requirements that specify actual changes to be realized. By decomposing a change request into individual changes and by abstracting the essence out of each such change while generalizing it at the same time, a change type applicable to a range of the applications that belong to the same domain can be defined.

We will introduce our approach by a series of examples on a common scenario. 3 Suppose a merchant who runs his online music shop purchases a general affiliate marketing software [START_REF] Goldschmidt | Strategic Affiliate Marketing[END_REF] to advertise at third party web sites denoted as affiliates. In a simplified schema of affiliate marketing, a customer visits an affiliate's site which refers him to the merchant's site. When he buys something from the merchant, the provision is given to the affiliate who referred the sale. A general affiliate marketing software enables to manage affiliates, track sales referred by these affiliates, and compute provisions for referred sales. It is also able to send notifications about new sales, signed up affiliates, etc.

The general affiliate marketing software has to be adapted (customized), which involves a series of changes. We will assume the affiliate marketing software is written in Java and use AspectJ, the most popular aspect-oriented language, which is based on Java, to implement some of these changes.

In the AspectJ style of aspect-oriented programming, the crosscutting concerns are captured in units called aspects. Aspects may contain fields and methods much the same way the usual Java classes do, but what makes possible for them to affect other code are genuine aspect-oriented constructs, namely: pointcuts, which specify the places in the code to be affected, advices, which implement the additional behavior before, after, or instead of the captured join point (a well-defined place in the program execution)-most often method calls or executions-and inter-type declarations, which enable introduction of new members into types, as well as introduction of compilation warnings and errors.

Domain Specific Changes

One of the changes of the affiliate marketing software would be adding a backup SMTP server to ensure delivery of the notifications to users. Each time the affiliate marketing software needs to send a notification, it creates an instance of the SMTPServer class which handles the connection to the SMTP server.

An SMTP server is a kind of a resource that needs to be backed up, so in general, the type of the change we are talking about could be denoted as Introducing Resource Backup. This change type is still expressed in a domain specific way. We can clearly identify a crosscutting concern of maintaining a backup resource that has to be activated if the original one fails and implement this change in a single aspect without modifying the original code: The around() advice captures constructor calls of the SMTPServer class and their arguments. This kind of advice takes complete control over the captured join point and its return clause, which is used in this example to control the type of the SMTP server being returned. The policy is implemented in the getSMTPServerBackup() method: if the original SMTP server can't be connected to, a backup SMTP server class instance is created and returned.

Generally Applicable Changes

Looking at this code and leaving aside SMTP servers and resources altogether, we notice that it actually performs a class exchange. This idea can be generalized and domain details abstracted out of it bringing us to the Class Exchange change type [START_REF] Bebjak | Evolution of web applications with aspectoriented design patterns[END_REF] which is based on the Cuckoo's Egg aspect-oriented design pattern [START_REF] Miles | AspectJ Cookbook[END_REF]:

public

Applying a Change Type

It would be beneficial if the developer could get a hint on using the Cuckoo's Egg pattern based on the information that a resource backup had to be introduced. This could be achieved by maintaining a catalog of changes in which each domain specific change type would be defined as a specialization of one or more generally applicable changes.

When determining a change type to be applied, a developer chooses a particular change request, identifies individual changes in it, and determines their type. Figure 1 shows an example situation. Domain specific changes of the D1 and D2 type have been identified in the Change Request 1. From the previously identified and cataloged relationships between change types, we would know their generally applicable change types are G1 and G2. A generally applicable change type can be a kind of an aspect-oriented design pattern (consider G2 and AO Pattern 2). A domain specific change realization can also be complemented by an aspect-oriented design patterns, which is expressed by an association between them (consider D1 and AO Pattern 1).

Each generally applicable change has a known domain independent code scheme (G2's code scheme is omitted from the figure). This code scheme has to be adapted to the context of a particular domain specific change, which may be seen as a kind of refinement (consider D1 Code and D2 Code).

Catalog of Changes

To support the process of change selection, the catalog of changes is needed in which the generalization-specialization relationships between change types would be explicitly established. The following list sums up these relationships between change types we have identified in the web application domain (the domain specific change type is introduced first):

-One Way Integration: Performing We have already described Introducing Resource Backup and the corresponding generally applicable change, Class Exchange. Here, we will briefly describe the rest of the domain specific change types we identified in the web application domain along with the corresponding generally applicable changes. The generally applicable change types are described where they are first mentioned to make the sequential reading of this section easier. A real catalog of changes would require to describe each change type separately.

Integration Changes

Web applications often have to be integrated with other systems. Suppose that in our example the merchant wants to integrate the affiliate marketing software with the third party newsletter which he uses. Every affiliate should be a member of the newsletter. When an affiliate signs up to the affiliate marketing software, he should be signed up to the newsletter, too. Upon deleting his account, the affiliate should be removed from the newsletter, too. This is a typical example of the One Way Integration change type [START_REF] Bebjak | Evolution of web applications with aspectoriented design patterns[END_REF]. Its essence is the one way notification: the integrating application notifies the integrated application of relevant events. In our case, such events are the affiliate sign-up and affiliate account deletion.

Such integration corresponds to the Performing Action After Event change type [START_REF] Bebjak | Evolution of web applications with aspectoriented design patterns[END_REF]. Since events are actually represented by methods, the desired action can be implemented in an after advice: The after advice executes after the captured method calls. The actual action is implemented as the performAction() method called by the advice.

To implement the one way integration, in the after advice we will make a post to the newsletter sign-up/sign-out script and pass it the e-mail address and name of the newly signed-up or deleted affiliate. We can seamlessly combine multiple one way integrations to integrate with several systems.

The Two Way Integration change type can be seen as a double One Way Integration. A typical example of such a change is data synchronization (e.g., synchronization of user accounts) across multiple systems. When a user changes his profile in one of the systems, these changes should be visible in all of them. In our example, introducing a forum for affiliates with synchronized user accounts for affiliate convenience would represent a Two Way Integration.

Introducing User Rights Management

In our affiliate marketing application, the marketing is managed by several coworkers with different roles. Therefore, its database has to be updated from an administrator account with limited permissions. A limited administrator should not be able to decline or delete affiliates, nor modify the advertising campaigns and banners that have been integrated with the web sites of affiliates. This is an instance of the Introducing User Rights Management change type. Suppose all the methods for managing campaigns and banners are located in the campaigns and banners packages. The calls to these methods can be viewed as a region prohibited to the restricted administrator. The Border Control design pattern [START_REF] Miles | AspectJ Cookbook[END_REF] enables to partition an application into a series of regions implemented as pointcuts that can later be operated on by advices [START_REF] Bebjak | Evolution of web applications with aspectoriented design patterns[END_REF]: What we actually need is to substitute the calls to the methods in the region with our own code that will let the original methods execute only if the current user has sufficient rights. This can be achieved by applying the Method Substitution change type which is based on an around advice that enables to change or completely disable the execution of methods. The following pointcut captures all method calls of the method called method() belonging to the TargetClass class:

pointcut
pointcut allmethodCalls(TargetClass t, int a):

call(ReturnType TargetClass.method(..)) && target(t) && args(a);

Note that we capture method calls, not executions, which gives us the flexibility in constraining the method substitution logic by the context of the method call.

The pointcut call(ReturnType TargetClass.method(..)) captures all the calls of TargetClass.method(). The target() pointcut is used to capture the reference to the target class. The method arguments can be captured by an args() pointcut. In the example code above, we assume method() has one integer argument and capture it with this pointcut.

The following example captures the method() calls made within the control flow of any of the CallingClass methods: This embraces the calls made directly in these methods, but also any of the method() calls made further in the methods called directly or indirectly by the CallingClass methods.

By making an around advice on the specified method call capturing pointcut, we can create a new logic of the method to be substituted:

User Interface Restriction

It is quite annoying when a user sees, but can't access some options due to user rights restrictions. This requires a User Interface Restriction change type to be applied. We have created a similar situation in our example by a previous change implementation that introduced the restricted administrator (see Sect. 3.2). Since the restricted administrator can't access advertising campaigns and banners, he shouldn't see them in menu either.

Menu items are retrieved by a method and all we have to do to remove the banners and campaigns items is to modify the return value of this method. This may be achieved by applying a Additional Return Value Checking/Modification change which checks or modifies a method return value using an around advice: In the around advice, we assign the original return value to the private attribute of the aspect. Afterwards, this value is processed by the processOutput() method and the result is returned by the around advice.

public

Grid Display Changes

It is often necessary to modify the way data are displayed or inserted. In web applications, data are often displayed in grids, and data input is usually realized via forms. Grids usually display the content of a database table or collation of data from multiple tables directly. Typical changes required on grid are adding columns, removing them, and modifying their presentation. A grid that is going to be modified must be implemented either as some kind of a reusable component or generated by row and cell processing methods. If the grid is hard coded for a specific view, it is difficult or even impossible to modify it using aspect-oriented techniques.

If the grid is implemented as a data driven component, we just have to modify the data passed to the grid. This corresponds to the Additional Return Value Checking/Modification change (see Sect. 3.3). If the grid is not a data driven component, it has to be provided at least with the methods for processing rows and cells.

Adding Column to Grid can be performed after an event of displaying the existing columns of the grid which brings us to the Performing Action After Event change type (see Sect. 3.1). Note that the database has to reflect the change, too. Removing Column from Grid requires a conditional execution of the method that displays cells, which may be realized as a Method Substitution change (see Sect. 3.2).

Alterations of a grid are often necessary due to software localization. For example, in Japan and Hungary, in contrast to most other countries, the surname is placed before the given names. The Altering Column Presentation in Grid change type requires preprocessing of all the data to be displayed in a grid before actually displaying them. This may be easily achieved by modifying the way the grid cells are rendered, which may be implemented again as a Method Substitution (see Sect. [START_REF] Charfi | Reliable, secure, and transacted web service compositions with AO4BPEL[END_REF]

Input Form Changes

Similarly to tables, forms are often subject to modifications. Users often want to add or remove fields from forms or perform additional checks of the form inputs, which constitute Adding Fields to Form, Removing Fields from Form, and Introducing Additional Constraint on Fields change types, respectively. Note that to be possible to modify forms using aspect-oriented programming they may not be hard coded in HTML, but generated by a method. Typically, they are generated from a list of fields implemented by an enumeration. Going back to our example, assume that the merchant wants to know the genre of the music which is promoted by his affiliates. We need to add the genre field to the generic affiliate sign-up form and his profile form to acquire the information about the genre to be promoted at different affiliate web sites. This is a change of the Adding Fields to Form type. To display the required information, we need to modify the affiliate table of the merchant panel to display genre in a new column. This can be realized by applying the Enumeration Modification change type to add the genre field along with already mentioned Additional Return Value Checking/Modification in order to modify the list of fields being returned (see Sect. 3.3).

The realization of the Enumeration Modification change type depends on the enumeration type implementation. Enumeration types are often represented as classes with a static field for each enumeration value. A single enumeration value type is represented as a class with a field that holds the actual (usually integer) value and its name. We add a new enumeration value by introducing the corresponding static field: public aspect NewEnumType { public static EnumValueType EnumType.NEWVALUE = new EnumValueType(10, "<new value name>"); }

The fields in a form are generated according to the enumeration values. The list of enumeration values is typically accessible via a method provided by it. This method has to be addressed by an Additional Return Value Checking/-Modification change.

An Additional Return Value Checking/Modification change is sufficient to remove a field from a form. Actually, the enumeration value would still be included in the enumeration, but this would not affect the form generation.

If we want to introduce additional validations on the form input data to the system without built-in validation, an Additional Parameter Checking change can be applied to methods that process values submitted by the form. This change enables to introduce an additional check or constraint on method arguments. For this, we have to specify a pointcut that will capture all the calls of the affected methods along with their context similarly as in Sect. 3.2. Their arguments will be checked by the check() method called from within an around advice which will throw WrongParamsException if they are not correct: Adding a new validator to a system that already has built-in validation is realized by simply adding it to the list of validators. This can be done by implementing Performing Action After Event change (see Sect. 3.1), which would implement the addition of the validator to the list of validators after the list initialization.

Changing a Change

Sooner or later there will be a need for a change whose realization will affect some of the already applied changes. There are two possibilities to deal with this situation: a new change can be implemented separately using aspect-oriented programming or the affected change source code could be modified directly. Either way, the changes remain separate from the rest of the application.

The possibility to implement a change of a change using aspect-oriented programming and without modifying the original change is given by the aspectoriented programming language capabilities. Consider, for example, advices in AspectJ. They are unnamed, so can't be referred to directly. The primitive pointcut adviceexecution(), which captures execution of all advices, can be restricted by the within() pointcut to a given aspect, but if an aspect contains several advices, advices have to be annotated and accessed by the @annotation() pointcut, which was impossible in AspectJ versions that existed before Java was extended with annotations.

An interesting consequence of aspect-oriented change realization is the separation of crosscutting concerns in the application which improves its modularity (and thus makes easier further changes) and may be seen as a kind of aspectoriented refactoring. For example, in our affiliate marketing application, the integration with a newsletter-identified as a kind of One Way Integration-actually was a separation of integration connection, which may be seen as a concern of its own. Even if these once separated concerns are further maintained by direct source code modification, the important thing is that they remain separate from the rest of the application. Implementing a change of a change using aspectoriented programming and without modifying the original change is interesting mainly if it leads to separation of another crosscutting concern.

Evaluation and Tool Support Outlooks

We have successfully applied the aspect-oriented approach to change realization to introduce changes into YonBan, a student project management system developed at Slovak University of Technology. It is based on J2EE, Spring, Hibernate, and Acegi frameworks. The YonBan architecture is based on the Inversion Of Control principle and Model-View-Controller pattern. We implemented the following changes in YonBan:

-Telephone number validator as Performing Action After Event -Telephone number formatter as Additional Return Value Checking/Modification -Project registration statistics as One Way Integration -Project registration constraint as Additional Parameter Checking/Modification -Exception logging as Performing Action After Event -Name formatter as Method Substitution No original code of the system had to be modified. Except in the case of project registration statistics and project registration constraint, which where well separated from the rest of the code, other changes would require extensive code modifications if they have had been implemented the conventional way.

We encountered one change interaction: between the telephone number formatter and validator. These two changes are interrelated-they would probably be part of one change request-so it comes as no surprise they affect the same method. However, no intervention was needed.

We managed to implement the changes easily even without a dedicated tool, but to cope with a large number of changes, such a tool may become crucial. Even general aspect-oriented programming support tools-usually integrated with development environments-may be of some help in this. AJDT (AspectJ Development Tools) for Eclipse is a prominent example of such a tool. AJDT shows whether a particular code is affected by advices, the list of join points affected by each advice, and the order of advice execution, which all are important to track when multiple changes affect the same code. Advices that do not affect any join point are reported in compilation warnings, which may help detect pointcuts invalidated by direct modifications of the application base code such as identifier name changes or changes in method arguments.

A dedicated tool could provide a much more sophisticated support. A change implementation can consist of several aspects, classes, and interfaces, commonly denoted as types. The tool should keep a track of all the parts of a change. Some types may be shared among changes, so the tool should enable simple inclusion and exclusion of changes. This is related to change interaction which is exhibited as dependencies between changes. A simplified view of change dependencies is that a change may require another change or two changes may be mutually exclusive, but the dependencies between changes could be as complex as feature dependencies in feature modeling and accordingly represented by feature diagrams and additional constraints expressed as logical expressions [START_REF] Vranić | Multi-paradigm design with feature modeling[END_REF] (which can be partly embedded into feature diagrams by allowing them to be directed acyclic graphs instead of just trees [START_REF] Filkorn | An approach for integrating analysis patterns and feature diagrams into model driven architecture[END_REF]).

Some dependencies between changes may exhibit only recommending character, i.e. whether they are expected to be included or not included together, but their application remains meaningful either way. An example of this are features that belong to the same change request. Again, feature modeling can be used to model such dependencies with so-called default dependency rules that may also be represented by logical expressions [START_REF] Vranić | Multi-paradigm design with feature modeling[END_REF].

Related Work

The work presented in this paper is based on our initial efforts related to aspectoriented change control [START_REF] Dolog | Representing change by aspect[END_REF] in which we related our approach to change-based approaches in version control. We identified that the problem with change-based approaches that could be solved by aspect-oriented programming is the lack of programming language awareness in change realizations.

In our work on the evolution of web applications based on aspect-oriented design patterns and pattern-like forms [START_REF] Bebjak | Evolution of web applications with aspectoriented design patterns[END_REF], we reported the fundamentals of aspectoriented change realizations based on the two level model of domain specific and generally applicable change types, as well as four particular change types: Class Exchange, Performing Action After Event, and One/Two Way Integration.

Applying feature modeling to maintain change dependencies (see Sect. 4) is similar to constraints and preferences proposed in SIO software configuration management system [START_REF] Conradi | Version models for software configuration management[END_REF]. However, a version model for aspect dependency management [START_REF] Pulvermüller | A version model for aspect dependency management[END_REF] with appropriate aspect model that enables to control aspect recursion and stratification [START_REF] Bodden | Avoiding infinite recursion with stratified aspects[END_REF] would be needed as well.

We tend to regard changes as concerns, which is similar to the approach of facilitating configurability by separation of concerns in the source code [START_REF] Fazekas | Facilitating configurability by separation of concerns in the source code[END_REF]. This approach actually enables a kind of aspect-oriented programming on top of a versioning system. Parts of the code that belong to one concern need to be marked manually in the code. This enables to easily plug in or out concerns. However, the major drawback, besides having to manually mark the parts of concerns, is that-unlike in aspect-oriented programming-concerns remain tangled in code.

Others have explored several issues generally related to our work, but none of this work aims at capturing changes by aspects. These issuse include database schema evolution with aspects [START_REF] Green | An aspect-oriented framework for schema evolution in object-oriented databases[END_REF] or aspect-oriented extensions of business processes and web services with crosscutting concerns of reliability, security, and transactions [START_REF] Charfi | Reliable, secure, and transacted web service compositions with AO4BPEL[END_REF]. Also, an increased changeability of components implemented using aspect-oriented programming [START_REF] Kvale | A case study on building COTS-based system using aspect-oriented programming[END_REF][START_REF] Li | A case study on improving changeability of COTS-based system using aspect-oriented programming[END_REF][START_REF] Papapetrou | Aspect-oriented programming for a component based real life application: A case study[END_REF] and aspect-oriented programming with the frame technology [START_REF] Loughran | Supporting product line evolution with framed aspects[END_REF], as well as enhanced reusability and evolvability of design patterns achieved by using generic aspect-oriented languages to implement them [START_REF] Rho | Independent evolution of design patterns and application logic with generic aspects-a case study[END_REF] have been reported. The impact of changes implemented by aspects has been studied using slicing in concern graphs [START_REF] Khan | Analysing requirements dependencies and change impact using concern slicing[END_REF].

While we do see potential of configuration and reconfiguration of applications, our work does not aim at automatic adaptation in application evolution, such as event triggered evolutionary actions [START_REF] Molina-Ortiz | An author tool based on SEM-HP for the creation and evolution of adaptive hypermedia systems[END_REF], evolution based on active rules [START_REF] Daniel | Combining conceptual modeling and active rules for the design of adaptive web applications[END_REF], or adaptation of languages instead of software systems [START_REF] Kollár | Functional approach to the adaptation of languages instead of software systems[END_REF].

Conclusions and Further Work

In this paper, we have described our approach to change realization using aspectoriented programming. We deal with changes at two levels distinguishing between domain specific and generally applicable change types. We introduced change types specific to web application domain along with corresponding generally applicable changes. We also discussed consequences of having to implement a change of a change.

Although the evaluation of the approach has shown the approach can be applied even without a dedicated tool support, we believe that tool support is important in dealing with change interaction, especially if their number is high. Our intent is to use feature modeling. With changes modeled as features, change dependencies could be tracked through feature dependencies. For further evaluation, it would be interesting to expand domain specific change types to other domains like service-oriented architecture for which we have available suitable application developed in Java [START_REF] Rozinajová | Bridging the gap between service-oriented and object-oriented approach in information systems development[END_REF].

Fig. 1 .

 1 Fig. 1. Generally applicable and domain specific changes.

  public aspect PerformActionAfterEvent { pointcut methodCalls(TargetClass t, int a): . . .; after(/ * captured arguments * /): methodCalls(/ * captured arguments * /) { performAction(/ * captured arguments * /); } private void performAction(/ * arguments * /) { / * action logic * / } }

  pointcut specificmethodCalls(TargetClass t, int a): call(ReturnType TargetClass.method(a)) && target(t) && args(a) && cflow(call( * CallingClass. * (..)));

  public aspect AdditionalParameterChecking { pointcut methodCalls(TargetClass t, int a): . . .; ReturnType around(/ * arguments * /) throws WrongParamsException: methodCalls(/ * arguments * /) { check(/ * arguments * /); return proceed(/ * arguments * /); } void check(/ * arguments * /) throws WrongParamsException { if (arg1 != <desired value>) throw new WrongParamsException(); } }

  class AnotherClass extends MyClass {

	. . .
	}
	public aspect MyClassSwapper {
	public pointcut myConstructors(): call(MyClass.new());
	Object around(): myConstructors() {
	return new AnotherClass();
	}
	}

  .2):

	public aspect ChangeUserNameDisplay {
	pointcut displayCellCalls(String name, String value):
	call(void UserTable.displayCell(..)) || args(name, value);
	around(String name, String value): displayCellCalls(name, value) {
	if (name == "<the name of the column to be modified>") {
	. . . // display the modified column
	} else {
	proceed(name, value);
	}
	}
	}

This is an adapted scenario published in our earlier work[START_REF] Bebjak | Evolution of web applications with aspectoriented design patterns[END_REF].

Acknowledgements The work was supported by the Scientific Grant Agency of Slovak Republic (VEGA) grant No. VG 1/3102/06. We would like to thank Michael Grossniklaus for sharing his observations regarding our work with us.


Petr Weiss
email: weiss@fit.vutbr.cz

Service-Based Realization of Business Processes Driven by Control-Flow Patterns

Keywords: Service-Oriented Architecture, Service-Oriented Analysis and Design, Business Process Modeling, Service Specification, Composite Services

This paper deals with Service-Oriented Analysis and Design (SOAD). SOAD comprises requirements elicitation, analysis of the requirements to identify services and business processes and finally implementation of the services and processes. It is a heterogeneous approach that combines a number of well-established practices. The key question in SOAD is how to integrate the practices to model a true service-oriented system with all its requirements. The approach presented in this paper helps to bridge the semantic gap between business requirements and IT architecture by using a method for transformation of business process diagrams into service diagrams. The service diagrams describe how the process is realized by using services. In details, the method transforms diagrams denoted in Business Process Modeling Notation into a set of UML diagrams. The principle of the method is demonstrated in an example.

Introduction

Service-Oriented Architecture (SOA) is a complex solution for analysis, design, maintenance and integration of enterprise applications that are based on services. Services are autonomous platform-independent entities that provide one or more functional capabilities via their interfaces. In other words, SOA is an architectural style for aligning business and IT architectures. If a new service is considered it has to fulfill both business requirements and the fundamental SOA properties such as loose coupling, service independence, stateless and reusability [START_REF] Erl | Service-Oriented Architecture: Concepts, Technology, and Design[END_REF]. It means that Service-Oriented Analysis and Design (SOAD) should focus not only on services but also on business requirements.

This paper introduces an approach for integration between Business Process Modeling and Service Modeling. The approach is based on a technique that transforms business process models into models of service orchestration by using control-flow patterns. Service orchestration represents realization of a business process. To be more specific, business process diagrams are denoted in Business Process Modeling Notation (BPMN) and service orchestrations are modeled by means of UML.

The reminder of this paper is organized as follows. Section 2 containes an overview of main approaches that are relevant to the subject. Section 3 introduces the concept of primitive and composite services and presents the idea of service specification. Next, in Section 4 the transformation rules are explained. They are illustrated with an examplary business process in Section 5. Finally, Section 6 discusses advantages and disadvantages of our approach compared with the approaches presented in Section 2. Conclusions and future work are contained in Section 7.

Related work

The work presented in this paper has been influenced by several different proposals. First of all, we should mention UML profiles for SOA. [START_REF] Amir | A UML profile for service oriented architectures[END_REF] introduced a simple UML profile that is intended to use for modeling of web services. [START_REF] Johnston | UML 2.0 Profile for Software Services[END_REF] provided a well-defined profile for modeling of service-oriented solutions. In [START_REF] Ortiz | Toward UML Profiles for Web Services and their Extra-Functional Properties[END_REF] it is showed how services and their extra-functional properties can be modeled by using UML. The ideas presented in these approaches are a good starting point to model both the structural and the behavioral properties of services by means of UML. However, Service Modeling needs to take into account some additional aspects. Primarily, we have to know the connection between business requirements and functional capabilities of modeled services. [START_REF] Van Der Aalst | Advanced Workflow Patterns[END_REF] introduced 21 patterns that describe the behavior of a business process. Next, [START_REF] White | Process Modeling Notations and Workflow Patterns[END_REF] showed how these patterns can be modeled by means of UML and BPMN. The author discussed the readability and technical properties of each model. Furthermore, [START_REF] Wohed | Pattern-based Analysis of BPMN -An extensive evaluation of the Control-flow, the Data and the Resource Perspectives[END_REF] analyzed using of Control-flow, Data and Resource patterns in BPMN, UML and BPEL. The relationship between BPMN and UML is also introduced in [START_REF] Amsden | Business services modeling: Integrating WebSphere Business Modeler and Rational Software Modeler[END_REF]. The BPMN is defined in [START_REF]Object Management Group: Business Process Modeling Notation (BPMN) Specification[END_REF]. The author describes a high-level mapping of a business process to UML 2.0 Business Service Model (BSM) that represents service specification between business clients and information technology implementers. Lastly, [START_REF] Murzek | Business Process Model Transformation Issues -The Top 7 Adversaries Encountered at Defining Model Transformations[END_REF] addressed main problems of transformation between business process modeling languages. Particularly, ADONIS Standard Modeling Language, BPMN, Eventdriven Process Chains and UML 2.0 Activity Diagrams were mentioned.

Service specification. Primitive and composite services

Within this paper, each service is modeled as a stereotype service that extends the UML class Component [START_REF]Object Management Group: UML Superstructure Specification, version 2.0[END_REF]. This concept is introduced in [START_REF] Weiss | Modeling of Services and Service Collaboration in UML 2.0[END_REF]. Every service interacts with its environment via interfaces. During an interaction, service can play two different roles: service provider or service consumer. These two roles are distinguished in the service model by means of a port. The provider port (stereotyped as <<prov>>) of a service implements interfaces that specify functional capabilities provided to possible consumers of the service, while the consumer port (stereotyped as <<cons>>) requires interfaces of defined services to consume their functionality.

In our approach, we prefer a flat model to a hierarchical model of the serviceoriented architecture. For this purpose we introduce two types of services: primitive services and composite services. Primitive services are derived from service invocation tasks, and are responsible for providing functional capabilities defined by a task. A composite service is an access point to an orchestration of other primitive or composite services. It means that a composite service does not enclose its internal services participating in the orchestration and does not delegate its interfaces to them. It only represents a controller of those services, i.e. the composite service communicates with its neighboring services at the same level of hierarchy in the producer-consumer relationship. The flat model provides better reusability of services, because the context of a service is defined only by its implemented (i.e. provided) and required interfaces, not by its position in the hierarchy.

A specification of each service includes description of its architecture and internal behavior. The architecture is defined by interfaces that the service provides and requires. Each service provides at least one interface at the consumer port. Such an interface involves service operations that realize the functional capability of the service. Parameters of these operations describe format of an incoming message. The internal behavior describes which actions are executed when an operation of the service is invoked. In the case of a composite service, the behavior describes an orchestration that this service provides. It means which actions have to be performed in order to execute the corresponding orchestration.

The transformation

As mentioned above, SOAD provides techniques required for identification, specification and realization of services and service flows. It is obvious that the initial activity in the development of a new SOA-based system is the service identification. It consists of a combination of top-down, bottom-up, and middle-out techniques of domain decomposition of legacy systems, existing asset analysis, and goal-service modeling. The result of the service identification is a set of candidate services. In the context of this paper, the service identification is a prerequisite for the transformation. Since this paper is mainly focused on the transformation, the details about the service identification are omitted here. More about service identification can be found in [START_REF] Inaganti | Service Identification: BPM and SOA Handshake[END_REF].

The transformation consists of two basic steps. The objective of the first step is to identify which tasks from the Business Process Diagram (BPD) represent service invocations and therefore will be transformed into services. This decision takes into account such aspects as which service providers provide which services, Quality of Service (QoS) requirements, security issues, etc. [START_REF] Arsanjani | Service-oriented modeling and architecture: How to identify, specify, and realize services for your SOA[END_REF] and is closely related with the results of the service identification. Such an analysis is beyond the scope of this paper.

The second step, the transformation process itself, generates an orchestration of the identified services. The orchestration represents realization of the given business process. The transformation is based on transformation rules. Each rule defines how to transform a control-flow pattern (eventually basic BPMN element) into an UML service pattern. Each service pattern is described by its structure and by a communication protocol. Due to the limitation of space in this paper, only basic rules are introduced (see Table 1 to Table 3). Some rules include context information that is needed to understand the using of the rule. For this purpose, the actual transformation step is inserted into a red-line-bordered area. To distinguish a primitive service from a composite one, the convention used in this paper is to name a primitive service with a capital letter (e.g. serviceA) and a composite service with a number (e.g. service1). Besides, some BPD elements can by transformed in more than one way (see e.g. Table 2). 1 contains transformation rules for basic BPD elements. The first row of the table depicts a rule for a pool. A pool represents a business entity in the given process. Graphically, a pool is a container for the control flow between BPD elements. Each pool in a BPD is mapped to a corresponding composite service in a service diagram. The composite service is then responsible for the execution of that part of a business process that is modeled within the pool. Hereafter, we assume that all BPD elements belong to the processA pool, unless otherwise indicated.

A pool can contain one or more lanes. Lanes model internal sub-partitions (usually called roles) within a business entity. These roles encapsulate a given part of the BP and ensure its execution. In the context of service diagrams, this relationship is modeled by means of packages. Next, a message start event is mapped to a message (implicitly asynchronous) and a message end event is mapped to a replay.

The last row in Table 1 contains a transformation rule for a single service invocation task. Generally, a task represents some unit of work performed in a process that is not further modeled. A service task is a task that provides some sort of service. Graphically, it is used to depict a service task with a small sprocket-symbol in the upper right corner to distinguish a service task from a task. A service task in a business process diagram is represented by a primitive service in a service diagram. As mentioned above, Task1 (from Table 1) belongs to processA. It means that Task1 is executed within the scope of processA. As a result, a new service1 is created and connected to serviceA. This is made by means of an assembly connector. The connector defines that service1 provides some capabilities that serviceA requires. In this case, it means that service1 is controlled by serviceA. In the other words, serviceA is an access point to service1. The corresponding sequence diagram describes details of the communication between serviceA and service1. As we can see, the invocation of Task1 is modeled by means of an incoming message to service1.

In Table 2, it is shown how to transform a sequence of two service invocation tasks. The transformation can be done in three different ways. The first one is to add a new primitive service to the existing service diagram and to specify the communication protocol in the corresponding sequence diagram (see Table 1, the first row). The alternative way is to create a new primitive service and a new composite service. These two services will be added to the service diagram as follows (see Table 2, the second row): service2 is the primitive service that represents Task2, and serviceB is the composite service that acts as a gate to service2 and service1. Hence, service2 is connected to serviceB and service1 has to be switched to serviceB if it was connected to another service before this transformation step. Interactions among these services are depicted in the sequence diagram. Lastly, the sequence of two service tasks can be transformed into a single primitive service. It is achieved through adding a new interface to the provider port of the existing primitive service and connecting this interface to the corresponding composite service. Hence, it follows that such a service provides functional capabilities that correspond to both of the tasks. When the service is invoked, the capability is chosen according to the message that is sent to the service. See Table 2 (the third row) for details. Generally, the first rule is usually used when we need to create a new standalone service. The second rule is used when we need to control the primitive services for some reason, i.e. because of QoS or security issues. If we want to use an existing service with only some modifications, we can apply the third transformation rule. Transformation rules for passing of data in a BPD are in Table 3. In this case, a data object is sent from one task to another, via a sequence flow. The first row describes the transformation of a general data passing. As we can see in the sequence diagram, the composite service is responsible for forwarding data from one primitive service to the another one. This rule can be used also for tasks that are not adjacent to each other in a BPD. The alternative rule (the second row) can be used only for two adjacent service tasks. In this case, service1 just produces data that is needed to pass to service2. For this purpose, service1 has to be switched directly to service2 if it has been connected to another service before this transformation step. The sequence diagram then shows details of the communication among these services. At first, serviceA invokes service2. After that, service2 calls service1 and waits for the data. As soon as the data is passed, service2 can complete its processing and send the result message back to serviceA.

Example

Figure 1 shows an exemplary "Purchase Order" business process model. This example is adopted from [START_REF]Object Management Group: UML Profile and Metamodel for Services (UPMS), Request For Proposal[END_REF]. As we can see, there are three roles, which are responsible for realization of the "Purchase Order" process: "Invoicing", "Shipping" and "Scheduling". Processing starts by receiving a purchase order message. Afterwards, the "Invoicing" role calculates an initial price. This price is not yet complete, because the total price depends on where the products are produced and the amount of the shipping cost. In parallel, the "Shipping" role determines when the products will be available and from what locations. At the same time, the process requests shipping schedule from the "Scheduling" role. After the shipping information is known, the complete price can be evaluated. Finally, when the complete price and shipping schedule are available, the invoice can be completed and sent to the customer.

In this example, we assume that following tasks (from Figure 1) were identified as service invocation tasks: "Initiate Price Calculation", "Complete Price Calculation", "Request Shipping" and "Request Production Scheduling". We can generate a service orchestration (see Figure 2) from this BPD by using the transformation rules mentioned in Section 4. The orchestration is composed from one composite and three primitive services. The composite service -the PurchaseOrder service -represents the business process itself. This service controles the rest of following primitive services. The PriceCalculation service provides two interfaces (i.e. two functional capabilities) iInitialPrice and iTotalPrice according to the "Initiate Price Calculation" and "Complete Price Calculation" tasks. Similarly, Production-Scheduling and Shipping provide functional capabilities specified by "Request Production Scheduling" and "Request Shipping", respectively. Figure 3 depicts the service topology, which belongs to the orchestration.

In Figure 2, we can also see that the PurchaseOrder service provides the iAsyncReplay interface at its consumer port. Each service that enables asynchronous communication has to implement this auxiliary interface. Consumed services use this interface to send replies back to the consumer.

As a composite service, the PurchaseOrder service is responsible to keep its subordinate services independent and stateless. This is done by controlling of passing of data between its subordinate services. The principle can be shown on the collaboration between PurchaseOrder and PriceCalculation (see Figure 4). In order to complete the invoice, the price has to be calculated. Consequently, the PurchaseOrder service requests the PriceCalculation service. PriceCalculation calculates the initial price and returns it to PurchaseOrder. PriceCalculation does not store the calculated price for later use, i.e. it does not hold any state information. When the service is invoked again (in order to calculate the final price), its initial state has to be set by sending of the initial price.

Because this paper deals mainly with the issue of generating models of service orchestration from a BPD, it is payed less attention to specify single services. The details about messages, which are being passed between services, and details about architectures of every single one service mentioned in this example can be found in [START_REF] Rychly | Modeling Of Service Oriented Architecture: From Business Process To Service Realisation[END_REF].

Discussion

The transformation technique presented in this paper is motivated by several approaches introduced in Section 2, especially by [START_REF] White | Process Modeling Notations and Workflow Patterns[END_REF], [START_REF] Wohed | Pattern-based Analysis of BPMN -An extensive evaluation of the Control-flow, the Data and the Resource Perspectives[END_REF] and [START_REF] Inaganti | Service Identification: BPM and SOA Handshake[END_REF]. Compared to these approaches, the technique proposed in this paper is primarily focused on realization of business processes rather than on modeling of business processes by means of UML. [START_REF] Amsden | Business services modeling: Integrating WebSphere Business Modeler and Rational Software Modeler[END_REF] provides a method for integrating Business Process Modeling and Object Modeling by treating each business process as a contract. The contract is a mediator between business clients and IT implementers. It specifies service providers playing roles in a collaboration fulfilling some business rules in order to achieve some business goals. Our technique follows this method by describing how to implement the business process by services in the context of SOA.

[10] proposes a similar concept to our approach. However, that concept does not provide any description of the relation between business process diagrams and UML models. What is more, it contains a number of incorrectness. The most significant one is that the stateless of services (the fundamental SOA principle) is ignored. Services are designed in such a way that they store data affecting their functionality between two single incoming requests. Our approach solves this problem by using a composite service (see Section 3 and 5). Furthermore, in our approach, services' interfaces are restricted to provide only one functionality. Regardless, it is possible to implement services with more interfaces (i.e. with more functional capabilities), but the interfaces have to provide independent functionality. This allows to add, remove or alter any capability, which is provided by the service, without large modifications in the service specification. This provide better reusability and leads to easy extensibility of modeled services. This paper concerns Service-Oriented Analysis and Design, especially integration between Business Process Modeling and Service Modeling. We outlined a transformation technique that defines how a business process should be transformed into an orchestration of services and how the services should collaborate to fulfill the business goals. The transformation is based on control-flow patterns and is designed in conformity with fundamental SOA principles such as loose coupling, service independence, stateless and reusability. Some of these features are novel and have not been integrated into existing service-oriented modeling methods.

The presented ideas are a part of a greater project, which deals with modeling and formal specification of SOA and underlying component-based systems. The approach, which is presented in this paper, is aimed at modeling of highlevel-abstract layers of the SOA hierarchy. The future work will focus on formal description of the proposed transformation and on an integration with formal component models. This allows formal verification of a whole modeled system (e.g. tracing of changes in a business process model to the changes in components' structure). Furthermore, the formal description of the transformation allows validation of the generated service orchestration. Besides, the ongoing research includes design of additional transformation rules, especially rules for business patterns based on gateways and events, and applying the transformation in a real-world case study.

Fig. 1 .

 1 Fig. 1. BPMN model of the Purchase Order process.

Fig. 2 .

 2 Fig. 2. The derived service orchestration.

Fig. 3 .

 3 Fig. 3. The service topology.

Fig. 4 .

 4 Fig. 4. The behavior of the PurchaseOrder service.

Table 1 .

 1 Transformation rules for basic BPMN elements.

	BP pattern	Service pattern	Communication protocol
			None
			None
		None

Table

Table 2 .

 2 Transformation rules for the Sequence Pattern.

	BP pattern	Service pattern	Communication protocol

Table 3 .

 3 Transformation rules for the Data-Passing Pattern.

	BP pattern	Service pattern	Communication protocol
		None