Programming Methodologies

Conrad Huang

conrad@cgl.ucsf.edu

Genentech Hall, N453A, x60415

Programming Paradigms

  • Engineering
    • You (think you) know what you want.
    • You want to build to a blueprint.
    • You want software engineering.
  • Exploration
    • You are not sure what you need.
    • You do not want to exert too much effort until you think there is a payoff.
    • You want exploratory or agile programming.

Software Engineering

  • Requirements
  • Specification
  • Design
  • Coding
  • Verification
  • Debugging
  • Documentation
  • Dissemination
  • Maintenance
  • Enhancement

Why Doesn't It Work (for us)?

  • We always get fuzzy requirements.
  • The most important phase is often the least well defined, particularly in a research environment.
  • We rarely have enough time to go through the entire cycle.
    • “What's documentation?”

Exploratory/Agile Programming

  • Faster feedback loop helps refine requirements while making progress towards creating a product.
  • Focus on using or implementing components helps organization.
  • Willingness to refactor helps keep code readable.

A Brief History of Methodologies

  • Functional decomposition
  • Structured programming
  • Modular programming
  • Object-oriented programming

  • Generic programming
  • Extreme programming
  • Agile programming

Methodology vs.
Programming Language

  • Methodology and programming language are orthogonal.
  • Methodologies may be applied using any programming language.
  • Some languages are easier to use with some methodologies.
  • The outward appearance of a program is determined by the language (e.g., indentation) but the methodology may be discerned from code organization (e.g., modules and classes).

Which is Best?

  • Methodologies should help create applications that are:
    • correct,
    • maintainable,
    • flexible, and
    • reusable.

Functional Decomposition

  • Divide problem into phases.
    • Use flowchart diagrams.
    • Frequently ends up as “Input, Compute, Output.”
  • Design algorithm for each phase.
  • Poster child language: Fortran.
  • Correctness: okay.
  • Maintainability: okay.
  • Flexibility: limited.
  • Reusability: limited.

Structured Programming

  • Organize at a local level.
    • No go to statements.
    • Use functions for grouping.
  • Maligned as “just indentation.” by unbelievers.
  • Poster child language: Fortran, C, Pascal.
  • Correctness: okay.
  • Maintainability: better.
    • more readable code
  • Flexibility: limited.
    • simpler to reorganize
  • Reusability: limited.
    • reuse functions

Modular Programming

  • Group related data and functions together.
    • Module functions operate on module data.
    • Non-module functions do not operate on module data.
  • Separate interface from implementation.
  • Introduce data abstraction and data encapsulation.
  • Poster child language: C, Algol, Ada.
  • Correctness: good.
    • module-based testing
  • Maintainability: good.
    • localized changes
  • Flexibility: better.
  • Reusability: better.
    • reuse entire modules

Object-Oriented Programming

  • Formalize convention of always passing module data structures to module functions.
    • Class: definition of functions (method) that operate on instance data.
    • Instance: data created using initialization method defined by class.
  • Classes represent concepts with state (data) and behavior (methods).
  • Poster child language: Smalltalk, C++, Java, Python.
  • Correctness: good.
    • class-based testing
  • Maintainability: better.
    • internal consistency
  • Flexibility: better.
  • Reusability: better.
    • reuse concepts

Generic Programming

  • Back to algorithms.
    • Objects that share the same interface can be manipulated generically.
    • Algorithms may be implemented for use across multiple data types, e.g., sorting.
      • If the data type defines a comparison operator, then a sorting algorithm may be applied regardless of other properties of the data type.
  • Products include toolkits of algorithms that may be applied to objects that conform to APIs defined by the toolkits.

Extreme/Agile Programming

  • Focus on people
    • Pair programming
    • Collaboration
    • Response to changes
    • Frequent releases
    • Continual redesign and refactoring

Classic Reference Material

  • Object Oriented Design with Applications, Grady Booch
  • Object-oriented Software Construction, Bertrand Meyer
  • Software Tools, Brian Kernighan, et al.