British Computer Society BCS Computer Aided Incremental Specification

Formal requirements specifications play an important role in enhancing the reliability and effectiveness of software development. They provide a precise, unambiguous standard for the construction of a system and raise the confidence in a planned system by enabling a proper mathematical analysis of its requirements. The construction of formal specifications can be effectively supported by computer based tools if those tools are suitably tuned to the logic of composing specifications. 
 
In this paper we discuss the possibility of providing 'intelligent' assistance during the incremental construction of well designed and reliable algebraic specifications of complex (software) systems. Based on a model of the specification process, we show how the demand to preserve certain properties in the evolving specification can be exploited to design functions of a specification tool which assist the process in an effective manner.


Introduction
Requirements analysis is the phase in software development where the characteristics of a desired system are determined and specified.The result of this activity is a collection of documents called requirements specification.These specifications play a key role in the software development process.Firstly, they represent the standard for the actual implementation of the specified system.The specifications guide the software design and construction process and serve as a point of reference for validation.Secondly, and more importantly, they form the basis for a proper judgement by clients of the usefulness of the system.Such a judgement is indispensable for a well founded decision about their investment.Given this central role, it is obvious that flaws and errors in requirements specifications can have drastic effects and must be avoided at any cost.Frequently occurring errors include incompleteness, inconsistencies and ambiguities.Such deficiencies may result in wasting large amounts of design and implementation work and often lead to a system which is unsatisfactory, from the clients point of view 1 .It is therefore essential that requirements specifications are reliable and trustworthy and it is appropriate to make an extra effort to ensure this.
Reliable specifications are more likely to evolve when a suitable notation is used and appropriate methods are adopted.Early semi formal methods such as SSADM [1] and JSP were very useful in this respect and have found their way into the commercial world.Nevertheless it is now commonly accepted that the use of formal methods during requirements analysis is the best way to establish the reliability of specifications.
There are various reasons for this belief.Firstly, the use of a formal notation ensures that specifications are precise and unambiguous.It therefore helps to avoid misunderstandings between client and designer, as well as between designer and programmers.Secondly, it is possible to subject a planned system to a thorough mathematical analysis prior to construction.Such an analysis, on the one hand, is carried out to demonstrate the feasibility of the system, in particular the consistency of the requirements.On the other hand, it can be used to raise the designers, analysts and clients confidence in the requirements by showing, for example, that a system with the specified properties achieves certain goals.Many more benefits could be listed.
Given these and other reasons, considerable effort was and still is devoted to the design of formal specification notations and specification techniques.Prominent examples for different specification paradigms are VDM [2] for state based specifications, STATECHARTS [3] for transition based specifications and LARCH [4] for algebraic specifications.
When these notations were introduced it was clear that it was not sufficient to just invent a new specification language, but that associated computer based tools had to be developed to support the respective specification techniques.For example, the tools supporting the methods and notations just mentioned are MURAL in the case of VDM, the Larch Prover for LARCH and STATEMATE2 for STATECHARTS.It was obvious that without such tools there was little chance that formal methods would ever find their way into the practice of requirement analysis.
Existing support tools vary widely in providing assistance for the task of compiling requirements specifications.In their simplest form they offer some sort of filing and text processing facilities together with tools to check syntactic and, perhaps, some semantic properties.More sophisticated systems include automated theorem proving tools to help specifiers to carry out a mathematical analysis of the requirements in order to assess their validity.This is of course a central issue in requirements analysis and because of the importance of this task a considerable amount of the work invested into specification tools centred around this problem.
On the other hand, other important aspects of constructing requirements specifications are rarely supported.For example, there is usually no explicit methodological help provided by these tools.By that we mean that the system has capabilities to guide and support a user to conduct a systematic requirements acquisition process which is based on suitable models of building formal theories.Such support would, of course, be extremely useful since it helps to ensure that the 'right' requirements go into the specification which is crucial for a successful outcome of the requirements analysis task.Work in the context of the KAOS project [5] is directed towards this problem.
Even on the more mundane level of the actual writing of syntactically and semantically correct specifications, many specification tools only support the typical 'write -check' cycle known from programming.Rather than providing active support during the writing process to ensure that the created objects are proper specifications, i.e. have certain required properties, many tools only offer editing facilities which permit the unrestricted composition of texts or graphical structures.Afterwards the user applies tools to check whether these texts or graphs are indeed specifications.If the check fails, as often happens, the user repeats the 'write -check' cycle.
It is well known that this approach is unsatisfactory and usually puts an unnecessary burden on the user.In this paper we consider a model of specification construction which makes it possible to assist users in the development of specifications in a more effective way.The aim is to relieve specifiers from the burden of simple clerical tasks and thus permit them to concentrate on the 'real' problem of determining adequate requirements for a planned system.
We will demonstrate how certain integrity constraints on specifications can be exploited to design a function of a specification tool which provides useful help in the most frequent development activity, namely adding new material to a specification.This design is realised as part of the specification tool ASPECT [6] developed by the author.

