Skip to main content

| EDGE
UBC: CPSC110 Systematic Program Design

This page will help you understand the differences between how we do things in lecture/lab/problem sets/exams from the way they are in the edX videos.

The goal of CPSC 110 is to be a world leading introductory course in software development.  We aim to help you learn expert-like ways of thinking about programming that can begin a path to being an excellent software engineer.  As such, CPSC 110 it is always evolving, always improving to keep up with research and practice in programming languages and software engineering. The great thing about that is that you will learn about ideas use in companies with leading software development cultures.

But being on the cutting edge has some costs.  Because we are always improving the course, some of the scaffolding is still visible.  This shouldn't surprise students at what is sometimes called the university of building construction.   Computer science, and certainly 110, is the department of course construction.  One of the most visible pieces of scaffolding is that there are some improvements to the course that are not yet reflected in the module videos.  The cost and mechanics of updating the videos is such that we want to have a number of improvements ready before we update them next.

The purpose of this page is to explain the differences between the module videos and the other course material.

Types

In the module videos we sometimes use something called an interval type.  An interval type looks something like Integer[10, 20), which means integers in the interval from 10 to 19 inclusive.  But we no longer use interval types in the course.  They are definitely on the horizon for professional software development, but there were too many complexities associated with integrating them with some of the other improvements we have made to the course.  It is nonetheless sometimes important to restrict the range of numeric values, we now do that with a constraint in the function signature, or in a data definition as shown here (module videos on the left, all other course material on the right):

edX videos lecture, labs, problem sets, exams

In a data definition:

;; Cat is Number[0, WIDTH]
;; interp. The cat's x position in pixels

In a function signature:

;; Integer[5, 10] -> Number

In a data definition:

(@htdd Cat)
;; Cat is Number
;; interp. The cat's x position in pixels
;; CONSTRAINT: always in the interval [0, WIDTH]

In a function signature:

(@signature Integer -> Number)
;; function purpose
;; CONSTRAINT: first argument is in the interval [5, 10]

@Tags

An emerging practice in leading software development organizations is to add annotations to programs that describe additional properties of the program's design.  Because these annotations are data about the program itself, they are called metadata annotations or metadata tags.  In 110 we uses a systematic design process which inherently generates important metadata describing how the program was designed.  In the videos this additional information always appears in comments; but we are now writing that information using metadata tags.  These tags formalize the notation for writing the information, and will also allow tools like the autograder to check the information.  All the information in the tags also appears in the videos - it just takes a different form in the tags.

edX videos lecture, labs, problem sets, exams

File header:

<nothing>

Start of Function Design:

<nothing>

Signatures:

;; Number String -> String

Origin of template:

;; template from SpaceShip

Start of Data Design:

<nothing>

Data driven template rules used:

;; Template rules used:
;;  - atomic distinct: "Stopped"
;;  - atomic non-distinct: Number

File header:

(require spd/tags)

Start of Function Design:

(@htdf <function-name>)

Signatures:

(@signature Number String -> String)

Origin of template:

(@template SpaceShip)

Start of Data Design:

(@htdd <type-name>)

Data driven template rules used:

(@dd-template-rules atomic-distinct      ; "Stopped"
                    atomic-non-distinct) ; Number

Glossary of @tags:

(@assignment <id>)

Goes at top of file to indicate which assignment is being submitted with SPD handin. Never edit this annotation.

 
(@cwl <id1>  <id2 (optional)>)

Goes after @assignment to indicate one or two ids of students submitting assignment.

 
(@problem <Natural>)

Goes throughout file to indicate that portion of file from that @problem to the next is the solution to the given problem number. Never edit this tag.

 
(@htdw <TypeName>)

Indicates that entire file follows the HtDW design recipe for a world program with the given world state type.

 
(@htdd <TypeName>)
(@htdf <function-name>

Indicates that portion of file up to next @htdd or @htdf follows the HtDD or HtDF design recipe for a type/function of the given name.

 
(@dd-template-rules <rule>...)

Lists HtDD data driven template rules used to form the immediately following template function. Note that the function must NOT be commented out. All rules in an @dd-template-rules annotation must be one of: one-of, atomic-non-distinct, atomic-distinct, compound, self-ref, or ref.

 
(@signature <TypeName>... -> <TypeName>)
(@signature <TypeName>... -> <TypeName> or false)

Specifies signature of current @htdf design.

 
(@template <origin>...)

Specifies origin(s) of the template for the immediately following function definition. Every origin in an @template annotation must be one of:

  • A primitive type.
  • A typed defined in an @htdd section of the same file.
  • A non-type template origin: htdw-main, fn-composition, try-catch, 2-one-of, encapsulated, use-abstract-fn, genrec, bin-tree (must be used w/ genrec), arb-tree (must be used w/ genrec), accumulator, or for-each.