The ground model method deals with the issues at the beginning of the development process, i.e. user requirements capturing. The discussion of the ground model method in the following is based on [14].
Usually, the first system specification, which is formulated in ASMs straight from the user requirements in natural language, is called the ground model in the ASM method. In the case of reverse engineering, the ground model is the concrete one from which more abstract models are derived by abstraction.
3.5.1 The Properties of the Ground Model
The fundamental problem in building computer systems is deciding precisely what to build. The user requirements are to describe what to build, but often their formulation is incomplete or too detailed, ambiguous or inconsistent. Hence, we need a model, namely a ground model, for capturing the requirements, to be
• precise at the appropriate level of detailing yet flexible, to satisfy the required accu-
racy exactly, without adding unnecessary precision;
• simple and concise to be understandable by both domain experts and system de-
signer, and to be manageable for inspection and analysis - this is achieved by “di- rectly” reflecting the structure of the real-world problem;
3.5. THE GROUND MODEL METHOD Jane Qiong Zhao
• abstract (minimal) yet complete. Completeness means that every semantically rele-
vant features is present with no hidden clauses. The completeness property requires the designer to include a statement of the assumptions made for them at the ab- stract level and to be realized through the detailed specification left for the later refinements.
• validatable and thus in principle falsifiable by experiment.
• equipped with simple yetprecise semantical foundation as a prerequisite for rigorous analysis and as a basis for reliable tool development and prototyping.
3.5.2 Three Problems in Formulation
The difficult and error-prone task in requirements capturing is the formalisation task, that is, to translate the usually natural-language problem description into a sufficiently pre- cise, unambiguous, consistent, complete (but different from program code), and minimal formulation of the“conceptual construct” of a computer system.
There are three essential problems in the requirements formalisation, namely
• the language and communication problem,
• the verification-method problem, and
• the validation problem.
The language and communication problem happens between the domain expert and the system designer in deciding what to build. As the common understanding of ”what to build” will be used as a contract to bind the two parties in the rest of the development process, it is to be documented in such a model that both the domain expert and the system designer are able to understand. This requires the language to be suitable to model the problem closely (at the right level of abstraction) focusing on the domain issues of the given problem.
The verification problem stems from the fact that there are no mathematical means to prove the correctness of the passage from an informal to a precise description. This can only be replaced by inspections on some kind of “evidence” of the desired correspondence between the informal model and the precisely formalised model, namely the ground model. This requires that the ground model inspection provides the evidence of correctness. To establish the system completeness and consistency, it requires that the ground model can be used to describe the original intention of the system, and to express it correctly to the designer, and it can also be used by the domain expert to inspect its completeness, as well as the designer to check formally the internal consistency and the consistency of different system views.
The validation problem is about the possibility of performing experiments with the ground model, in particular to simulate it for running relevant scenarios (use cases), providing a framework for systematic attempts to falsify the model against the counter part in reality.
3.5.3 ASMs for the Formalisation Problems
ASMs solve the language and communication problem due to the notion of ASMs, which is easy to understand for both system designers, by the imperative style, and domain
experts, by problem-orientation, and allows one to tailor the ground model to resemble the structure of the real-world problem.
Using ASMs as ground models eases the verification problem since it allows one to use both inspection (through easy to understand) and reasoning (mathematical based) with other means that are appropriate. The notation does not limit the verification space.
The validation problem is solved by the operational semantics of ground model ASMs (by executable ground model or program walk through), which come with a standard notion of computation or“run”.
3.5.4 An Example of Ground Model
A small example, simplified from B¨orger’s work [17, pp. 89-91] is used in the following to show how an ASM ground model is derived from user requirements.
Example 3.1. The problem description of an order invoicing system: R0.1 The subject is to invoice orders.
R0.2 To invoice is to change the state of an order, from pending toinvoiced.
R0.3 On an order, we have one and only one reference to an ordered product of a certain quantity. The quantity can be different from other orders.
R0.4 The same reference can be ordered on several different orders.
R0.5 The state of the order will be changed to invoiced if the ordered quantity is either less than or equal to the quantity which is in stock according to the reference of the ordered product.
R1.1 All the ordered references are in stock.
R1.2 The stock or the set of the orders may vary due to the entry of new orders or cancelation of orders, or due to having a new entry of quantities of products in stock at the warehouse. But we do not have to take these entries into account.
R1.3 This means that you will not receive two entry flows, orders or entries in stock. The stock and the set of orders are always given to you in an up-to-date state. From the above requirements, we can derive the state of the system as follows:
• By R0.1 and R1.3, we have a universeORDER, with neither initialisation nor bound specified.
• By R0.2 there is a dynamic function state:ORDER → pending,invoiced.
• By R0.1 and R0.2, it implies that initially state(o)=pending for all the orders o. • By R0.5 and R1.1, we have two universes PRODUCT and QUANTITY.
• By R0.3 and R1.1, we have two dynamic functions, product:ORDER →PRODUCT,
and orderQuantity:ORDER →QUANTITY.
• By R0.5, there is a dynamic function stockQuantity:PRODUCT → QUANTITY, but it does not say when and by who it should be updated.