Teoría de los prototipos

The diagrams generated by our inference calculus can only be as reliable as the rules used to generate it. To establish a measure of the reliability of our inference method, its consistency,soundness andcompleteness will be proved. To do so, a definition of each property is provided before the actual proof.

Definition 1. A formal system is consistent if and only if no contra- dictions are derived from the application of the inference rules.

A contradiction occurs when a formula φ and its negation ¬φ are both found within the axioms or the theorems of the system. The formulas for the system proposed are predicates for the elements of diagrams and specifications. The system is composed only by these predicates and the inference rules listed before. None of the inference rules produces the negation of a predicate. From which it follows that it is impossible to have a formula of the form ¬φ. Thus the system cannot present any contradiction, that is,the system is consistent.

Definition 2. A formal system is sound if and only if every formula that can be proved in the system is valid with respect to the semantics of the system.

It is known that all formulas are predicates, and all the predicates proved (derived) correspond uniquely to the elements of the class diagram. In consequence, it is needed to establish the semantics of the predicates for the diagram, to do so, the following conditions must be established.

1. Every formula can only be be applied in the context of a given clause. The following statements define the semantics of the predicates for class diagrams and ConsSpec specifications.

Definition 3. Semantics for diagram and specification predicates 1. CLS predicates are valid only if they are inferred from an ACTOR

predicate.

2. OPR predicates are valid only if they are inferred from an ACTIV- ITY predicate.

3. ATR predicates are valid only if they are inferred from an STRUC- TURAL SENTENCE predicate.

4. INH predicates are valid only if they are inferred from an

TYPE SENTENCE predicate.

That means that all formulas have to be applied one by one to every clause in the contract. The class rule can only be applied in the actors section of the contract. Operation rules must be applied in the activity section. Attribute and inheritance rules can be applied in any of the condition fields, that is preconditions, activity conditions, and postconditions.

From the rules listed in the previous section, it is clear that these relations are satisfied, and since there are no other ways to generate predicates, it is proved that the system is sound.

Definition 4. A formal system is complete with respect to a given property if and only if every formula having that same property can be derived using that system.

In this particular system, completeness is evaluated in terms of the predi- cates of the class diagram, then the question to answer is “can the inference rules proposed derive all the predicates associated with a class diagram?” ; and the answer is no. It is enough to consider the diagram predicate REL, which captures the relationships between classes; this predicate is not the conclusion of any inference rule, and since these rules are the only way to generate predicates, then REL predicates cannot be generated. Thus it is proved that the system is not complete.

It has been proved that our inference system is consistent and sound, though not complete. With this consideration, we move forward to exemplify the use of our inference system in the following section.

5.2. CLASS MODEL INFERENCE 79

5.2.3

Example

To demonstrate the use of these rules, the clause C2 of the specification presented in Section 4.3 is used as a reference, which expresses the requirements for a basic library system. This clause is repeated in the following contract segment.

ConSpec 5.2: Library specification, clause C2 - C2:

Activity: Borrow items Actors:

- Customers Preconditions:

- Customer's membership must be valid - Loaned-items must be less than 8 - Book's bar-code must be read Postconditions:

- The item is added to the customer's loaned-items Consequences:

- Return the description of the unsatisfied-precondition Dependencies:

- C5

As it was established in Section 5.2.2, the inference rules must be applied in the context of each clause to maintain soundness. Theclass rule is applied first as shown next to generate the class and type for the customer.

ACTOR(Customers)

CLS(Customers, classifier), TYPE(Customers)

The uni-parametric operation rule is then applied to the previously gener- ated class and the activity of the clause. For clarity of the inference rule, the following formula assignments are done.

α= CLS(Customers, classif ier) β = ACTIVITY(Borrow, items)

γ = VBB(Borrow)

δ= QUALIFIED ENTITY(items)

φ= OPR(Customers, Borrow,, +, instance,{items})

α β γ δ φ

In this clause there are no structural sentences or type sentences; hence there is no need to apply the attribute or inheritance rules. The partial class model generated by inference from the clause 2 of the library specification looks like follows:

CLS(Customers, class)

TYPE(Customers)

OPR(Customers, Borrow, ,+, instance,{items})

We just illustrated the use of the inference rules within a ConSpec clause for our simple library system. However, manual inference is time-consuming and error-prone, and it is hence crucial to develop tools that automate this process; this is the subject of Chapter 6.

In this section, we defined a formal system to infer class diagrams from requirements specifications, stated the inference rules, established its consis- tency and soundness, and demonstrated its application with an example. In the next section, we describe a formal system for class diagram validation.