focuses on the specification of goals by Abstract Data Types. ... can be met. The functional specification of a process is given by its characteristics. (Processchar) ...
Formal Specification of Goals Reuse of modular specifications by refinement and specialization Christine PIERRET-GOLBREICH LR I, CNRS URA 410 Université Paris Sud 91405 Orsay Cedex, France Email: pierret @ lri.lri.fr
Abstract Meta-reasoning for flexible problem-solving and reuse of methods in Knowledge Engineering both needs a clear separation between the statement of problems or expected goal, and the description of methods to solve problems. Various formal languages have been proposed to formalize the methods (DESIRE, ML2, KBSSF, TFL etc), however the formal specification of goals has not been considered until now. This paper precisely focuses on the specification of goals by Abstract Data Types. The incremental development of a goal specification in reusing modular specifications by successive refinement and specialization is stressed. The specification is based on PLUSS, a language offering several mechanisms for reuse: genericity, enrichment of completed modules or of draft modules. The assignment problem type, and examples from Sisyphus I and Sisyphus II are used for illustration. 1. Introduction Meta-reasoning for flexible problem-solving and reuse of methods in Knowledge Engineering both needs a clear separation between the problems (the what) and the methods (the how). Goal and process are the two primitives we use to explicitly define these components. A goal refers to a functional specification stating what is expected to be achieved. A process refers to an operational process indicating how to meet a given functionality. This view introduces an important question, both for Knowledge Acquisition and Verification&Validation, the relevance problem : how to relate a relevant process to a goal. Indeed, on the one hand, from the dynamic viewpoint of problem-solving, an agent or a method is relevant to achieve a goal only if its functional specification matches the goal which is specified to be met. On the other hand, from the static viewpoint of Knowledge Acquisition, use or reuse of methods, needs to be aware both of the expected goal and of the specific functionality of the methods. Our interest concerns the benefits of KBS formal specification. In the context of task-method approaches, several proof obligations have been identified : correctness proof, efficiency proof, applicability proof, relevance proof etc. (Fensel, 1995). Our current work is concerned by the relevance proof, that is proving that a process is relevant to a goal. However, it is first necessary to define a formal framework for specifying all the ingredients involved in such proofs: goal, method, method functionality, method underlying assumptions etc. In (PierretGolbreich & Talon, 1995) we have proposed a formalization of methods and agents in using Abstract Data Types (ADTs). In (Benjamins & Pierret-Golbreich, 1995) we present a conceptual framework for task-assumptions together with a first attempt of formalization in FOL of assumptions. Until now, goals and method functionality were only informally described in natural language. This paper is focused on the formal specification of goals. The work is based on the TASK approach which states a clear separation between problem specification and problem solving methods. In TASK, a problem-solving situation (Situ) is the declarative description of a problem to solve. A situation is characterized by its goal and case. A problem solving process (process) refers to a dynamic process indicating how a functionality can be met. The functional specification of a process is given by its characteristics (Processchar) which meaning is close to that of a PSM functional specification (PSMdec ) in (Fensel, 1995), while the Task-module competence (TM Comp) defines the agent competence specification (Pierret-Golbreich, 1994). A goal can be matched with a relevant process or TM if it is possible to prove that the functional specification of the process or TM fulfills the expected goal (Fig. 1). 1
WHAT ?
Situation Goal Case
HOW ? Process
applied-to
match Task Module
what
Characteristics
Competence
how
Operational specification
Operational specification Task Module
Situation
Process
Figure 1 : Clear separation between problem specifications (goals) and problem solving processes (task, process)
The paper presents a formal specification of goals based on ADTs but to prove that a process is relevant to achieve a given goal is out of scope. In particular, the incremental development of a goal specification by reuse is stressed. The specification is based on the PLUSS language which offers several interesting mechanisms for reuse : genericity, enrichment of a completed module (spec) using the use construct or enrichment of a draft module (draft) using the with construct. T Section 2 quickly summarizes the TASK methodology. Abstract Data Types basic concepts and the main constructs of the language PLUSS are presented Section 3. Section 4 proposes a formalization of goals. Section 5 presents the incremental development of goals by progressive refinement of a generic goal. The assignment problem, and examples from Sisyphus I and Sisyphus II are used for illustration. 2. TASK Our work is based on TASK, a task oriented framework. which can be related to other taskmethod frameworks like (Puerta,Agar,Tu, & Musen, 1992), (Chandrasekaran,Johnson, & Smith, 1992), (Steels, 1990). The basic principles of TASK are the following : • The description of what needs to be achieved and how to perform it are clearly separated. • Expertise is modeled as several agents which cooperate to solve a global problem. • Expertise is divided into three categories : domain, problem-solving, strategic knowledge. Dynamic knowledge concern the two latter : problem-solving knowledge refers to the operative knowledge which operates on the domain data, while strategic knowledge refers to the knowledge used to get (to select or to build) the right problem-solving knowledge to be applied. • Domain, problem-solving, and strategic knowledge are interdependent, like in the Generic Tasks12, 13 Interaction Hypothesis. Related knowledge are connected together within an agent. Each agent has a partial view of the problem solving. He is assigned with a specific competence and with own local knowledge available to achieve his competence. T ASK terminology for dynamic knowledge includes the terms of Situation, Task-Module, Process, Strategy (Pierret-Golbreich, 1995). 2.1. Problem-solving situation In TASK, a problem-solving situation, in short Situation, is the concept used to make explicit the problem to be solved (the what), independently of the way to achieve it. It can be
2
considered as close to task-definition in CommonKADS1 (Breuker & Van de Velde, 1994), however differs from it on several points. A problem-solving situation is a declarative description of the problem type meaning "I want to achieve that type of functionality for that type of case". Each application corresponds to a specific situation : a specific functionality (goal) needs to be achieved for different cases having the same specific pattern (case). A situation specification is composed of two parts Situ Case and Situ Goal (Pierret-Golbreich, 1994) (Pierret-Golbreich & Hugonnard, 1993). The situation goal (Situ Goal) refers to the functional specification of the problem indicating what is required to be achieved. Diagnosis, assignment, parametric design are examples of generic goals. Sisyphus I office allocation, VTparametric design, are examples of application specific goals. The situation case (Situ Case) refers to the case specification indicating for which type of case this goal has to be met. On its part, Situ Goal defines the type of the expected. Situ Goal and Situ Case don't vary for a given application. The same goal is instantiated on different instances of the case. Therefore, different instances of Situ Case are created for the different cases under resolution within the application. For example, the Sisyphus I office allocation can be achieved for different teams : YQT, PROTEGE-GROUP, IASI-GROUP etc. Situ Case : each case is specified in terms of Input, Output. which describe the problem input/output types. Situ Goal : each goal is a tuple {Source} {Pre} OPERATION {Target} {Post} specified in terms of an Operation applied to some Source satisfying some preconditions Pre, in order to meet some Target so that to satisfy some postconditions Post (Pierret-Golbreich, 1994). Two different applications can share the same goal but have distinct cases. For instance, Sisyphus I offices-allocation and Sisyphus I VT-assignment share the same goal assignment, but have distinct specialized cases: for offices-allocation the input are offices/members while parametrs/values for VT parametric design. 2.2. Problem-solving Process The term of problem-solving process, in short process, is used for any type of operative knowledge. It is a knowledge level description of some means of solving a problem in terms of Input, Output, Precondition, Postcondition, Resources, Body, Assumptions. Each process refers to a primitive or a composed inference process (deterministic or not). When a process is executed, an instance of the process is created. 2.3. Strategy The strategic knowledge is described in terms of focus and strategy. Foci are the building blocks, strategies express which foci have to be activated and when. A focus describes an heuristic which aims at favoring some type of problem-solving knowledge. It is expressed as a set of constraints operating on the problem-solving knowledge. The criteria of selection can be any of its feature : type of Process, Task-Modules, Input/Output, Precondition, Postcondition, Resources, Operation, Assumptions etc. 2.4. Task-Modules An intelligent agent knows what to do when. In TASK the term of TASK-MODULE (TM) refers to such a knowledge level model of an agent and a KBS is modeled in terms of multiple TMs which interact to solve a problem. A TM is composed of two parts : a "functional" part and a "knowledge" part. The functional part sets the situations the TM is relevant to, i.e. defines its range of competence. The knowledge part sets the TM knowledge available to achieve this competence. The specification of a TASK-MODULE includes both : - the specification of its Competence in terms of its case and goal description - the specification of the knowledge related to this competence, in terms of Resources, Processes, Strategies. which respectively refer to the TM specific domain models, processes and strategies. In short, a TM sets the goal to be met and the knowledge that is suitable for it. 1 But it must not be confused with it or with a task, the difference being that, conversly to a task-definition, a
situation is a concept defined on its own, completely independently of that of task. A situation is neither a part of a task, nor is linked to a task body.
3
The conceptual (semi-formal) language of TASK and its modeling primitives are described in , (Pierret-Golbreich, 1995). A first step towards the formal specification language TFL, and in particular, the formal specification of Task-Module, Process, Strategy is proposed in (PierretGolbreich & Talon, 1995). One important original point of TFL is that dynamic knowledge, i.e. processes and tasks, have both static and dynamic semantics. First, they can be considered as operative knowledge which are applied to data. Second, they can also be considered as data when the control processes are applied to them. Another original point is that characteristics of a composed process are automatically derived from its structure. A process or a task specification is made of two parts : one part describes how to apply the process or the task to data (e.g. axioms for inference application), the other part describes its functionality (e.g. axioms for inference characteristics). However, the formalization of goals was still lacking in TFL until now. Therefore, in order to enable future work on the relevance proof, this work is now focused on the goals formal specification. After having presented the main mechanisms for reuse of the specification language PLUSS, the benefits of PLUSS for specifying goals is enhanced. 3. Algebraic Data Type The basic concepts of algebraic specifications are first presented 2. Then the particular constructs of the PLUSS algebraic specification language which are useful to understand the formalization in the next sections are quickly described. 3 . 1 . Basic concepts An ADT presentation (or more simply a specification) is a triple (S, F, A) where (S, F) is a signature denoted ∑ and A is a set of first order logic formulae. A signature is a finite set S of sorts (i.e. type-names) and a finite set F of operation-names with an arity defining their domain and codomain (in PLUSS, the signature also defines a set of predicate-names). The axioms A describe the required properties for the operations (and predicates). An example of specification is the specification Bool (Fig. 2). A ∑-algebra (model) is characterized by one or several sets of values associated to each name of sort (carrier sets) and some operations and predicates on these sets for each operation or predicate declared in ∑. An example of ∑-algebra is the set of booleans as traditionally defined with the operator ¢ and the constants TRUE and FALSE. A finetely generated ∑-algebra is an algebra where each value of the algebra can be denoted by a closed ∑-term. GEN(∑, A) is the set of all finetely generated ∑-algebra that satisfy the axioms A. If these axioms are restricted to equations or Horn clauses, the class GEN(∑, A) contains a unique ---up to isomorphism---particular algebra, the so called initial agebra.3
spec Bool sorts : bool; operations :
end
% specification name % sort name
true: æ bool; false: æ bool; - or - : bool*bool æ bool; axioms : true or b = true; false or b = b; where : b : bool; Bool
% constant of the sort bool % operation name
% variables
Figure 2 : Specification of booleans.
2 3
see (Ehrig, & Mahr, 1985) for a complete presentation. the initial algebra is isomorphic to the quotient of the ground term algebra by the smallest congruence relation compatible with the axioms.
4
The syntax which is adopted in the paper is that of PLUSS, a specification language developed in the framework of the ASSPEGIQUE project (Capy, 1987). The main characteristics of the language are described in (Bidoit,Gaudel, & Mauboussin, 1988). In all the specification modules, the axioms are expressed by first order logic formulae built on atomic formula with the connectors : ', ¢, ⇒ , iff. The atomic formula are either equations or assertions on predicative terms using the constructions is-true and is-false. The semantics associated with a specification in PLUSS is of the ''set of models'' type (opposed to the initial approach where the initial algebra is considered as the semantics of an algebraic specification). The semantics of a PLUSS specification (∑, A) is defined as the class of finetely generated models that satisfy the axioms of the specification (∑, A), and that moreover comply with hierarchical constraints (no junk and no confusion). Thus the class of models of a PLUSS specification is in general strictly included in GEN(∑, A). 3 . 2 . Reusability mechanisms in PLUSS One main originality of PLUSS is to state a clear distinction between completed specification modules introduced by the keyword spec and under design specification modules introduced by draft or sketch (Bidoit, 1989), (Bidoit,Gaudel, & Mauboussin, 1988): •
•
Completed specifications modules are "implementable" modules. A completed specification is considered to be finished. It means that the class of models of a completed specification is fixed and must not depend of the context of its use. In particular, it must not change if the specification is used in a more complex specification. Thus, once a specification is considered to be completed, the class of all its possible implementations is fixed. This requirements induce very strict constraints on the modular structuration of a specification and on the content of a module. Sketch and Draft are "not yet implementable" specification modules. At the beginning of the specification process, the above constraints may be too constraining. Indeed, more often the set of values is not yet fixed, the operations to be defined and their properties are not fully known. The signature and the axioms cannot be fixed but have to be further refined. This has motivated the introduction of Sketch and Drafts in PLUSS which constitute a category of specifications clearly distinguished from completed specification.
The different PLUSS constructors and the reusability mechanisms offered are now quickly presented : • Spec and use construct Each standard specification is introduced by the keyword spec followed by the module name. The enrichment of completed specifications is realized by the use construct. The use construct is a mean for incrementally adding new features (sorts, operations, predicates) to previously defined specifications. It is used to enable a modular development of specifications in developing specifications modules separately then assembling them together. The use construct has a very precise semantics : using a spec must not change the class of its models (hierarchical constraints). This property makes it possible to develop an implementation of some spec while reusing it in another spec. The example of specification of integers spec Nat (§ 5.8.1.1) is a typical example of a spec built on the top of another one the spec Bool. The sufficient completeness property (all the terms of a sort of ∑ can be obtained by the operations that have been declared in (∑, A)) and the hierarchical consistency property (two equal ∑-terms were already equal in the used specification (∑, A)) are sufficient to prove that a use is correct. This enables to validate the composition of modules. In order to avoid trivial models, basic modules which have the initial semantics, can be specified using the basic spec construct (e.g. basic spec Char § 5.8.1.2). • Draft and with construct A draft specification is introduced by the keyword draft followed by the module name. The enrichment of a draft is realized by the with construct. In a draft the generators are fixed (opposed to a sketch), nevertheless it is still possible to modify their properties in order to adapt them to a particular need. In particular it is possible to modify the definition domain of
5
their generators or to collapse some values denoted by generators composition. GENERICconstrained_assignment(Component, Resource) is an example of enrichment of the draft GENERIC-assignment(Components, Resources) which precise the precondition of its generator assign (§ 5.3). However, like for the spec it is impossible to introduce new values for the sorts already predefined in the required spec. With is less rigid than use. Enrichment of drafts has not to comply with the same hierarchical constraints as the spec ones. The hierarchical consistency property is sufficient to prove that a with is correct. Drafts can enrich spec with the construct use (e.g. GENERIC-constrained_assignment-1 § 5.3) but not the reverse. • Parametrization Parametrization enables to use generic specifications, so it prevents from writing several versions for various specifications of the same pattern. For example, a parameterized specification of Set avoids writing several specifications such as set-of-integers, set-of-char etc. A generic specification is introduced by the keyword generic spec. A generic specification is parameterized by formal parameters. A formal parameter specifies the minimal properties that actual parameters must fulfill in order to be suited to replace it in the instantiation process. A generic specification is similar to an ordinary specification, but all the objects in the signature are not declared. Example of generic spec are the generic spec Set(Resource) (§ 5.4) or the generic spec SISYPHUS I-assignment (Lab, Member) (§ 5.6). The parameters Lab and Member are instantiated by the actual parameters specifying the case to solve : here, LRI offices and YQT members (§ 5.6). Parametrization can be used with spec or draft. In conclusion, three different mechanisms for reusing specifications have been described. Each of them is suited to a specific reusability meaning. Enrichment of completed specifications by a use corresponds to reusing software based on their formal specification. On the opposite, enrichment of draft modules by a with corresponds to reusing specifications in order to develop new ones. Finally, genericity is another essential reusability mechanism, since it enables to obtain several instances of a same pattern of specification. Thus, it can be noted that PLUSS can be considered both as a specification language and as a language for the development of specifications. Section 5 demonstrates that these different types of reusability are also relevant in Knowledge Engineering. 4. Formalization of goals Our present interest concerns the formal specification of situations and in particular of goals. The specification which is proposed here fits the Hoare triples {ϕ} OP {ψ} where ϕ and ψ are logica formula called precondition and postcondition. The Hoare's precondition ϕ specifies properties that must hold for the I/O variables of the program OP so that OP can be achieved. The postcondition ψ specifies the properties that must be fulfilled by the I/O variables after OP has been completed. A goal is a functional specification of a problem. Like the Hoare triples it is described in terms of {ϕ} OP {ψ} but in complement the source and target objects are explicitly defined. A goal is a tuple (S, {ϕ}, OP, T, {ψ}), where OP is an operation which operates on source objects S and provides Target objects T. Like the Hoare's precondition the precondition ϕ states restrictions on the Source and/or Target objects that must hold so that the operation OP can be applied. The postconditions ψ state properties that must be fulfilled by the Source/target objects after the operation is completed. A goal is defined by the following constituents : • an operation: the operation which generates the Target objects • a source : the source objects of the operation • a target : the target objects of the operation. • a precondition : the operation can be applied iff some precondition is satisfied • a postcondition : after the operation is completed some postconditions are fulfilled.
6
For example, the assignment goal (Fig. 8) is defined by the constituents : • source : the source objects of an assignment-problem are Components and Resources • target : the target object of an assignment-problem is an Assignment. • operation: the operation assign generates an Assignment from Components, Resources and a partial assignment. • precondition : assign can be applied iff the precondition assign-pre is satisfied • postconditions : after assign has been achieved two types of postconditions Constraints and Requirements must be fulfilled. The syntax and semantics of a goal is given by the following draft specification Generic Draft Goal which describes the data structure goal in general (Fig. 3). par Source sorts : source; end Source
par Target sorts : target; end Target
Generic Draft Goal (Source, Target) sorts : Source,Target; operations : Op : Source * Target æ Target; predicates :
pre : Source * Target; post : Source * Target; complete : Target; precondition : Op(s,t) is-defined iff pre (s,t) is-true axioms : pre (s, t) is-true ' complete(Op (s, t)) is-true ⇒ post(s, Op (s, t) ) is-true
% axioms PRECOND specifying the precondition by defining properties of Pre % axioms POSTCOND specifying the postcondition by defining properties of Post
where :
s : Source, t : Target
end GOAL (Source, Target)
Figure 3 : Specification of goals
This definition of a Goal can be compared with Aben's inference specification. The operation OP is not supposed to be primitive as the inference Body is assumed to be in (Aben, 1995). This operator specification is of main importance since it defines how this operator generates the target objects. OP is specified by its own. Its specification is not redundant with that of the postconditions which on their part describe the properties to be fulfilled by the source/target objects. We have chosen to specify a goal by an operation but other options should have been possible, for instance a goal may be specified in terms of state (a required condition on a final state) rather than in terms of operation. In Benjamin's framework and Aben's associated formalization, a PSM has a head and a body. The head has a goal and input, output roles while the body consists of a subtasks decomposition with a control-flow. A goal is informally defined in Benjamins whereas expressed as a postcondition by Aben ((Aben, 1995),.p.139). Section 5 presents the formalization of several goals of different genericity level. It shows the benefits of the algebraic language PLUSS both for the reuse of modular specifications, and for the incremental development of a specification by successive refinement of drafts, in the framework of a goal specification. The example used to illustrate such an incremental development of a goal specification is assignment. It is interesting to note that the following examples of goal specification bring to light that the notion of reuse in Software Engineering is quite different from that commonly viewed in Knowledge Engineering.
7
5. Formalization of assignment-problems Assignment is a generic category of problems where resources needs to be given to a set of components fulfilling several constraints. 5 . 1 . A generic problem type A typology of problems has been proposed in CommonKADS distinguishing eight types of problems. Assignment has been identified as one of those Problem Types (Breuker & Van de Velde, 1994) and defined as a synthesis task, characterized by the following : • it operates on at least two sets of objects • the solution consists of establishing assignment relations between objects of the different sets, such that defined requirements and constraints are satisfied. The two sets of objects, respectively called demands and supplies by (Poeck & Puppe, 1992), components and resources by (Schreiber, 1992), or sources and targets etc play two different roles in the assignment . In the following Schreiber's terminology is used. 5 . 2 . Assignment-problems An assignment-problem is a description of the desired artifact which can be defined in terms of the sorts Resources, Components, Assignments, the conditions Requirements, Constraints, and the operation assign as follows (Fig. 4): • source : the source objects of an assignment-problem are Components and Resources • target : the target object of an assignment-problem is an Assignment. • operation: the operation assign generates an Assignment from Components, Resources and a partial assignment. • precondition : assign can be applied iff the precondition assign-pre is satisfied • postconditions : after assign has been achieved two types of postconditions Constraints and Requirements must be fulfilled. Requirements are postconditions that specify the properties required for an assignment in general. Constraints are additional specifications that precise when an assignment is a valid solution : constraints define the criteria of validity of a solution. The distinction between requirements and constraints is often fuzzy. The distinction introduced here is grounded on their role in the assignment process Requirements are used for restraining the search space while Constraints are used for evaluating a proposed solution. When several solutions are possible, additional constraints are often specified to select a preferred solution usually referred by the term Preferences.. Requirements Constraints Component assign
Assignment
Resource Assign-Pre Input/Output concepts
Operation
Static knowledge
Assignment-Goal: ¥ source ¥ target ¥ operation ¥ precondition ¥ postcondition
=> => => => =>
Components, Resources Assignment assign Assign-pre Requirements,Constraints
Figure 4 : Assignment problem
8
More precisely, an assignment-problem can be defined by a tuple (C, R, A, P, assign, Q, T) • C is a set of Components C1, C2...Cn • R is a set of Resources R1, R2...Rm • A is the set of Assignments of resources to components. It defines the space of all possible solutions. • P is a finite set of preconditions P1, P2...Pr defining the preconditions of the assign operation that is the conditions must hold to enable the assign operation to be achieved • Q is a finite set of Requirements Q1, Q2...Qp defining the specifications of an assignment, that is the properties required for an assignment • T is a finite set of Constraints T1, T2...Tq defining the criteria for a valid solution, that is the properties required for that solution 4. • assign is an operation which can be achieved iff P is satisfied and when it ends creates an assignment from resources and components that fulfills Q and T. Different level of genericity of assignment problems can be distinguished. Generic assignment refers to a generic goal characterizing the assignment problem type, independently of any application. Application-assignment refer to a particular goal that concerns a particular application of the assignment type : it is application dependent but case independent. An Application-assignment goal needs to be achieved for several particular cases: • Generic-assignment What is shared by all assignment-problems is (i) the existence of objects that play the role of resources and components, (ii) the definition of the general properties of an assignment that are defined by some axioms giving the own semantics of an assignment and (iii) the operation assign which generate an assignment. • Application-assignment What is specific to each particular application which is of the assignment type is the particular type of resources and components of the problem, the particular set of requirements for the assignment and of constraints and the specific preconditions that the assign operation must satisfy to be applied. An example of an assignment problem is SisyphusI offices-allocation where persons (resources) need to be assigned to offices (components). Another example is Sisyphus II VTdesign where an elevator is configured by selecting components and values (resources) have to be assigned to their parameters (components) • Case-assignment What is specific to each case of assignment is the actual set of components and resources and the assignment solution. An example of reuse of modular specifications by successive refinement and specialization is now described. The different steps of the incremental development of the goal specifications are given. The assignment example is used to illustrate how very different applications such as the Sisyphus I and Sisyphus II applications, can be specified in reusing the same generic goal. 5 . 3 . Generic-assignment specifications Generic-assignment is the most general assignment. It is specified by a very generic datastructure. Then different more specialized assignments, but still generic, since common to some problem type, are specified. 5 . 3 . 1 . Generic-assignment The generic goal assignment is specified thanks a generic draft GENERIC-assignment which describes a data structure representing such an assignment goal. Only the sorts, operations, and generic properties shared by any assignment problem are specified, but no particular property is
4
for reasons of simplification, we assume a single solution. In case of several valid solutions properties expressing preferences should be added to the specification
9
given at this stage. In order to keep the generality of that data structure, this draft is a generic draft parameterized by the types of source elements, Components and Resources (Fig. 5). The sorts resources, components which play an important role in the specification of an assignment problem are defined by using parameters. As those elements do not have any specific properties, they are simply specified as follows:
par Component sort : component; end Component par Resource sort : resource; end Resource generic draft GENERIC-assignment(Component, Resource) sort : assignment; generated-by :
empty : æ assignment; assign : resource * component * assignment æ assignment; operations : undef : æ component; solution : æ assignment; % particular assignment representing the solution : resource * assignment æ Bool; ’: component * assignment æ Bool; assigned-to: resource * assignment æ component; assigned-with: component * assignment æ resource ;
axioms:
% --------------definition of " " ---------% (R, empty) = false; R=R’ • (R, assign (R’, C, a)) = true; R›R’ • (R, assign (R’, C, a)) = (R, a); % --------------definition of " ’" ---------% ’(C, empty) = false; C=C’ • ’(C, assign (R, C’, a)) = R; C›C’ • ’(C, assign (R, C’, a)) = ’ (C, a); % --------------% definition of "assigned-to" ---------% assigned-to(R, empty) = undef; R=R’ • assigned-to(R, assign (R’, C, a)) = C; R›R’ • assigned-to(R, assign (R’, C, a)) = assigned-to (R, a); % --------------% definition of "assigned-with" ---------% assigned-with(R, empty) = undef; C=C’ • assigned-with(C, assign (R, C’, a)) = R; C›C’ • assigned-with(C, assign (R, C’, a)) = assigned-with (C, a);
where :
R, R’: resource C, C’ : component a : assignment; end GENERIC-assignment(Component, Resource) Figure 5 : The generic parameterized draft GENERIC-assignment (Components, Resources)
5 . 3 . 2 . Generic-assignment refinements Generic assignment can be further refined, according to particular properties required from the solution. For example, each resource must be assigned ( GENERIC-assignment-v1, Fig. 5a), or each component must be assigned with a resource (GENERIC-assignment-v2, Fig. 5b).
10
generic draft GENERIC-assignment-v1(Component, Resource) with : GENERIC-assignment(Components, Resources); axioms : % -------------- "solution" specification --------- % (R, solution) = true; assigned-to(R, solution)› undef;
where :
R : resource
end GENERIC-assignment1(Component, Resource) Figure 5a : GENERIC-assignment where each resource must be assigned
generic draft GENERIC-assignment-v2(Component, Resource) with : GENERIC-assignment(Components, Resources); axioms : % -------------- "solution" specification --------- % (’C, solution) = true; assigned-with(C, solution)› undef;
where :
C : component;
end GENERIC-assignment2(Component, Resource) Figure 5 b: GENERIC-assignment where each component must be assigned with a resource
5 . 3 . 3 . Constrained assignment The condition that states the possibility of adding an element to a partial existing assignment is translated by a relevant precondition assign-pre about the generator assign. The introduction of this precondition is made in defining the generic draft GENERIC-constrained_assignment which is an enrichment of the specification GENERIC-assignment (Fig. 6). It should be noted that this condition cannot be described at the level of a formal parameter since it involves the element assignment. This condition is willingly left not specified so that to enable further specializations afterwards, corresponding to more specific expected properties.
generic draft GENERIC-constrained_assignment(Component, Resource) with : GENERIC-assignment(Components, Resources)5; predicates :
% predicate representing a precondition of assign depending on each particular application % assign-pre : resource * component * assignment;
preconditions: assign(R,C,a) is-defined iff assign-pre (R, C, a) is-true where :
R : resource C : component a : assignment; end GENERIC-constrained_assignment(Component, Resource)
Figure 6 : Introduction of the assign operation precondition
5.4. Particular preconditions specifications Based on that generic draft (Fig. 6), different types of conditions can be defined, depending on the particular expected properties of the generators of the assignment. Thus, the second step is a refinement step corresponding to the introduction of a more specific precondition. Two versions of more specific constrained assignments are now presented. The first one is a particular version which involves components having a maximum capacity maxsize and where 5
To simplify, this draft is considered as an enrichment of the GENERIC-assignment draft but it can also be defined as an enrichment of any refinment : GENERIC -assignment-v1 is relevant for Sisyphus I while GENERIC-assignment-v2 for Sisyphus II
11
it is only possible to assign a resource to a component if this maximum capacity has not already been reached (cf. Version 1). The second one involves components having a particular set of permitted resources and where it is only possible to assign a resource to a component if this component belongs to this domain (cf. version 2). This type of problems often occurs with application in the area of parametric design where parameters have to be assigned with values inside a given domain. For instance, a parameter's value is constrained by being in acceptable boundaries (e.g. "the car cab height must be between 84 and 240 inches, inclusive") Version 1 of a constrained-assignment The generic draft GENERIC-constrained_assignment-1 (Fig. 7) enables to refine the precondition on assign so that only assignment (1) respecting a components maximum capacity and (2) and where a resource is assigned once, can be done. This generic draft is refined from the generic draft GENERIC-constrained_assignment (Fig. 6):
generic draft GENERIC-constrained_assignment-1(Component, Resource) use Nat with : GENERIC-constrained_assignment(Component, Resource); operations: % number of resources already assigned in a component nbassign : component * assignment æ Nat; % office maximum capacity maxsize : component æ Nat
axioms:
nbassign(C, empty) = 0; C = C ’ • nbassign (C, assign (R, C’ a)) = nbassign (C, a)) +1; C › C ’ • nbassign (C, assign (R, C’ a)) = nbassign (C, a)) ; % (R, a) = false means there is only one R in an assignment. % % an assignment is possible until a component maxsize % assign-pre (C, R, a) iff (R, a) = false ' nbassign (C, a) < maxsize (C) is-true;
where
R : resource C, C’ : component a : assignment; end GENERIC-constrained_assignment-1(Component, Resource) Figure 7: Refinement of the assign precondition to describe assignment with capacity limited components
Version 2 of a constrained-assignment generic spec Set(Resource) use Bool sort : set; generated-by empty-set : æ set; add : resource * set æ set; operations: belongs-to : resource * set æ bool axioms: belongs(R, empty-set) = false; R = R ’ • belongs (R , add(R’, S)) = true; R › R’ • belongs (R, add(R’, S)) = belongs(R,S); where S : set R, R’ : resource; end Set(Resource) Figure 8 : Specialization of a set of resources
12
The generic draft GENERIC-constrained_assignment-2 (Fig. 9) refines the precondition assignpre so that only assignment respecting a specific component range can be done. It uses the specification of acceptable resources sets, which are specified above by the generic spec Set(Resource) (Fig. 8). The generic draft GENERIC-constrained_assignment-2 (Fig. 9) enriches the generic draft GENERIC-constrained_assignment (Fig. 6)
generic draft GENERIC-constrained_assignment-2(Components, Resources) use Set(Resource); with : GENERIC-constrained_assignment(Components, Resources) operations: % set of acceptable resources for a component range: component æ set ;
axioms:
range(C) › empty-set; % assignation possible in a predefined range .% assign-pre (C, R, a) iff belongs-to( R, range(C)) is-true;
where
S : set C, C’ : component R: resource a : assignment; end GENERIC-constrained_assignment-2(Components, Resources) Figure 9 : Refinement of the assign precondition to describe assignment with range limited components
It can be noted that on its turn, the generic draft GENERIC-constrained_assignment-2 (Fig. 9) might have been further refined into a more specialized but still generic goal, generic draft GENERIC -parametric-design, in instantiating the parameter Resource by spec Value (cf §5.8.1.4) as below:
generic draft GENERIC-parametric-design (Component) with GENERIC-constrained_assignment-2 (Component, Resource • Value); renaming component into parameter; end GENERIC-parametric-design (Component) For reasons of simplification, this step is omitted and particular applications are now directly specified thereafter. 5 . 5 . Particular assignment applications The Sisyphus I Office-assignment (§ 5.5.1) and the Sisyphus II VT-assignment (§5.7) are the examples succesively used for illustration of Application-assignment specifications. Whereas Sisyphus II VT-assignment expertise involves a too large quantity of knowldege, it was impossible to give the complete specification of this example. However an extended description of Sisyphus I Office-assignment is reported. Sisyphus I Office-assignment and Sisyphus II VT-assignment are respectively concerned with particular sorts and properties specifying the specific input, ouput, requirements, constraints, of each application.
13
5 . 5 . 1 . Application-assignment : Sisyphus I Office-allocation Sisyphus I Requirements & Constraints Lab assign
Sisyphus IAssignment
Member Sisyphus I-Pre Input/Output concepts Static knowledge
Operation
Figure 10: Sisyphus I Office-allocation
Sisyphus I offices-allocation problem is an example of a particular application which belongs to the category of assignment problems. The members of the group YQT are moved to a new floor of their castle, so each member must be assigned to an office. • An office among all the possible offices (R1, R2, … Rm) of a laboratory after called Lab is described by its properties : a number, a position (central), a size (large, twin), a list of the close and next offices. • a person among all the possible members (C1, C2, … Cm) of a team after called Member is described by several properties : his name, function (researcher, manager, head-of-group, head-of-project or secretary), the project he is working on, the persons he works with, whether he is a smoker or not etc. • There exist a list of particular requirements that an office allocation must fulfill: - each person has an office and a single one (Q1) - a large office contains at least three persons (Q2) - the maximal capacity of a twin office is two (Q3) - a small office can only contain one person (Q4) - the persons number of an office is less than its maximal capacity (Q5) • In addition to these general requirements, there exist a list of particular constraints that the office allocation solution must moreover fulfill to be valid : - the head-of group needs a large and central office (T1) - secretaries should be in the same office next to head-of-group (T2) - the manager is alone in a small central office, next to the head-of-group and close to the secretaries (T3) - the project-head is close to the head-of-group and to the secretaries (T4) - two persons who work on the same project don't share the same office (T5) - smoker and no-smoker must not be assigned to a same office (T6) The following specifications are mostly inspired by the work of (Sadfi, 1994) 6 where a full specification of the domain layer is given. The parameters that play the role of components and resources for this application are the formal parameter Lab and Member. Their specification (extracted from (Sadfi, 1994)) is given below to illustrate how the particular input/output of an application, here sthe application Sisyphus I, can be specified.
6
DEA report under M.C. Gaudel and M.C. Rousset direction
14
par Lab sort : office; operations :
undef æ office; capacity : office æ Nat predicates : close : office, office; next : office, office; large : office; twin : office; small : office; central : office;
axioms :
close(X,X); close(X,Y) • close (Y,X); next(X,X); next(X,Y) • next(Y,X); next(X,Y) • close (Y,X);
where : end Lab
X, Y : office
par Member use BOOL sorts :
person; project;
operations :
head-of-group : æ person % constant referring to the single head-of-group manager : æ person % constant referring to the single manager is-group-head: person æ bool; is-manager: person æ bool; is-project-head: person æ bool; is-secretary: person æ bool; is-researcher: person æ bool; project-of : person æ project;
predicates :
work-with : person, person is-smoker : person; axioms : project-of(X) = project-of(Y) • works-with(X, Y) % axioms stating that each person as a single function; is-group-head(head-of-group) = true; is-group-head(manager) = false; % a head-of-project is not the group-head is-group-head(head-of-project(Pr)) = false; is-researcher(X) = true • is-group-head(X) = false; is secretary(X) = true • is-group-head(X) = false; ---. is secretary(X) = true • is-researcher(X) = false;
where:
X, Y : person; Pr : project; end Member Figure 11: Formal parameters parameter Lab and Member
15
Based on the generic draft GENERIC-constrained_assignment-1(Component, Resource), it is possible now to distinguish various assignment problems corresponding to different applications of this type. Each application is characterized by particular elements playing the role of component and resource and also particular requirements and constraints. Therefore, it is not necessary to fully instantiate the formal parameters Component and Resource. A formal instanciation by the more specific formal parameters Lab and Member is sufficient.
generic draft SISYPHUS I-OFFICE-assignment (Lab, Member) with GENERIC-constrained_assignment-1 (Component • par Lab, Resource • par Member); renaming component into office; resource into person; assigned-to into office-of maxsize into capacity assignment into Office-assignment axioms :
% list of requirements concerning the offices type% large(O) • capacity(O) = 3; twin(O) • capacity(O) = 2; small(O) • capacity(O) = 1; % list of constraints to be fulfilled by the solution% -------% the head-of group needs a twin and central office (C1)-------% nbassign(office-of (head-of-group, solution), solution ) =1) central(office-of (head-of-group, solution ); twin(office-of (head-of-group, solution ); -------% secretaries should be in the same office next to head-of-group (C2)-------% is-secretary(P) ' is-secretary(P’) • office-of(P, solution) = office-of (P’, solution); is-secretary(P) • next(office-of(P, solution), office-of (head-of-group, solution) -------% the manager is alone in a small central office, next to the head-of-group and close to the secretaries (C3)-------% nbassign(office-of (manager, solution ), solution) =1; small(office-of (manager, solution ); next(office-of (manager, solution ), (office-of (head-of-group, solution )); is-secretary(P) • close(office-of(manager, solution),office-of(P, solution)), -------% project-head is close to the head-of-group and to the secretaries (C4)----% is-project-head(P) • close(office-of(head-of-group, solution), office-of(P, solution)), is-project-head(P) ' is-secretary(P’) • close(office-of(P, solution), office-of(P’, solution)), -------% two persons who work on the same project don’t share the same office (C5)--% works-with(P, P’) ' P › P’ • office-of(P, solution) ›office-of (P’, solution); -------% smoker and no-smoker must not be assigned to a same office (C6)-------% office-of(P, solution) = office-of(P’, solution) and is-smoker (P) • is-smoker (P’) where: O, O’ : office P, P’ person end SISYPHUS I-OFFICE-assignment (Lab, Member)
generic spec SISYPHUS I-assignment (Lab, Member) from SISYPHUS I-OFFICE-assignment (Lab, Member)
Office-assignment into Sisyphus I-assignment solution into Sisyphus I-solution end SISYPHUS I-assignment (Lab, Member) Figure 12 : Draft of specification of the application SISYPHUS I-assignment and its completed version
16
5 . 6 . Particular assignment cases. A particular case of office allocation corresponds to a particular team and a particular lab. YQT team is characterized by a set of persons, projects and properties respectively described by the specifications basic spec Names-YQT, basic spec Names-Project, spec YQT.
basic spec Names-YQT sorts : person; generated by : Thomas, Hans, .... Katharina, Eva ....: æ person; end Names-YQT basic spec Names-Project sorts : project; generated by : P-120, P-121, .... : æ project; end Names-YQT spec YQT use Names-YQT, Names-Project, Bool; operations :
head-of-group : æ person % constant referring to the single head-of-group manager : æ person % constant referring to the single manager is-group-head: person æ bool; is-manager: person æ bool; is-project-head: person æ bool; is-secretary: person æ bool; is-researcher: person æ bool; project-of : person æ project;
predicates :
work-with : person, person is-smoker : person; axioms : project-of(X) = project-of(Y) • works-with(X, Y) Thomas = head-of-group is-group-head(Thomas) = true; is-manager(Thomas) = false; is-project-head(Thomas) = false; is-researcher(Thomas) = false; is secretary(Thomas) = false; Eva = manager is-group-head(Eva) = false; ---project-of(Eva) = P-120; project-of(Thomas) = P-121; ----
where : end YQT
X, Y: person;
Figure 13 : Specification of the team YQT characterized by a set of persons, of projects and properties respectively described by the specifications basic spec Names-YQT, basic spec Names-Project, spec YQT
17
LRI lab is characterized by a set of offices and properties respectively described by the specifications basic spec Names-offices, spec LRI (Fig.14):
basic spec Names-offices sorts : office; generated by :
Of1, Of2, ....Of119, Of120, Of121, Of123 ....: æ office;
operation:
end
undef : office; Names-offices
spec LRI use Names-offices; predicates :
close : office*office; next : office* office; large : office; twin : office; small : office; central : office;
axioms :
close(X,X); close(X,Y) • close (Y,X); next(X,X); next(X,Y) • next(Y,X); next(X,Y) • close (Y,X); close (Of1, Of3) = true; next(0f119, Of123) large(0f119 ); twin(0f123 ) =true; central(0f121 )
where : end
X, Y : office
LRI Figure 14 : Specification of the lab LRI characterized by a set of offices and properties
The particular assignment problem corresponding to the particular case where the concerned lab is LRI and the members are YQT is a specification (Fig. 15) obtained by instantiating the formal parameters of the generic spec SISYPHUS I-assignment (Fig. 14) with the actual parameters LRI and YQT defined above as follows :
spec YQT-assignment as SISYPHUS I-assignment (Lab • LRI, Member •
YQT)
Figure 15 : Specification of the YQT specific assignment case
5 . 7 . Application-assignment : Sisyphus II Elevator-parameters assignment A simplified version of Sisyphus II Elevator-parameters (VT-problem) is another example of application which belongs to the category of assignment problems. Last year, the members of the group YQT were moved from the ground floor of their castle. Now YQT has to install an elevator in this castle. This elevator has to be configured, so that a suited value is assigned to each parameter characterizing the various parts of this elevator 7. 7
for clear reasons of simplification, the presentation is limited to parametric design where all the components are supposed already chosen , which is not the exact description in (Yost, 1992), so the set of external adn internal prameters is assumed fixed.
18
The goal of this application is defined in Yost document by : the goal of the configuration process is to derive values for all of the output parameters listed in Section 8 such that none of the constraints in Section 7 are violated. This goal must be achieved for different cases (customers). A particular list of information must be supplied by each customer before the elevator system can be configured. This includes certain characteristics of the elevator system (such as desired speed and capacity) and relevant building dimensions. • • •
•
a value among all the possible values (after called Value) is either an integer, a string of characters, a real, or a boolean a parameter among all the possible parameters of the elevator (after called Elevator) is characterized by its properties external, internal, or output. An external parameter (e.g.Capacity, Speed, Door opening) has an input value assigned by the user. Requirements. There are range or depedency requirements. A parameter value must belong to a range of values defined in (Yost , 1992) for example as follows: Capacity: The maximum total car occupant weight, in pounds, that the system must be able to support. The capacity must be between 2000 and 4000 pounds. Speed: The desired traveling speed of the elevator. Acceptable values are 200, 250, 300, 350, and 400 feet per minute. Door opening: Center for doors that open in the center, side for door that open to one side of the opening. An internal parameter is related to an expression used to compute its value from other parameters, i.e. to assign a value to the parameter. In other words an internal parameter must fulfill some assign requirements expressed by arithmetic expressions. For example Car runby is an internal parameter defined in (Yost , 1992) as follows : The distance from the bottom of the car assembly to the top of the carbuffer, when the car is at the bottom landing, is referred to as the car runby. The car runby equals the pit depth minus the sum of platform height, safety height, car buffer height, carfooting channel height, and car buffer blocking height. Constraints : Moreover there exist particular constraints that limit in some way the values a parameter can take on. Constraint violations can be remedied by changing other aspects of the design. Examples of constraints are : Car runby constraint: the car runby can be at most 24 inches for safety reasons. This constraint is related to the fix: the car runby can be reduced by increasing the car buffer blocking height Bracket spacing constraint. The max bracket spacing is 168 inches. There are no fixes. Cab height constraint The cab height must be between 84 and 240 inches, inclusive. There are no fixes. Car buffer blocking height constraint. The blocking height must be at least zero inches. If it is not, try increasing the pit depth by one-inch steps. The blocking height must be at most 120 inches. If it is not, try decreasing the pit depth by one-inch steps. Sisyphus II Requirements & Constraints Elevator assign
Sisyphus II Assignment
Values Sisyphus II-Pre Input/Output concepts Static knowledge
Operation
Figure 16: Sisyphus II VT parameters-assignment problem
19
First, the parameters Elevator and Value that play the role of components and resources in that application are specified. Then the requirements and constraints to be fulfilled are specified as axioms of the generic draft SISYPHUS II-VT-parametric design(Elevator) (Fig.25). 5 . 7 . 1 . Specifying values Here are some specifications of the possible values, integer, string, real, boolean. 5.7.1.1.
Specification of integers
spec Nat use Bool sorts : nat; generated-by :
end
0 : æ nat; s : nat æ nat; operations : -+- : nat*nat æ nat; axioms : 0 + y = y; s (x) + y = s(x + y); where: x , y : nat; Nat
5.7.1.2.
Specification of strings of characters
basic spec Char sorts : char; generated-by : A, B, C, D, E, end Char
Z: æ char;
spec String use Char; sorts : string; generated-by :
end
empty : æ string; add : char * string æ string; operations : - o - : string * string æ string; axioms : empty o y = y; add(c, x) o y = add(c, x o y) where: x , y : string; c : char; String
5.7.1.3.
Specification of numerical values and values:
spec Numvalue use Nat; Real sorts : numvalue; operations : undef : æ value; end Numvalue Figure 17: Specification of the numerical values
20
Since the only possible values of arithmetic expressions are numerical, Numerical values are distinguished (Fig. 17). All possible values are specified Fig. 18.
spec Value use Numvalue; String, Bool, sorts : value; operations : - : numvalue : æ value; undef æ value;
Figure 18: Specification of all type of value .
5.7.1.4.
Specification of range of values:
The specification of the domain of acceptable values of parameters is defined by the spec Range which is obtained by instantiation of the generic spec Set(Resource)
spec Range as Set(Resource • Value by m) where : m : resource • value, belongs-to • belongs-to renaming set into range end Value Figure 19: Specification of range of values
5.7.2. Specifying parameters An elevator is composed of several parts characterized by a set of parameters. For reasons of scope we reduce an elevator description, to a set of parameters with particular ranges of values. The set of parameters to be assigned is assumed to be independent of the elevator parametric design, and is considered fixed in the application Sisyphus II VT-assignment. The parameters names are defined as constants of the sort parameter:
basic spec Names-param sort parameter; generated by : end
Cab height, Capacity, Car intercom, Car lantern, Car intercom, Car lantern, Car phone, Car position indicator, Door opening, Door speed, Floor height, Hoistway depth, Max motor torque, Peak .etc: æ parameter YQT-Names-param
par Elevator use Names-Param, Value;
% to tackle the global VT problem , define here the sort part and the relation related-to between a part and the related parameters operations : % two types of parameters are distinguished external and internal external : parameter æ bool; internal : parameter æ bool; % definition of the user input and of the required output s input : parameter æ value; output : parameter æ bool;
axioms :
%----------------- % a parameter is either external or internal ------------------------------% internal (X) = false • external (X) = true ; external (X) = false • internal (X) = true ; %----------------- % a parameter is not external and internal at the same time------------internal (X) = true • external (X) = false; external (X) = true • internal (X) = false;
21
%----------------- external parameters should be produced as outputs----------------------% external (X) = true • output (X) = true; %----------------- list of external parameters (defined in section 3)--------------------------% external(Cab height)= true; external(Opening height)= true; external (Capacity) = true; external(Opening strikeside)= true; external(Car intercom)= true; --external(Machine room to machine beam support);= true %----------------- % list of internal parameters (sections 4.1- 4.5, 5.1-5..14, 6.5-, 7)-----% internal(Bracket spacing)= true; internal(Machine beam bear. plate thickn.)= true; internal(Machine room floor to underside)= true; internal(machine beam)= true; .---internal(Max motor torque); internal(Peak); etc. %----------------- list of output (internal) parameters--------------------------% output(bracket spacing) =true; output(car buffer model ) =true; output(quantity) =true; output(blocking height) =true; output(car rail unit weight ) =true; etc.
where :
X: parameter;
end Elevator
Figure 20: Specification of the elevator parameters as a formal parameter
5.7.3. Generic draft SISYPHUS II-VT-assignment The generic draft SISYPHUS II-VT-assignment (Elevator) is now progressively derived from the generic draft GENERIC-constrained_assignment-2(Component, Resource), which is first specialized by partial instantiation into VT-parametric design (Fig.21), then refined (Fig. 25) in adding the particular requirements, constraints and fixes of the given application. The formal parameter Resource is instanciated by the actual parameter Value whereas Component is instanciated by the formal parameter par Elevator. 5.7.3.1. VT-parametric design
generic draft SISYPHUS II-VT-parametric design (Elevator) with GENERIC-constrained_assignment-2 (Component • par Elevator, Resource • Value); renaming component into parameter ; resource into value ; assigned-to into parameter-of assigned-with into value-of range into range-of : assignment into vt-assignment end SISYPHUS II-VT-parametric design (Elevator) Figure 21: Specialization of the generic draft GENERIC-constrained_assignment-2 into VT-parametric deign
Each internal parameter is assigned thanks the evaluation of an expression. The specification of arithmetic expression is needed to specify dependencies, constraints, fixes in the generic draft SISYPHUS II-VT-assignment. 5.7.3.2. Expression as a binary tree A binary tree is a data structure either empty or of the form : æ node * tree* treeæ tree; operations : root : tree æ node; left : tree æ tree right : tree æ tree; content : node æ element;
preconditions
root(t) is-defined iff t › empty; left(t) is-defined iff t › empty; right(t) is-defined iff t › empty; axioms : root( < n, t, t’> = n; left( < n, t, t’> = t; right( < n, t, t’> = t’;
with end Tree
t, t’ :tree; n : node, Figure 22: Specification of binary tree
VT arithmetic expressions (Fig. 23) are used to specify parameters dependencies, constraints or fixes. The node content in a VT- expression is called a vt-element. It is either an operator among +, -, *, / a numerical value or a parameter. Therefore, the specification of these expressions uses the Operators and the Names-param and Numvalue modules defined above
basic spec Operators sort operator; generated-by : +, -, *, / : æ end Operators
operator,
spec VT-element use Operators; Numvalue, Names-param; sort vt-element; generators , - : operator æ vt-element; - : parameter æ vt-element; - : numvalue æ vt-element; end VT-element
spec VT-Expression as Tree(Element • VT-element by m) where : m : element • vt-element, root • root, tree • tree, left • left right • right, content • content ) renaming tree into expression; end Expression Figure 23: Specification of expressions used for expressing VT parameters depedencies, constraints, fixes.
23
5.7.3.3. Specifying Range of values of VT-parameters
spec VT-Range use Range; sort VT-range; generators
%------------ the parameters range defined as constants of the sort range--------% R-speed, R-Capacity, R-Car intercom, R-Car lantern, R-Car intercom, R-Car , lantern, R-Car phone, R-Door opening, R-Door speed, etc. : æ VT-range;
Operations : - : VT-range axioms :
end
æ range;
%----------------------parameters range-------------------------------------------------% R-speed = {200, 250, 300, 350, 400} R-Door opening = {CENTER, SIDE} R-Door speed = {SINGLE, DOUBLE} R-Opening strikeside = {LEFT, RIGHT} R-Car intercom = {YES, NO} R-Car lantern = {YES, NO} R-Car phone = {YES, NO} etc. VT-Range Figure 24: Specification of range of VT parameters .
The range of the VT- parameters is specified by the module spec VT-Range (Fig. 22) where Rpar denotes to the range of the parameter par . For example, R-Capacity refers to the range of the parameter Capacity, that is to the set of integers [2000, 3000]. 5.7.3.4. Specifying Requirements and constraints •
Specification of requirements
For example, Yost document states that: The peak current required by the motor is a function of the max motortorque. For each motor model, it is calculated by a piecewise linearfunction as follows (where M denotes the max motor torque): Model 10HP: 1.25 M if M≤ 40, 1.333 M - 3.333 if 40 < M ≤ 62.5, otherwise 1.6 M 20}. Such requirements are specified by axioms which define the relevant expression to compute an internal parameter. : M ≤ 40 • depend (P, 1.25 *M) = true 40 < M ≤ 62.5 • depend (P, 1.333 *M- 3.333 ) = true M > 62.5 • depend (P, 1.5 *M-20) = true •
Specification of constraints
Constraints are listed in section 7 of Yost document, for example the car runby constraint is: the car runby can be at most 24 inches for safety reasons. this constraint is related to the fix: the car runby can be reduced by increasing the car buffer blocking height Such constraints are specified by axioms like : value-of(car runby, solution) ≤ 24 The different axioms concerning the application specific requirements and constraints are defined in that draft. The precondition concerning a valid input is also now specified.
24
generic draft SISYPHUS II-VT-assignment (Elevator) use VT-Expression; VT-Range; with SISYPHUS II-VT-parametric design (Elevator); Operations :
% operator returning the evaluation of an expression for the current assignment8 eval : expression* vt-assignment : æ numvalue;
predicates : - † - : numvalue *numvalue - ‡ - : numvalue *numvalue - eq - : numvalue *numvalue axioms :
% LIST OF REQUIREMENTS %
%----------------- definition of the range of Value of parameters-----------------------------------% range-of (Capacity) = R-Capacity; range-of (Speed) = R-speed; ----range-of (Door opening) = R-Door opening %----------------- definition of the dependency relations ---------------------------------------------% % expression defining the dependency relation between parameters value-of(Max motor torque, a) † 40 • eq(value-of(peak, a), eval(1.25*Max motor torque, a)) 40 62.5 • eq(value-of(peak, a), eval(1.5 *Max motor torque -20, a) = true --% LIST OF CONSTRAINTS FOR A VALID SOLUTION% %car runby can be at most 24 inches for safety reasons value-of(car runby, solution) † 24 %maximum bracket spacing is 168 inches value-of(bracket spacing, solution) † 168 %cab height must be between 84 and 240 inches, inclusive. value-of(cab height, solution) † 240 ' value-of(cab height, solution) ‡ 84 ---
preconditions:
%external parameters have user input input (X, V) is-defined iff external(X) =true ' belongs-to(V, range-of(X)) where: X: parameter; V : value; E : expression; a : assignment end SISYPHUS II-VT-assignment (Elevator) Figure 25: Draft specification of SISYPHUS II-VT-assignment (Elevator) obtained by refining SISYPHUS II-VT-parametric design (Elevator);
8
for reasons of scope, this operator is nor specified here, but the specification of an evaluator of formal expression is classical.
25
Fixes could be introduced in the same way by refining (Fig. 23)the above generic draft with the axioms for fixes:
generic draft SISYPHUS II-VT-assignment-with fixes (Elevator) with SISYPHUS II-VT-assignment (Elevator); % LIST OF AXIOMS FOR FIXES% To simplify, we skip this step and go straight to the completed specification of the application
generic spec SISYPHUS II-assignment (Elevator) from SISYPHUS II-VT-assignment (Elevator) VT-assignment into Sisyphus II-assignment solution into Sisyphus II-solution Figure :26: Completed version of the application SISYPHUS II-assignment
5.7.4. Specification of the particular case YQT elevator assignment The last step is the specification of the particular problem concerning the Sisyphus II elevator assignment for the case of the YQT castle. The specification of this particular case of assignment is obtained by instantiating the formal parameter Elevator of the generic spec SISYPHUS I-assignment by the actual parameter YQT-elevator which now defined by : : Defining the YQT initial requirements The customer supplies some information before the elevator is configured. This includes characteristics of the elevatorsystem (e.g. desired speed and capacity) and relevant building dimensions. They are specified in the spec YQT by the axioms "specification of YQT customer requirements". For example, Yost reports that the input values for YQT (Values defined in Section 3) are the following: Cab height Capacity Car intercom etc.
96 3000 NO
Openingheight Opening strikeside Opening to hoistway left
84 RIGHT 32
spec YQT-elevator use Value, Names-Param, Bool; operations :
external : parameter æ bool; internal : parameter æ bool; range-of : parameter æ range; input : parameter æ value
axioms :
internal (X) = false • external (X) = true ; external (X) = false • internal (X) = true ; internal (X) = true • external (X) = false; external (X) = true • internal (X) = false; %----------------- list of external parameters (defined in section 3)--------------------------% external(Cab height)= true; external(Opening height)= true; external (Capacity) = true; external(Opening strikeside)= true; external(Car intercom)= true; --external(Machine room to machine beam support);= true %----------------- % list of internal parameters (sections 4.1- 4.5, 5.1-5..14, 6.5-, 7)----% internal(Bracket spacing)= true; internal(Machine beam bearing plate thickness)= true; internal(Machine room floor to underside)= true; internal(machine beam)= true;
26
---internal(Max motor torque); internal(Peak); etc.
%----------------- specification of YQT customer requirements ----------------------------% input(Cab height) = 96; input(Openingheight) = 84; input (Capacity) = 3000; input(Opening strikeside) = RIGHT; input(Car intercom) = NO; input(Opening to hoistway) = 32; input(Car lantern) = NO; input(Opening width) = 42; input(Car phone) = YES; input(Openings) = 6; input(Car position indicator) = YES; input(Overhead) = 192; input(Door opening type) = SIDE; input(Pit depth) = 72; input(Door speed,) = DOUBLE; input(Platform depth) = 84; input(Floor height) = 165; input(Platform width) = 70; input(Hoistway depth,) = 110; input(Speed) = 250; input(Hoistway width) = 90; input(Travel) = 729; input(Hoistway to front machine beam support) = 3; input(Machine beam support distance) = 118; input(Machine beam support type) = POCKET input(Machine room to machine beam support) = 16; end YQT-elevator Figure :27 Specification of YQT customer specific requirement
The specification of the case concerning the YQT elevator assignment is obtained by instantiating the formal parameter Elevator of the generic spec SISYPHUS II-assignment with the actual parameter YQT-elevator defined above :
spec YQT-assignment as SISYPHUS II-assignment (Elevator •
YQT-elevator)
Figure 28 : Specification of the YQT specific assignment case
In conclusion, these examples have demonstrated how specifications of several applications of the same type, SISYPHUS I-assignment(Lab, Member) and SISYPHUS II-assignment (Elevator), can be derived by successive refinement and specialization of a common initial draft, generic draft GENERIC -assignment(Component, Resource) specifying the generic type of an assignment problem. Generic-Assignment Generic-Assignment-v1
Generic-Assignment Generic-Assignment-v2
Constrained-Assignment Constrained-Assignment-1
Constrained-Assignment Constrained-Assignment-2
Sisyphus I- Office-Assignment
Sisyphus I Assignment
Sisyphus II-VT-Assignment
Sisyphus II Assignment
Draft Spec
Implementation
Implementation
Figure 29 Successive refinement of specifications
27
sMoreover, it has been shown how the parametrization mechanisms are also important and can be used to obtain several versions of an application specification. As illustrated Fig. this approach clearly match with that proposed by TASK to formalize a situation (§ 2) in terms of Situ Case and Situ Goal, the Situ Case being specified as a formal parameter, which can be instanciated by actual cases provided that the adequation between the Situ Case and the actual Case can be proved generic spec
generic goal specification
par Formal parameter specification
case specification
Figure : Parametrization used to specify a generic goal parameterized by the case
generic spec
par Formal parameter specification adequation between the formal parameter and the actual parameter Actual parameter specification
generic goal
case
adequation between the case specification and the actual case Actual case specification Figure : Instantiation used to specify several more specialized versions of the same application goal
6.
Conclusion and perspectives
Section 5 has shown that the different types of PLUSS reusability mechanisms, initially introduced for Software Engineering needs, are very useful in Knowledge Engineering too. This work has brought to light several interesting results. First, it has been exhibited that genericity in Software Engineering differs from the common understanding of genericity in the Knowledge Engineering community. According to the KE usual notion of genericity, it would have been expected that several applications of the same type might have been specified as instanciations of a generic goal. In fact, this approach is not possible with the current semantics 28
of the completed specification modules in PLUSS. The rigid constraints related to such specifications and modular structuration prevent from specifying an application goal as an instantiation of a generic goal in using the genericity mechanism. However, application goals specification can be obtained by reuse of generic specifications but rather in using other reusability mechanisms : goals specifications have been developped by successive refinments of draft specifications (together with parametrization). Genericity (parametrization) mechanisms are nevertheless, also useful. As shown, it is interesting to specify more specialized versions of a specification from a general model. In particular, parametrization has been used to specify specific case-application (instances of situation) as the instanciation of a generic situation on specific cases instances. Moreover, the first steps towards a methodology for the incremental development of KBS specifications have been put forward. The incremental approach used to develop application goal specifications by combining refinment of successive draft modules and specializations of generic modules might surely be generalized to the development of specification for the other categories of a KBS knowledge. Further perspectives will concern two directions. First, investigate more carefully such a methodology for Knowledge Acquisition. Second, investigate how goal formal specifications can be used for proofs, in particular to prove that a process is relevant to achieve a given goal. Acknowledgments This paper would not have been possible without helpful discussions with Marie-Claude Gaudel who improved the understanding of some characteristics of the PLUSS language considerably and gave useful comments on this work. References Aben, M. (1995) Formal Methods in Knowledge Engineering. Thesis, Universiteit van Amsterdam. Benjamins, R., & Pierret-Golbreich, C. (1995). Assumptions of Problem-Solving Methods. In Knowldege Engineering Methods and Language, KEML'96. Paris: Bidoit, M. (1989) PLUSS, un langage pour le développement de spécifications algébriques modulaires. Thèse d'Etat, Univerité Paris Sud. Bidoit, M.,Gaudel, M. C., & Mauboussin, A. (1988). How to make algebraic specifications more understandable Research report No. 439. LRI, Université Paris Sud. Breuker, J., & Van de Velde, W. (1994). CommonKADS Library for Expertise Modelling. Amstrdam, Osaka, Kyoto: IOS Press. Capy, F. (1987) ASSPEGIQUE : un environnement d'exceptions. Univerité Paris Sud. Chandrasekaran, B., Johnson, T. R., & Smith, J. W. (1992). Task-structure analysis for knowledge modelling. Communications of th ACM, 35(9), 124-137. Ehrig, H., & Mahr, B., (1985) Fundamentals of Algebraic Specification, Springer-Verlag. Fensel, D. (1995). A case study : Assumptions and limitations of a problem-solving method. International Journal of Human-Computer Studies Studies, submitted. Pierret-Golbreich, C. (1994). TASK MODEL : a framework for the design of models of expertise and their operationalization. In B. R. Gaines & M. A. Musen (Ed.), 8th Banff Knowledge Acquisition Wprkshop, . Banff: SRDG Publications, University of Calgary. Pierret-Golbreich, C. (1995). TASK platform, a Task Oriented Approach for Structuring (Research report). LRI, Université Paris Sud. (to appear) Pierret-Golbreich, C., & Hugonnard, E. (1993). Organization and use of generic Models based on the Task language. In 5th European Knowledge Acquisition Workshop, EKAW'94, In position papers colection . Brussels: Springer-Verlag. Pierret-Golbreich, C., & Talon, X. (1995). An algebraic specification of the dynamic behavior of Knowledge-Based systems. Knowledge Engineering Review (to appear). Poeck, K., & Puppe, F. (1992). COKE : Efficient solving of complex assignment problems with the propose and exchange method. In 5th International Conference on Tools with Artificial Intelligence, (pp. 136-143). Arlington, VA, USA: Puerta, A.,Agar, J.,Tu, S., & Musen, M. (1992). A multiple method shell for the automatic generation of knowledge acquisition tools. Knowledge Acquisition, 4, 171-196. Sadfi, S. (1994). Spécifications formelles des connaisances DEA internal report, LRI, Université Paris Sud. 29
Schreiber, A. T. (1992). Applying KADS-I to the Sisyphus domain No. KADS II/WP6/TR/UvA/19//2.0, ESPRIT project P5248). Steels, L. (1990, Components of expertise. AI Magazine, p. 28-49. Yost, G. R.(1992), Configuring Elevator Systems. Technical report, Digital Equipment Co, Marlboro, Massuchussets.
30
