Re: [tamie] Updates on lts xml for input to script compiler, some questions about monitoring for condition guard values...

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

I'm still a little in the dark about what aspects of the ebBP's
definition of a process are intended to be tested or monitored
with TaMIE/eTSM. The exercise of thinking what a conformance
profile (perhaps expressed as test assertions) might look like
if the ebBP definition was written as a conformance profile, such
an exercise might help determine what the eTSM script would
have to test. Then it's a mapping exercise to match those eTSM
features to the profile and thence to the ebBP. Then it's a matter
of generalising this, etc.

So: Q1. an ebBP says what about a process? and Q2. which (if not
all) of those things (things=assertions, if you will) is to be of
interest to the script writer/generator?

e.g.
Q1. what assertions does an ebBP definition make about an endpoint, etc
A1.
a) valid events
i) valid documents received - including valid structures, valid
content (e.g indicator content)
ii) valid documents sent
iii) valid signals received
iv) valid signals sent
v) valid events other than documents and signals (e.g. timeouts)
b) valid triggers of an event
c) valid results of an event
d) valid transports for each document or signal (sent/received)
e) valid signatures (for each party, document, etc)
f) valid decisions and decision outcomes
g) valid joins
h) valid parties
i) valid time to performs
j) validity of application of process definition (e.g. prior to expiry
date-time)
k) constraints on security in handling of messages, etc
etc

Q2. for which of these does eTSM intend to provide testing/monitoring?
A2. perhaps at least a) to j) [how much of each?]

Then an exercise might be to write out test assertions for a particular
use case for Q1.

Next step might be to select which of these test assertions apply to Q2:
Which are relevant for testing/monitoring using TaMIE?

e.g.
Id:TA001
target: endpoint A
normative source: process X...
prerequisite: message header denotes process X is being followed
predicate: receives Order, OrderResponse, OrderResponseSimple

This would highlight / pinpoint the precise aspects of the ebBP need
to end up in the eTSM script.

Next step; which bits of the ebBP map to which of those bits of the
script.

Next step generating for this use case

Next step generalising for many use cases

- Steve




2009/3/20 Jacques R. Durand <JDurand@us.fujitsu.com>:
> <JD> inline,
> -jacques
>
> -----Original Message-----
> From: Moberg Dale [
> mailto:dmoberg@axway.com]
> Sent: Thursday, March 19, 2009 3:53 PM
> To: stephen.green@documentengineeringservices.com
> Cc: tamie@lists.oasis-open.org
> Subject: RE: [tamie] Updates on lts xml for input to script compiler, some
> questions about monitoring for condition guard values...
>
>
> Dale, (asks Stephen)
>
> Just to seek clarification of what might seem obvious - I gather the goal is
> to treat an ebBP as being a kind of test assertion (or set of test
> assertions) about the collaboration(s). Is that
> right: Are we aiming to test the exchanges for conformance to the ebBP?
>
> <Dale>
>
> I actually wondered whether the way to proceed would be to transform the BP
> into TAG style assertions. That might also be possible. I have not followed
> up on that question; is there a standard way to take TAG and end up with
> ETSL? If there is, I suspect that there might be a way to XSLT our way to
> TAG style assertions.
>
> <JD> Although test assertions are the proper way to "interpret" a
> specification in a way that allows for conformance verification, I suspect
> that in the BP world, if the domain is well understood and has its own
> canonical representation (e.g. LTS) and where conformance has a precise
> meaning (e.g. an engine must only produces state transition "paths" that are
> specified in the BP def) then TAG would be of little help in the process of
> producing executable test cases.  I'd go directly to eTSM generation from
> the canonical rep (the augmented LTS). I see TAG test assertions here as a
> way to "specify" the kind of test to be perform - a bluprint. But in order
> to have TAG itself become a starting point in an eTSM generation process, we
> would have to "profile" it with a more formal expression language for BP.
> This might end-up becoming something close to ebBP ;-), so not sure if TAG
> would help here ! </JD>
>
> I think TaMie is trying to see whether the events on the board provide an
> "execution trace" for a process. If the events do that, then the events
> would conform with the process model (or selected aspects of it) specified
> by the ebBP.
>
> If by "conformance" you mean to say something about the
> implementation(s) that are producing events, there may be quite different
> approaches to assessing whether the implementation conforms with the
> specification.
> I am not certain that gathering an execution trace (or even many of
> them) establishes conformance with the specification.
>
> <JD> If there are other dimensions to conformance, then Tas may be a good
> way to capture these. </JD>
>
> Validation of the implementation (with respect to a specification) drifts
> more into "proving" that under whatever conditions that satisfy the
> implementation's description are ones where the traces that are produced are
> ones that satisfy the specification. Often these derivations require
> reasonably powerful logics (with mathematical induction support, for
> example, possibly over "big" ordinals) But I digress.
>
> In TaMie, we are testing or verifying implementations for conformance, but
> not validating them (which in accordance with some linguistic communities,
> would need something like a derivation of the specification assertions from
> some properties of the implementation...)
>
> Anyway, I think I would need to understand your usage of conformance, and
> also clarify what is being said to conform with what, to be confident that I
> am addressing your question. I am afraid my brain is a bit too cluttered
> with a bunch of distinctions to provide a simple straightforward response.
>
> Maybe a discussion on the call would help?
>
> </Dale>
> Secondly, is there anything else we would want to test using the derivatives
> of the ebBP? Perhaps in combination with some other configuration
> documentation - such as business criteria (like no orders being over 1000
> USD) - or is that out of scope for uc3?
>
> <Dale>
> It seems to me that we could add test assertions for business rules
> connected with the specifics of the collaboration. Certainly worth
> investigating.
>
> But these rules would not in general be extracted from the ebBP (except that
> the timeouts are associated with how long an "offer" is extended.
> Monica M or Jamie C can elaborate on how these business/tort law sorts of
> considerations are partly captured in ebBP) UNCEFACT (TMG maybe?) used to
> have an initiative for capturing BRs of the sort you mention (real TPAs) but
> I am not certain the group completed a full ratified open development
> procedure.
> <Dale>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>



-- 
Stephen D. Green

Document Engineering Services Ltd



http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice