Echoview

Exploring Echoview’s Exporters  

Echoview 15 is here, bringing a wave of exciting new features! Our Development Team (comprising Coding and Quality Assurance) have been busy behind the scenes, programming, testing, and fine-tuning every detail to ensure seamless performance and elevate your Echoview experience.

We’re excited to highlight one of the standout new features, “Exporters”. Exporters are new objects in the Dataflow window (a key area in Echoview, empowering you to implement building blocks to enhance any workflow or data processing task) that allow you to preconfigure custom exports and save them in your workflow.

Echoview has always supported the analysis exports, which previously were obtained via a structure menu of 7 options. Echoview 15 will include new Dataflow features to make exporting and variable naming more intuitive, making it easy to repeat a range of exports in future analyses, including via EV file templates. Exporter objects are available for:

• Fish track analyses
• Frequency distributions
• ICES acoustic trawl survey database analyses
• Single targets analyses
• Sv integration
• Vegetation analyses
• Wideband frequency response analyses
  

They can be created via a New Exporter dialog and visually connected to the acoustic variables they will export. Exporters can be added to a dataflow via the selection of an export type on the New Exporter dialog, and then connected to an acoustic variable much like Echoview’s use of virtual variables.

Meet Mathew, Charles, and Ziggy, members of our Development Team (8 members in total) that worked on this feature. Charles, our Systems Architect, designed the exporter framework that developers used to implement the supported exporters in version 15. Mathew, our Senior Quality Assurance Engineer, led testing and ensured product quality. Ziggy, as Software Developer, was responsible for coding the functionality for nearly all the exporters. Find out from them how this feature was developed.

Why were Exporters introduced in Echoview 15?

Mathew
Traditional access to Echoview analysis export operations such as Sv integration by cells is through a multi-layered structure of menu options. While powerful, this has limitations, such as providing users with an overwhelming number of options, which can quickly become daunting.

New users may have also found it difficult to understand why various options are not possible for a specific echogram data type when viewing the contextually enabled export analysis options.

Early during the Echoview 15 development process a set of requirements to overhaul Echoview’s export system were defined with the goals of simplifying the process for end-users, while also increasing the reproducibility of exports.

What was the design process?

Charles
The design process consisted of considerations around:

• The requirements, what the problem is that we’re trying to solve.
• What the options are for solving this problem.
• What is the scope, i.e. what can be implemented in the time allocated that gives the most benefit to the user.

The main problems recognized were:

• Identifying which variables should be exported in an EV file.
• What settings should be used for each export. Some settings are currently provided as parameters to the export itself or are otherwise set on the variable\EV file, which reduces discoverability and means that users can’t easily specify different settings for different exports.

We then worked through a design specification with QA, I'll leave it to Mathew to outline the process.

Mathew
A design specification was created by the Development Team with inspiration taken to expand Echoview's already familiar dataflow-based workflow. The design specification outlined an implementation to migrate the menu-based export analysis options into dataflow objects which became named Exporters.

How did you approach implementation and evolution of the design?

Charles
The design called for implementing a new class of dataflow objects to model the different types of exporters. Some considerations that came up during initial design and development were:

• How to model the different exporter objects. Here we were able to adapt the existing operator approach for virtual variables where instead of calculating pings we perform the export instead.
• How to allow users to configure the exporters. To streamline configuring multiple exporters we evolved the design to allow editing the properties of multiple exporters of the same type simultaneously.

Ziggy
I wasn’t part of the initial design specification but during development if there were any design decisions required, usually I would create and propose a solution and then start a discussion with Mathew about this design. A notable example of this is the wideband frequency response exporters which needed a way to choose input variables including the reference. The choice of using the dataflow and operands to do this came from this process.

What was the programming process?

Charles
The general development process was:

• Adding the new exporter dataflow object type to the dataflow (e.g. what it looks like on the dataflow, hooking up the operands etc).
• Extending the operator system to allow it to be useable by the new exporter object. This meant removing some of the links to existing variables and the concept of that operator for calculating line segments\pings, so that it could be specialized in terms of types (e.g. acoustic variables calculate pings, lines calculate line segments, exporters export data).
• Implementing property dialog system to allow users to set them up.
• Implementing specific exporters for the existing analysis exports.

Ziggy
Generally, I find the best way to approach an implementation is just to go for it and create a working draft solution, which involves doing the programming and creating the user interface. Through this process problems will present themselves as you work and at this point you can iterate on the design. Charles created the exporter backend and infrastructure which made it easy to build the exporters that you see in Echoview 15!

What was the Quality Assurance (QA) process?

Mathew
Quality assurance began following the completion of an initial Vegetation Analysis exporter prototype. The prototype supported functionality such as exporter dataflow objects; a New Exporter dialog; the Exporter properties dialog; and the required COM and command interface support for Exporters.

Initial investigative quality assurance reviewed how the implementation operated in the context of Echoview as a system. Discoveries from this process, fed back into the development to solidify the vision of how Exporters are presented and function within Echoview.

Once we were happy with the overall definition and interfaces that would support Exporters, each individual export type was implemented into Echoview. The functional quality assurance process continued with an in-detail review of the formal requirements documents. Then a structured functional test-plan was developed.

Tell us about regression testing and its support for this new feature?

Mathew
As part of Echoview Software’s focus on rigorous and meticulous quality assurance we undertake a suite of over 2800 automated regression test cases against every developmental build of Echoview. Verifying our continued support of over 75 echosounder and sonar file formats from 17 manufacturers, and more than 70 operations which allow for the manipulation and analysis of echogram data from release to release of Echoview. Ensuring exported results match validated reference results.

We have enhanced our automated regression testing solution to support interaction with Echoview’s new exporter dataflow objects. This will allow us to ensure the reliability of exporter results throughout future releases of Echoview with the creation of 54 initial test cases.

What are the future plans for further development?

Charles
Looking forward to seeing what other problems the exporters can be used to solve, as well as expanding our list of supported exports.

Ziggy
So much! I’m currently working on greatly expanding the number of exporters we have, including exporting to CSV and Echoview data file format. There’s a lot to come in Echoview 16!

Mathew
Echoview 15 provides new exporter support for all of Echoview’s analysis export operations. With future releases of Echoview we will expand exporter support to include all of Echoview’s data exports such as CSV, Matlab and EVD formats.