pints software practices jarett hailes july 22, 2003
Post on 18-Dec-2015
219 views
TRANSCRIPT
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)