Major architecture developments challenges and debates

2.6.2.1 General challenges influencing the architecture evaluation

In 2000, three important areas of software architecture advancement were mentioned by Garlan[2000]. These are: development of architecture description languages and tools, emer- gence of product line engineering and architectural standards, and codification and dissemina- tion of architectural design expertise. In addition, three factors that impact the development of software architecture have been introduced. It involves changing build versus buy balance (COTS), network-centric computing, and pervasive computing.

Further investigations into factors that influence “industrial practices of software architec- ture evaluation” were made by Babar et al.[2007]. It was discovered that; technical, socio- political, business, managerial and organisational factors had roles to play. To be a participant in their studies, one had to have a minimum of 5 years experience as a software architecture designer with an average number of 8 years experience of designing and evaluating software architecture in different industrial domains. Empirical evidence from research has confirmed that there were some influential factors to be considered in architecture evaluation.

Most important, the technical factors that could influence this research direction are: • Quality attributes being evaluated.

• Integration issues between evaluation model and other environments (e.g. systems to eval- uate).

• Representing and visualising architectures.

• The languages to be used and the availability of tools, (e.g. SysML language, Artisan tool) The practice of the product line engineering is still not common. Thus, we need to have a better understanding of the economics, processes, and objects that could help in the use of the product line approach to become successful. The product line approach requires different

2.6. RESEARCH CHALLENGES

development methods, which is an issue. When it comes to a single product approach, the evaluation of the architecture is based on the specifications of the product itself. This has made it easier to build several single products, which are independent from each other. Each architecture is based on the developmental environment and many assumptions,Garlan[2000].

This challenge makes the integration of different products, from different vendors, which can bridge the gaps between products without any mismatch in their architectures very difficult. As a result, the evaluation process of the end product integration (if we can make the integration) becomes harder. The general architecture evaluation method will allow evaluators to adjust the model to the required environment. This will allow them to evaluate any architecture through an automation process, which is not an impossible task, but we are still far from achieving this.

Architecture description language challenges:

Due to the popularity of box and line depictions for describing architecture designs, which employ non-formal notations leads to a number of problems, such as:

• Designs in this situation cannot be analysed to see if they meet the required set of QAs. • The architectural constraints that may have been observed at the beginning of the design

may not be implemented during the system development. Also, tools support is important:

The use of tools that support architectural languages and modelling techniques (e.g. ACME- Studio by Garlan, Rational Rose by IBM, and Artisan) has been provided to facilitate developers tasks. Utilisation of the tools involves, parsing, displaying, analysing and simulating archi- tectural descriptions. Thus it defines the importance of tool support in architectures and their evaluation.

The availability of good tools helps researchers to do more quality work with less time, also to blend-in some methods, frameworks, languages, and notations into one approach, if necessary; such as Artisan tool, which support several languages and architecture framework, as explained in future work section (Chapter 7).

Some researchers do care about the methodology and notations of a language during their development of any product, neglecting to pay attention to the tools that support their utilised language, which results in:

• Time wasted, so developing architecture description using tool that supports languages and models creation, is much faster.

• Product with no modifiability, especially if the language is not supported by any tool. • Loss of interest by other researchers, to develop and improve the existing product.

More information about ADLs can be found in Appendix B, Section B.3

At the same time, we should note that there is a difference between what researchers see as desirable and what can be observed from practice. For example, ADL provides tool support,

but there has been some proposals that focus on areas like analysis, refinement, and dynamism, Medvidovic et al.[2000].

Another challenge facing the SA and SAE are the limitations of some languages with no mechanism of integrating them. For example C2, Rapide, Wright and SADL can support archi- tectural analysis. In these areas, ADL has always left some facets unexplored and focused on a particular technique. This has led to the use of ACME as an architecture interchange language. In order to help during the interaction and instill cooperation between different ADLs and tools, thus filling the gaps. SADL and Rapide are the only tools that can provide support to refine archi- tectures across multiple levels of abstraction. SADL requires the mapping of constructs between the abstract and an architectural style, thus making its support limited. Currently, ACME can only provide visuals and conformance of the architectures.

It has been observed that, the ADLs available emphasise is on visuals and analysis of soft- ware architectures as compared to their refinement and dynamism. It is worth pointing out that they are still growing. The integration of architectural based-tools used in the architecture de- scription modelling and languages, standardisation of the notations, requirement elicitation, and evaluation methods are still considered as a major challenges facing SA description in gen- eral and ADLs development in particular.

2.6.2.2 Standardisation as a common problem in software architecture

There are common problems that impact the development of software architecture and its evaluation. This brings us to standardisation. Different and common architectural factors influ- ence the development and evaluation of software architecture today concentrating on standard- isations, which are:

• Commercial off-the-shelf products (COTS) versus the requirements satisfaction. • Integration of different products versus environment challenges.

• Major companies buying out small companies that face integration and tool challenges. Garlan[2000], proposed three solutions to the three challenging factors above. The solu- tions were as follows:

• Creation of industry standards (e.g. component based standards, UPDM). • High-level architecture standards (e.g. IEEE-42010, DoDAF, MoDAF). • Standardisation of notation and tools (e.g. UML, SysML, ADLs).

All his three solutions enforce standardisation in general for the architecture development process and evaluation while taking into account environmental challenges. For example, ac- cording toBabar et al.[2007] “Describing architectures is a big challenge. We use UML for this purpose, and UML tools evolved to have better integration with documentation packages like MS Word. Also, the survey reported byMalavolta et al.[2013], indicated the needs for better standardisation, integrability, and mature tools, in order to improve the description of SA and make its artefacts more useful in industry.