space. Besides, the get-param helper finds a possible parameter within the
activity string, assuming the parameter is found after the first space between two words. The current implementation infers operations from activities composed by only one verb and one parameter at most, for example, “register user” and “login” .
This implementation allows identifying the actor of the activity as the class of the operation, the first word of the activity as the name of the operation, and the second word of the activity as the parameter, as required by the corresponding inference rule.
Similar to the operation rule are the implementations of the attribute, inheritance, and attribute rules. They all have initializer functions that “iterates” over the elements of each set of the specification in order to infer its corresponding element of the class diagram. The complete implementation of the inference rules together with an example are provided in Appendix B.1
The output of the SMT-solver is an SMT-LIB model like the one shown in CVC4 Output for inferred class model. In it, it is observed that all classes, attributes, operations and inheritances are described as singletons. Our python implementation parses this answer in order to generate the corresponding python object, which, if needed, can be derived into the formal representation of a diagram. A desirable extension would be a visualization of the model generated in the form of a diagram.
SMTLib 6.7: CVC4 Output for inferred class model (singleton (CLASS "Library" "classifier"))
(singleton (CLASS "Loan-Item" "classifier"))
(singleton (OPR "Library" "loans" "e" "+" "instance", (as emptyset (Set Params)))) (singleton (OPR "Library" "issues" "e" "+" "instance", (as emptyset (Set Params)))) (singleton (ATR "Books" "title" "e" "e" "e"))
(singleton (ATR "Members", "date-of-birth" "e" "e" "e"))) (singleton (INH "Loan-items" "Books"))
6.4
Validation
In Section 5.3.1, the rules necessary to validate a class model against a given specification were discussed. Throughout this section, we will discuss the structure of the SMT-LIB implementation of most relevant rules.
Both sections, validation and diagram equivalence, make use of the defi- nition of concept equivalence. For T4TOMM, two words equivalent if they have the same meaning, or if they have the same base word. For example,
“customer” and “Customer” are equivalent words varying only in capitaliza- tion, “customer” and “customers” are equivalent varying in the number,
and “customer” and “client” have an equivalent meaning. In most general cases, any synonyms of a word are its equivalent.
In order to define word equivalence, we provide the following SMT-LIB model.
SMTLib 6.8: Word Equivalence
(declare-datatypes ( (Entry 0) ) ( ((mk-entry
(synonyms (Set String))
))))
(declare-const syns_dict (Set Entry))
(assert (member (mk-entry (insert "w1" "word1" "Word1" "Word 1"
(singleton "w 1"))) syns_dict)) (assert (member (mk-entry (insert
"word2" "w2"
(singleton "W 2"))) syns_dict))
(assert (= syns_dict (as univset (Set Entry))))
In this model, the Entry datatype represents an element of the dictionary of synonyms. Every entry is a set of equivalent strings. From the example above, it is observed that “w1” , “word1” , “Word1” , “Word 1” , and
“w 1” are equivalent. Every set of equivalences is added to the dictionary, which will then be used in the validation and equivalence tasks.
The current python implementation generates these sets automatically by varying each of the words found in the class diagrams and the specifica- tions. However, further semantic equivalence is required in order to enable the introduction of exceptional cases. For example, in a bank system, the terms “customer” and “cardholder” may be equivalent, which cannot be automatically identified without user input.
The actor rule ∃CLS(x, e)∈M,∃ACT OR(y)∈S |x≈y
expresses the basic condition that there is a class and a actor whose names are equivalent.
In order to prove the soundness of the diagram, we have to prove that this rule is true for all the classes, which we write in SMT-LIB as follows.
SMTLib 6.9: Class Soundness
; There is an actor thar derives the class
(define-fun check_class ((c Class)) Bool
(exists
((a Actor))
(and
6.4. VALIDATION 111 (is_syn (cls_nme c) (actor_name a) ) ) ) )
; All the classes come from an actor
(define-fun actors_rule () Bool
(forall ((c Class)) (=> (member c classes) (check_class c) ) ) )
The function actors_rule allows to reason about all classes, while the
function check_class verifies that there is at least one actor whose name is equivalent to the name of the class being analysed.
Inversely, we need a rule to verify completeness of the model, i.e. to check that all the actors in the specification have an equivalent class in the diagram. We use the following functions to prove class completeness.
SMTLib 6.10: Class completeness
(define-fun check_actor ((a Actor)) Bool
(exists ((c Class)) (and (member c classes) (is_syn (actor_name a) (cls_nme c) ) ) ) )
(define-fun inverse_actors_rule () Bool
(forall ((a Actor)) (=> (member a actors) (check_actor a) ) ) )
In this model, the function inverse_actors_sule allows to reason about
all the actors of the specification, while the function check_actor is respon- sible for proving that there is a class whose name is equivalent to the name of the actor.
A similar implementation is made for the remaining rules, which are fully described in Appendixes B.2 and B.3. Note that these rules also depend on the meta-model described in Section 6.2.
In order to check either completeness or soundness, we must evaluate (assert) each of the rules, and we must assign the output to a variable that can be queried in SMT-LIB to conclude the validity of the model. We demonstrate these steps in the following model.
SMTLib 6.11: Checking for Soundness
;--- ; Validating model
;---
(declare-const actors_validation Bool)
(declare-const operations_validation Bool)
(declare-const attributes_validation Bool)
(declare-const inheritances_validation Bool)
(assert (= actors_validation actors_rule))
(assert (= operations_validation operations_rule)) (assert (= attributes_validation attributes_rule)) (assert (= inheritances_validation inheritances_rule))
;--- ; Checks ;--- (check-sat) (get-value (actors_validation)) (get-value (operations_validation)) (get-value (attributes_validation)) (get-value (inheritances_validation)) (exit)
Notice that the boolean constants named as *_validation store the result
of the evaluation of the corresponding rule. For instance, actors_validation
stores the result of the boolean function actors_rule.
At the bottom of the model, we have the (check-sat) command which
effectively executes the solver in order to prove our rules. After checking for the satisfiability of the model, we query the value of these variables. Should all of them be true, we conclude that the diagram is sound with respect to the specification. In these SMT-LIB models, the return value of the SMT solver is
unknown, because when using universal quantifiers, the solver cannot entirely derive conclusions about the universe of elements. For this reason, we only take into consideration the results for the specific rules, which constraint the reasoning domain to the elements that are members of the sets that describe the specification and the diagram.
The following model depicts the output of the solver when validating a diagram against a specification using our implementation of the validation rules for soundness.