Brief Analysis of SA description methods

The architecture of any software application is an integral part of its design and deploy- ment.2Therefore, it is extremely important for any application to have well-defined descriptions outlining the architecture. Thus, the study and description of software architectures is necessary aspect of the software life cycle.

There are several different ways in which software architecture can be viewed depending upon the purpose and target audience.

There are three main methods for describing SA, as illustrated in Figure 2.3.

Figure 2.3: The three main methods for describing SA.

1. Informal methodsuses languages/notations such as textual, english language, and general purpose diagramming.

2. Semi-formal methodsuses languages/notations such as UML, and SysML. 3. Formal methodsuses languages/notations such as ADLs, and Z.

These methods are used to describe various kinds of software architectures in terms of its structure, behaviour, components, and the relationship between them. This section explores the ways in which each method of description differs from others. Also, it is to focus on the common formal methods for describing software architectures.

There are several problems that need to be addressed during the development of a soft- ware application. If the size of the application is small, the computational problems, which are encountered can be solved by using regular algorithms and data structures. However, larger ap- plications are rarely so simple or one-dimensional and are often made up of large interconnected structures, which need to work together as a system. For example, most of Command, Control, and Communication (C3_{) systems include mission planning and direction subsystem, mission}

execution subsystem, and surveillance subsystem, which are connected to each other through various interfaces and, hence, support each other,Hughes Company[1993].

2.3. SOFTWARE ARCHITECTURE DESCRIPTION

gence (C4I) system, as I have participated in its development processes in 2016 with the Raytheon company for the Saudi Ministry of Defence and Aviation (MODA).

Also, the same concept exists on banking software applications, which are made up of core banking modules that work together with an internet banking modules and credit card handling systems.

These complexities are inevitable to ensure that the application delivers the necessary func- tionality flawlessly, remains reliable, reusable and is easy to maintain. However, the architect- ing, designing, and testing of such complex systems poses several challenges. As the size of the system increases, the development related problems increase manifold and with the increas- ing size and complexities of present day software systems, design problems can no longer be sidelined,Safwat et al.[2015].

The emerging field of architecture description concerning different aspects, such as defining the high level system components and the connectivity between them, predicting and formalising the expected behaviour of the system and defining the overall abstract structure of the system that identifying the interconnected components. These processes contribute towards solving prob- lems like translating a system from requirements to design, creating architectural descriptions and ensuring that the architecture will stand up to the requirements,Dick et al.[2017].

In the context of this thesis theDiagrams and Modelsdiffered from each other. Whereas,

Diagramis a form of graphical representation that explains the architecture using any format

and notations alongside a natural language, without following any standards, languages, or specific semantics. WhileModel is an abstract that follows a standard notation to describe some aspects of the architecture, such as its components structure, and how they interact with each other.

• The informal methodsfor describing software architectures (e.g. English, general purpose diagramming) mostly used to explain the architecture in terms of simple boxes and lines where boxes represent the components and lines represent the connections between them, with some textual comments that does not follow any rules or specific notations.

The informal description of SA is easy to develop, understand, and interpret. However, some of the common limitations arising due to the use of informal languages are mentioned below:

1. Ambiguity: Informal diagrams, notations, and the use of natural languages result in a lot of ambiguity regarding various factors, such as the meaning of connectors, their directionality and related associations. In addition to, the way data and control infor- mation flows, despite the components and connectors being represented as separate presentation and visual forms. Often, these ambiguities can result in confusion and non-uniform interpretations, which can lead to misunderstandings.

requires large teams interacting with other each to produce separate pieces of artefacts, which together form the system. In such scenarios, smooth flow of information and good communication is very important and the ambiguity of informal methods hinders both.

