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 u.voges@conterra.de Slide 1 1

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

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

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

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

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

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

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

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

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

Conformance Classes Maybe to align CC with Capabilities Doc Slide 11

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

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

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

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

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

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

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

Issues ETS: Ordering ICD has several async operations, but the TEAM engine at the moment does not support these operations. Same for checking email 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 20-25 (depending on resources left) Slide 19

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