Tool Support in Incremental Specification
The purpose of requirements analysis is to determine required properties of a prospective system and to collect them in the requirements document.These properties may be given explicitly, for instance, as functional requirements of the system.Alternatively, the system requirements could be specified implicitly in terms of system goals or by the fact that the system has to fit into certain specified behavioural patterns.
In either case these specifications consist of a detailed description of certain classes of objects and relations which model entities and relationships pertinent to a specific 'domain of interest'.In software engineering the 'domain of interest' is a 'slice of the real world', i.e. an application domain ( e.g.some work environment or enterprise ), together with the intended system which is to be embedded into it.
Thus some of these classes of object model relevant kinds of entities of the application domain.Others represent types of information to be manipulated by the system.Similarly, the specified relations and functions model certain observed relationships in the application domain together with functional dependencies which determine the tasks, goals or the behaviour of the system [7].
A specification, therefore, represents a body of domain knowledge and intentions expressed in terms of the constructs and structures of a given specification language.Developing such specifications is the process of making this domain knowledge explicit and fixing the system aims.This, clearly, is an incremental process.In the first place, the application domains of systems, except in the most trivial cases, are very complex.Therefore the relevant domain knowledge which goes into a specification can only be built up gradually.
Similarly, to identify and capture desirable systems goals and properties can only be done in steps.This understanding leads to the following view of the specification process which is in line with the triplet based process described in [8] and the ideas expressed in [9].
Starting with an outline specification S 0 the specification process consists of a series of steps or activities A 1 , A 2 , ..., A n where each activity A i leads from a development state S i to a new state S i+1 .Roughly, S i is the specification achieved at stage i in the process.At each step A i specification S i is modified in a certain way to form S i+1 which is a more adequate formalisation of the domain of interest.Mostly the modifications consist in adding new material or facts to the current specification S i in order to capture more details of the domain of interest.Occasionally a specification is restructured to achieve a 'better' specification.This could, for instance, lead to a specification which is better organised or one which expresses the accumulated knowledge in terms of more adequate concepts. 3t a more detailed level each individual step involves an analysis of the specification developed so far, a decision as to which action to take (if any) and performing the necessary amendments.

S i →
Step A i : 1. examine S i and decide on action to take, 2. perform action, i.e. transform specification S i to S i+1 → S i+1