3. System validity issues: From the development perspective, it is important that the ar- chitecture is validated early, to ensure that it meets the specifications and fulfils the requirements. This ensures that the architecture is translated into a design, and then can successfully be translated into code. It is very difficult to properly validate an architecture which is described using informal methods. Even assuming that the in- formation is complete and accurate, it is still difficult to arrive at a precise validation model due to the lack of scientific or mathematical notation to measure the complete- ness and quality of such systems,Pressman[2006] andQin et al.[2008]. This might lead to a system failure at a later point of time. This becomes especially problematic if the project development is being executed from multiple geographic locations. 4. Inaccurate behaviour description of architecture: The behaviour description of archi-

tecture deals with the functionalities of different units, communication between them and their validity. Hence, it is a very important part of the overall description, but in- formal methods fail in several aspects to describe SA behaviour adequately, due to var- ious factors like ambiguity, translation of diagrams into analytical models, tool based support and automation process. All this can lead to communication gaps, system deadlocks, and invalid systems.

5. One of the main differences between informal methods and other methods, is that the system and architecture verification is done manually with informal methods. Whereas in the case of other methods, verifications are (or could be) automated and standardised even though the effort involved would be greater,Rushby[1993a].Taking into account that, a manual ’verification’ may involve incorrect interpretations of symbols within diagrams, because sometimes a box might be interpreted as a component and lines might be assumed to represent flow/order, while the architect meant boxes to merely indicate concepts and arrows to indicate data-flow. Thus, the communications between stakeholders is an important factor to have common interpretations.

Therefore, the informal approaches do not provide a good foundation for describing and evaluating SA, even though they can be useful in the initial stages of a project life cycle.

• Semi-formal methods rely heavily on standardised notations/languages (e.g. UML and

SysML) that prescribe the architecture and follow rules to apply them,Bass et al.[2013]. Recently, the Semi-formal languages have become more advanced and supported by tools. Their level of formality is increased and they can be automated to generate code such as usingX_TUML language with a model compiler, or the Artisan tool3, that generates different

3

2.3. SOFTWARE ARCHITECTURE DESCRIPTION

types of code (e.g. Java, C++ and Ada) from the UML/SysML models.

The high level models created by using these languages can be of one or more different kinds, which are used for visualising the architectural designs of the system. For example, Use Case models, Business Process models, Object models, State models, Deployment models, and Component models. Each of these models describes one or more aspects or points of view of the system architecture through diagrams, often intended for particular group(s) of stakeholders. For example, the Use Case model can be represented by Use Case diagrams, which is meant for both the user and developer. Similarly, the Deployment diagram can be used to represent the Deployment model, which is useful from the system engineer’s perspective etc.

Semi-formal models are more generic and can cover different views of the architecture, even though they could be limited during the analysis phase. Also, they can be annotated by a natural language and automated at the same time.

However, two points need to be considered during the utilisation of semi-formal models as follows:

1. The generation of code is mostly incomplete because accurate and precise models are needed. Hence, the generated code may require some amendments after the gener- ation process, due to different reasons, such as models accuracy, tools maturity, and the size of the system.

2. Semi-formal methods use natural language features, which could be good or bad, depending upon the architects and the accurate utilisation of the natural language in the correct manner and places, when constructing architecture descriptions.

In addition, there are some comments in the literature regarding semi-formal notations/lan- guages in general and the UML in particular such as, it is not completely sufficient to elimi- nate the presence of ambiguity as models can contain only a limited amount of information and expressions. Considering the size of specification documents for a complex system, it is almost impossible to represent them with complete accuracy,Pressman[2006] andQin et al.[2008].

Furthermore, Semi-formal methods lack precise descriptions for SA behaviour. Even though the semi-formal diagrams, such as (activity and sequence) diagrams are useful in predicting the behaviour of systems, but “cannot represent time constraints effectively”,Ribeiro et al. [2016]. Also, they are insufficient to describe computational data and to simulate real-time dynamic behaviour. All this can lead to communication gaps, system deadlocks and invalid systems,Rozier[2016].

I argue that the above comments are partially correct with respect to UML, where“UML modelling tools provide poor support for composite state machine code generation. Gener- ated code is typically complex and large, especially for composite state machines. Existing

