PINTS Software Practices Jarett Hailes July 22, 2003.

PINTS Software Practices

Jarett HailesJuly 22, 2003

Acknowledgements

• Practices have been developed in conjunction with:– Surrey Kim– David Ballantyne– Calvin Chan– Jonathan Wiersma– Jesse McCrosky– Nikki Hu– Liam Stewart– Mike Kouritzin

Outline

• Background

• Objectives

• Practices– Organization– Standards– Testing & Review– Software Design Framework

Background

• Before:– One off project development

– Little coding standards

– Limited independent testing

– Management burden

Background Cont.

• Early initiatives:– Determine common interfaces

– Provide group collaboration

– Discussed standard way of presenting data/code

Background Cont.

• We found:– Bottom-up approach didn’t catch everything

– Common code helped speed development

– Needed to build more consistent structure usage

– Haven’t made independent testing a reality

Objectives

• Reorganize PINTS to distribute leadership and maximize productivity

• Finish developing management reporting, and coding standards

• Establish and execute trial run of testing and code review

• Develop versatile framework for all projects

Organization

Project Leader

Project Manager

Project Head Project Head Project Head…

Project Members

Project Members

Project Members

Standards

• Project Standards– Outline– Informal updates– Project Reports

• Coding Standards– Style & Substance

• Documentation Standards– Recording all relevant information

Testing

• Independent, black box testing

• Based on code documentation in interfaces

• Deterministic versus random components

Code Review

Process:

1. Prior to meeting, main author sends out code to reviewers

2. Reviewers look over code for:a) Correctness

b) Coding style standards

c) Clarity/relevance of comments

Review Contd.

3. Meeting: a) Tester presents black box results

b) Reviewers provide feedback on code

c) Suggest/Require changes

4. Post-Meeting:a) Alter code as necessary

b) Follow-up with subset of reviewers

Framework Outline

• Requirements

• Interface

• Directions

Requirements

• Easy to assimilate (new users)

• ‘Plug and Play’ filters/problems

• Provide distributable computing interface

• Ability to build language around framework

• Make filter code more versatile

Interface

• Basic Object Hierarchy

• Signal / Observation Models

• Filter breakdown– Modules– Filter interface

• Executables

Basic Objects

Signal / Observations

Modules

Filter

Executables

Putting it Together

• Example:ProjectManager::buildEnvironments() {

numFilters = parameterFile.getFilterCount();

for (i=0; i<numFilters; i++) {

parameterFile.getFilterVariables

(i, vars);

switch(vars.filterType) {

case SERP:

this->buildSERPEnvironment(vars);

…

}

}

Example Contd.

ProjectManager::run() {

for (int i=0; i<numFilters; i++) {

for(int j=0; j<moduleCount[i]; j++)

executeModule(filters[i], moduleOrder[i][j]);

}

Directions

• Complete interface standardization

• Realize helper classes (updater, visualizer, etc.)

• Implement on all combinations for:– 2 Signal/Observation pairs– 2 Filters: Particle & (REST or IDEX)