1. Ordering Services for EO Products Abstract Test Suite (ATS)
HMA FollowOn – Task 4
PDR Meeting at Esrin
03 February 2010
Uwe Voges, con terra GmbH
Slide 1 1

2. Agenda Introduction General Model Conformance Classes Test ‘Scenarios’
Test Cases
Results
Next Steps
Issues
Slide 2

3. Sample fictive ProductOrder Specification
Collection XY
Band 1
Band 2
Band 3
Band 1
Band 2
SceneSelection:
sceneCoordinates (Polygon)
Band 3
Product 2
Collection:
Collection XY
Band 1
Product:
Product 2
Band 3
OrderItem
Order Option:
spectralBandComposition (Band 1, Band 3)
Slide 3

4. Introduction
An Abstract Test Suite ATS: provides a basis for developing an Executable Test Suite (ETS)
Purpose is to verify that an Implementation Under Test (IUT) conforms to all relevant functional specifications.
Relationships between set of specification documents:
Slide 4

5. General Order Model
Figure: general UML model of the EO Order Service Interfaces (OGC approach)
EOOrderService class associated with five classes
each associated class de- fines one or more operations
EOOrderService is realization of OGC Service
each instance of the EO- OrderService must implement two or more associated classes, depending on the abilities of that service instance
EOOrderCore type is abstract class from which three concrete classes are derived
Slide 5

6. Conformance Classes
Each is related to an order- type which is handled by the operations
Instance of the EO- OrderService type is composite object that is high-level characterization of an EO Order Service
Associated classes are mandatory or optional
A compliant EO Order shall implement OGCService and EOOrderCore and can implement additional classes
Each concrete type has one or more Conformance Test Classes associated (green)
These Conformance Classes are defined within the ATS
Slide 6

7. Conformance Classes
The relatively large number of Conformance Classes result from the combinatoric of three different attributes which span a three dimensional space
The three axis of this space are:
The Operations: a set of mandatory (Core) operations GetCapabilities, GetOptions, Submit and GetStatus can be combined with the three optional operations (GetQuotation, Cancel, DescribeResultAccess)
The OrderType: ProductOrder(PO), Subscription (Sub), Tasking (SPS)
The Processing type: synchronous, asynchronous with notification
Slide 7

8. Conformance Classes
Each of the following three Conformance Classes (dark green) address the core set of synchronous operations for one specific OrderType
Supporting one or more of these conformance classes is mandatory for an HMA EO Order Server:
EOOrderCorePO
EOOrderCoreSub
EOOrderCoreSPS
The following additional conformance classes test additional optional behaviour (“light green” coloured in the figure above).
Slide 8

9. Conformance Classes
EOOrderCoreAsynchPO / EOOrderCoreAsynchSub / EOOrderCoreAsynchSPS
test cases which cover the optional additional support for asynchronous Submit requests.
Submit operation allows the client to specify a Callback handler
EOOrderQuotationPO / EOOrderQuotationSub /EOOrderQuotationSPS
these conformance classes define test cases covering the GetQuotation support (orderTypes: PO, Sub, SPS) for the two processing types:
- Synchronous quotation / Asynchronous quotation with monitoring
EOOrderQuotationAsynchPO / EOOrderQuotationAsynchSub / EOOrderQuotationAsynchSPS
These conformance classes define test cases covering the optional additional support for asynchronous (with notification) GetQuotation requests.
GetQuotation operation allows the client to specify a Callback handler.
Slide 9

10. Conformance Classes EOOrderResultAccess EOOrderCancel
This optional conformance class defines test cases covering the support for the DescribeResultAccess operation
EOOrderCancel
This conformance class defines test cases covering the support for the synchronous Cancel operation
EOOrderCancelAsynch
This conformance class defines test cases covering the optional additional support for asynchronous (with notification) Cancel
Cancel operation allows the client to specify a Callback handler
The last three classes are independent from an OrderType
they require only an orderId (and not an orderSpecificationInformation) as input parameter.
Abbreviation “Asynch” in Conformance Class Names mark support for asynchronous (with notification to Callback) behaviour.
Slide 10

11. Conformance Classes
Maybe to align CC with Capabilities Doc
Slide 11

12. Test ‘Scenarios’
Some test cases within a conformance class are dependant on the results / procedure of other test cases within the same conformance class
Test class can be seen as a Scenario
UML state diagrams in ATS visualize those scenarios as transitions (from the servers point of view)
transitions of the core test classes EOOrderCore(PO|Sub|SPS: lines coloured green in the state diagram
Transitions of EOOrderCancel Test Class visualized with pink lines
Transitions of the EOOrderResultAccess Test Class are visualized with red lines
EOOrderQuotation: separate diagram (not included here)
Slide 12

13. Tests Cases
Each Test Class (or Test Scenario) includes a set of Test Cases
Every Test Case represents the execution of a service call and the testing of the service results
A Test Case looks like:
Slide 13

14. Tests Cases Some Test Cases are dependant from other test cases:
Scenario has to wait for a specific status to proceed with next Test Case:
Slide 14

15. Tests Cases
As the definition of the different Test Classes would result in massive replications of Test Cases I defined a concept of sliding-in or replacing Test Cases
Example:
Slide 15

16. Results: ATS
First draft of ATS on Ordering prepared and reviewed in December 2009;
Separate Document
Later to be integrated in OrderD
Last version delivered by conterra on 25/01/2010, under consortium review.
Version before delivered to ESA by 22/01/201 0
Update after PDR
Slide 16

17. Results: ATS Darm stadt Frasc ati Setup Issue Tracker Includ ed Items
Lots of input for Order ICD
Meetings:
Darm stadt
Frasc ati
Input for OGC Ordering SWG
Telecons
Slide 17

18. Next Steps: ETS Start working on ETS (CTL-Scripts)…
Must reflect slide-in concept of ATS
Slide 18

19. Issues
ETS: Ordering ICD has several async operations, but the TEAM engine at the moment does not support these operations.
Same for checking receival
Elaboration of complicated ATS concept and lots of inputs into Order ICD, Issue Tracker, Order SWG resulted in major consumation of Resources than expected
Consequence: not all ATS Test-Cases can be covered by ETS
This was already foreseen -> therefore we restricted in our proposal the amount of test cases to (depending on resources left)
Slide 19

20. FYI
For EUMETSAT we are currently implementing HMA Order for EUMETSAT...
Slide 20