ARiA (A Framework to Perform Refactoring on the Software Architecture)
Performing refactoring on the SA is a good way to increase software quality before implementation. Identification of software pitfalls before implementation decreases the cost of development drastically. Avoiding the known bad smells in designing architecture and applying appropriate SA styles and patterns decreases the likelihood of project failure and increases the satisfaction of the stakeholders. Based on the above mentioned benefits, performing refactoring before going into implementation phase is quite advisable.
Performing refactoring after implementation may help in finding design bugs and can suggest styles and patterns useful for increasing the quality of the software. Applying a refactoring pattern on an implemented system is a hard task to do. This kind of process has to deal with the traceability of the architecture elements to the source code and can lead to large modifications to the source code, huge changes in documentation and so on.
Applying refactoring at the SA level is not as simple as the code level. The first problem one faces when performing refactoring on the SA is the lack of proper tools to support automatic or semi-automatic refactoring. The diversity of the domains and viewpoints for describing the SA increase the number of ADLs and the ways in which the SA can be described. One cannot realistically hope to design refactoring tools for all different ADLs. To deal with the diversity of ADLs, in this paper we set out to convert every ADL to a middle model and define the refactoring patterns and constraints of each pattern on that model. While it is possible that more than one ADL describe one domain, the properties of each domain are independent of the ADLs. Each of the ADLs with the same domain can be transformed to a UML Profile (middle model) which describes the properties of that domain. Using the patterns defined in that UML Profile, the refactoring process can then be performed on the SA.
The impact of SA refactoring on software qualities is wider than the impact of code refactoring. Each refactoring pattern affects some of software quality and sub-quality attributes. In this paper, we introduce a way to define the impact of each refactoring pattern on software quality and sub-quality attributes. A metric is used to measure the impact of refactoring patterns on each quality or sub-quality attribute. The fact that we do not have enough metrics to measure software quality attributes is troublesome. One important future work is to define new metrics to quantify different quality attributes. Refactoring goals describe the aim of the refactoring process. Applying a refactoring pattern which increases system security and decreases system performance where the refactoring goals prioritize performance increase, is not a good choice. Refactoring goals specify the importance of each quality and sub-quality attribute of the software. The refactoring goals should be taken into account when performing SA refactoring.
Each refactoring pattern has an added value to the project. We use W to specify this added value. This W is calculated by considering refactoring goals and the effect of the refactoring patterns on software quality attributes. The metrics measure the impacts of a refactoring pattern on a quality attribute. To homogenize the impact of each metric in calculating the value of W, we introduce the concept of metric normalization. The normal values are between -3 and 3. We assume that the values of the metrics grow linearly. This is not a good assumption for every metric, because some metrics exhibit not-linear behavior.
The aim of this framework is to provide a tool for performing automatic refactoring on the SA. Despite all the benefits that this framework provides, some critical challenges remain unsolved. Difficulties in describing patterns, bad smells and conditions using a particular language is the first challenge. The semantics of some patterns is written in natural languages, and it is hard to describe them using known languages (such as OCL). It is obvious that we should find a way to describe these patterns formally, if we want them in automatic analysis tools. The second challenge is the heterogeneity of the metrics. Our suggestion to overcome the problem of metric heterogeneities (Normalization of the metrics) is not applicable in the case of the non-linear metrics. In this situation a mapping table (between the real and normalized values) can be used. One of the other challenges is the small number of the metrics which can be used to measure the quality attributes with. The fourth challenge comes from transformation languages such as QVT and ATL. These languages do not carry out priority rules. Implementing the priority rules in the 3G languages (such as Java) decreases the flexibility and scalability and increase complexity of developing tools. However, we implement a priority mechanism in ARiA tool.