Fig. 1 A development step
In computer aided specification construction a specifier interacts with a computer based tool to perform the various tasks arising during the development process.Given the above outline model of the specification process, such a support system provides, at the very least, facilities for storing and manipulating specifications.Ideally, of course, it should offer a collection of functions which support all the activities of specification development.
Tool support may be offered in a 'passive' manner by just making the functions available.In this case the system serves as a tool box from which the user can choose functions to carry out the various tasks arising during specification steps.An advanced system may play a more 'active' role in providing interactive help and perhaps even methodological assistance by suggesting some course of action at various development stages.The value of such a tool obviously depends on the range of individual functions on offer and on the degree to which the functions are tuned to assist in the specification process.
Considering the first task of a development step, for instance, assistance could simply be provided by a text editing facility which enables the user to scroll through the specification text.A simple tool of this kind does not really support the task of examining a specification and deciding on the action to take.To permit a more meaningful method of inspecting specifications more sophisticated browsing and inspection facilities have to be developed.This is possible, for example, if one interprets specifications as hyper texts or objects with links.These link and other relationships between specifications can then be displayed in graphical form offering an insightful way of inspecting specifications and thus assisting the specifier properly in deciding on which course of action to take.
A further improvement in the support for the first task of a development step is the addition of automated theorem proving facilities with the capability to detect and point out flaws in specifications.Finding inadequacies in specifications is of course the main purpose of that activity and a tool with such capabilities would be extremely useful.Finally one could consider extending this theorem proving capability to a knowledge based decision support tool which assists in choosing appropriate actions.
The second activity of a development step is to modify a specification in order to remove certain inadequacies which were detected in the specification in the initial phase of the step.Tool support for this task is usually provided by some text or graph editing facility which can be used to achieve the desired transformation of the specification.However these facilities on their own are not sufficient.Since the goal of the development process is, among others, to compose a proper specification it has to be ensured that the transformations lead to objects which have properties required of specifications.
Only when these constraints are established is it safe to progress in the development.Therefore, in addition to the editing capabilities, functions are provided to enable users to check whether the transformed specifications have certain required properties.An example for such a function is a parsing tool to check whether an adjusted specification conforms to the syntactic rules of the notation at hand.Such a parsing component can be found in virtually every support tool.
The 'change and check' approach to modifying specifications just described is the predominant method supported by existing specification tools.However this method has several major drawbacks.
Although this method of updating specifications helps to maintain certain desirable qualities of an evolving specification with respect to the over all development, it does not help to prevent errors being introduced temporarily when specifications are changed.Rather than assisting users in preventing errors, tools based on the simple 'change and check' paradigm are only capable of pointing out that they have happened after the changes take place.If an error was introduced the user engages in another 'change and check' cycle using the feed-back from the system as regards the errors.This approach is obviously not very effective.It puts too much burden on users to ensure that no errors are introduced when they manipulate the specifications and therefore distracts from more important tasks during specification.Clearly tools which provide more interactive and error preventing support for changing specifications are called for.
Another disadvantage is that the 'change and check' approach requires that the user follows changes through to their completion because usually the checking facilities can only determine the correctness of specifications in their entirety.Very often, however, the specifier is only required to state the essential parts of a desired change and the system is capable of completing the change based on context information.This type of assistance where a tool takes over some of the task of updating specifications is obviously superior to the support provided by the simple 'change and check' technique.
This leads to the question whether it is possible to provide more effective help with regard to the principles of prevention and completion just mentioned.From the discussion above we see that changing specifications is constrained by the fact that the object which results from these transformations must be a proper specification.This fact can be exploited in the design of improved support functions by permitting a higher rate of interaction with the user and by building the goal that the functions have to preserve certain properties of specifications into them.In the remainder of this paper we show that this is a useful design principle.
To illustrate this point consider, for example, the case where specifications are changed by adding new material.Rather than permitting the user to write text freely and thus to introduce errors as regards the syntax of specifications, a syntax directed editor can assist the user more effectively since it has syntax knowledge built into it.A tool of this kind can help to prevent syntax errors, for example, by offering syntactic templates to the user to be filled in.In addition, since editing and syntax checking are closely coupled, it is possible to catch errors as early as possible and assist in their immediate correction.
Another example of an application of the design principle mentioned before is discussed in [10].The objective there was to ensure that the specifications evolving during the development process are comprehensible and clear.This is achieved by maintaining these qualities throughout the development.Thus while the specification is continually transformed towards an adequate formalisation of the domain of interest at hand the property 'well-structured' is preserved, i.e. it is considered as an invariant of specification development and therefore of the functions which supports the modification of specifications.The need to preserve this invariant is used in the design of the functions supporting the updating of specifications in such a way, that the specifier only has to carry out part of a required change while the system automatically completes the necessary modification to achieve a well-structured specification.
In the present discussion we consider the problem of maintaining the quality of well-sortedness during the construction of specifications.We present an analysis of this task and show how this invariant leads to a function of a specification support tool which provides effective help in a similar manner as in the previous example.

