Analysis and Design of the Test Client



| | |

| | |

ESSNET on SDMX

‘SDMX Data Explorer’

Analysis and Design of Query Builder

Version 0.2

September 2010

|Type of Document |Project deliverable |

|Reference: | |

|Issue: |0 |Revision: |1 |Status: |Draft |

|Created by: |Vignola Laura |Date: |2 |

|Updated by: | | | |

|Approved by: | |

Document Change Record

|Issue/ Revision|Date |Change |

|0.1 |20/08/2010 |Initial version of the document. |

| |08/10/2010 |Second version of document |

| | | |

| | | |

| | | |

| | | |

| | | |

| | | |

Table of contents Page

1 Introduction 5

1.1 Purpose 5

1.2 Structure 5

1.3 Reference Documents and Standards 5

2 Use case view 7

2.1 Requirements overview 7

2.1.1 Functional requirements 7

2.1.2 Non-functional requirements 9

2.1.3 Scenarios that were added for Query Builder 10

2.1.3.1 Scenario 1 – Select components 10

2.1.3.2 Scenario 2 – Insert Header 10

2.1.3.3 Scenario 3 – Load Header 11

2.1.3.4 Scenario 4 – Create SDMX query 11

2.2 Actor specification 11

2.3 Use case model 12

2.3.1 TstC-UC-1: Load DSD 12

2.3.2 TstC-UC-2: Insert Header 13

2.3.3 TstC-UC-3: Load Header 14

2.3.4 TstC-UC-4: Visualize query 15

2.4 Use-case/Functional Requirements traceability matrix 16

2.5 Activity Diagrams 17

2.5.1 Query builder 17

2.5.2 Test Web Service 18

2.6 Context Diagram 19

3 Logical View 20

3.1 Class diagram 20

3.2 TestClient package 23

3.2.1 WindowsApplication class 23

3.2.2 Constrain class 33

3.2.3 WebServiceClient class 33

3.2.4 WebServiceTest class 35

3.2.5 WebConigurationSettings class 36

4 Dynamic view 38

4.1 Sequence diagrams 38

5 Test Client New GUI proposed for SRA-19 40

List of figures Page

Figure 2-1: Test client Use case model 13

Figure 2-2: Test Client Generate Data Activity Diagram 20

Figure 2-3: Test Client -Test Web Service Activity Diagram 21

Figure 2-4: Test Client Components Diagram. 22

Figure 3-1: Test Client - Packages Diagram 23

Figure 3-2: Test Client - Class Diagram 24

Figure 4-1: Generate Data sequence diagram 40

Figure 4-2: Execute SDMX Query with Web Service sequence diagram 41

Figure 5-1: The WindowsApplication form, the main form. 42

Figure 5-2: The WindowsApplication form, the main form showing Build SDMX Query 43

Figure 5-3: The WebServiceTest form, at “Settings” tab. 43

Figure 5-4: The WebServiceTest form, at “Web Service Test” tab. 44

List of tables Page

Table 1-1: Terms and Abbreviations 6

Table 2-1: Task 22 Test Client enhancements Functional Requirements 9

Table 2-2: Test client Editor Non-Functional Requirements 9

Table 2-3: UC/REQ traceability matrix 19

Introduction

1 Purpose

This document serves as the software specification for the sub task “Query Generator” of the work package WP3 “SDMX data explorer”. This is a live document that will be further updated in order to reflect the actual state of the software

NOTE: It is recommended that readers of this document should have SDMX technical knowledge.

2 Structure

The structure of this document is as follows:

Section 2 describes the Use Case view. Functional and non-functional requirements are presented. The use case relations are presented in a use case model diagram. Activity diagrams are described in order to present the activities for each use case. Finally, the context of the tool is illustrated in a component diagram.

Section 3 describes the logical view, which depicts the detailed design structure of the application into packages and components.

Section 4 describes the dynamic view of the tool. This view shows the behaviour of the application, which is illustrated by using a sequence diagram.

Section 5 contains the proposed screens of the Test Client modification.

3 Reference Documents and Standards

The following documents and standards are applicable references:

Standards and Conventions

a. Unified Modelling Language (UML)

b. SDMX Technical standards, version 2.0 (November 2005)

Terms and abbreviations

|Acronym |Definition |

| | |

|FR |Functional requirements |

|NFR |Non functional requirements |

|NSI |National Statistical Institute |

|NSI WS |National Statistical Institute Web Service |

|SDMX |Statistical Data and Metadata eXchange |

