Reference Architectures

Reference Architectures

1. It clarifies the differences between the reference architecture and reference model, as well as between the reference architecture and product line architecture

   • definitions:
     • Kruchten [KRU 00]: “A reference architecture is, in essence, a predefined architectural pattern, or set of patterns, possibly partially or completely instantiated, designed and proven for use in particular business and technical contexts, together with supporting artifacts to enable their use. Often, these artifacts are harvested from previous projects”
     • Rosen et al. [ROS 07] stated that “A reference architecture is a working example of a critical aspect of your enterprise architecture, such as [...] how to work with your organization’s message bus or [...] how to work with your business rules engine”
     • Angelov et al. [ANG 09] stated that “A reference architecture is a generic architecture for a class of information systems that is used as a foundation for the design of concrete architectures from this class”
     • Reed thinks that “A reference architecture consists of information accessible to all project team members that provides a consistent set of architectural best practices”.
   • A reference model can be considered an abstract framework that presents a set of unifying concepts, axioms and relationships within a particular problem domain, independent of specific standards, technologies, implementations or other concrete details

2. It presents a model that describes the set of elements that could be found in reference architectures.

   • Domain: it contains elements related to self-contained, specific information of the space of human action in the real world, such as domain legislations, standards and certification processes, which impact systems and related reference architectures of that domain.
   • Application: it contains elements that provide a good understanding about the reference architecture, its capabilities and limitations. It also contains elements related to the business rules (or functionalities) that can be present in software systems built from the reference architecture.
   • Infrastructure: it refers to elements that can be used to build the software systems based on the reference architecture. These elements are responsible for enabling these systems to automate, for instance, processes, activities and tasks of a given domain.
   • – Crosscutting elements: it aggregates a set of elements that are usually spread across and/or tangled with elements of the other three groups (domain, application and infrastructure). We have observed that communication (which we have identified as internal and external) in the software systems built from the reference architecture, as well as the domain terminology and decisions, are present in a spread and tangled way when describing other groups and are, therefore, crosscutting elements.

3. The process, named ProSA‐RA2PLA, is an iterative process that systematizes the steps to build product line architectures using the knowledge and elements contained in the reference architectures.

   • is a process that systematizes the design, representation and evaluation of reference architectures.

4. Various perspectives of applying these architectures are also discussed.

5. The chapter ends with examples of these architectures and future perspectives for them.

   • examples
     • AUTomotive Open System Architecture (AUTOSAR) [AUT 13], for the automotive domain, and Continua [CON 13] and UniversAAL [UNI 13], for AAL [BRO 10].
   • future perspectives
     • Systems-of-Systems (SoS), SOA, dynamic software architectures, Multi-Software Product Line (MSPL or simply Multi-Product Line – MPL) and variability in reference architectures.

Imágenes y archivos del mapa