Disadvantages Of Software Architecture

Particularly when considering large, complex software systems, software architecture plays a central role to bridge the gap between system requirements and implementation. By software architecture’ we mean “the structure of the components of a program or system, their interrelationships, and principles and guidelines governing their design and evolution over time” [34]. We use the definitions of the main architectural building blocks given in [30]: components, connectors, data, and configurations.

• A component is an abstract unit of software instructions and internal state that provides a transformation of data via its interface. • A connector is an abstract mechanism that mediates communication, coordination, or cooperation among components.

The work presented in [32] summarizes the characteristics of these ADLs, except AADL, and discusses the main concepts of software architecture such as components, ports, composite component, or configuration and connectors. In this context, rewriting logic had taken its place among the different formalisms used to specify software architecture and many attempts try to develop a rewriting-logic-based ADL as CBabel [14], to translate AADL [60, 9] and AADL behavioral annex [60]to rewriting logic. or to use rewriting logic directly for the specification of software architecture as presented in [42]; Table 1 summarizes their proposition for the correspondence between software architecture concepts and Real-Time MAUDE constructs.

The analysis process of large/complex system by exhaustive testing or by full simulation is often too difficult, costly or even impossible. Therefore, it is better to turn away from the real world to the virtual world of modeling, where an abstract model of the system is developed. This model represents a reduction of the real system, and its more tractable size makes it a candidate for model checking [22, 38], a technique for automatically determining whether a model of finite state concurrent systems adheres to a specification. Model checking offers a means to verify given properties Φ1, Φ2, . . . Φn (constraints of a specification) are satisfied by a model

Rewrite theory specified by a system module M-SYSTEM, which describing the behavior of the system; 2. PROP-M module, which contains the set of predicates expressed in standard LTL propositional logic as the defined syntax in the module SATISFACTION; and 3. 3. The initial state from which the model checker starts checking, is specified in module M-CHECK. Then, we have to load the module M-CHECK, in order to check the property formula expressed in linear temporal logic (LTL) with the LTL model-checker. Noting here, that the module M-CHECK may contain the property formula, which allows automatically the test after it’s loading. The main modules used by the MAUDE’s LTL model-checker are presented in the following figure (Fig. 1). The MAUDE’s LTL model-checker modules have well defined roles as follow: • MODEL-CHECKER: This is the main module in the verification process. • LTL : This functional module formalizes the syntactic and semantic definitions of linear temporal logic (LTL). • LTL SIMPLIFIER : It tries to further simplify the negative normal form of the formula ¬ϕ : in the hope of generating a smaller Bchi automaton