|EUPL |European Union Public License |

|DDB |Dissemination Database |

Table 1-1: Terms and Abbreviations

Definitions:

Structure Message - The Structure is a message that contains all the structural metadata about a data set. This can be key families, concepts, or codelists.

For more information please consult SDMX Technical standards, version 2.0.

Use case view

1 Requirements overview

1 Functional requirements

|FR 1 |The Query generator should allow the user to create a SDMX query message starting from a DSD |

|FR 2 |The system should use a DSD already loaded in the "Load DSD" form. The system should display the concepts that belong to|

| |DSD loaded in a “Concepts” form in which they will be distinguished in: |

| |concepts (dimensions / attributes) coded |

| |concepts (dimensions / attributes) not coded, |

| |time dimension |

| |Dataflow |

| | |

| |The system must allow the user to insert Header information in a “Header” form to use inside the SDMX Query message. The|

| |header information could be insert directly by the user or loaded by a file |

| |The Query could be visualized in the “Query” form. |

|FR 3 |The “Concept” form should allow user to define information to create the element in the SDMX Query Message. |

| |The concepts form will be created automatically loading the Structure file containing the DSD. It will be conceptually |

| |divided in four parts: Concepts coded, concepts not coded, time dimension and Dataflow: |

| |The system should show concepts coded in two tree structures one for Dimensions and the other one for Attributes and |

| |allow user to select one or more codes. The structure of the two tree must contain: |

| |a root node for Dimension tree and one for Attribute tree having an “Expanding/Collapse” icon. |

| |Inside the “Dimensions” root node, a sub tree composed by coded dimensions. The name of the node will be the id of |

| |dimension as indicated inside the Structure file. The dimension icon node is a “Expanding/Collapse” icon . |

| |Inside the “Attributes” root node, a sub tree composed by coded attributes. The name of the node will be the id of |

| |attributes as indicated inside the Structure file. The attribute icon node is a “Expanding/Collapse” icon |

| |For every coded dimension, a sub tree of codes of the codelist to which the dimension refer to. The code icon node is a |

| |“checkbox” icon. |

| |For every coded attribute, a sub tree of codes of the codelist to which the attribute refer to. The code icon node |

| |should be a “checkbox” icon. |

| |The system should allow user to insert |

| |for every dimension not coded, one or more values, inside a grid where the first columns will contain a list of |

| |dimension not coded |

| |for every attribute not coded, one or more values, inside a grid where the first columns will contain a list of |

| |attribute not coded |

| |for the time dimension a StartTime and EndTime, |

| |one values for the dataflow. |

| |The “Concepts” form must contains: a button “Clear” to unselect all attributes and dimension selected and to remove all |

| |the information insert for not coded concepts. |

|FR 4 |In the “Header” form the user should have the possibility to insert the following information: |

| |ID |

| |Test |

| |Truncated |

| |Name |

| |Prepared |

| |Sender |

| |Receiver |

| |DataSetID |

| |DataSetAction |

| |ReportingBegin |

| |ReportingEnd |

| | |

| |For Sender and Receiver the information: |

| |Name |

| |Contact |

| | |

| |For Contact the information: |

| |Name |

| |Department |

| |Role |

| |Telephone |

| |Fax |

| |X400 |

| |URI |

| |Email |

| |The “Concepts” form must contains |

| |a button “Clear Header” to unselect all attributes and dimension selected and to remove all information inserted for not|

| |coded concepts. |

| |a button “Load header” to load a header already saved |

| |a button “Save header” o save header insert to reuse in a next time |

| |The Header form must allow the user to select a header files structured as in SDMX format and to load directly in the |

| |form |

|FR 5 |The “Query” form should allow the user to visualize query with the information inserted before. |

| | |

| |The “Query” form should allow the user to modify the SDMX query and check the correctness against Query Schema |

| | |

| |The “Query” form should allow user to save a query produced and to load a query already saved that user want to modify. |

| |Before to save the query have to be validated versus schema. |

Table 2-1: Query Builder Functional Requirement

2 Non-functional requirements

| | |

| | |

| | |

Table 2-2: : Query Builder Non - Functional Requirement

3 Scenarios that were added for Query Builder

1 Scenario 1 – Select components

Step 1: The user runs the SDMX_Data_explorer application

Step 2: The user select the label “Select components”

Step 3: The user load the DSD

Step 4: The user click on bottom “Query builder”

Step 5: The application creates the elements in the “Query” form:

Step 6: The user select the label "Conceps"

• Tree for dimensions coded

• Tree for attribute coded

• Grid row for dimensions not coded

• Grid row for attribute not coded

• StartTime and EndTime text box for TimeDimension (if exists in the DSD)

• Text box for dataflow

Step 7: The user select codes of dimensions or attribute that have to be included in the SDMX Query message

Step 8: The user insert values, separated by a character control, in the test box for every dimension or attribute not coded

Step 9: The user insert a StartTime and Endtime

Step 10: The user insert a DataFlow name that wants to query

2 Scenario 2 – Insert Header

Step 1: The user runs the SDMX_Data_explorer application

Step 2: The user select the label “Query Builder”

Step 3: The user select the label “Header”

Step 4: The system show a set of empty fields corresponding to information to insert in the Header xml element of the SDMX query

Step 5: The user insert information

3 Scenario 3 – Load Header

Step 1: The user runs the SDMX_Data_explorer application

Step 2: The user select the label “Query Builder”

Step 3: The user select the label “Header”

Step 4: The system show a set of empty fields corresponding to information to insert in the Header xml element of the SDMX query

Step 5: The system show button to choose a xml file containing the information of Header

Step 6: The system load header information

4 Scenario 4 – Create SDMX query

Step 1: The user runs the SDMX_Data_explorer application

Step 2: The user select the label “Query Builder”

Step 3: The user select the label “Query”

Step 4: The user click button “Query Builder”

Step 5: The system check for mandatory information and give an error message if mandatory information are not insert into the previous form “Components” and “Header”

Step 6: The system create a SDMX query message inside a text

Step 7: The user can modify Query SDMX message.

Step 8: The user clicks “Validate” button to validate SDMX query message against a schema.

Step 9: The user clicks “Save” button to save SDMX query message in local folder.

2 Actor specification

|Actor 1 |

|Name: |User |

|Abbr. Name: |US |

|Brief Description: |The user using the Query Builderuery Builder |

|Characteristics: |The user using the Query Builder to create a SDMX query message. |

|Actor 2 |

|Name: |Query Builder |

|Abbr. Name: |QB |

|Brief Description: |The Query Builder is the system that allow user to create the SDMX query message |

|Characteristics: |. |

3 Use case model

The following diagram presents the Use Case model of Test Client.

[pic]

Figure 2-1: Query Builder

1 TstC-UC-1: Load DSD

|Use case name: |Select Components |

|Unique use case ID: |TstC-UC-1 |

|Actor(s): |User, System |

|Precondition: |Installation of the web application Data Explorer |

|Brief description (flow of |Step 1: The user select Query Builder label |

|events): | |

| |Step 2: The user use the “MessageDataset” object previously loaded |

| | |

| |Step 3: For every Dimension coded the system will add a node inside the Dimensions tree while|

| |for every Attribute coded the system will add a node inside the Attributes tree. For every |

| |components the system will create a sub-tree with all the codes belonging to the codelist |

| |associated to the component in the DSD |

| | |

| |Step 4: For the components not coded components the system will create a grid in which, in |

| |the first column there will be for every rows a list box with all not coded conceps. In the |

| |next column corresponding to the concept selected, the user can insert value |

| | |

| |Step 5: The user select constraints for coded components. He will check codes from the |

| |codelist of corresponding concept that want to include inside the DataWhere element of the |

| |SDMX query. |

| | |

| |Step 6: The user could select in the list the component he needs (also more then one times) |

| |and in the next column corresponding to the concept selected, the user can insert value |

| | |

| |Step 7: The user can expand or collapse tree nodes, the values checked will be maintained. |

| | |

| |Step 8: The user can insert Time and EndTime for the components TimeDimension if this exist |

| |in the DSD. The StartTime and EndTime should have this format “YYYY-MM” |

| | |

| |Step 9 The user must insert a dataflow name |

|Post conditions: |None |

|Alternative flows and exceptions: |A1: After Step 3, 4, 5, 6, 7, 8, 9 user can clear information inserted. |

| | |

| |A3: The steps 3, 4, 5, 6, 8, 9 can be done in every order |

|Assumptions: |None |

|Issues: |None |

2 TstC-UC-2: Insert Header

|Use case name: |Insert Header |

|Unique use case ID: |TstC-UC-2 |

|Actor(s): |User, System |

|Precondition: |None |

|Brief description (flow of |Step 1: The user select the label “Insert Header” |

|events): | |

