Re: [tag] Comments on the TA Model 0.8.0.1

[Stephen Green <stephen.green@documentengineeringservices.com>]

I'm OK on most of these points. Just one I'm still
not sure about. Point 4. If we define logicalExpression
as a kind of abstract class
a) it pushes us even further down the road of an OO
model - so far that it implies an OO implementation
(which might even be a problem for XML, but all the
more for something completely non-OO like a database,
flat file structure or table).
b) it makes it a little confusing as to whether, as with
point a), an implementation has to (i) implement both
predicate and prerequisite with the exact same structure
(or 'class') (ii) use an 'abstract' or some equivalent for the
logicalExpression (iii) implement logicalExpression at
all in some demonstrable way in order to be conforming.

I'd also be wary of how we would make it clear that the
logicalExpression is not a concrete class - especially
without invoking and emphasising OO inheritance
principles of 'is-a' inheritance, abstract classes, etc. We
don't really expect people to somehow actually implement
explicitly and demonstrably a logicalExpression class do
we? Would they have to call it that or something that can
be mapped to it? etc...

What are the benefits we can offset against these 'costs'?
Best regards
---
Stephen D Green




2009/12/8 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
>
>
>