Comments on the TA Model 0.8.0.1

["Jacques R. Durand" <JDurand@us.fujitsu.com>]

 

Comments on the TA Model 0.8.0.1:

-----------------------------------------

 

 

---------------------------------------------------------------------------------------------------

1. "Abstract model vs. Concrete representation"

 

We need to clearly distinguish and define the notion of "concrete representation" of the model,  (as mentioned in "Implicit TA parts" of subsection 3.1, or in the conformance clause)  from the model itself. We use the term "representation" for the model itself, e.g. in title "Convention Used for Representing the Model", which is confusing for the reader: which representation are we talking about, a "concrete" one? or the model itself?

 

I suggest that we call the syntax we provide, an "abstract model definition" or a "formal definition", but not a "representation" of the model. We can then leave the term representation for all "[concrete] representations" such as an XML markup, an UML diag, etc.

So what we provide could be described as a THE "formal syntax or definition" of the model - leading to defining abstract models only - , not a representation of it.

An introduction blurb would be useful about this. Then users would not be confused as which kind of  "representation" is being discussed in the COnformance Clause section.

 

So when introducing the formal definition of each construct in section 3, e.g. Target, TestAssertion, etc, I would not say :

 

Representation:

class: testAssertion {....}

 

But instead:

Formal definition:

class: testAssertion {....}

 

---------------------------------------------------------------------------------------------------

2. The definition of cardinality is misleading:

 

(0..1) specifies an optional, singular entity (lower bound 0, upper bound 1)

(0..*) specifies an optional, multiple entity (lower bound 0, upper bound unlimited)

(1..1) specifies a mandatory, singular entitiy (lower bound 1, upper bound 1)

(1..*) specifies a mandatory, multiple entity (lower bound 1, upper unlimited)

 

Because as it turns out, every part of a TA in the abstract model has cardinality (0..something) suggesting they are all optional, while in fact some are mandatory although could be implicit. Given that "implicit" is mostly a convenience feature, I would suggest to :

(a) add a NOTE that says "in a concrete TA representation, mandatory parts could be absent provided that they are implicitly defined somewhere else....(i.e. that their actual representation can be inferred, either from a container structure like "TA-set" or from other rules.)

(b) in the formal / abstract model, we can then clearly stick to what we said about core / optional earlier in 3.1:

 

class: testAssertion {

id : string (1..1)

language : string (0..1)

NormativeSource : normativeSource (1..1)

Target : target (1..1)

Prerequisite : prerequisite (0..1)

Predicate : predicate (1..1)

...

 

---------------------------------------------------------------------------------------------------

3. We should explicitly map the model classes we develop (testAssertion, normaticeSource, target...) , to the informal "TA parts" introduced beginning of section 3.1 e.g.:

"the "target" class is a formal definition for the Target TA part described in 3.1."

 

I also think we should add a new subtitle like " 3.2 Test Assertion Model", just before "Convention Used for Representing the Model". And Section 3.1 could be renamed "Overview of a Test Assertion Structure"

 

 

---------------------------------------------------------------------------------------------------

4. Shouldn't we define a "logicalExpression" or "condition" class that would be reused for both Predicate and Prerequisite, showing clearly that their values are same type of material?

 

So instead of:

  Prerequisite : prerequisite (0..1)

  Predicate : predicate (0..1)

Use:

  Prerequisite : logexpr(0..1)

  Predicate : logexpr(0..1)

 

With the following definition:

class: logexpr{

content : string (0..1)

language : string (0..1)

}

 

We would then add some "semantic" requirements to the logexpr class , like:

"the content element / property MUST contain an expression that can be evaluated to "true" or "false".

While such semantic additions may not be necessary in the cases where they have already been specified in the TA parts introduced 3.1 , e.g. once we said that testAssertion "id" maps to "Test Assertion Identifier" in 3.1, then we know it is supposed to contain values that uniquely identify a TA.

 

 

---------------------------------------------------------------------------------------------------

5. The Report element:

I would remove these introductory sentences:

 

"The report class is included in the test assertion for usability to allow implementations to include some

degree of automation of execution of profiled test assertions. In which case the output of the execution of

test cases derived from a test assertions may need to be specified in the test assertion itself without the

need to extend the model with additional attributes and associations."

 

which insist a bit too heavily on "execution", while in fact error messages or the like can be associated with a TA outcome as "abstractly" as a the Description element is. These Report messages can be seen as more precise "prose descriptions" of the TA outcomes, in terms of what they mean for the Target.

 

The "when" attribute can then be defined as of class "logexpr" (see comment #4)

 

 

 

 

-jacques