Patterns describe successful solutions to known problems and using patterns in software development is a well-known approach. Patterns have proven useful to help developer to reuse successful practices. In addition patterns teach useful techniques, they help people communicate better, and reason about different solutions.
Based on our experiences in the Travel Agency case study in the previous chapter, we have extracted some generic patterns. In this chapter we presented these patterns formally. Formalising patterns provide a well-founded support for reuse. Furthermore, formalised patterns are a step toward defining a framework for developing mission-critical Web-based Applications. As a continuation of our work in the first step we developed some formal models for generic patterns that we presented in this chapter.
In the next chapter we will apply our findings in this chapter to some real case studies and assess our model. In applying these patterns the instantiation and composition of patterns as a main strategy that will be considered. The outcomes will show to what extend these formal patterns could assist the formal development process. The final findings could serve as the basis for development of new generation of tools for the B-Method and extending it to support automatic or semi-automatic refinement.
Specification Partitioning and
Composition Techniques
5.1
Introduction
In conventional B development we start the formal specification process with a single B machine which usually contains few operations and related variables. This single spec- ification could be refined in a stepwise manner by introducing extra events’ definitions and their related variables to produce a more concrete model. During the refinement process when the complexity of the concrete model reaches a specific level that makes it difficult to manage and understand the model we can decompose the refined model to a number of sub-models. After this stage each sub-model could be refined independently. Based on our experiences in developing a formal specification for the Travel Agency System in Chapter 3 we found that the following characteristics of real Web applications make conventional B development unsatisfactory.
• Multi-layer Architecture: The multi-layer architecture of this kind systems which put a lot of emphasis on separation of layers’ specification and design is not com- patible with the idea of a single B machine for the whole system specification. Using a single B machine in early stage of specification and refinement resulted in mixing up functionalities which in most cases are independent. The major de- sign criteria like modularity, manageability and comprehensibility are in favour of separation between the specifications of different layers.
• Substantial Requirements: The substantial list of requirements for an actual Web application could makes the specification and refinements process very compli- cated. Unlike simple exploratory case studies, it is not very convenient to start the formal specification of these systems with a few operations and variables. The
main reason is that we have a comprehensive list of closely related requirements with the same precedence. The close connection between requirements simply means that it is not possible to specify one requirement without introducing all other related properties and it is the point where the complexity is laying. Here according to Abrial’s view [10] may argue that in many systems it is possible to classify the initial requirements to a number of subsets of closely linked require- ments. Then in the second phase we can pick up each subset one at a time and incorporate it into our model through superposition refinement. Based on our experiences, especially with the travel case study, even when this approach is pos- sible it is not convenient. A major problem associated with this approach is that it could be a long-drawn-out process before reaching the point to have the full spec- ification and starting the actual refinement. Another weakness of this approach is that any changes in one model may effects all previous models and bringing them inline with the changes could be very time consuming and tedious job.
To overcome these complications, we devise a new development approach in this chapter. Our alternative approach is based onspecification partitioningin the early stage of formal specification. In this approach the system specification comprises a few separated but closely connected B machines. The relation between different models is defined by some composition relations which are an essential part of this new approach. Each B machine, articulates a specific aspect, layer or part of the system. In Web applications different models should be devised in such a way that should match with the multi-layer architecture and underlying platforms.
With reference to indispensable role of composition in our approach, in the next part of this chapter we first explore the bases of the composition mechanism. In the later sections we extend the composition mechanism based on different scenarios in the case study.
In this chapter we pursue a practical approach rather than a theoretical one. For this purpose we have chosen an online English auction system to develop our ideas and demonstrate how they work in practise. A short informal presentation of the case study in addition to the overview of the system architecture are presented in section 5.3. Another important aspect of our work in this chapter is to apply the formal specifica- tion patterns which we developed in the previous chapter. Assessing the suitability of these patterns for real cases is an essential aspect of pattern based development. An important issue which can arise by our new approach to the formal modelling, is how the specification partitioning could effect the formal patterns of Chapter 4. In section 5.4.1 and during formal development process these issues will be discussed in detail.