CMPT 376: Assignment 4 - Describing a Process (Rough Draft)

Turn in between 4 and 9 double-spaced pages total. You must include at least two
diagrams. The following don't count towards the page limit: reference list, diagrams,
figures, or screen shots and copies of the benchmark results. Submit via the CS
submission server by midnight (end of day) Friday, November 26. Submit a single pdf
file compressed with either zip or gzip) with the name "fourth-rough.zip" or "fourth-
rough.gz".

Overview

Your company has expertise in a technology. They wish to publicize that expertise by
having one or more key employees write an article in a trade magazine on some aspect
of the technology. You enjoy writing (by this point in the semester, of course you do)
and know the area, so you've volunteered to write the article. A prominent technical
magazine (such as IEEE Computer or Communications of the ACM) is interested in
publishing it.

Rhetorical situation

Subject (primary focus)

The primary focus of this article is your subject, and by accepting your article, the
editors of this magazine are expressing their judgement that you are an expert in the
topic.

Audience (secondary focus) - The audience for this magazine are professional
programmers and systems engineers. They work with a diverse range of software
technologies. A few will already know your topic at least as well as you do, but your
article isn't for them. This article is written for those familiar with software in general but
not with your topic specifically. There's a slight fiction here: For this exercise, you might
pick a topic that nearly everyone in this magazine's audience would be expected to
know. That's fine for our purposes. There's no requirement that you stretch the
boundaries of professional education for this assignment. We're focusing on the
choices required in writing such an article, not the precise technical content.

Context - This is a formal context. You will be writing in a high-profile magazine,

representing your organization. Many people important to the future careers of both you
and your company will read this article.

Observe the basic principles of formal writing. Don't use contractions. Humor is
acceptable, provided it's understated. On the other hand, the principles of clear writing
still apply. Take responsibility for your opinions with phrasings such as, "I believe" or "I
recommend", rather than offering opinions in the passive, "It is widely believed". If you
wish to claim that you are presenting the opinion of your organization, you are welcome
to phrase it as, "We believe", or even, "At Yoyodyne Propulsion Systems, we believe
'The Future Begins Tomorrow'".
CMPT 376: Assignment 4 - Describing a Process (Rough Draft)

(Note that the context of this assignment description is decidedly less formal than the
article you are writing.)

Subject

Select a process that arises in computing and describe it. In computing, processes
arise all the time. Examples include resolving a page miss in virtual memory, the stages
in a POSIX pipe script, compiling a programming language, the steps of a sorting
algorithm, or the cycle of an agile development method. A process is characterized by a
series of steps performed by an agent or a series of stages through which some data
passes. For example, in an agile development process, a developer might do four
steps: write user stories, develop one incremental feature, do an integration test, and
check the feature in to the production system. An email message passes through
stages on its way from sender at SFU to recipient at Gmail: in the sender's outgoing
mail queue, in the SFU server's outgoing mail queue, in the Gmail incoming server, in
the recipient's inbox queue.

Processes are superficially easy to describe but can be hard to describe well. The easy
route is to simply churn through the steps one at a time, inviting the reader to envision
themselves as performing the steps themselves or being the object the steps are
performed upon. But this approach may ultimately be more writer-centered rather than
reader-centered.

A reader-centered approach seeks to maintain the reader's interest, and the reader's
interest is often not focused on the first steps. The preparatory steps are often the least
interesting, however vital they may be for ultimate success. As a chef, are you
fascinated by techniques for chopping vegetables or would you really rather read about
simmering the main course? If you were writing a cook book, you would probably want
to tease the reader with the interesting part before describing the application of knife to
zucchini. Perhaps you would begin with a photograph of the whole meal together with
an opening paragraph describing its taste.

A reader-centered approach may also require starting with ideas familiar to the reader
and moving to unfamiliar ideas. Once again, the reader may only see the need for
preparatory steps after later steps have been described. Returning to the agile
development example above, the step "write user stories" may seem unnecessary or
perhaps the reader agrees on their need but doesn't see what details to include, only
becoming clear to the reader when they see how the stories will be used in actual
development. Thus the writer may choose to begin by describing development and only
then backtrack to describe writing user stories.

Selecting a process to describe

You may pick any process that falls under the large heading of "computing science". It
does not need to be a topic in a course you are taking this semester, and in fact does
CMPT 376: Assignment 4 - Describing a Process (Rough Draft)

not need to be a topic in any course you've taken. It could just be something that
interests you. Some processes make better topics than others. You'll need something
with rich detail to sustain this many pages of description. A topic can be too large: for
example, "software engineering" is likely too abstract. Indeed, "software engineering"
itself isn't a process, but a collection of processes such as development cycles, testing
strategies, estimation procedures, and so forth. By contrast, small processes rarely
have the same problem of insufficient detail. Almost any technical topic has enough
complexity to fill several pages. Although you should be careful not to pick a process
that is too small, the greater risk is to pick one that is too large.

