1.4　Our approach

Correspondingly, we develop an approach based on UML-like meta models and graph transformation techniques to support sound methodological principles, powerful modeling, formal analysis and refinement. In detail, we can divide the approach into five main parts:

Requirements analysis　The very first step of an architecture-centric approach is to characterize the problem domain, conclude the main characteristics and aspects to be modeled. Understanding the problem domains and their properties is a key to better understanding the needs of software architectures, architecture-based development, and architectural description. We develop a conceptual framework for understanding and comparing the different approaches, which is abstracted from specific implementation details and summarizes the main characteristics of the middleware. The generalization enables us to compare different approaches from a same point of view, and observe similarities and common aspects from the great diversities of the middleware. This builds a basis for constructing the architectural style of the middleware, which should originate from the results that practitioners have achieved in the area.

The modeling language　The modeling language is based on the Graph Transformation Systems (GTSs) and UML-like metamodeling technique. We exploit the GTS for specifying the architectural style of the middleware for mobile systems, which includes the specification of mobility related elements. Visual representation and formal semantics are the main advantages of the modeling language. It has not only a graphic, easy understandable syntax, but also an operational semantics. It supports rich modeling techniques, such as separation of concerns, refinement, adaptability, extensibility, etc. It can describe complex structures and systems, and model concepts and ideas in a direct and intuitive way. At the same time, the formal semantics allows execution, analysis, transformation, automation and tool support.

The architectural style　The great diversity of the middleware for mobile systems makes it quite difficult to build architectural styles for the middleware. It is difficult to explore commonalities across the middleware families. We observe that the middleware presents some commonalities among the basic aspects, which are summarized as the characteristics for the middleware during the requirements analysis process. Therefore, we develop the architectural style through exploring the commonalities among these basic aspects, which include not only the concrete design specific models and patterns, but also the more abstract features brought by different definition of mobility, e.g., how to define the movement space and how components move. This makes our style vary greatly from the traditional architectural style for distributed systems. We also explore how to separate these aspects into the styles on different abstract layers. Such separation can decrease the complexity brought by mobility, help the designers and developers fully understand how mobility influences the middleware, and how to come to a complete design gradually. We illustrate the process of developing the style through constructing the style of the middleware for nomadic networks.

Simulation　The operational semantics of the GTS allows us to execute the models and thus analyzing and validating the system through simulation. Simulating the dynamic behavior of the system allows the designers to execute the system and to play with specific scenarios. The designers can concentrate on the key aspects of the architecture. It can also detect errors and improve the confidence of the model. In such a validation process, it happens often that the result is wrongly judged as incorrect, although the specification is proved to be correct later on. This is normally caused by inputting an incomplete initial state, or the reference test result is wrong itself, both of which result in naturally wrong test result or wrong judgement. This makes the validation process itself error-prone and very inefficient. We solve this problem by constructing the minimal initial state and the expected test result with the help of an algorithm. Our approach can greatly enhance the correctness and efficiency of the validation process.

Besides supporting simulation, we also focus on providing a practical and usable process and environment to help the design and development of the style. The tool support of style specification, style refinement and other related concept is very important too. After comparing the available simulation tools, we choose the existing Fujaba [1] environment as our basis. Fujaba is a CASE (Computer-Aided Software Engineering) tool that aims to push graph transformation systems to a broader industrial usage. Fujaba allows a seamless integration of object-oriented software development and graph transformation systems, which facilitates greatly the designers and developers who are not familiar with graph transformation systems. With its support, we develop a style-based engineering process for efficient style development, which includes style specification, style validation, refinement consistency check, behavioral consistency check and code generation.

Refinement　When developing the style, we use a stepwise refinement-based approach in order to decrease complexity and enhance reusability. We start from a simple abstract (i.e., conceptual) style that is refined to a more concrete one (platform-independent) with more design specific aspects, which is further refined to an even more concrete style (platform-specific). We develop refinement correctness criteria that check whether the concrete style is a correct refinement of the abstract one. The correctness criteria include both structural and behavioral ones. Especially, we formalize the refinement relationship between two abstract layers mainly based on the mapping of rules. We derive a simplified rule for a sequence of rules through a scenario based construction. The derived rule preserves the semantics of the sequence of rules, thus it can be used to substitute the complicated rule sequence. By using the derived simplified rule, we build a bi-directional mapping between a sequence of rule and another rule sequence. We also develop an algorithm to construct the derived rule.

The approach can check the correctness of the sequence of rules. It also enables us to check the correctness of newly added structural and behavioral elements through the scenario construction, which associates the completely different concrete elements with the abstract ones. Besides, our formalization can construct exactly the needed state graphs and transformation sequences for checking, which makes the approach efficient and practical to large systems. It also enables us to use the existing graph transformation simulation tool Fujaba as the basis for automating the refinement consistency check.

Consistency check　We develop a framework that supports behavioral consistency check between models on different abstract layers. It checks whether the specified architectures in a same hierarchy belong to the same family of middleware, i.e., they should realize and provide the same functionalities, although they belong to different abstraction layers and use different design strategies. Besides, we automate the consistency check process with the support of Fujaba.