approaches either do not handle this case at all or handle it by flattening the composite state machine into a simple one with a combinatorial explosion of states, and excessive generated code”, Badreddin et al.[2014]. I agree that the size of the system could be a challenge for Semi-formal approaches in regard to accuracy, features and precise code generation, which been noticed during my inspection for the speed controller system artefacts with Artisan tool.

Generally, the code generation process for UML models, are dependent on the properties of a specific tool generator. In order to make generation process independent and compatible with several tools, the code generators need a “uniform input model”, which a noteworthy contribution towards standardisation concept and UML models transformation introduced byNoyer et al.[2014].

Recently, semi-formal languages have evolved dramatically and they can model the whole system including its behaviour and generate code from those models with more precision. Also, they have been involved in SA frameworks (e.g., DoDAF), formal methods (e.g., AADL), requirements, automation analysis, code generation, management processes. There are hundreds of semi-formal development in different domains, such as (but not limited to) the work done byLamancha et al.[2010],Silva Melo et al.[2014],Pereira et al.[2015], Hilken et al.[2015],Lugou et al.[2016],Ribeiro et al.[2016], andRibeiro et al.[2017]. Indeed, Semi-formal methods are not as precise as Formal methods. However,Semi-formal approaches do have the strength over the Informal languages, such as, understandability. So, they are understandable to human, and their models can demonstrate different architec- tural views. Also, they do have some of the Formal methods strength regarding machine readability.

Furthermore, They do not have the same ambiguity as Informal methods. Also, it’s not hard to learn, develop, and understand. As a result, it is a good foundation for describing and evaluating Software Architecture (SA).

• Formal methods are used to express architectures formally. One way is to describe SA

in terms of Component and Connector (C&C) and configurations that carry computational information and provide the foundation for development of analytical functions. Such lan- guages are (but is not limited to), the AADL, ACME, Arch-Java, Koala, and MontiArc Automaton Architecture description language (MAAADL),Wortmann”[2016].

If we take as an example the AADL and the MAAADL as formal languages, they are consid- ered to be an efficient to analyse and create architecture descriptions based on formal nota- tions and tools,Medvidovic et al.[2000] andWortmann”[2016]. The AADL is a modelling language to model both (software and hardware) components, and associated properties, whereas MAAADL focuses on modelling SAs logically.

According toWortmann”[2016],“the MAAADL modelling infrastructure comprising the concepts, ADL, state-based behaviour language, model transformation and code generation

2.3. SOFTWARE ARCHITECTURE DESCRIPTION

framework to enable multi-platform generative software engineering”. More analysis of formal methods is presented in the next section.

However, if we compare semi-formal and formal, we find that each one has different ad- vantages. Formal languages are powerful during syntax and semantics analysis. Some of the main advantages of formal methods in describing behaviour are mentioned below,Qin et al.[2008]:

1. Formal methods are more concise and accurate than other methods, which able inven- tors or designers to express their specific concept through its semantics, and hence support new designing approaches to be manifested.

2. Formal methods are more effective in describing aspects such as behaviours and pat- terns, thus they are cognitive to behaviour analysis and creation of rules.

3. Due to the absence of ambiguity, it is possible to validate the system architecture beforehand and also measure it for quality parameters.

In general the above points is correct, but it is vary from language to another. For exam- ple, the formal semantics and executability are two limitations of AADL’s as examined by Ölveczky et al.[2010]. However the AADL were evolved during the last few years and its semantics becoming more mature, Oquendo[2016].

Challenges hindering the utilisation of formal methods are: 1. hard to learn;

2. hard to develop;

3. hard to understand by all stakeholders;

4. need an expert, who may not always be available; 5. high cost;

6. time consuming.

Considering the above factors along with, the fact that Semi-formal and Formal methods description play an important role in the application of software architecture description and modelling approaches, they are being hailed as the way forward.

More discussion about Formal methods is represented in section 2.3.3.

See the three notation representations in Table 2.2 that are describing a section of the Pipe- Filter pattern, in order to better visualise the argument above.