Diagrams

Processes are natural candidates for description by diagram. Your final description
must include at least two diagrams, and your text must be organized around these
diagrams. You may wish to include additional diagrams. For example, you might wish
to show a system's progress through several stages, with a separate diagram for each
one.

Each diagram should clarify parts of your description that are difficult to express in
words. The spatial organization provided by a diagram is especially good for showing
hierarchies of components and communication paths between components, as well as
steps in a complex process. A diagram can sometimes organize large amounts of detail
far more clearly than words can.

Code is usually insufficient as a diagram. The only exception is if you annotate the
code with, say, arrows and boxes showing storage layout or things like that. In general,
don't use code as your diagram. As always, diagrams do not count towards your page
count.

Each of your diagrams must be original. A diagram must not be simply a redrawn
version of someone elseʼs diagram. Furthermore, each diagram should contribute new
information that is not easily captured verbally. Simply putting each element of an
enumerated list in a box and drawing arrows between the boxes, for example, would not
warrant using a diagram.

Goal and structure of draft

As with any writing, you will choose the order in which you make your points based
upon your understanding of the audience, the structure of the material, and what the
audience expects and already knows about the material. It is best to try out several
different approaches before selecting your final sequence. Chances are, as soon as
you imagine describing this process, you think of a "natural" way to describe it. For the
draft, I want you to consider several "less natural" alternatives. These will give you
some insights into your final presentation.
CMPT 376: Assignment 4 - Describing a Process (Rough Draft)

There are several approaches you might use for describing a process:
• Describe it as a series of steps: First this happens, then that, and finally this other
thing.
• Describe it as movement through a series of locations or data structures: Start here,
then go there, then go this third place. In computing, the "locations" are often data
structures rather than physical locations.
• Describe it as a series of human or machine actors: First this person works on it,
then this person, finally this one. Or first this algorithm processes the input, then this
algorithm, and so forth.

There are other ways, but these three approaches the most common.

Example of the three approaches

Consider the POSIX pipeline

tr '\n\t' ' ' | tr -s ' ' | tr ' ' '\n' | sort

which takes an input file and produces a sorted list of the words in the file, one word per
line. Using the above approaches, we might generate the following descriptions:

Series of steps
1. Translate all newlines and tabs to spaces.
2. Convert all sequences of spaces to a single space.
3. Convert all spaces to newlines.
4. Sort all lines.

This phrasing is likely the one most writers would begin with.

Series of data structures (locations)

1. A string whose only whitespace is space characters
2. A string for which every space has a non-blank neighbor.
3. A list of lines, one word per line.
4. A list of lines, one word per line, sorted.

This phrasing is admittedly odd—you would more likely describe the steps of
processing in this case. But note how the focus on data structures forces a
greater clarity of their description.

Series of actors (in this case, programs or algorithms)

1. t r breaks up every word to a separate line.
2. s o r t sorts the list in ascending lexicographic order.
CMPT 376: Assignment 4 - Describing a Process (Rough Draft)

Note how focusing on actors coalesced the first three steps. This organization
emphasizes the common element of the first three steps, distinguishing them
from the final sort step.

The example pipeline is too simple to require much descriptive detail, but it should be
sufficient to illustrate the three approaches. With a richer process to describe, the
differences between these approaches would be more dramatic.

Structure and format of rough draft

For your draft, describe your process using the three different approaches to
sequencing the points. Represent two approaches by diagrams. Organize your draft in
the following structure:
1. Name the process you are describing. This should only take a sentence.
2. First, describe the process as a series of steps.
3. Second, describe the process as a series of data structures or locations.
4. Third, describe the process as a series of actors (human or machine).
5. Two of the three approaches should be accompanied by a diagram.

The descriptions should be a mixture of outline points and actual sentences. Specify
the major structure as bullet points (that saves the effort of developing transitions for a
structure you will likely not use). Within each major point, write sentences. The
sentences themselves don't need to be crafted, just detailed enough that you have to
think through the smaller points. You do not need as much detail as you will put in the
final version. Separate each approach with a header.

It is likely that one of the approaches to organizing the material will seem strained.
That's fine. The goal of the draft version is to (once again) get you to look at your topic
through several lenses, seeing different details each time. For the final version, you will
likely include elements discovered by each approach.

Work to make each approach distinct from each other. Don't simply recast your first
approach in slightly different language. The point of this draft is to consider your
process from very different points of view, highlighting different aspects.

Your diagrams can be rough. Focus on the content, rather than the visual appearance.
Feel free to sketch a diagram on paper and scan it. For the rough draft, diagrams can
be placed in a group at the end of the article, rather than interpolated into the text.
Follow the requirements for a rough draft set out at the end of Assignment 1 Rough.