Meta Architecting: Towered a New Generation of Architecture Description Languages

: The techniques of meta-modeling and meta-levels have become a mature concept and have been largely used to solve real problems in programming languages, distributed environments, knowledge representation, or data bases. In this article it is shown how the same techniques can be applied in component-based software architecture. It also shown the need to propose mechanisms of reflexivity within the domain of software architecture meta-modeling. The outcome of this is a meta-meta-architecture with a minimal core whose finality is to define meta-components, meta-connectors and meta-architectures. Call this meta-meta-architecture MADL (Meta Architecture Description Language).


INTRODUCTION
In the domain of Knowledge Representation [1] one speaks about meta-knowledge to evoke knowledge relating to knowledge, or meta-model for a model representing a model, etc. In the context of software architecture [2] meta-modeling is an act of modeling that is applied to an architecture. The result of such an act of modeling, i.e. the use of an architecture A to establish an abstraction of a system S, is called the Architecture (A) of the system S. Similarly, the meta-architecture of an architecture is itself an architecture, which does not model a final application but an architecture. When the act of modeling is applied to software architectures, it is called meta-architecting. A meta-architecture is thus a formal or semiformal Architecture Description Language (ADL) [3] that permits to describe particular systems, called architectures. Meta-Architecture (MA) itself is an architecture and thus in a more general way a system, which can be described. One then can define the architecture of a meta-architecture by the meta-meta-architecture (M 2 A). As in any recurring modeling, it is advisable to stop by a reflexive architecture, i.e. auto-described architecture. The number of levels imports little, but it seems that three levels of modeling are sufficient within the domain of software architecture engineering where the M 2 A serves as an auto-modeler and as a modeler of ADLs.
In object-oriented modeling, this self-modeling is generally implemented by the concept of meta-class which guarantees the homogeneity of the concepts and the extensibility of the system. It is a question of conceiving an architecture by itself or using an architecture to define or conceive another architecture.
Meta-architecting of an architecture can be a tool to define, comment, document, compare architectures, in particular semiformal architectures. It is about describing an architecture by its conceptual diagram, resulting of a step of specification using a meta-architecture that most of the time itself is a semiformal. This diagram then constitutes a document of explanation and/or documentation of the architecture.
Meta-architecting can also be a means of formalization for semiformal architectures. Formal ADLs are based on mathematical theories ensuring obtaining exact specifications [4] . However the formalisms of these ADLs can discourage the designers. In additional, formal ADLs are not easily comprehensible for non trained designers, thus it is very useful to transfer a semiformal specification to a formal specification. The approach consists of specifying, once and for all, the concepts of semiformal architecture in a formal specification. One then obtains a meta-architecture of the semiformal architecture which can then be directly used.
For brevity, it can say that meta-architecting is a good way to: • Standardize: Architectures are based on well-defined semantics. These semantics are provided by means of meta-architectures. Each architecture must conform to a meta-architecture, which specifies a specific way to define architectures. Describing different architectures using the same metaarchitecture confers on the meta-architecture a role of standardization for at least the architecture that it describes. • Map ADLs into other modeling techniques, e.g. UML [5] .

MADL: Meta Architecture Description Language :
In object-oriented modeling, self-modeling is generally implemented by the concept of meta-class which guarantees the homogeneity of the concepts and the extensibility of the system. It is a question of conceiving an architecture by itself or using an architecture to define or conceive another architecture. Meta-architecting of an architecture is a technique to define, comment, document, compare architectures, in particular semiformal architectures. It is about describing an architecture by its conceptual diagram, resulting of a step of specification using a meta-architecture that most of the time itself is a semiformal. MADL is intended to be a meta-matearchitecture that defines meta-architecture. It is based on the Y architecture, hence we have three main elements in MADL: meta-component, meta-connector and meta-configuration (or meta-architecture).
The four abstraction layers of software architecture : The four metamodeling layers of OMG (application layer, model layer, meta-model layer and meta-meta-model layer [7] ) can be applied in software architecture and the outcome of this is an architecture with four levels of abstraction represents the different architecture levels, starting from the definition of the meta-meta-architecture to the application level. Consequently, one can see four abstraction levels in software architecture: meta-meta-architecture level, meta-architecture level, architecture level and application level (

Architecture level (A):
In this level, various types of components, connectors and architectures are described. Architectures conform to meta-architectures (ADLs), therefore, each element of A is associated with an element of MA. For example, in Fig. 1, Client and Server are components, RPC is a connector and Client-Server is a configuration.
Application level (A 0 ): Allows us to describe applications. An application is seen as an assembly of instances of types of components, connectors and architectures. Applications conform to architectures. Each element of A 0 is associated with an element of A. For example in Fig. 1, CL1 is an instance of client, S1 is an instance of server, RPC1 is an instance of RPC and C-S is an instance of client-server.
The structure of MADL: The meta-meta-architecture must be a minimal generic core whose finality is to define meta-meta-architecture elements, which define type elements for meta-architectures. It introduces the concepts: meta-components, meta-connectors and metaarchitectures needed to manipulate and to define architectural concepts (structural and behavioral). It is organized these meta-concepts in a meta-metaarchitecture called MADL (Fig. 2).
MADL is organized in three packages: Meta-Meta-Architecture package, Meta-Architecture package and Architecture package.
Meta-meta-architecture package : To define an architecture we need a meta-architecture and to define a meta-architecture we need a meta-meta-architecture, therefore, Meta-meta-architecture package composed of Meta-architecture package and Architecture package. Meta-meta-architecture package holds all the concepts needed to define meta-architectures and architectures. Meta-meta-architecture does not conform to another architecture, but acts as its own meta-architecture. Similarly, each element of Meta-meta-architecture has to be associated with another element of Meta-metaarchitecture, to respect the auto-conformity relation. For brevity, Meta-meta-architecture is an instance of itself.

Meta-architecture package :
To define architectures we need a meta-architecture, so Meta-architecture classifies and defines architectures. Architectures contains components and connectors, therefore, Metacomponent and Meta-connector are parts of Metaarchitecture (hence, each component and connector of level MA must be a part of an architecture of level MA). Meta-architecture is an Architecture, that is why Meta-architecture inherits Architecture. To permits architectures of level MA to have interfaces Metaarchitecture is composed of Meta-interface. Metaarchitecture conforms to the definition of Meta-metaarchitecture, i.e. it is an instance of Meta-metaarchitecture. Meta-architecture is composed of the following meta-elements: We can also count four types of relation among elements in MADL, instance of, association, composed of and inheritance: • Instance of, when an element conforms to the definition of another element. It defines the association between an element (or an architecture) and its meta. For example, component is an instance of Meta-component, Architecture is an instance of Metaarchitecture. To respect the reflexive principle, on which MADL is based, architecture is an instance of metaarchitecture, component is an instance of meta-component and meta-component is an instance of itself, so all the instantiation relations ends in meta-component. The principle is also applied to meta-metaarchitecture which is an instance of itself.
• Association, when an element has an association with another element. For example, the association between Metacomponent and Meta-connector, the multiplicity is set to 1..*, so components of level MA can engage in more than one association at the same time.
• Composed of, when an element is composed of another element. For example, Metaarchitecture is composed of one or more Metacomponent, one or more Meta-connector and zero or one Meta-interface.
• Inheritance, when an element inherits another element. For example, Meta-component, Meta-connector and Meta-interface inherit component.
All these relations are nothing but instances of Meta-Connector, i.e. are implemented using specific types of connectors, in order for the model to utilize merely architectural elements. For example, inheritance is achieved by a specific connector that implements the inheritance relation between two elements, the roles of this connector (the interfaces of the connector) connect the two parties (the super element and the sub-element) and the glue, which defines the behavior of the connector, insures that the sub-element is identical (from the same type) to the super element.  [7] and Acme [8] . The key associations are: • Attachments. Link a port to a role.
• Bindings. Link two ports or tow roles together.
• Uses. Link a services (or services) to port/role (or ports/roles).
Instantiating COSA from MADL : Figure 4 shows how COSA is instantiated from MADL. The figure shows only the part related to components. As can be concluded from the figure, each MA notation is an instance of MADL notations. For example components and configurations are instances of Meta-component, connector, binding, attachment, are instances of Metaconnector, while interfaces such as ports and roles are instances of the Meta-interface. The meta-architecture itself is an instance of the met-meta-architecture (M 2 A).
Acme : Other models can be easily instantiated from MADL. As an example, we chose Acme, because it considers most of architecture description concepts and notations. Acme has resulted from a careful consideration of issues in and notations for modeling architectures. As such, it can be viewed as the starting point for studying existing ADLs and developing new ones. However, Acme represents the least common denominator of existing ADLs rather than a definition of an ADL. Architectural structure is defined in Acme using seven types of entities: components, connectors, systems, ports, roles, representations and rep-maps.

CONCLUSIONS
In this article we have shown how techniques of meta-modeling can be applied in software architecture. We have also shown the need to propose mechanisms of reflexivity within the domain of software architecture meta-modeling. Next we have presented a meta-meta-architecture dedicated to software architecture, then we have shown how to use it to instantiate meta-architectures. Our approach shows that meta-meta-architecting can be a good tool of documenting, analyzing, comparing and unifying ADLs. Present proposal is directed to the context of the recent research work, in which software architecture is oriented more and more toward the OMG group works [6] . Thus, the introduction of software architecture concepts in UML 2.0 [9] is considered as a sign of this orientation and it gives an indication for the possibility to define (component based) software architectures in a way that refinement to adapted executive platforms is much easer.