Deduction

Generating new statements from given statements by means of rules is the essence of deduction in logic. An interesting observation is that the "repairing procedure", discussed in the last paragraph, can be also described as a procedure deducing new sketch constraints from given sketch constraints.

We consider a sketch G together with a set *C*<sup>G</sup> of sketch constraints on *G*. If *C*<sup>G</sup> contains a general constraint (*c*, !*G*) with *c* = **0** ∀(*L* : ( *St*<sup>1</sup> <sup>→</sup> *<sup>∃</sup>*(*ϕ*, *<sup>R</sup>* : *St*2))), we can deduce a local sketch constraint (( *St*<sup>1</sup> <sup>→</sup> *<sup>∃</sup>*(*ϕ*, *<sup>R</sup>* : *St*2)), *τ*) on *G* for any context morphism *τ* : *L* → *G*. This step corresponds to the **universal elimination rule** in classical first-order logic.

We do have a sound "quasi-propositional" **modus ponens rule schemata** for sketch constraints at hand: For all contexts *X*, all sketch conditions *X c*1, *X* (*c*<sup>1</sup> → *c*2) and all context morphisms *μ* : *X* → *Y*, the sketch constraints (*c*1, *μ*) and ((*c*<sup>1</sup> → *c*2), *μ*) imply the sketch constraint (*c*2, *μ*).

If there is a constraint ( *St*1, *<sup>τ</sup>*) <sup>∈</sup> *<sup>C</sup>*G, we can apply this modus ponens rule and deduce the sketch constraint (∃(*ϕ*, *R* : *St*2), *<sup>τ</sup>*) on *<sup>G</sup>*. Keep in mind that *<sup>L</sup>* <sup>∃</sup>(*ϕ*, *<sup>R</sup>* : *St*2)! The pushout construction generates, finally, the constraint ( *St*2, *<sup>τ</sup>*<sup>∗</sup> : *<sup>R</sup>* <sup>→</sup> *<sup>H</sup>*) on *H*. This looks very much like an analogon to **Skolemization** in classical first-order logic. More precisely, we can consider this pushout construction as a pendant to the introduction of Skolem constants. This is quite in accordance with the characterization of operations in graph term algebras by pushouts in [3].

As another example, motivating the use of sketch constraints as "first class citizens", we discuss atomic Ξ*CT*-statements, as introduced and discussed in the Examples 39 and 49: We included now the feature symbols mon and fnl in our sample footprint Ξ*CT* to exemplify, in a more appropriate way, the use of feature symbols in diagrammatic specifications in general. In Example 51, we discussed, first, that we can specify known or desired properties of features by means of sketch conditions. Later, we have shown that we can even express the universal properties, defining the concepts "monomorphism" and "final object", respectively, by means of sketch conditions.

Given a Stm*CT*-sketch G = (*G*, *St*G), the sketch condition *mon*, defining the concept monomorphism, may help us to deduce from the cmp-statements, present in *St*Gthat two parallel edges in *G* have to be identified. We need just a rule which generates for each atomic <sup>Ξ</sup>*CT*-statement (*α*(mon), mon(*idα*(mon)), *<sup>β</sup>* : *<sup>α</sup>*(mon) <sup>→</sup> *<sup>G</sup>*) in *St*<sup>G</sup> a corresponding sketch constraint (*mon*, *β*) on G. This works so easy, since we designed our examples in such a way that the context of *mon* is just *α*(mon). In general, any atomic Ξ-statement (*α*(mon), mon(*idα*(mon)), *β*) (*α*(*P*), *P*(*idα*(*P*)), *β* : *α*(*P*) → *G*) and any condition *K c* may generate a sketch constraint (*c*, *γ*; *β*) for any context morphism *γ* : *K* → *α*(*P*). Since *β* binds all "free variables" in *mon*, we just need to adapt the three steps (1) universal elimination, (2) modus ponens and (3) Skolemization, as discussed above for general constraints, to deduce identifications of parallel edges in *G*.

To keep Ξ*CT* as small as possible, we have not included in Ξ*CT* feature symbols for other limits and colimits like equ, pb, po, prod, for example. Employing sketch constraints we can even avoid to do this! As discussed in Remark 10, any (co)limit of shape *I* is axiomatized by the feature Ξ*CT*-expressions *existsI* and *uniqueI*.

Analogous to "anonymous functions" in programming, we can use the sketch condition *CI* {*trCI* (*existsI*), *trCI* (*uniqueI*)} as an **anonymous feature** representing the (co)limit concept that corresponds to the shape graph *I*. With anonymous features, we can not formulate statements, i.e., entities within a sketch G, but constraints, like ( {*trCI* (*existsI*), *trCI* (*uniqueI*)}, *β* : *CI* → *G*) on the sketch G.

There should be now sufficient evidence that it will be beneficial to work in future DPF with sketch constraints as first class citizens and our discussion suggests, especially, to employ pairs of a sketch G = (*G*, *St*G) and a set *C*<sup>G</sup> of sketch constraints on G as an appropriate formalization of software models. We call those pairs ((*G*, *St*G), *C*G) **constrained sketches**.

**Remark 40** (Constrained sketches in MDE)**.** *Our approach to use and develop DPF as a theoretical foundation of MDE is based on the idea that any diagrammatic specification formalism/technique is characterized by a certain choice of a category* Cxt *and a footprint* Ξ *where the corresponding diagrams/models can be described as* Stm*-sketches. Sketch conditions and sketch constraints have been developed to provide the necessary additional means to describe/constrain the syntactic structure of diagrams/models. In such a way, we can characterize now a diagrammatic specification formalism not only by a certain category* Cxt *and a certain footprint* Ξ *but also by an additional set of* Stm*-sketch conditions.*

*We should, however, distinguish between two kinds of* Stm*-sketch conditions: The first kind of conditions is used to formulate those constraints on* Stm*-sketches* G *that can be legally used as elements in C*G*. For a constrained* Stm*-sketch* (G, *C*G)*, the occurrence of a constraint* (*c*, *τ*) *in C*<sup>G</sup> *will certify that* G |= (*c*, *τ*)*. Requirements for the* relational data model *[18,21] like "every table must have a primary key" and "a foreign key should only refer to a primary key" will be formalized by conditions of this kind.*

*Conditions formalizing requirements like "inheritance is transitive" or "a subclass inherits all attributes of all its superclasses", however, should not be included in any C*<sup>G</sup> *to avoid diagrams/models becoming too polluted with redundant information. Those additional conditions are part of the formalism as a whole and represent the background knowledge and rules that can be used to deduce for any constrained sketch information from the information given in St*<sup>G</sup> *and C*G*, respectively, and to repair violations of the constraints in C*G*.*