| |Step 2: The user fill all the textboxes inside the form |

| | |

| |Step 3: The user can save information about header in a xml file, indicating the full path |

| |and name of the file, to reuse in Load Header UC. |

|Post conditions: |None |

|Alternative flows and exceptions: | |

| |A1: After step 2 user can clear information inserted. |

| | |

| |E1: If no information are insert in the form the system will not save the Header File and |

| |signal an error |

|Assumptions: |None |

|Issues: |None |

3 TstC-UC-3: Load Header

|Use case name: |Load Header |

|Unique use case ID: |TstC-UC-3 |

|Actor(s): |User, System |

|Precondition: | |

|Brief description (flow of |Step 1: The user selects an Header xml file using “Browse” button |

|events): | |

| |Step 2: The user click the “Load” button. |

| | |

| |Step 2: The System check the validity of the xml file against a schema. |

| | |

| |Step 3: The System load information inside the form |

| | |

| |Step 4: The user can modify information |

| | |

| |Step 5: The user can save information about header in a xml file to reuse in Load Header UC. |

| |(where user can save header information? It will be necessary to let user the choosing of |

| |header file or not?) |

|Post conditions: |None |

|Alternative flows and exceptions: |A1: After Step 3 and Step 4 the user can clear information inserted. |

| | |

| |A2: After step 2 the user can select another Structure File information will be changed only |

| |after to click the “Load” button |

| | |

| |E1: If no information are insert in the form the system will not save the Header File and |

| |signal an error |

| | |

| |E2: If the Header File is not correct against schema an error will occur. |

|Assumptions: |None |

|Issues: |None |

4 TstC-UC-4: Visualize query

|Use case name: |Visualize Query |

|Unique use case ID: |TstC-UC-4 |

|Actor(s): |User, System |

|Precondition: |None |

|Brief description (flow of |Step 1: The user select the “Query Visualization” form. |

|events): | |

| |Step 2: The user click the button “Visualize”. |

| | |

| |Step 3: The system will read all the information insert in the Load DSD form and in the |

| |Header form. |

| | |

| |Step 4: The system will show in the text area the query using for the Header element the |

| |information inserted in the Header form and a as Datawhere element the information insert |

| |into the Load DSD form. |

| | |

| |Step 5: For every coded components in the Dimensions tree, having one value checked in the |

| |list of code, the system will create a element “” with the id of dimension and |

| |having as text the value checked. If the values checked are more then one, the system will |

| |crate more than one element (one for every code checked) and they will be |

| |included in a element. |

| | |

| |Step 6: For every coded components in the Attributes tree, having one value checked in the |

| |list of code, the system will create a element “” with the id of attribute and |

| |having as text the value checked. If the values checked are more then one, the system will |

| |create more than one element (one for every code checked) and they will be |

| |included in a element. |

| | |

| |Step 7: For every un-coded dimension, having one value filled in the text box the system |

| |will create a element “” with the id of dimension and having as text the value |

| |inside the text box. If in the text box there is a list of values separated by a character, |

| |the system will create more than one element (one for every value in the lists) |

| |and they will be included in a element. |

| | |

| |Step 8: For every un-coded attribute, having one value filled in the text box the system |

| |will create a element “” with the id of attribute and having as text the value |

| |inside the text box. If in the text box there is a list of values separated by a character, |

| |the system will create more than one element (one for every value in the lists) |

| |and they will be included in a element. |

| | |

| |Step 9: If the Time Dimension element is filled, the system will check insert a |

| |element having as and the values insert inside the form |

| | |

| |Step 9: If the DataFlow textbox is filled the system will insert a element inside |

| |the element |

| | |

| |Step 10: The user can save the query indicating the full path and name. |

|Post conditions: |None |

|Alternative flows and exceptions: | |

| |E1: If Dataflow textbox is not checked the user signal and error |

| | |

| |E2: StartTime must be before then EndTime otherwise an error occur. |

|Assumptions: |None |

|Issues: |None |

4 Use-case/Functional Requirements traceability matrix

|Use case ID |UC Name |REQ ID |

| |Select Components |FR 1, FR 2, FR 3 |

|TstC-UC-1 | | |

| |Insert Header |FR 1, FR 4 |

|TstC-UC-2 | | |

| |Load Header |FR 1, FR 4 |

|TstC-UC-3 | | |

| |Visualize Query |FR 1, FR 5 |

|TstC-UC-4 | | |

Table 2-3: UC/REQ traceability matrix

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download