CS 1150 PEEE   Modularization to Organize Actions

Overview

We have discussed the fundamentals of programming as consisting of data & actions (often on data) and organizing the actions via sequence, selection, repetition and modularization. This practice/learning activity will revisit those ideas in more detail focussing on modularization to organize the actions in a program (or set of scripts). The learning activity is described after the Process Reminders below.

Process Reminders

Pair Programming

Keep the "pair programming" process in mind as you work. One person types and the other person watches and corrects, questions, etc. After a bit (at most 30 minutes) you change roles.

Grading

This activity is for you to learn, so it is not graded. The learning will be inferred in the PARR (Programming Activity and Reflection Report) document you (eventually) submit and in one of the in-term exams. Remember to add to your notes for the PARR.

If you have questions or difficulties

If you have questions about the assignment send me an e-mail or drop by my office. If you have a question while working on the assignment do the same. Keep in mind that when you encounter something you can't figure out you can/should think, explore, seek answers on google, etc. but, do not spend more than 15-30 minutes trying to overcome a particular error or problem.

Extra Credit

The syllabus noted a couple ways you might earn extra credit. I am adding another.

One is to share some aspect(s) of programming or Snap! you think others might not have experienced. You should annotate your program using the program notes (File icon | Program notes) and/or comments blocks (see p.68 of the Snap! Reference Manual. The annotation should describe or explain the learning/insight(s) you want to share.

To receive extra credit for such an annotated program on this activity you will also need to submit a copy of your algorithms. Either create a PDF of a document or include the text in your submission message.

The alternative method to work for extra credit is that the partnership could suggest additions to our how to do it page. You might suggest a revision to clarify (or finish) something that is there already or an entirely new topic. Please indicate how/why you think the would be helpful. Be sure you fully and clearly describe what you are talking about.

The third method to receive a bit of extra credit is to submit the "Create your own problems ..." that you created and solved. Include all three problems and a pseudo-code algorithm of each solution.

Submitting something for either kind of extra credit is as simple as sending an e-mail message. The message should:

Learning Activity

The goal here is to provide activities that help you understand and use modularization as a program tool. Modularization can help organize the execution of actions to accomplish particular goals by allowing you to think in terms of overall tasks and leaving the details for later development after you have "solved" the problem in terms of big ideas. We are at the point where programs/scripts are getting more complex. Modularization also allows us to use the same code to do similar (or identical) tasks without having to have multiple copies of the same code. For example you might draw the initials JPE twice to produce a look of narrow letters drawn inside fatter letters. Or you might draw them at different locations or with different sizes or colors. Another modularization task is to develop a rectangle drawing module that allows you to draw a house windows and doors and a sidewalk leading up to it.

When developing modules (new blocks) it is useful to consider:

I suggest you use a different sprite for each of the items. This should make working on a particular script less confusing.

The Items

Initials (actually MPI)

The goal is to produce scripts that draw a set of initials or an organizations acronym, e.g., UNI. However, to provide some consistency and to provide some particular programming experience, everyone is to draw the letters MPI. Each initial/Letter should be drawn by its own module (block).

  1. the basic drawing

    The initials should be of the same height.

  2. "add" (in a new sprite) a height specifier (parameter)

    Draw the letter(s) to a specified height. Each letter will need to set its width to be proportional to the height value. I suggest height to width ratios of 60% for most letters, 80% for W & M, and 25% for the I. Feel free to experiment or otherwise choose different ratios. Note that the width ratio value will belong to the letter, not the caller/invoker.

  3. "add" (in a new sprite) a location specifier

    Draw the letter(s) at a specified location (x- & y-coordinates). I suggest you use the upper-left point of the letter as the location. (If you were drawing an O or Q you could think about the upper-left corner as indicating half the width from the center. The G would be more problematic.) This should build on (still include) the capability of specifying the height.

  4. "add" (in a new sprite) line-thickness & color specifiers

    Draw the letter(s) with a specified line thickness and line color. This should build on (still include) the capabilities of specifying the height & location. Note that you can specify in the settings whether you want the ends of the line to be square or rounded (Flat line ends checked or not).

Include a single script that will call/test/exercise all four routines. The script should clear the screen at the start but not in between the calls, i.e., all four should appear on the screen at the same time. The routines should do only what is needed. However, as a safety mechanism, you might consider having them all assume the pen is up when they start and pick the pen up when they end.

Block Drawing

The goal is to produce a block and a main/controlling script that will draw a scene. The primary user-defined block/module you are to use is a rectangle. The block/module should have parameters for length and width (a length shorter than the width will produce a rectangle on its end), and for location (x- and y-coordinates of some corner). Some examples of the possibe scenes include:

In all cases you might consider adding things such a door knobs, chimneys, vent pipes, etc. Trees and bushes could be added by doing a spirograph-like drawing.

You may wish to produce other modules/blocks for such things as slanted roofs (triangle of a given size & location), trees (1 or more spirals over a solid line for the trunk), etc.

There will need to be an overall controlling script that puts the pieces together.