CPSC 480 Software Engineering (SE) Fall 2025

News

---

• Week 11 Class 20 Tue Nov 04 Posted: Nov 04

  Announcements

  • Special Office Hours Today 10:30 - 10:45 am, 3:15 - 4:15 pm. Make up for shortened early Office Hours.
  • Project 2 Scores in Brightspace. Feedback in the branch feedback in the file Feedback.md.
  • Exercises Caught up with feedback and grading for sortTDD, and the team exercises. Suggest you look at the feedback.
  • Project 3: Code Analysis TDD Remember the deadlines

  • Exercise 43: Project 3 Feedback 1

    The feedback for this exercise (and your first commit to Project 3: Code Analysis TDD) is in Brightspace.

    Just a clarification: if you receive a 10 / 10 on this exercise, it does not mean you get 100% on that part of the project. It means that you followed the procedure. See the feedback (in the Grades) if I noticed any other issues.

    Also, further exercises for the progressive due dates will not provide feedback on the commit messages, content of the commit, etc. Only on the number of test cases, which should equate to the number of rules implemented.

    If I pointed out issues in the Brightspace feedback, you can fix those in separate commits, using the commit message that starts with "Fix".

    General Comments:

    • The commit message should not mention the test. In a TDD process, we assume the test with every commit that adds functionality.
    • The build directory must not be in the repository
    • Indentation is a fixed indentation size: 4, 8, 12, 16, … or 8, 16, 24,…. Even ChatGPT thinks so. Do not indent 4 then 2 spaces. Fix this immediately. And, if you do so in the future, it is a 0 for that exercise and that part of the project.
    • Each rule must have a separate test. Make the test the simplest that you can to test the feature.
    • Each test specifies the input (the settings of the fields in the request) and the output (the string returned from formatAnalysisXML()). Use of find(), or substring checking is not part of the test case. Do not make your test case have more complexity (i.e., number of conditions) than your implementation
    • Keep in mind the rule about a single attribute output, unit.addAttribute(), for every unique attribute.
    • Follow the exact code formatting and style
    • Perform refactoring as part of the test and implementation of every commit
    • Treat each rule implementation (and its corresponding commit) as the last commit you will make to this repository. There is no "cleanup" stage that is not part of a TDD commit.

    • Think before every commit:

      • ✓ Added a new test to the test file
      • ✓ Added implementation to get that test to pass
      • ✓ All tests still pass
      • ✓ Refactored the code given the refactoring guidelines
      • ✓ Style of the added tests and implementation follow the coding style of the existing code
      • ✓ Did not add any incorrect files. For Project TDD, this means adding no files.

  Class

  • HFSD Chapter 8
  • Git Commit Messages
  • HFSD Chapter 9
  • Exercise 44: Team Mock Clock II

  Unless stated otherwise, all exercises are due by 3 pm on Wed Nov 05

• Git Commit Messages Posted: Nov 04

  The article How to Write a Git Commit Message has guidance on commit messages in general and Git projects specifically. Especially note the 7 rules. As the writeup mentions, these ideas are not new.

  A message with only a subject line is adequate for our projects. The rules that only concern the subject are:

  • Limit the subject line to 50 characters
  • Capitalize the subject line
  • Do not end the subject line with a period
  • Use the imperative mood in the subject line (command or instruction)

  Make sure to use these guidelines as you implement any projects or exercises.

• Exercise 44: Team Mock Clock II Posted: Nov 04

  If you haven't completed Exercise 42: Team Mock Clock, do so before completing this one. Notes from this are due at the end of class.

  After that, answer the following questions. Use a couple of sentences (at least) for each of them.

  1. Explain what it takes to add the same test to each of the branches:
     a. main direct testing
     b. dip Using DIP (Dependency Inversion Principle)
     c. mock Using a mock object
  2. Explain the relationship of the real-time clock to the Session class for each of the following. You may want to review the code and examine the UML Class Diagram in Exercise 42: Team Mock Clock.
     a. main direct testing
     b. dip Using DIP (Dependency Inversion Principle)
     c. mock Using a mock object
  3. For each, indicate which of direct testing (main), dip, and mock is the best answer. There can be multiple answers:
     a. Easiest to add a test in terms of time to implement:
     b. Easiest to understand what is going on:
     c. Time to run the tests:

  These questions can be answered after class and are due by 3 pm on Wednesday, Nov 5. Upload a new document with these answers added to your notes for today.

• Project 3: Code Analysis TDD Posted: Oct 30

  To implement the project below, follow the TDD process. The Brightspace course page has an invitation link to create the GitHub Classroom repository.

  Create your repository (via GitHub classroom) and implement each one of the Rules separately with a single pass through the TDD workflow (red, green, refactor). Each rule (and error message) is implemented in a single commit.

  Due Dates

  The purpose of many class exercises and projects in this class is to practice good workflows of actual, real, 40-hours-a-week software development. Due to time limitations, each part of a project cannot be very long. Treating this as a "race" at the last minute is not part of SE or any good workflow. It tends to produce less-than-optimum software in both external quality, i.e., bugs, and internal quality, i.e., poor design.

  Therefore, the project has progressive due dates regarding the number of rules implemented. Each failure to meet a due date will result in a 10-point reduction in your score out of 100. The following are due dates, not the day you have to work on them, unless you wait until the last day.

  No.	Due Date	Total Rules Implemented	Exercise Feedback
  1	Monday, Nov 3 11:59:59 pm	1	43
  	Stop Wait until I provide feedback on your initial workflow by giving you a score for the corresponding exercise. If you don't see a comment, I have not examined your first commit. If you are waiting to continue, send me an email.
  2	Wednesday, Nov 5 10:00:00 pm	3
  3	Thursday, Nov 6 10:00:00 pm	4
  4	Friday, Nov 7 10:00:00 pm	5
  5	Monday, Nov 10 10:00:00 pm	7
  6	Tuesday, Nov 11 10:00:00 pm	8
  7	Wednesday, Nov 12 10:00:00 pm	9
  8	Thursday, Nov 13 10:00:00 pm	10
  9	Friday, Nov 14 10:00:00 pm	11
  	Monday, Nov 18 11:59:59 pm	All rules and all error messages

  Due dates are given for each step. No work will be accepted after the last due date.

  All commits must appear in the repository on GitHub. Commits or code changes in GitHub Codespaces do not count.

  Project

  The input for a source-code static analysis tool can come from multiple sources, including individual files, e.g., main.cpp, directories of source-code files, e.g., src/, source-code archives, e.g., project.tar.gz, file.zip, and standard input, i.e., stdin, e.g., std::cin. In addition, solitary files and source-code archives can include a URL, e.g., https://mlcollard.net/fragment.cpp

  To perform the code analysis, the source code is wrapped in a single XML element with metadata about the source code, including filename, programming language, URL, hash, LOC (lines of code), and timestamp. For the source code:

  the resulting XML is:

  Note: Scroll to see all the attributes.

  The attribute hash is of the source and is a SHA1 160-bit (20 bytes) represented in 40 hex characters, which is what Git uses. The xmlns:code="http://mlcollard.net/code" is not an attribute but an XML namespace declaration, handled automatically by XMLWrapper.

  The general attribute rules are:

  • The order of the attributes in your output must follow the order above.
  • If the value for an attribute is empty, the attribute is not displayed

  The attribute's variety of input sources and program options follows the Rules stated below.

  Assignment

  Implement the following rules following a Test-Driven Development (TDD) approach. Write a test in CodeAnalysisTest.cpp, implement the minimal code necessary to get it working in CodeAnalysis.cpp, refactor/clean up the code to make it clear and logical, and then commit with an appropriate commit message.

  All commits must result in a program that compiles and passes all tests. This means you must successfully compile and pass the test program before a commit. Any commit that does not build will result in a 0 for that step, and every commit will be checked.

  • The code to implement is in the function formatAnalysisXML().
  • Do not change or create tests for the function filenameToLanguage().
  • Do not create any new functions.
  • Using libraries or including files beyond those already defined is unnecessary and strictly forbidden.

  Rules

  The following rules are unordered. Do not refer to them by number.

  • The minimum LOC is 0. If the option loc is non-negative, add the attribute loc.
  • If you cannot figure out the attribute language based on any other rule, use the default language.
  • When the option hash is not empty, use it for the attribute hash.
  • When the source url is not empty, use it for the attribute url.
  • When used, the option url has priority over the source url for the attribute url.
  • The option language has priority over any other way of determining the attribute language.
  • The option filename has priority over any other way of determining the attribute filename.
  • For a non-archive source-code file, the file extension of the disk filename determines the language, e.g., for the disk filename main.cpp, the language is C++. Use the provided function, filenameToLanguage(), to convert from a filename to a language for the attribute language.
  • For a file in a source-code archive, the file extension of the entry filename determines the language, e.g., for the entry filename main.cpp, the language is C++. Use the provided function, filenameToLanguage(), to convert from a filename to a language for the attribute language.
  • For a source-code archive, use the entry filename instead of the disk filename for the attribute filename.
  • For a non-archive source-code file use the disk filename for the attribute filename.
  • For standard input (i.e., std::cin) of non-archive source code, the disk filename is a single dash "-" and the entry filename is the literal string "data". In this case, you must use the option filename for the attribute filename.
  • For standard input (i.e., std::cin) of a source-code archive, the disk filename is a single dash "-". In this case, use the entry filename for the attribute filename.
  • When the timestamp is not empty, use it for the attribute timestamp.

  Error Handling

  All error messages are written to standard error (i.e., std::cerr) on a separate output line, and the function should return an empty string.

  • If the file extension is used to determine the language, and there is no mapping for that language, output the error message “Extension not supported”
  • When the input is from standard input, and a language cannot be determined, output the error message “Using stdin requires a declared language”

  Workflow

  The workflow for implementing one rule:

  1. Add a single new test case for a single specific rule in the test program CodeAnalysisTest.cpp
  2. Successfully compile and build
  3. Run the test program and verify that the test case fails
  4. Add the implementation only for the new test case in the file CodeAnalysis.cpp
  5. Successfully compile and build
  6. Run the test program and verify that all tests pass, including the new test case
  7. Refactor the test and the added code
  8. Successfully compile and build
  9. Run the test program and verify that all tests still pass, including the new test case
  10. Commit with the appropriate commit message

  Refactoring Guidelines

  All implementation should result in code that is as clean and clear as possible. For this case:

  • Output of a particular attribute must occur only once in the code.
  • Ideally, each rule implementation should only require one additional if-statement.
  • Prefer simple conditions over complex conditions.
  • Prefer initialization and if-then over if-then-else.
  • Separate the logic of calculating an attribute value from the output of the attribute value.
  • Initialize variables on declaration instead of declaring and then initializing.
  • Prefer std::string_view to std::string.
  • Instead of comparing strings to "", use the empty() method.

  Evaluation Environment

  The project is built and graded in a Docker container running srcml/codespaces, which is the same environment as GitHub Codespaces for this project. It is based on Ubuntu 24.04 and uses the GCC compiler.

  On macOS, clang is the default compiler and the one you want to use in most cases. This should not cause a problem with this program. However, before you commit, I recommend ensuring your code can build and pass the tests with GCC and the default compiler, clang.

  Add GCC via homebrew:

  brew install gcc
  

  The preset macos-gcc (in the file CMakePresets.json) provides settings to compile with GCC:

  cmake .. --preset macos-gcc
  

  This preset only appears in macOS and not in Linux or Windows.

  To return to using clang:

  cmake .. --fresh
  

  Instead of flipping back and forth in the same build directory, use two build directories, one for clang and one for GCC. Be sure to build and test in both build directories before you commit. Note It might seem like a pain to have two build directories, but it is not uncommon in real software development and is a good skill to have.

  Grading

  Your score will depend on the following:

  • Meeting the deadlines.
  • Following the TDD process. This must be reflected in your commit history, both when commits are made and the commit messages.
  • Successful implementation of the rules.
  • Following the commit message guidelines.
  • Coding style, including use of if-statements. The function logic should be as simple as possible. Pay attention to the coding style criteria given in class.

Archive