3.
Adding Laws to Specifications.
A basic action in specification construction is to add new facts about the domain of interest to the specification developed so far.With tool support this can be achieved, for instance, by invoking a function, say add_law, with one or more new facts and the specification to which they have to be added as arguments.The result is a new specification with the new facts integrated into the argument specification.
From the point of view of the previously discussed model of the specification development process the argument specification forms part of the development state and invoking add_law corresponds to a transition to a new state.We call add_law a transaction function and its use a transaction with the support tool.
1st Irish Workshop on Formal Methods, 1997 The specification under construction is one component of the development state.As another component we take some section of that specification.This section we call the focus.The focus component of a state reflects the situation that at the stage of the development represented by that state the user is particularly interested in that part of the specification given by the focus.This choice of focus will influence the behaviour of the transaction functions.The focus can be compared to the cursor concept in texts.Another important component of the state, which we ignore here, is of course the interface to the user.
The facts to be added are expressed in terms of the structures of the specification notation at hand.These could, for example, be graphical constructs as in the case of Statecharts.We use as notation for our specifications the SPL notation which is the language base of the ASPECT tool.SPL provides language constructs to write algebraic specifications in a similar style as in [11].Further details about the SPL notation can be found in [12].Given this choice of specification notation facts are expressed as logical statements called laws. 4hus, in formal terms, we consider a function of the form op add_law : law, state -> state where, for the purpose of this discussion, we take as states pairs with a specification and a focus as components.Formally Not every pair ( S, C ) corresponds to a proper state.We have already mentioned the condition C ∈ S, i.e. the current focus C must be a component of the specification S. Other conditions for components are which ensures that there are no multiple definitions of notions and makes sure that each notion referred to in a law is defined5 .Because of (1) it is defined exactly once.The signature of a law is defined as where O 1 , … , O n are the distinct operations occurring in the law.Signature inclusion is defined as Σ (S 1 ) ⊆ Σ (S 2 ) ⇔ sorts(S 1 ) ⊆ sorts(S 2 ) ∧ ops(S 1 ) ⊆ ops(S 2 ).
Similarly for operations we have with ∩,∪ suitably extended for pairs of sets and ∅ standing for a signature where the sets of sorts and operations are empty.By sorts(O) for an operation O we mean the set of argument sorts and target sort listed in the profile of the operation.Other conditions might be Property ( 4) states that if a component defines some sorts then at least one of the argument or result sorts of each defined operation of the component must be one of these sorts.Condition (5) prevents laws from occurring in components where none of the notions referred to in the law are defined in the component.Properties ( 4) and ( 5) are part of the conditions which establish that specifications are suitably structured.For details see [10].These are some examples of properties which might be required for specifications.If a state satisfies these conditions we say the state is well-formed.Any transaction with the ASPECT tool has to preserve wellformedness: it is an invariant of transaction functions.Obviously, if all transactions leave this property invariant we are assured that the end result of the specification development also has this desired property.Therefore, with op well_formed : state -> bool added to component state above, the intended function add_law must satisfy law well_formed(S) ⇒ well_formed( add_law(L,S)) (6) That means while add_law changes the specification S of the current state it preserves the property well_formed.Law (6) expresses a goal of the system to be designed.This goal can be used to derive functional properties of operation add_law.

