SC‐24sp‐2024‐05‐06‐Afternoon - TheEvergreenStateCollege/upper-division-cs-23-24 GitHub Wiki

Software Construction, Spring 2024

Week 06 Afternoon Lab

First Hour

Run code, verify address generation, reset road counter.

Step 0:

  • Copy from sc-24sp/assignments/ppham/city-addresses to your assignments directory
<repo_dir>/sc-24sp/assignments/<your_github_username>/week6

You can examine the changes from this morning

Create a dev diary entry to document your steps below.

Step 1:

Iterate over the addresses HashMap and print them out.

Verify that your address generator works by

Print size of HashMap

In your main function, print out the size of the addresses, the number of Streets, and the number of Avenues. Why is this consistent with the city you randomly created on that run?

Step 2: Verify the Generated Addresses

Look at three or four generated addresses by iterating through your addresses hashmap, both the value (String) and the key (coordinate of (usize,usize)).

Step 3: Reset Address Counter to Zero for Each Road

Right now all Street Numbers are cumulative in the city. We start at 0 and never reuse this number within the whole city.

In actual addresses of cities, the address number "100" could be used multiple time.

Modify your implementation so that the address counter for each road (street or avenue) resets to 0, so that address numbers are reused.

Like in the previous step, look at three or four generated addresses by iterating through your addresses hashmap, both the value (String) and the key (coordinate of (usize,usize)). Print them out, copy and paste these values into your dev diary, and explain how it shows that the address counter is being reset between roads.

Second Hour - Design and Abstraction

Step 4: Testability

How can we test the generated addresses of our city, including resetting road counters, given that it's random each time?

Two approaches:

  • Seed a deterministic pseudo-random generator from a u64, like the ChaCha8 crate.
  • Read from the addresses generated, like we did above, and use a subset of them for dynamic tests.

You can use either approach.

Document your code and output (using code snippets or screenshots) in your dev diary.

Step 5: Unit Tests

Create a lib.rs file and create at least one unit test demonstrating that three selected generated addresses are what you expect.

In your dev diary, include your test code and show command-line output showing that it passes.

Step 6: Refactor

Right now our city_builder method does a lot, perhaps too much.

  • It marks address locations next to streets and avenues as long as they don't overlap.
  • It generates and assigns street addresses.

How can we "break up" this method, abstract out what's different and keep what's common, to accomplish the same functionality in an easier-to-understand, possibly shorter way?

(This is called refactoring).

Make a design change to the city_builder method so that address generation code and address location marking don't have to be done side-by-side.

(Hint: How did you abstract out the generation of North-South Avenues and East-West Streets in the lab two weeks ago?)

You can change the method signature, or create whatever other functions, structs, traits, or other members that you need.

In your dev diary, include code snippets, screenshots, and terminal output showing that your same tests from Step 5 still pass, but with your improved abstractions.

⚠️ **GitHub.com Fallback** ⚠️