Test Assertion Modeling - comments, etc

[stephen.green@systml.co.uk]

I've had a few thoughts on the material on the wiki before the
meeting which I wasn't confident about putting on the wiki as
yet so I thought I'd send a few to the list.

It strikes me that only simpler spec items can be represented
by the Predicative or the Event-behaviour models and TCs might
be challenged too much with more complex items. I was considering
the UBL SBS profile as an example and it has two normative rules
which are succinct in prose but would, I think, be very long and
complex if expressed as a list of TAs and even then could not be
so expressed using the models, I fear. They would need something
more like an ontology even though they are short. Rule one states:

"Parties sending UBL documents to parties specified as receivers of a  
UBL 1.0 Small Business Subset (SBS) document or documents SHOULD NOT  
require the same

receiving party to process any part of the UBL document which is  
external to the specified SBS."
http://docs.oasis-open.org/ubl/cs-UBL-1.0-SBS-1.0 - section 2.1.1

So it seems to me there need to be onotological statements defining
party
sender
subset
specified
external
... etc
even before a list of test assertions can be modelled for this rule
(and such test assertions would be, after all, just formal rules
which could then be turned into actual software tests).

Then there are issues like - how to model 'SHOULD', can there be
artifacts of artifacts, properties of properties, and can this complexity
even be modelled as a set of predicatives, etc?

Maybe this sort of item just needs to be prose with minimal structure (list?).

I did start to get an idea of what a set of predicatives might look like
though. I modelled them as generalaised XML nodes, looking at two factors

1. elements vs attributes - mainly elements?
2. nesting vs listing - with XOR, etc as attributes?

and one way to model the predicative features, mapping these to the XML is:

<talist>
	<preCondition OR>
		<preCondition/>
	</preCondition>
	<preCondition AND>
		<preCondition/>
	</preCondition>
	<ta>
		<preCondition XOR>
			<preCondition/>
		</preCondition>
		<preCondition/>
		<preCondition/>
		<preCondition/>
		<artifact OR>
			<property/>
			<property/>
			<property/>
			<artifact XOR>
				<property/>
				<property/>
				<artifact AND>
					<property/>
					<artifact>
						<property/>
						<property/>
					</artifact>
				</artifact>
			</artifact>
		</artifact>
	</ta>
	<ta>
		<preCondition XOR>
			<preCondition/>
		</preCondition>
		<preCondition/>
		<preCondition/>
		<preCondition/>
		<artifact OR>
			<property/>
			<property/>
			<property/>
			<artifact XOR>
				<property/>
				<property/>
				<artifact AND>
					<property/>
					<artifact>
						<property/>
						<property/>
					</artifact>
				</artifact>
			</artifact>
		</artifact>
	</ta>
</talist>

In its simplest form, either model (predicative or event-behaviour)
seems just to be a bulleted list or perhaps with some nesting and
distinction of a few types of bullets such as artifact, property and
maybe precondition (being borrowed from event-behaviour?)

I've lots more thoughts, issues, comments, etc but maybe I'm so off
track that they are best kept in hand.

Best regards

-- 
Stephen Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

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