This section discusses the related work in the architecture description languages (ADLs) literature. Both component models and ADLs share the component concept. A compre- hensive study of ADLs was presented in [MT00]. Recent studies have shown the limited support of ADLs for non-functional requirements. Garlan and Schmerl [GS06] remark that, “despite the notable progress and concern for ways to represent and use software architec- ture, specification of architecture designs remains relatively informal, relying on graphical notations with weak or non-existent semantics that are often limited to expressing only the basic of structural properties”. This section presents a brief review of three ADLs: Acme [GMW00], secure-xADL [RT05], and AADL [AAD].
2.3.1 Acme
Acme is a second generation architectural description language. It provides support for specifying the canonical set of structural elements of an architectural design. It includes definitions of component, port (runtime interface), connector, connector role, system, prop- erty (attribute), constraint, and representation (substructure of a component or a connector). Acme is extensible. Therefore, it serves as a basis for developing new domain specific ADLs and integrating existing architectural design analysis tools. Acme is intended to pro- vide a unifying ADL for interchanging architecture descriptions between different ADLs. It includes only the essential items that are common among ADLs. Since non-functional requirements are not common in ADLs, component definition in Acme does not include non-functional requirements. Hence, it is not suitable for defining architecture of trustwor- thy component-based systems.
2.3.2 Secure-xADL
A secure architectural description language (secure-xADL) was introduced in [RT05]. The proposed language is based on extending xADL, an XML based extensible ADL. The ba- sic structural elements of architectural modeling in xADL are components and connectors. Secure-xADL uses an access control mechanism for modeling security at the architectural level. The access control model [Bis03] precisely defines the rights of every subject with respect to every other secured entity. In order to ensure security, components and connec- tors play different, yet complementary, roles. Component types provide security contracts that specify the subject it acts for, the principals it can take, the privileges it possesses, and the safeguard it requires. These are defined as part of its interface specifications. On the other hand, connectors regulate and enforce the defined security contracts of the communi- cating components. Connectors check the contracts at the two ends of the communicating components and decide whether they have sufficient privilege to communicate. Then it either lets the communication passes through or rejects it.
Although Secure-xADL introduces a promising approach for modeling security at the architectural level, there are four major issues that, to the best of our knowledge, have not been addressed by Secure-xADL. First, it does not provide a solution to the compositional problem which is a major concern in component-based development. Second, Secure- xADL does not provide mechanism for the formal verification of security policies in a component and in the whole system. Third, it does not provide a mechanism for perform- ing consistency checking to ensure that the defined policies does not include conflicting specifications. Fourth, security contracts are maintained at a component level; therefore, there is a need to prove that the subject actually posses the claimed privileges on the ob- jects. Otherwise, any component can make false claims and violate security by accessing restricted resources. There is a need for either a centralized or distributed authentication authority to confirm the legitimacy of the claimed privileges. To the best of our knowledge, Secure-xADL is the only secure ADL proposed in the literature.
2.3.3 AADL
The architecture analysis and design language (AADL) [AAD] is a textual and graphical architecture description language used to specify the design of real-time systems. AADL provides formal modeling abstractions for the specification of complex real-time embedded
systems. The structure of a system is specified as an assembly of communicating compo- nents. Their interfaces, functional and data, and non-functional properties, such as timing requirements and space requirements, are precisely defined. Component specification in AADL includes an identity, possible interfaces with other components, properties, and subcomponents defining the internal structure of the component’s implementation. Com- ponents are divided into three categories: application software, execution platform (hard- ware), and system. Each component category has its own predefined set of properties. Interactions between components are defined as flows of control and information through defined connections. Multiple predefined configuration settings and interactions between components can be defined using operational modes. The language enables deployment specification by allocating software components to execution platform components. It is possible to extend the language with more properties and analysis specific constructs that can be associated with components. The error model annex is a standard AADL extension that supports fault/reliability modeling and analysis.
In AADL a primitive component represents a single service for which the defined data
ports specify the stimulating input or triggered output event and the input and output data
parameters. Therefore, AADL does not provide a clear distinction between a component and a service. In AADL, the critical safety requirements are specified as properties that de- fine timing requirements, period, worst-case execution time, deadline, space requirements, and arrival rates. These properties are included in the component specification. This hin- ders the reuse of components for different deployments. In our view, specifying contracts outside component definition enables reuse of components and contracts definitions and al- lows changes to contract without affecting component specification. AADL does not sup- port security specification, but it supports reliability specification by defining error models annotated with probability parameters. However, the values of the probability parameters are based on assumptions. Therefore, the accuracy and precision of these values can not be proven or justified. AADL does not provide a mechanism to analyze availability.