Software architecture is the result of the decomposition of a system into subsystems providing a set of functionalities and collaborating in the realization of its requirements. It is defined by Bass et al. as the structure of the system made of software components, their externally visible properties, and the relationships between these components (Bass et al., 2003; Bass et al., 2012). By casting details aside, the architecture depicts the software systems at a level of abstraction that is high enough to ease the reasoning about the different steps of their life cycle (Ducasse and Pollet, 2009). These include the understanding, construction, reuse, analysis, evolution, and management of the software (Garlan, 2000). Bass et al. further discuss different advantages of an explicitly designed and documented architecture (Bass et al. 2003):

• Stakeholder communication: the architecture represents the system at a high level of abstraction. As such it can serve as a basis for the discussion between the different stakeholders involved in the system development.

• System analysis: explicitly representing the architecture at the beginning of the system development requires some analysis. Indeed, decisions related to architectural design have a significant impact on the ability of the system to respond or not to critical requirements (e.g., maintainability, availability, and performance).

• Large-scale reuse: the architecture of systems that meet similar requirements is often the same and can therefore support large-scale software reuse.

Hofsmeister et al. argue that the different steps of architectural design drive the designers to early take into account the key elements of the design process (Hofsmeister et al., 2000). They explain that the software architecture can act as a design plan that allows negotiating the system requirements and structuring the discussions between the stakeholders. In addition, they suggest that the software architecture is essential to address the complexity of a system.

As stated in (Ducasse and Pollet, 2009), the literature (e.g., (Kazman and Carriere, 1999; Medvidovic and Jakobac, 2006)) generally distinguishes between the conceptual architecture and the concrete architecture. The term concrete architecture designates the architecture that is derived from source code’s artifacts. The concrete architecture is also called the as-built, as-implemented, realized, or physical architecture. The conceptual architecture designates in turn the architecture that either exists in human minds or in the documentation of software. The conceptual architecture is also referred as the idealized, as-designed, logical or intended architecture.

Architectural styles

The business value of a system is the fruit of its quality attributes as perceived by acquirers as well as end-users (Sury, Abran and April, 2003). The architecture of a system determines the quality attributes that this system will have at the end of its development. In this context, a quality attribute is defined as “a measurable or testable property of a system that is used to indicate how well the system satisfies the needs of its stakeholders” (Bass et al., 2012). The organization of the architecture of a system with respect to some quality attributes can be achieved using architectural styles that support these attributes. These quality attributes are also referred as non-functional requirements (Abran et al. 2004; Bourque and Fairley, 2014). Since the lack of quality attributes unsatisfies users, leads to financial loss, and might also threaten lives, quality attributes have become critical for the system (Sury, Abran and April, 2003).

Definition 

Medvidovic and Jakobak (Medvidovic and Jakobak, 2006) describe the architectural style as “a key design idiom that implicitly captures a large number of design decisions, the rationale behind them, effective compositions of architectural elements, and system qualities that will likely result from the style’s use”. According to Le Métayer (Le Métayer, 1998), « the architecture style can be seen as the « type » (or form) that the architecture must have at run time, that is to say the possible connections between its individual components ». It therefore represents a form of codification of the aspects that must be met by the architecture it structures (Bhattacharya and Perry, 2005). An architectural style governs the vocabulary of components and connectors used when instantiating this style, together with a set of constraints on how they should be arranged (Garlan and Shaw, 1996). As such, the definition of an architectural style involves the following concepts:
• The components: they are the « principal processing units and data stores » (Clements et al., 2003). A component is implemented as an abstract unit of software instructions and internal state that allows transforming data through its interface (Fielding, 2000).
• The connectors: they are the « pathways of interaction between the components » (Clements et al., 2003). Hence, a component has a set of connectors determining how it can interact with other components. Connectors allow transferring data from one component’s interface to another without altering these data (Fielding, 2000).
• The constraints: they are the rules that define how the components and connectors must be assembled in order to create a valid instance of the style (Clements et al., 2003). These constraints can either be topological or semantic. A system that is compliant to a given architectural style must conform to its constraints at design time and during its evolution (Clements et al., 2003). These constraints express the fundamental rules embodied by the architectural style.

An architectural style is an element of primary importance in the architectural design (Mikkonen et al., 2004). It allows describing a family of architectures conforming to the set of constraints that it specifies (Tamzalit and Mens, 2010). These constraints allow the architectural style to guide the evolution of architecture toward this family of architectures (Tamzalit and Mens, 2010). This being said, most systems need to combine several architectural styles in order to organize their structure, since every architectural style supports specific quality attributes. This is achieved by using an architectural style for structuring the whole system, and using different architectural styles to organize the internal structure of the various parts of the system (Sommerville, 2007). A description of many common architectural styles can be found in (Shaw and Garlan, 1996; Clements et al., 2003; Bass et al., 2003). Examples of such styles include the layered, pipes and filters, and serviceoriented styles.

Architectural styles are usually classified into three categories of styles (Clements et al., 2003), namely: the module, the component-and-connectors and allocation styles. The module styles allow describing the architecture of a system as a static partition of its software’s functionalities. The component-and-connectors styles allow depicting the runtime behaviour of a system. The allocation styles allow describing the mapping of a software‘s entities to the resources (e.g., hardware, file systems) of its development and execution environments.