Well-sorted Specifications
We now consider a particular well-formedness condition, namely that of laws being well-sorted.This means, essentially, that operations occurring in laws are used in line with the profile given in their definitions listed in the signatures.It corresponds to typing conditions in typed programming languages and can be checked automatically.The advantages of having a typed programming language are well known.Types add some redundancy to programs and provide a great help for the programmer to avoid errors.The same is true in the case of specifications.
Various solutions for checking typing conditions exist, e.g.[13].Mitchell [14] gives a detailed account of the issues involved.We are considering this task in an iterative, incremental context.This creates some additional problems.
Formally we captured the property of well-sortedness by specifying a predicate well_sorted : term -> bool defined on terms and states.To this end we first define terms which are taken to be boolean expressions for simplicity.1st Irish Workshop on Formal Methods, 1997 (* Symbol classes identifier, sort and functor are disjoint sets and assumed to be given.Variables are identifiers starting with a capital letter whereas a sort symbol is an identifier starting with a small letter.*) term = { op var -> term, oper -> term, oper( terms ) -> term so : term -> sort, so : seq(term) -> seq(sort), fully_sorted : term -> bool Thus a term is a variable (e.g.X,Y...), a constant (e.g.1,c...) or a composite term like f(A,c: → s).A term is fully sorted if all variables and operators are given with their profile.That means variables are of the form X:s and not just X.Also operators are of the form f:s 1, ...,s n →s 0 or c:→s 6 and not only the functors f or c.
Note that for fully sorted terms the function so is defined for all subterms.This function is needed later.Here the symbol ⊆ denotes the subterm relation which can easily be defined in a similar way to so.V:var refers to a variable V of sort var which can be coerced by var -> term to a term.The operation definition var -> term is a shorthand for _ : var -> term and oper ( terms ) -> term is short for _ ( _ ) : oper,terms -> term.By default a specification component of the form sp = ... defines a sort sp.Now the state specification is extended by the following operations.
A term t, therefore, satisfies the sorting condition sort_cond in some state s if it is • fully sorted 6 c:→s is a shorthand for c:λ→s where λ is the empty sequence of sorts .A term x .y denotes the addition of an element x to a sequence y.
1st Irish Workshop on Formal Methods, 1997 • the sorts of terms in argument positions match the argument sorts of the operation applied • each operation occurring in a law is defined in some component ( condition ( 2) ) and • every variable name is associated with exactly one sort.

Refining the Operation add_law
As stated above the property well-sorted constitutes part of the predicate well-formed and has to be kept true when the state is modified in order to meet condition (6).We now use this requirement to determine laws which specify the behaviour of add_law in more detail.

Adding fully sorted Laws.
With the definitions above the specification of add_law can be refined as follows.
law well_sorted(L,S) ⇒ add_law(L,S) = merge( ( Σ(L), {L} ) , S ) Clearly, if the law to be added is well sorted, i.e. it is fully sorted and satisfies the sorting condition, it can be added to the specification without violating the well-sorted condition.This can be achieved using operation merge.
Applying merge in the way merge( (Σ (L),{L} ) ,S ) integrates law L and the notions in Σ (L), i.e. sorts and operations occurring in the new law, into state S.This is done by either identifying existing notions or adding new notions to (possibly newly created) components.This process occurs under the constraint that a well-formed state has to be achieved.Thus, for instance, creating new components and placing laws and notions is partially constrained by conditions ( 5) and ( 6) above.The ASPECT tool exploits such facts to perform merge with as little user interaction as possible (cf.[10]).

Adding partially sorted Laws.
An operation add_law with the properties as specified in ( 7) is obviously not very useful.It forces the user to enter laws with full sort information.For example, f(X)= g(X) would have to be writtten in the form f:a →b(X:a) =:b,b→bool g:d→b(X:d).This is undesirable, particularly, because the sort information can be filled in automatically once operations f and g are identified in f(X)= g(X).We therefore admit as arguments of add_law, terms which may not be fully sorted.For example, a term like f(X)= g(X) ( with the usual infix notation for equality ) which is not fully sorted since the sort of the variable X and the profile of f and g is not fixed is permitted.Such a law has to be transformed into a well sorted law first, before it can be added using the merge operation.This can be expressed by weakening condition (7) as follows.
The relationship L' ~ L in S expresses the fact that L is the same as the well-sorted term L' except that some of the sort indications of variables or operations in L' have been dropped.We say L is a partially sorted term for L' in S. Formally this is expressed in terms of a predicate similar which is related to the erase function in [14].
op _ ~ _ in _ : term,term,state -> bool, similar : term,term -> bool, similar : seq(term),seq(term) -> bool, law T ~ T' in S ⇔ well_sorted(T',S) ∧ similar(T,T'), similar( T,T ), similar( X, X:S ), similar( X, X:→S ), similar( X,X' ) ⇒ similar( F(X), F:D→R(X') ), similar( λ ) = λ, similar( X.Y ) = similar( X ) .similar( Y ) 1st Irish Workshop on Formal Methods, 1997 Law (8) is not yet adequate since for a given term L there may be several well-sorted terms L' such that L' ~ L in S and hence the operation add_law is not well defined.This is due to operation overlay.If, for instance, there are definitions f:a->b and f:c->d present in a state S then f:a→b(X:a) ~ f(X) in S and f:c→d(X:c) ~ f(X) in S holds.We have to restrict the choice of L' such that there is exactly one for any L in a given state S.This is achieved in two steps.First a term is transformed into a fully sorted term by the following operation.The operation any produces a new sort symbol each time it is used unless the sort information is explicit in a term L. The newly introduced sorts are called flexible sorts.
In the next step a mapping from flexible to concrete sorts is constructed.First we consider fully sorted terms L which may contain flexible sorts.We take into account that in many cases some of the functor symbols in L are the names of operations already defined in the specification to which the law should be added.This makes it possible to fix the profile of some operations by suitably renaming some of the flexible sorts.The rest of the operations are new and interaction with the user is required to determine the flexible sorts remaining in their profile.The complete step can be formalised by introducing The intention is that shared( L, Sp ) produces a one-one mapping or renaming of flexible sorts in L to concrete sorts such that applying the renaming to a certain sub-signature of L is that sub-signature of Sp which contains exactly the notions which are considered to be the same in Sp and L. Thus determining shared corresponds to operator identification.Operation shared must determine exactly one suitable renaming.Operation new produces a renaming for the flexible sorts left over after applying the renaming generated by shared.
Note that corr ( sort, sort ) is the SPL way of specifying that renaming is an instance of the corr specification schema with actual parameters ( sort, sort ).Hence objects of sort renaming ( which is implicitly introduced by the specification name renaming ) are finite one-one mappings from sort symbols to sort symbols.Schema corr provides operations to manipulate mappings including an operation to apply a mapping.A generalised version for terms is used in the above law.Its specification is trivial.

Maximal Fit
In a first attempt, operation shared can be characterised by the following law.
1st Irish Workshop on Formal Methods, 1997 Here we refer to the concrete sorts in a law by concrete(L).This operation can easily be specified.
There is still the possibility that several groups of operations of equal size can be identified.In this case the appropriate action is to present the options given by the matches to the user so that s/he can choose.This is obviously an easier task for users than having to provide detailed sort information in every law.
Furthermore, the situation may arise that an operation is identified whereas the user intention is to introduce a new operation.This case is handled by asking the user to confirm the choice of match and offer a possibility to revise previous decisions.

New Operations
After identifying some operations in a law with existing operations using shared, the task remains to determine the profile of newly introduced operations.This task is captured by operation new.The operation is intended to determine a renaming for the flexible sorts left over after applying the renaming generated by shared.
The situation where new operations and sorts are introduced while adding laws occurs quite frequently in incremental specification.Adding one or more laws corresponds to formalising new facts about the domain of interest.Often this involves the introduction of new concepts, i.e. sorts and relationships.Naturally the user might want to choose suitable names.While the functors of new operations are stated in the law, there may still be flexible sorts left in their profile.
The simplest route one can take in such a situation is to leave the flexible sorts as place holders, integrate the new material, i.e. sorts, operations and law, to form a new state and provide a function to explicitly rename sorts.In this case new just needs to generate the identity mapping from flexible sorts to flexible sorts.
Alternatively one can engage in a form based dialogue which enables the user to pick appropriate names for the flexible sorts.The result of operation new is the user determined correspondence of flexible sorts and chosen sort names.

Conclusion
In this paper we outlined a model of the process of constructing formal requirements specifications.We have shown how this activity can be effectively supported by a computer based tool which is tuned to the logic of incremental composition of specifications.Given, among others, the objective of developing well-sorted specifications we described how this goal can be exploited to design and specify a mechanism to deduce the sort of variables and profiles of operations in laws.This permits the user to submit laws with a minimum of sort information attached.
While part of determining the signature of laws is done automatically by the tool based on the state of the development process, there are situations where the tool has to engage in a dialogue with the specifier.This interaction only takes place if the information available to the tool is not sufficient for one specific course of action.
One might argue that this is a disadvantage.In fact we believe that this is a great advantage since the decisions and information demanded from specifiers during these dialogues require a deeper insight on their part into the role of the various notions specified and thus enhances the specifiers understanding of the specification at hand.This better insight is clearly of great benefit.This paper also demonstrates our particular approach to specification construction, i.e. specification by goal oriented incremental specialisation.According to this approach requirements specifications are built by alternating between stating system goals and gathering and formalising facts which reflect the application domain better and/or characterise system functions more specifically.Reasoning at each stage that the specified goals are achieved by the system functions defined so far ensures that the requirements in the final specification are satisfactory, provided the system goals are captured adequately.The driving force behind the specification process is the need for the planned system to achieve certain goals while fitting into a specific application domain and supporting certain desired use scenarios.This methodological principle forms the basis for the design of the ASPECT specification tool.Current work is mainly concerned with studying the principles of goal oriented incremental specification with the aim to build methodological knowledge thus gained into the tool.This approach, however, has its limitations.There are situations where functional requirements cannot be derived from systems goals because it is difficult to formalise these goals.For instance, the key decision in 1st Irish Workshop on Formal Methods, 1997 our development of a function to support sort inferencing was the choice of context to be used for operation identification.This determines the effectiveness of the tool support.To judge the value of this choice it is necessary to use operation add_law in practice because it is difficult to specify the concept of 'effective support' precisely.Evaluating functional requirements with respect to goals of this kind can be done by constructing a prototype of the partially specified system.Experiments with the prototype often lead to a revision of the specification at hand.This new specification is the starting point of another phase of goal oriented specification development.Thus deduction based and engineering type approaches to specification construction complement each other.Integrated specification tools should support both techniques.
state = ( spec sp, component cur), spec = set( component ), component = ( signature Σ , set ( law ) Λ ), signature = ( set( sort ) sorts, set( operation ) ops ) Thus a state St is a pair ( St_sp, St_cur) where St_sp is the specification under construction, consisting of a set of component specifications.Component C_cur ∈ S_sp is the current focus of the user.In SPL we can refer to the specification of a state St by St_sp and to the focus by St_cur.Each component is a pair ( C_Σ , C_Λ ) made up of a signature C_Σ = ( C_Σ _sorts, C_Σ _ops ) and a set of first order sentences C_Λ, called laws.The signature lists the notions defined by the component and the laws describe properties of these notions.Sorts specify different sets of objects.Operations which are of the form f : s 1 ,... , s n → s or f : → s represent relevant relationships between the various object sets.The latter are constants or individuals of sort s and the former describe functions which transform tuples of objects of argument sort s 1 ,... , s n into objects of target sort s.The sort information s 1 ,... , s n → s and → s, respectively, is called the profile of the operation.The signature of a specification S = ( C 1 , .... , C n ) is the union of signatures of its components.That means, based on a suitable union operation for signatures, we define Σ(S) = 7 1≤ i≤ n Σ(C i ).