CPSC 421-020 Object-Oriented Programming (OOP) Spring 2025

Week 6 Class 11 Thu Feb 20 Posted: Feb 20

After Class

• Project 1 Scores

  Project 1 scores for all parts are posted.

  I changed how the scores are presented. The grade item Project 1 has the overall score, now out of 100 points (parts v1a, v1b, v1c, v1d, and v1e). In addition, the individual part scores are reported in separated grade entries:

  • Project 1 v1a
  • Project 1 v1b
  • Project 1 v1c
  • Project 1 v1d
  • Project 1 v1e

• Exercise 30: Utilities

  Scores are in Brightspace.

  See the note below on what I took off points for.

• Underlining for yuml.me Class Diagrams

    [StaticClass|__+flag:Boolean__ |__static()__ ]
  

• srcml on macOS I have an experimental brew package for the srcml client on macOS. If you are on macOS, let me know if it does or does not work. With brew installed:

  To verify if srcml is installed:

  You can run this, from the build directory, on a source-code file and then run with srcfacts:

  Or, direct entry of text:

Announcements

• Project 2

  • All issues for v1d and v1e are in GitHub. I have not updated the scores in Brightspace.
  • I adjusted the due dates for Project 2

  • v1e Issue: Unnecessary added XML parsing code

    The purpose of v1e was to show how the new design makes adding functionality easier. Unfortunately, some implementations added low-level parsing code that was not necessary, and, in many cases, broke the parsing, especially with the BIGDATA.

    At most for each added count you needed:

    • One counting variable
    • One boolean variable to keep track if you were in the proper element (see next item)
    • Detect the start tag name and set the boolean variable (see next item)
    • Detect the attribute while in the start tag name and update the counter
    • Add the line to the output

    You are not writing XML parsing code. I already did that. You are redesigning the code.

  • v1e Issue: Code assumes unique attribute and value

    The code that counts the number of line comments assumes that the comment element is the only element that has the form: <… type="line">

    While not verified, it is also probably the case that the code for counting the number of literal strings has the same limitation.

    These elements do have these forms. But assuming this is true for all other srcML elements, current or future, is an assumption that is never stated or described. The choice is to describe in excruciating detail why this is the case, how someone could detect it, and what to do with their data when this happens. This requires forms that have to go to legal and be filled out in triplicate.

    Another choice is to fix the problem.

    I will not take points off for this issue. However, I expect it to be fixed:

    • It is easy to make assumptions about our input data for programming ease or program optimization
    • All assumptions must be clearly defined
    • A better choice is to remove the assumption
    • It is often easier (and better) to remove the assumption than it is to work around it
    • So if you can remove the assumption without much effort, it will pay to do so
    • There are exceptions as dealing with uncommon usages may delay delivery for common usages

• Project 2 Pull Request Added a Project 2 pull request that will add the files XMLParser.hpp and XMLParser.cpp and modify CMakeLists.txt so that XMLParser.cpp is part of the build.

• Exercise 30: Utilities

  I am still finishing the scoring. Points are taken off for:

  • @TODOs that are incomplete or not completed
  • Doxygen comments that are missing, incomplete, or contain errors
  • Scalar values passed by const value, e.g., const int
  • Objects passed by value instead of const reference, e.g., std::vector<int> v
  • Poor naming

  Notes: Utilities Feedback

• Zero-Tolerance Policy

  The following are fundamental design choices at the C++ level that we have spent more than enough time on. To make sure the message is received, any violations of the following will receive a 0 on the exercise, project, or test question:

  • Passing std::string by value, e.g. void f(std::string);
  • Passing std::vector<> by value, e.g., void f(std::vector<int>);
  • Passing by const value, e.g., void f(const int n);

  For why we do not pass large objects by value, see the Benchmarks

Agenda

• Exercise 33: Utilities II

  If you received a non-zero score for Exercise 30: Utilities, your score on that exercise will be replaced by this score if this score is higher. So if you got a 7/10 on Exercise 30, and you get a 10/10 for Exercise 33, your Exercise 30 score will change to a 10/10.

  Using the feedback in class, improve your function declarations for the Utilities code. I suggest a commit for each change of a function name, e.g., Rename ..., and each change of a parameter type, e.g., Change ....

  Other changes to consider:

  • Make sure to correctly identify [in],[out], and [in/out]. I saw some [in/out] that is really [out]. If the previous contents of a parameter are not used in the function, and the parameter value is changed, it is an [out].
  • You can pass data out from a function via a parameter or the return value. Do not use both for the same data.
• Guide: Boolean Expressions
• Notes: Iterator
• Notes: UML Class Diagrams
• Exercise 35: UML Class Diagrams Crossword

• Exercise 36: Create a UML Class Diagram

  Create a UML Class Diagram at yuml.me for the class diagram on the right.

  Compose your class diagram at yuml.me. The resulting contents of the box on yuml.me will go into the file ClassDiagram.txt in the GitHub Classroom Repository (link in Brightspace). You should be able to copy the contents of the file ClassDiagram.txt and paste it into the editor at yuml.me and see the diagram on the right.

  Your final result should look exactly like the image shown here. The style used for the image is Boring, instead of the default Scruffy or Plain.

  Make sure to commit after each of the following parts:

  • Name of the class
  • Attributes
  • Operations

  Note that yuml.me can be temperamental. Add iteratively and carefully. Commit often, as you might find yourself breaking your previously working diagram.