CPSC 421-010 Object-Oriented Programming (OOP) Spring 2024

Week 6 Class 11 Thu Feb 22 Posted: Feb 22

After Class

• 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.

• Generating a new concerns.html file

  I installed the concerns program (the one that generated your concerns.html file) in GitHub Codespaces.

  1. Start a new GitHub Codespaces session. A previous codespace will not work.
  2. Run the program on your files:

  This will generate the file concerns.html.

  To view the file, you can start a web server in your codespace:

  A pop-up will have the button "Open in Browser". You can use that to view your file.

  To stop the web server, type a Control-C

  You can even generate the concerns at a particular tag. The following shows the concerns for tag v1d:

• Project 2
  • I created a pull request in your repository for the files for the class and sequence diagrams.

Announcements

Project 1

• All issues for v1d and v1e are in GitHub. I have not yet updated the scores in Brightspace.
• Since creating the rest of the issues for v1d and v1e took me longer than I planned, I adjusted the due dates for Project 2.
• In the branch feedback I put a file concerns.html. To get to that file:

    git pull
    git switch feedback
  

  If you had a v1d tag, you should see the file concerns.html. Load that file up in your favorite browser. If you have never done that, try now. Do not try to look at concerns.html at GitHub, because it does not display as a web page. When you are done viewing it, make sure to return back to the main branch:

    git switch main
    git branch
  

  If you open this file in a browser, you will see the XML parsing low-level concerns in srcfacts.cpp marked in red. This is based on the functions declared in xml_parser.hpp at the tag v1d, so if you make any changes since then, they won't show up. Here is an example for the original srcfacts.cpp. Yours is based on your code at tag v1d.

  It is a bit imprecise, and I may be able to generate better ones over time. It is possible that some of the code in red cannot easily be moved to functions in xml_parser. But it should give you a general idea.

  The structure of the big while statement with the nested-if is not marked in red, as it is not possible to move that out of srcfacts.cpp quite yet. If you have, then you have srcML or srcFacts concerns in your xml_parser, which creates even more of a problem. A C++ class would not help remove this structure. For that, we need mechanisms for event-driven programming.

Code assumes unique attribute and value Issue

I repeat the text of this v1e issue here for those who did not make this assumption:

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 am not taking any points off for this issue. However, I expect it to be fixed. A few points to make:

• It is easy to make assumptions about our input data for programming ease or program speed
• Any 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

Exercise 33: Utilities 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 34: Utilities II

  If you received a non-zero score for Exercise 33: 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 33, and you get a 10/10 for Exercise 34, your new Exercise 33 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.
  • The function for // Split a container into two containers given the first occurrence of a value must be a single function. Also, consider your parameters carefully.

• Notes: Grouping Functions

  Motivation: Method Stereotypes

  Converter

• 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.