Research conceptual challenges

Formal methods, modelling approaches, evaluation techniques, architecture description languages, architectural styles, and design patterns are different aspects of software develop- ment that contribute to software architecture maturity, either totally or partially. In order to understand the automation mechanisms and architecture evaluation, we need to integrate the necessary and useful knowledge as well as describe the proper methods of these development aspects.

“We must now try to find out how we should go about getting a good fit. Where do we find it? What is the characteristic of processes which create fit successfully?” (Alexander[1964]).

It is substantial, one understood the relationships between the aforementioned points, and to formulate necessary aspects of SA. In order to help to evaluate the architecture accurately, and to automate the evaluation process. It is essential but complicated, because each aspect of the topics mentioned above is a large and growing area of research that keeps producing new

ideas, approaches and techniques. At the same time, researchers in these areas sometimes do not see out of their area or over their discipline fences. That leaves them separated from others, decreases their opportunity of integrating different approaches from different areas/disciplines, decreases their chances of using existing knowledge, tools and approaches to produce new ideas and to conserve time. Open minds lead to new inventions and help researchers to cope with technological evolutions.

Furthermore, there are many architecture evaluation approaches. However, none of them have produced fully automated evaluation techniques for different quality attributes with ad- justment options. Different software architectures consist of different characteristics that could be totally different in their forms, relations and their level of abstraction, which makes architec- ture difficult to study and to evaluate automatically.

Dragging architecture from its abstraction level to lower levels for evaluation purposes is not a good idea and most times, when that it happens, it loses its advantage of beingthe software big

picturewith no unnecessary details,Clements et al.[2002a]. Software architects and developers

use patterns in practically in every aspect of the software developmental process.

The following points blend reasons from different fields that enable the SAE process to become more challenging:

1. Formal methods and languages are important in the evaluation and automation process, when using a novel developmental approach. Automation and new developmental ap- proaches, such as Model Driven Architecture (MDA), base processes on machines, com- pilers, and transformers. A more precise and formal instructive language input is therefore necessary for machines to understand before processing. Natural descriptive languages such as English, are expressive languages. Even-so, they are non-rigorous and non-formal, and they cannot be processed and interpreted by machines correctly. Good examples of nat- ural descriptive languages for software patterns are written in books published byGamma et al.[1995] andBuschmann et al.[1996]. However, Architecture Description Languages such as the ADL family, still have some level of formalities that are not yet fully devel- oped. Formalisation of models/patterns with architectural modelling and/or description languages is therefore functionally limited pending the full development, such asGarlan et al.[1997] work in (ACME Studio).

2. Model-driven methodologies are one way in which architecture evaluation can be auto- mated. However, these approaches are also currently still in development; understanding and applying them, for the purposes of this study, is another challenge.

3. Some quality attributes cannot be evaluated in a systematic manner within the context of the architecture (e.g., Understandability). This may be addressed in further researches on the subject.

4. Although various tools are available to describe architectures and patterns, map code, and evaluate architecture, these tools are limited in number and also mostly in the growing

2.6. RESEARCH CHALLENGES

stages (e.g., Alloy, ACMEStudio, Armani, ArchE, and Discotect).

5. Multiple terms exist that refer to the same patterns, the descriptions of which include col- loquial terms (e.g., some patterns included in Design of Patterns byGamma et al.[1995] and Pattern-Oriented Software Architecture (POSA-V1) byBuschmann et al.[1996]. This allows interpretations to vary and thus becomes an obstacle in patterns-tracing and doc- umentation. In this case, the issue can be resolved by applying standardised names and formalised descriptions.

On the other hand, regarding architectures in Artificial Intelligence (AI) particularly; there are five challenging points as follow:

1. Variations in terminologies between software engineers and artificial intelligence research groups with regard to architecture, add to the challenges.

2. In AI groups, the lack of definitive research focus on architecture and its evaluation are a big challenge. As a result, developing a common evaluation method that can be used in many different AI systems is difficult. I think it will be a great contribution to AI discipline if future research regarding evaluation methods can be channelled to the AI arena. Furthermore,Selman et al.[1996] presented two sub-problems that that support SA challengings in AI systems:

• First, mastering architecture and attention and, second, preferences and utility in modelling. The first is primarily involved with where the data regarding state utility originates, whose particular utility is optimised, and what the most practical utility model is when evaluating finite action sequences. In utility model architecture, vary- ing assumptions result in varying qualities (e.g. efficiencies).

• Second is primarily involved in the development of richer attention models, which can turn the analytic machinery of decision-theoretic inference into the task of problem- solving, while applying satisfactory decision-making. In any case, the opportunity exists for the application of these approaches to maximise the general configura- tion and nature of any architecture, which includes decisions regarding the result- gathering stage.

3. Also, one of the problems in self-adaptive systems (which considered AI systems), when it comes to modelling dimensions is defining models that can represent a wide range of system properties,Selman et al.[1996]. If the models are more precise, they become more effective in supporting decision processes and run-time analysis. This brings the need for classification and enumeration of dimensions used in modelling, in order, to acquire precise models; also to support runtime, reasoning, and decision-making. As a result, achieving self-adaptability and specific quality. This point takes us back to an earlier argument about how important it is to amalgamate different knowledge (modelling approaches, qualities evaluation, formal descriptions, etc.) in order to develop a richer evaluation model.

4. In addition, in these types of intelligent systems, one concern lies in the mapping of re- quirements onto architecture, which involves the utilisation of patterns that could fulfil the required quality terms. Also, challenges exist in the building of reference architectures for self-adaptive systems that tackles structural control loop arrangements and quality trade- offs.

5. An engineering challenge also exists in the development of evaluation approaches that are able to automatically identify unintended interactions and specific qualities, Cheng et al. [2009]. One solution to the aforementioned sub-problems in AI can be achieved with the automation of architecture evaluation models using standardised languages and mature tools if available. Furthermore, it will be a more beneficial and an intelligent model for architecture evaluation if it can be made to be self-optimising through adaptation of a dynamic architecture context.