CPSC 421-010 Object-Oriented Programming Spring 2026

Archive

• Week 8 Class 13 Tue Mar 03 Posted: Mar 03

  After Class

  • Project 2 v2c Class Diagram Feedback in Brightspace if you did v2c and had a class diagram.
  • Exercise 42: Utilities II Feedback and scores in Brightspace. Definitely check this because naming and parameter passing are on the Midterm.
  • Exercise 34: Sequence Diagram II Feedback and score in Brightspace. Sequence Diagrams are on the Midterm.

  • Exercise 46: Member Initialization Lists Mistake in the CMakeLists.txt file for the Image directory. It refers to:

    It should be:

    You can make (and commit) this change. If you have problems, let me know and I can do it for you.

  Announcements

  • Midterm Exam
    • Know the required definitions
  • Project 2

  Agenda

  • Notes: Constructors and Initialization
  • Exercise 44: Memory Allocation Observations
  • Exercise 45: Constructors and Initialization Crossword
  • Exercise 46: Member Initialization Lists
  • Guide: Compilers
  • Notes: Encapsulation
  • Exercise 47: Encapsulation Crossword
  • Notes: Method Stereotypes

  Unless otherwise noted, exercises are due by 3:30 pm on Mon, Mar 9

• Exercise 45: Member Initialization Lists Posted: Mar 03

  The GitHub Classroom link is in Brightspace.

  Normally, each these programs would each be in a separate Git repository. We only have them in one repository as separate repos would required four separate invitations.

  Fix the code with the following problems in the following order:

  1. Sensor - compiler error
  2. Bank - compiler error
  3. Temperatures - compiler error
  4. Image - compiler error
  5. Image - implement @TODO

  Do not:

  • Rename any variables, parameters, or fields/data members
  • Change the type of anything
  • Add any comments
  • Add any methods, functionality, etc.
  • Use this-> to fix

  Perform each change in a separate commit

  Note that the Bank problem is really a compiler warning, not a compiler error. However, it is more complicated than that. While clang issues a warning, gcc does not. Here is the clang warning:

  You will want to compile with both gcc and clang. See the Guide: Compilers for instructions.

• Week 7 Class 12 Thu Feb 26 Posted: Feb 26

  After Class

  • Project 2 See the adjusted due dates

  Announcements

  • Midterm Exam
  • Project 2
    • Guide: Coding Standard - Classes

  • Exercise 37: Create a UML Class Diagram Scores in Brightspace. Common issues:

    • Invalid UML types
    • static operator
    • Missing type separator, i.e., :
    • Displays with commas, i.e., input is not separated by ; and may require to be on one line
    • School and process related comments, e.g., // Exercise ... and // Add ...

  • Exercise 39: Utilities Scores and feedback in Brightspace. I took off for:

    • Objects passed by value instead of const reference, e.g., std::vector<int> v
    • Scalar values passed by const value, e.g., const int
    • Doxygen comments that are missing, incomplete, or contain errors
    • @TODOs that are incomplete or not completed
    • 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 41: min min min In class

  • Exercise 42: Utilities II

    If you received a non-zero score for Exercise 39: 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.
  • Notes: Iterator
  • Exercise 40: Iterator Crossword
  • Notes: Cohesion
  • Exercise 43: Cohesion Crossword

  Unless otherwise noted, exercises are due by 3:30 pm on Fri Feb 27

• Midterm Exam Posted: Feb 26

  The Midterm Exam is during class time in our regular classroom on Thursday, Mar 5.

  You are responsible for the following:

  • Software Design - Definition, the two types of design (so far), where they come from, what they are concerned with
  • Software Design Characteristics - Know the list of characteristics
  • Algorithmic Decomposition - Definition and how it works
  • Structure Diagram Given code or description, draw.
  • Coding Style Given a function declaration or definition, improve the code using the principles we discussed in class. This includes proper parameter passing.
  • Function Design Given a description, create a function declaration with a proper Doxygen-style comment. Parameter passing must follow the coding-style rules.
  • Generalizing Functions - Given an example function, show how to generalize it
  • Physical Organization - Include guards, header comments, function comments, and separate function declarations and definitions
  • Naming & Method Naming Standards - Given a list of names, correct the poor names
  • Iterator - Four basic operations in GoF terms and C/C++ operators
  • Free-Function Stereotypes - Know the terms and be able to write a free function for each stereotype
  • Concerns - Definition, separation of concerns, be able to identify concerns
  • UML Sequence Diagram Given a scenario, be able to draw a sequence diagram
  • XML Know what is and what is not an XML concern
  • UML Class Diagram - C++ code ⇨ diagram, diagram ⇨ C++ code, single class only (no relationships)
  • Organizing Functions - free functions in a file, in a namespace, and as static methods of a class
  • Cohesion - Definition
  • Encapsulation and Information Hiding - Definition of each, the encapsulation rule and the information hiding rules.
  • Member Initialization List - Order of field creation, proper use of member initialization list

  The exam has a variety of problem types, including short-answer, definition, comparison, diagramming, and coding.

  The questions are based on what I covered in class, including the exercises and projects. If I did not cover it in class, it is not on the exam.

• Week 7 Class 11 Tue Feb 24 Posted: Feb 24

  Announcements

  • Project 2 See revised due dates
  • Project 2 Pull request for starting XMLParser files
  • Exercise 37: Create a UML Class Diagram Issues with yuml.me. Deadline extended to Wednesday. If you did already finish, then take a careful look at yours versus the posted diagram.

  Agenda

  • Notes: UML Class Diagrams Finishing up Note Production code styles only indent the class members (methods and fields) once. In general, the access specifiers, e.g., public, are not indented. Follow this style.
  • Notes: Scope
  • Exercise 38: Scope Crossword
  • Exercise 39: Utilities
  • Guide: Boolean Expressions
  • Notes: Iterator
  • Exercise 40: Iterator Crossword Due after next class meeting

  Unless otherwise noted, exercises are due by 3:30 pm on

• Exercise 39: Utilities Posted: Feb 24

  Provide a single function declaration in the file Utilities.hpp and a single function call in UtilitiesExamples.cpp for each @TODO in UtilitiesExamples.cpp. Once you do, remove the @TODO for that block. The function declarations in Utilities.hpp must follow the order of the examples of the call in UtilitiesExamples.cpp.

  Do not implement the function Do not provide a function definition Only provide the declaration and example single call using allof the variables given. The function declaration must be complete enough so that it would be possible to implement the function.

  Make sure the program compiles. There is a CMake build provided. However, since you are not providing a function definition, the program will not link or run successfully.

  Until you are all done, there are warnings about -Wunused-variable and -Wuninitialized (depending on the compiler). Do not fix them directly, but implement the function declarations and calls.

  For each function declaration, include a Doxygen comment that describes the function and describes what data is IN, OUT, or IN/OUT. An example is already in the include file. Note that Doxygen comments start with /**. The file DOXYGEN.md contains instructions for generating Doxygen documentation and on how to view it.

  Finish the problem for each @TODO, remove the @TODO, and then commit. Each commit should complete one @TODO. The first one is completed as an example.

  If any of the following occur, then the entire exercise score is a 0:

  • Function definitions
  • Does not compile (expected to not link)
  • Object files, e.g., UtilitiesExamples.o, in the repository
  • Additional includes
  • Any code changes besides adding function declarations and implementing @TODOs
  • Any remaining @TODOs, i.e., you have to declare them all
  • Use of any other files
  • Use of C++ standard library functions
  • Use of C++ templates

• Week 6 Class 10 Thu Feb 19 Posted: Feb 19

  Special Note The yuml.me site is experiencing problems. Due dates for class diagrams are extended. Other parts of tag deadlines are not extended.

  Additional Special Note The yuml.me site is back up. I will be lenient on the class diagrams for Project 2, but get the Class Diagram exercise completed so I can give you feedback.

  After Class

  • Project 2 See revised due dates
  • Project 2 Pull request for starting XMLParser files

  Announcements

  • Project 1 Issues in GitHub, scores in Brightspace
    • Issues for v1d
    • Issues for v1e

    • 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 See Due Dates

  • XML Parsing Concerns && xml_parser.hpp XML parsing concerns belong in xml_parser.cpp. The role of xml_parser.hpp is not to support xml_parser.cpp, but to allow the use of the functions in xml_parser.cpp to be called by external code, e.g., srcfacts.cpp.

    XML concepts belong in xml_parser.hpp. XML parsing details belong in xml_parser.cpp.

  • Guide: Parsing Concerns Tool to visualize concerns in srcfacts.cpp

  • Doxygen Function/Method Comments In the Utilities assignment today, the given example is

    The first line of text is the brief description. Note the blank line after it before the param. That is the style used by the Doxygen documentation, and many style guides. In fact, the @param part requires a blank line between it and the brief description.

  • Exercise 33: Sequence Diagram Scores and feedback in Brightspace.

  Agenda

  • Exercise 34: Sequence Diagram II Based on my feedback, fix your sequence diagram from Exercise 33: Sequence Diagram

    • If you received a 10/10 on Exercise 33, no work is needed
    • If you did not do Exercise 33, you have a 0 on this exercise
    • If you got any other score, then fix the diagram
    • If you don't fix the diagram, you get a 0

    Use the same repository.

  • Notes: Naming Now the rest
  • Exercise 35: Naming Crossword
  • Notes: UML Class Diagrams
  • Exercise 36: UML Class Diagrams Crossword

  • Exercise 37: 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.

    Note Due date extended. Due by 3:30 pm on Wed Feb 25

    

  Unless otherwise noted, exercises are due by 3:30 pm on Mon Feb 23

• Week 5 Class 9 Thu Feb 12 Posted: Feb 12

  After Class

  • Project 2 Due date changes.
  • Project 1
    • All issues and scores for v1d and v1e are posted

    Across all students, there were over 600 functions created and the number of issues for v1d was over 300. And many of the v1d issues referred to multiple function names. I use scripts to detect certain things, but I have to manually examine them. Whether generated by a script and manually examined, or done entire manually, mistakes can happen. If there is a question, then ask.

  • Exercise 31: TRACE

    TRACE Session Record of the terminal session streamed live in class.

  Announcements

  • President's Day Observance No class or Office Hours on Tuesday, Feb 17
  • Exercise 26: srcFacts Concerns Quiz Answers
  • Project 1
    • Every function should have single purpose. Do not make a function try to be an Accessor::predicate and Mutator::command. Use separate functions for each.
    • If your xml_parser functions refer to srcML, srcFacts, or srcfacts concerns, then they violate the rule of none of these concerns in xml_parser. Specifically, if they contain expression counts or use srcML tags, such as "expr", then they violate a primary design rule for this project. Remove them immediately.
  • Project 2 Available via this link or the Archive. Not on the main page until Project 1 expires.
  • Guide: asciinema

  Agenda

  • Notes: Generalizing Functions
  • Exercise 29: Generalizing Functions Crossword
  • Notes: Naming Motivation only for now
  • Notes: Method Naming Standards We will follow these naming standards in this course.
  • Exercise 30: Method Naming Standards Crossword

  • Exercise 31: TRACE

    The BUILD.md file contains instructions on turning TRACE on and off

    Demonstrate the running of your program with TRACE on for a:

    • Line comment
    • Short block comment
    • Doxygen block comment

    You will have to create the srcML for each of these code examples. Use the srcML Playground. Keep the examples as short as possible (i.e., only include a comment). Download these files and have them ready before you start the screencast. Also before the screencast, build with the TRACE option on.

    The form to submit the asciinema link is in the title of this exercise.

    To make the output cleaner, redirect the generate table to a file ./srcfacts < FILENAME > report.md

  • Notes: Event States
  • Notes: Grouping Functions
  • Exercise 32: Grouping Functions Crossword Due by 3:30 pm on Tuesday, Feb 17
  • Notes: Sequence Diagrams

  • Exercise 33: Sequence Diagram Due by 3:30 pm on Tuesday, Feb 17

    Create a sequence diagram at SequenceDiagram.org for the diagram on the right, which is for parsing a start tag with an attribute.

    Start with the SVG file with the GitHub Classroom Repository link at Brightspace, and commit your changes to that repository.

    Your final result should look exactly like the image shown here.

    Make sure to save as a SVG Image File (vector image with embedded source text)

    

  Unless otherwise noted, exercises are due by 3:30 pm on Fri Feb 13

• Project 2 Posted: Feb 12

  Continue to improve the design of srcFacts using more language features. There are no changes to the functionality of this project, only to the design.

  In addition to the following code changes, you will maintain two modeling diagrams. There is a pull request to add the starting files to your repository.

  • A UML Sequence Diagram, SequenceDiagram.svg, to model the relationship and control between srcfacts.cpp, the xml_parser functions, and the class XMLParser. In particular, you must show the same function/method calls used for each part. The sequence diagram for the sequence diagram is at sequencediagram.org. Make sure to export and save it as SVG.
  • A UML Class Diagram, ClassDiagram.txt, to model the class you create. This means showing the UML form of all fields/data members and member functions. The format for the diagram class diagram is the text yuml.me format.

  The diagrams must be updated to reflect the code for each tag. So do not tag until the part below is done and any diagrams are updated.

  Tag v2a Implement and close all issues I created as feedback from Project 1. When you finish fixing an issue, at least one commit must describe what you are changing. Add your calls' exact function names and (UML form of) parameters to the xml_parser for the sequence diagram. Due Feb 18 Feb 20

  Tag v2b Create a namespace, xml_parser, for the functions in xml_parser.{hpp,cpp}. This will involve making changes to the files srcfacts.cpp, xml_parser.hpp, and xml_parser.cpp. Due Feb 20 Feb 23

  From this point on, do not change the files xml_parser.hpp or xml_parser.cpp.

  Tag v2c Create the class XMLParser in the files XMLParser.hpp and XMLParser.cpp where the methods call the free functions from xml_parser.hpp. Do not use any fields/data members. The method parameters must be identical to the parameters of the free functions in xml_parser.hpp. Add the XMLParser as a participant for the sequence diagram and show how it is involved between srcFacts and xml_parser. Due Feb 24 Feb 27 Mar 3

  Tag v2d Eliminate any parameters in the XMLParser methods that you can, replacing them with field/data members in the class. In other words, move as many XML parsing variables from srcfacts.cpp as possible. Do this one field/data member at a time. For the class diagram, show the added fields and the removal of parameters. For the sequence diagram, update the parameter lists of the calls to the XMLParser. Due Mar 9 by 9 am

  Tag v2e Inline the calls to the xml_parser free functions into your XMLParser methods. Inlining the calls does not mean adding the inline specifier, and it does not mean changing anything in XMLParser.hpp. Do this one free function call at a time. Ultimately, your XMLParser.cpp should have no calls to xml_parser functions and will not need to include xml_parser.hpp. Do not make any changes to the files xml_parser.{hpp,cpp}. For the sequence diagram, remove the xml_parser participant and any calls. Due Mar 9 by 9 am

  Ensure the project compiles, builds, and produces the correct answer at every commit with GCC and Clang.

  There is a zero-tolerance policy for the following. A zero-tolerance policy means that you will receive a zero for that part if any of the following are violated:

  • At every tag, v2a, v2b, v2c, v2d, and v2e, the program must compile and build in gcc and clang without errors or warnings.
  • All data members/fields must be private
  • No mention of srcML or use of specific srcML element names (or attribute names/types) in the files XMLParser.hpp, XMLParser.cpp, xml_parser.hpp, or xml_parser.cpp.

• Week 5 Class 8 Tue Feb 10 Posted: Feb 10

  Announcements

  • Project 1 v1b Feedback for Project 1 v1b is posted as issues in your GitHub repository:

    Do not change tag v1b.

    You will need to fix these issues at some point.

  • Project 1 v1c Feedback for Project 1 v1c is posted as issues in your GitHub repository:

  • Project 1 v1d

    • If you have any srcFacts or srcML concerns in xml_parser then you are going in the completely wrong direction. In fact, what you are doing is worse than the existing code. Evidence that you are doing this is a single xml_parser function which tends to have a lot of parameters.
    • Cannot change the output. Design change must avoid breaking the program (build or runtime results) at all costs.
    • Direction of parameters: Algorithmic Decomposition
    • XML Interface Concepts: XML
    • Accessor::Predicate Stereotype: Free-Function Stereotypes
    • Accessor::Predicate Stereotype Example: Free-Function Stereotypes

  • Exercise 10a: IOBuffering and Exercise 10b: Software Design Characteristics Quiz.

    • Due to numbering conflict, renumbered Exercise 10: IOBuffering
    • Exercise 10b: Software Design Characteristics Quiz is considered a bonus. I will drop your lowest exercise score.
    • You will need to know that list of characteristics for the Midterm. I would also make sure that you know how to run a program directly.

  • Guide: srcML

  Agenda

  • Notes: Concerns
  • Exercise 26: srcFacts Concerns Quiz
  • Exercise 27: Concerns Crossword
  • Notes: Vertical Development
  • Exercise 28: Vertical Development Crossword

  • Exercise 20: Rainfall V

    OOPS26-Rainfall-010

    Make the same commits in your repository.

  • Notes: Generalizing Functions

  Unless otherwise noted, exercises are due by 3:30 pm on Wed Feb 11

• Week 4 Class 7 Thu Feb 05 Posted: Feb 05

  After Class

  • Project 1 Part v1b graded. Feedback as issues in GitHub (look for the label v1a), and scores out of 20 in Brightspace.

  Announcements

  • Project 1 Posted due dates for parts v1c to v1e
  • Project 1 Your repository has a pull request for xml_parser to use for part v1d. After you accept the pull request on GitHub, you have to git pull it into your local repository (even in a codespace).
  • Guide: srcML Guide to using srcML. I will add some more instruction to this.

  • GitHub Codespaces I updated the image, srcml/codespaces, used by our projects in the codespace container. Besides new versions of the installed packages, including cmake, you can now use the manual utility, man g++, and even man srcml.

    When an image is updated, existing codespaces are still using the old image. To use the new image, you must start a new up a new codespace. You also probably want to delete the old one so you don't get confused. Make sure you committed and pushed in the codespace

  • Exercise 22: For Semantics II due by 3:30 pm on Fri Feb 6

  • Exercise 21: Include Guard Name Quiz Available after class from a link in Brightspace.

    You may want to review your notes on include guard names before taking it. Answers must be exact.

  Agenda

  • Exercise 23: Role of Include Files

    For each of the following, write the code necessary to call the function. Include all error handling:

    • Combine.cpp uses Move.hpp
    • ReadFile.cpp uses ReadLine.hpp

    An include file is not for the developer of the corresponding .cpp file. It is so that the developer calling the function can use it, and use it properly. It has to be sufficient for the developer to call the function, but not include anything more.

    Facts

    • The number of developers and times a function is called is much higher than the number of developers who write (or modify) a function.
    • Most users of a function will not have access to the implementation file.
    • Even if a user of a function has access to the implementation file, they do not want to read it to figure out how to call a function.

    The results of part v1b is that overall there is a misunderstanding of the purpose of an include file.

    From the function caller's perspective:

    • Clear, single include file to use the feature. The include files is self-sufficient and I can include it wherever I need it in whatever order I want.
    • The include file has no extra dependencies (e.g., include files that are not needed).
    • The include file has a function declaration which gives me the name, parameters, and return type.
    • The include file has comments and naming that tells me what the parameters are for.
    • The include file has comments describing the general purpose.
    • The include file has comments given specific return values (or OUT values) and what they mean.
    • The caller of a function does not want access to the function definition.
    • They will most likely use the function from a library, which does not contain the original source code.
    • They don't care about the original source code.

    From the function developer's perspective:

    • They provide the include file so that others (and themselves) can easily call the function.
    • The better they meet the needs of the callers of the function, the more people will use the function.
    • The more people that use it, the less of a problem they will be to the developer of the function if the include file is good.
  • Guide: Coding Standard
  • Exercise 24: Coding Standard Crossword
  • Notes: Free Function Stereotypes
  • Exercise 25: Free Function Stereotypes Crossword
  • Notes: Concerns

  • Exercise 20: Rainfall V Continuing on using the workflow from Rainfall I. As before, you can follow along and see the commits that I make in class:

    OOPS26-Rainfall-010

  Unless otherwise noted, exercises are due by 3:30 pm on Monday, Feb 9

• Week 4 Class 6 Tue Feb 03 Posted: Feb 03

  After Class

  • Project 1 Remaining due dates posted
  • Exercise 20: Rainfall V Delayed until next class
  • Exercise 21: Include Guard Name Quiz Delayed until next class

  Announcements

  • Project 1 v1a Scores (out of 20 possible) are in Brightspace for Project 1. The feedback is in GitHub in the Issues tab of your repository. Issues include:

    • Missing tag v1a
    • Inconsistent spacing
    • Inconsistent spacing around keywords
    • Mixed tab and space indentation
    • Unnecessary comment

    Do not expect that every part (e.g., v1b) will be graded before the next part is due. This part is straightforward. The remaining parts involve more complex coding. Also, for some parts, I want to grade the parts together.

    The first step of Project 2 will be to fix these issues. You can fix these issues now or later. For small changes, I suggest now. Use a commit message that starts with "Fix". After the issue is fixed, close the issue.

  • Project 1 v1c Added the due date for tag v1c. The Coding Practices Task List is an issue in your GitHub repository.
  • Exercise 10: IOBuffering The grades and feedback are temporarily hidden while we fix an exercise naming issue.

  Agenda

  • Notes: XML

    You will not be asked to explain or define any XML terminology as part of any exam. However, to discuss the project's problem domain, we require this terminology.

    You need to understand that the parts of XML are a concern, the implementation of an XML parser is another concern, and the specific element names for srcML are another concern. We will cover the idea of a concern later on.

  • Exercise 18: XML Crossword
  • Notes: Coding Style
  • Exercise 19: Coding Style Crossword
  • Guide: Coding Standard
  • Notes: Rainfall Coding Practices

  • Exercise 20: Rainfall V Continuing on using the workflow from Rainfall I. As before, you can follow along and see the commits that I make in class:

    Delayed Until Next Class

    OOPS26-Rainfall-010

  • Exercise 21: Include Guard Name Quiz Available after class from a link in Brightspace.

    Delayed Until Next Class

    You may want to review your notes on include guard names before taking it. Answers must be exact.

  • Exercise 22: For Semantics II due by 3:30 pm on Fri Feb 6

  Unless otherwise noted, exercises are due by 3:30 pm on Wed Feb 04.

• Exercise 22: For Semantics II Posted: Feb 03

  If you did not take the Exercise 8: For Statement Quiz nor do Exercise 17: For Semantics I, then you cannot do this exercise, as it is based on your work on the quiz.

  In your for semantics repository is a file ForSemantics.cpp. It has a set of separate test cases with some setup, the code to evaluate, and an answer checked via an assert(), e.g.,

  Each test case is in its own block statement to isolate its scope. The test cases are scenarios of using the original code from the quiz, followed by a test case with your individual answers. There are multiple scenarios for each example/answer from the quiz.

  One special case is for Q3, which gave you macros (e.g., INCR) instead of the actual code. For that one, we used the preprocessing #define to make them into statements.

  This is a non-standard use of preprocessing statements, so don't treat it as a general solution.

  A CMake configuration is provided. So use the standard procedure to configure and build. There is no target run provided in the Makefile, so you will have to run the test program on the command line.

  So your job is to:

  • Fix the indentation in a single commit. Depending on how you entered the code in the quiz, it might not have proper indentation after it is injected. Do this in a single commit.
  • Fix any naming in a single commit. Some of you decided to rename the loop-control variable. Since it was i in the original for-loop, it should be i in the semantically-equivalent while-loop. Not count, vCount, or q. Besides, i is the standard name for a counter in a loop.
  • Replace any declaration statements with multiple declarations into separate declarations, e.g., change int total = 0, i = 0;
  • Fix the compile errors one-by-one with a separate commit for each test case. All of the test cases that use the original for-loop will pass, so the compile errors are because your while-loops are not semantically equivalent to the original for-loop. This tends to be a variable scope problem.
  • Once the compiler errors are fixed, you need to see if the test cases pass. Run the program and fix the code so that the assertions pass. Commit one fix at a time. As with the compiler errors, the assertion errors are because your while-loops are not semantically equivalent to the for-loops. Note that once an assertion fails, your program stops. So you will end up fixing this from top to bottom.

  You can only change what is between the // @START and // @END comments. Changes to any other places in the code will result in a 0 on the exercise.

• Week 3 Class 5 Thu Jan 29 Posted: Jan 29

  After Class

  • Project 1: v1a Scores for v1a are in Brightspace. Any feedback is in the form of issues in your repository.

    By Project 2, you will need to fix these issues. However, you can go ahead and fix them now. If you fix an issue, then mention it in the commit messages, and Close the issue in GitHub.

  Announcements

  • Project 1 Check due dates
  • Exercise 9: Rainfall II Report in feedback branch, Report2.md. Score and feedback in Brightspace. Also Rainfall III.

  Agenda

  • Notes: Git Basics

    With a few exceptions, the use of proper Git Commit messages is not a part of the grade for the projects or exercises. However, you should try to follow the rules because it is:

    • Essential for group projects
    • Good practice for real-world projects
    • A skill that takes practice
    • Allows me to monitor what students are working on and what they have completed
    • Allows me to assist you individually
  • Guide: Git Commands
  • Exercise 14: Header File Quiz
  • Notes: Separate Compilation
  • Exercise 15: Separate Compilation Crossword
  • Notes: Rainfall Coding Practices

  • Exercise 16: Rainfall IV

    Continuing on using the workflow from Rainfall I

    As before, you can follow along and see the commits that I make in class:

    OOPS26-Rainfall-010

  • Exercise 17: For Semantics I

    The For Statement Quiz had three for statements that you had to convert to using the while statement:

    No one got the entire conversion correct. Given the question's setup, many got the first two on a technicality, but no one got the third one completely correct. So I am going to have you fix your answers.

    For part I, you only need to create the repository for the exercise. Once you do that, I can give you the problem starting with your answers on the For Statement Quiz. In part II (not assigned yet), you will fix the conversion to a while so it works correctly.

    The reason for the split between parts I and II is that I cannot provide custom code until after the repository is created, and only you can create the repository.

    If you did not take the For Statement Quiz, then you cannot do this exercise as it is based on your work on the quiz.

  Unless otherwise noted, exercises are due by 3:30 pm on Fri Jan 30

• Week 3 Class 4 Tue Jan 27 Posted: Jan 27

  Announcements

  • GitHub Classroom Error

    If you get the following:

    

    Go to your GitHub account. From the icon on the far right top corner, select "Organizations". There you will see an invitation to accept the project.

  • Exercise 8: For Statement Quiz and Exercise 9: Rainfall II Feedback and grades are not ready yet.

  • make run

    • The users of a program will not have make so they cannot use make run.
    • The users of a program will want to run the program with their own data, not the demo data of a project.
    • Knowing how to run the program directly on the command line is required of every developer of a project, because that is how a user would run it.
    • The Rainfall project has a target run for the Makefile, i.e., make run. This was provided because the main program, rainfall, required an input file (the rain data) sent via standard input.
    • When programs have required input files or required options, a make run is often given as an example, along with demo data. It is not expected that make run is the only way to run the program.
    • So, when there is no provided make run, do not add one to the CMake files (this is not DevOps). Run the program directly.
    • In class, showed running IOBuffering directly from the command line.

  Agenda

  • Exercise 10: Software Design Characteristics Quiz

    Link to form provided in Brightspace during the quiz time.

  • Project 1: srcFacts

    All project due dates are 11:59:59 pm.

  • Exercise 11: Build srcFacts

    Build and run the Project 1 srcfacts program performing the following:

    • Clone the repository and move to the repo directory (Not required if you are using GitHub Codespaces or have already cloned the repository)
    • Create the build directory - If you already have a build directory, delete it first
    • Move to the build directory
    • Create the build using cmake
    • Build the project using make
    • Run the program with the demo make run
    • Run the program with the demo directly, not using make

    • Enter the following command:

    To demonstrate this, you will record a terminal session using asciinema, as we did in Exercise 10: IOBuffering.

    IMPORTANT The URL should not contain "connect" or be a local file. Test your URL in a browser verifying that it shows the session you recorded. An incorrect URL will receive a 0.

  • Notes: Algorithmic Decomposition
  • Exercise 12: Algorithmic Decomposition Crossword
  • Notes: Rainfall Coding Practices

  • Exercise 13: Rainfall III

    Continuing on using the workflow from Rainfall I

    As before, you can follow along and see the commits that I make in class:

    OOPS26-Rainfall-010

    If you have any questions or issues, make sure to contact me.

  Unless otherwise noted, exercises are due by 3:30 pm on Wed Jan 28

• Project 1: srcFacts Posted: Jan 27

  To fix bugs and add new features to software, you have to understand the source code. One approach is to count things, such as the number of statements, functions, classes, expressions, and LOC (Lines Of Code). The program srcfacts produces a report of these counts for a C++ program.

  Writing code in a program to directly parse C++, i.e., identify the syntactic parts of the code, is very difficult. So, the srcfacts program does not parse the C++ source code. It uses another tool, srcML, to convert the C++ source code into an XML format. The srcfacts program inputs this XML format, parses the XML while collecting counts of parts of the input code, and produces the report. The input has to be in the srcML format, e.g., demo.xml, however it can be compressed or part of an archive, e.g., demo.xml.zip, linux.xml.gz.

  The srcfacts.cpp program is one large, main() function using almost no design features. It is extremely fast; for example, it can produce a report on the entire Linux kernel (verison 6.18.7, 60,392 source-code files, an 4.7 GB file in the srcML format) in under 8 seconds. However, in its current form, it is not easy to debug the XML parsing, add additional program element counts, or even understand what is going on. It includes code for parsing all parts of XML, but it would not be easy to adapt the XML parsing code for another purpose, e.g., another report. The only way to reuse this code is by copy/paste reuse. Overall, it has the following:

  Design Characteristic	Level
  Scalability	Very High
  Performance	Very High
  Portability	Medium
  Usability	Medium
  Modularity	Very Low
  Extensibility	None
  Reusability	None
  Maintainability	None

  Your task is to take the srcfacts code, improve the overall design, and extract the XML parsing part of the code. When completed, a set of functions in the files xml_parser.hpp and xml_parser.cpp will handle as much XML parsing as possible, while the main program, srcfacts.cpp, generates the report using the XML parser functions for parsing.

  • You do not have to understand how to parse XML. You are only repackaging XML parsing code, not writing from scratch.
  • The existing code is brittle, so you need to work carefully not to break the code
  • The repository includes example input
  • Keep in mind all aspects of design as we discuss them in class

  The steps (in order) with the associated (git) tag are:

  Tag v1a: Without changing the design, add the code necessary for the report to include the number of return statements. First see how the other counts are collected, then use it as a guide. Do not make any other changes to the project. The heading in the table must be "Returns". Due Jan 30

  Tag v1b: Move the refillContent() function into the separate refillContent.hpp and refillContent.cpp files. The build is already configured for these files. Due Feb 4

  Tag v1c: Apply the specific design changes from the Coding Practices Task List (an issue in your repository). As you verify that the code follows the practices given, check them off. Once you have completed all of them, close the issue. Due Feb 9

  Tag v1d: Extract a set of (free) functions to handle the low-level details of the XML parsing. Put the declarations into xml_parser.hpp and the definitions into xml_parser.cpp. Extract one function at a time, i.e., each commit can only include a single extracted function. Due Feb 13

  Tag v1e: Add the necessary code to count the number of line comments and literal strings. The headings in the table must be "Line Comments" and "Strings". Due Feb 13

  Your repository for this project is through GitHub Classroom, with a link on the Brightspace course page.

  • Projects in this course build on each other. Failure to complete Project 1 will impede progress on Project 2.
  • Steps must be completed in order, e.g., Step v1a must be completed before Step v1b.
  • Your code must compile with both g++ and clang. An easy way to verify is with GitHub Codespaces.
  • Be sure to follow the good practices we discuss in class
  • There are no classes or structs created for this project. You are extracting a set of free functions. Any class you create to solve this problem now would not solve the primary problem of how the srcFacts code uses an XML parser.
  • The main() handles XML errors (invalid XML format) with a direct return 1; so the program exits with the status of 1. To exit the program from within any function, use exit(1); which requires the include file stdlib.h.
  • While you can create and use other branches, only the work on the main branch counts. The main branch is the default when you git clone and git checkout.
  • The code uses the library libarchive to input compressed and archive files, e.g., linux-6.6.xml.gz and demo.xml.zip. See BUILD.md for details.

  General Guidelines

  • Code must compile and build
  • Do not change the existing format of the output
  • Do not add or commmit your build directory
  • Follow the programming style of the existing code. E.g., do not change the indentation style.
  • Follow all guidelines given in class

• Week 2 Class 3 Thu Jan 22 Posted: Jan 22

  After Class

  • GitHub Classroom Error

    If you get the following:

    

    To fix, go to your GitHub account. From the icon on the far top corner, select "Organizations". There you will see an invitation to accept the project.

  • Rainfall II In class, I was committing to the feedback branch instead of the main branch. That his now fixed, so you will see the changes on the main branch. The Report1.md remains only the feedback branch.

  Announcements

  • Exercise 6: Rainfall I

    • I posted a feedback report, Report1.md, in your repository under the branch feedback. I strongly suggest looking at it on GitHub. Enter this command from your source directory (not the build subdirectory):

    • I posted the scores and any additional comments in Brightspace

    Report1.md Example report.

    Points were taken off for:

    • Less or more than 3 commits
    • Differences between your code for a commit and my code in the example
    • Not following the exact format of the header comment
    • Typos in words
    • Wrong form of the action in the commit message. It is "Add", not "Added", "Adding", or "add".

    Also, do not use term "assignment" or "exercise" in your code. We simulate working on real code.

    If you have spacing or wording to fix, you can fix them. However, these commits must start with the word "Fix". Not "Fixing", "Fixed", or "fix", but "Fix".

  • TA: Mr. Sumaila Iddrisu si63@uakron.edu

  Agenda

  • Notes: Software Design Characteristics

    Note: In the next class meeting, I will give an exercise in quiz form that requires you to list all of the software design characteristics.

  • Exercise 7: Software Design Characteristics Crossword

  • Exercise 8: For Statement Quiz

    Completed during class.

    This is an online form. Link will be in Brightspace.

  • Notes: Rainfall Coding Practices

  • Exercise 9: Rainfall II

    Continuing using the workflow from Rainfall I

    As before, you can follow along and see the commits that I make in class:

    OOPS26-Rainfall-010

    If you have any questions or issues, make sure to contact me.

  • Exercise 10: IOBuffering Due by 3:30 pm on Mon Jan 26

  Unless otherwise noted, exercises are due by 3:30 pm on Fri Jan 23

• Exercise 10: IOBuffering Posted: Jan 22

  Build and run the program main. You will have to create a build directory, move to the build directory, run cmake, and then build using make. See the workflow for Rainfall I for the commands.

  Now run the program and notice that the output of the debugging statement is not shown. If it does show, run it a few times.

  So even though the program reached the output statement, the output using std::cout was buffered and the program crash prevented it from completion.

  Record running the program and not seeing the debugging output in a terminal session using asciinema.

  Now, change the debugging statement to use std::cerr. Rebuild your program, and run it again. This time, you will see the debugging output. Commit this change using the git command:

  Make sure you git push and verify, via a web browser, that these changes are in your files at GitHub.

  Record running the program and seeing the debugging output in a terminal session using asciinema.

  Upload both asciinema URLs using the IOBuffering Form

  asciinema

  To demonstrate this, you will record a terminal session using asciinema. It records the commands you enter and the output the command produces. asciinema is already installed in the GitHub Codespaces image. You can also install asciinema on Linux/WSL/macOS.

  asciinema is relatively straightforward to use.

  You can play, pause, skip, etc. You can also copy the commands as text. Note that the replay even includes your pauses and any delay as the command is run.

  At the end of the terminal session, asciinema will show a URL. Anybody can use this URL to view the session. This is what you will submit for the exercise to the link in the exercise title.

  IMPORTANT The URL should not contain "connect" or be a local file. Test your URL in a browser verifying that it shows the session you recorded. An incorrect URL will receive a 0.

• Week 2 Class 2 Tue Jan 20 Posted: Jan 20

  After Class

  • Exercise 6: Rainfall I

    • I posted a feedback report, Report1.md, in your repository under the branch feedback. I strongly suggest looking at it on GitHub:

    • I posted the scores and any additional comments in Brightspace

    Points were taken off for:

    • Differences between your code for a commit and my code in the example
    • Not following the exact format of the header comment
    • Typos in words
    • Less or more than 3 commits
    • Wrong form of the action in the commit message. It is "Add", not "Added", "Adding", or "add".

    Also, do not use term "assignment" or "exercise" in your code. We simulate working on real code.

    If you have spacing or wording to fix, you can fix them. However, these commits must start with the word "Fix". Not "Fixing", "Fixed", or "fix", but "Fix".

  Special Announcement

  Our class will meet online today in Teams. During the meeting, please be muted, but leave your camera on if possible.

  Our Team is CPSC 421-010 OOP 2:00 - 3:15 pm. You should see the meeting in your calendar. There is also a direct meeting link in Brightspace. If you have any problems, send a chat message in Teams or an email.

  Announcements

  • Office Hours Online today from 1 - 2 pm. I will monitor Teams. If you want to meet, start a chat with me in Teams.
  • TA We have a TA (Teaching Assistant) for the course, TA: Mr. Sumaila Iddrisu si63@uakron.edu

  • Grades Exercises 1 - 4 are in Brightspace. Read the feedback.

    Future exercise posting to Brightspace will not be announced. Delays will be.

  • OOP Survey Results Link in Brightspace
  • Development Environment Survey Results Link in Brightspace

  Agenda

  • Guide: GitHub Authentication
  • Setup for Exercise 6: Rainfall I

  • Exercise 5: Statement Design Quiz

    • Completed during class
    • All solutions in a question produce the same result
    • Must choose the "best" choice, and state why it is better
    • If you complete the Design Quiz, you will get full credit for this exercise
  • Notes: Rainfall Coding Practices

  • Exercise 6: Rainfall I

    You can follow along and see the commits that I make in class:

    OOPS26-Rainfall-010

    If you have any questions or issues, make sure to contact me.

  • Notes: Software Design Characteristics

  Unless otherwise noted, exercises are due by 3:30 pm on Wed Jan 21

• Exercise 6: Rainfall I Posted: Jan 20

  Take the starting rainfall.cpp code and make the changes that I make in class. This means the exact same code changes and exact commit message.

  Your code is in a repository from GitHub Classroom:

  1. Log in to your GitHub account.
  2. Click on the invitation link (GitHub Classroom Rainfall) on the main course page in Brightspace.
  3. Follow the directions to link your GitHub account to your UA ID.

  Environment

  1. Local

     This would be on your own machine with local files.

     First, you need to authenticate your local environment with GitHub: Guide: GitHub Authentication. This only has to be done once per environment, e.g. WSL on Windows.

     Then you clone the repository. Cloning creates a local repository that is a copy of your repository at GitHub.

     You can get the repo link from the button <> Code on GitHub, then under Local and HTTPS.

     Cloning a repository creates a directory with the name of your repository, e.g., _rainfall-_. To work on the files, you need to move into that directory:

  2. GitHub Codespaces

     GitHub Codespaces provides a development environment in the browser. When you create one from your GitHub Repository, you are already authenticated with GitHub and have a cloned repository, so you can start working right away.

     You can start a Codespace from the <> Code button on GitHub, then under Codespaces.

  Build Setup

  Git Workflow on Rainfall

  1. Edit files locally, e.g., add a header comment to the file rainfall.cpp
  2. Build, run, and check your work
  3. View your changes
  4. Commit current changes to the local repository:
  5. Push your local commits to the GitHub repository:
  6. View and verify your changes at GitHub in your browser Do not skip this verification
  7. View your commits locally

  Note Your code must build and compile. If you have a build warning or error, fix these before making any more changes to the code.

  Note You must commit each change that I make separately and use the exact commit message that I use in class

• Snow Day Posted: Jan 15

  After Class

  Class on Thursday, Jan 20 will be online in Teams.

  You should see a meeting in your Teams Calendar. The name of our Team is _CPSC 421-010 OOP _.

  I will also post a direct link in Brightspace.

  Agenda

  Campus is closed today, so no class.

  I am not holding office hours, but am available for questions via email.

  In in place of a class meeting, complete the following:

  • Read the rest of Notes: Software Design. We covered up to the last slide, 32 . If you type g on the slide page a Jump to slide appears so you can go directly to that slide.
  • Exercise 4: Software Design Crossword Due 3:30 pm on Friday, Jan 16
  • Exercise 3: Development Environment Survey Due 3:30 pm on Friday, Jan 16. I am giving you extra time to fix any issues with the CMake and Ubuntu upgrades.

  • CMake & Ubuntu Versions

    As stated in the Development Environment: Tools the cmake version must be 4.2.1 or higher. Some of you have less recent versions, even though the instructions stated you need to be at 4.2.1 for cmake. Follow the instructions to install the APT repository from Kitware (CMake people).

    For Linux, upgrade your Ubuntu using:

    You should also be on Ubuntu 24.04, not an older version. To convert, first upgrade as above, then enter the command:

    Use the Development Environment: Tools to check your versions.

    If you make any of these changes, then edit or fill out a new survey.

• Week 1 Class 1 Tue Jan 13 Posted: Jan 13

  Announcements

  • Syllabus
  • Office Hours

  • GitHub We use GitHub and GitHub Classroom in the class to manage source code for projects, exercises, and examples. You are required to have a GitHub account.

    Optionally, you can apply for the Student Github Developer Pack and get a free GitHub Pro account. To apply, your account email can be a school account, or a personal account if you upload documents to prove your current enrollment status.

  • GitHub Codespaces All exercises and projects include GitHub Codespaces as an option. It runs in and browser and offers a development environment with Visual Studio Code, along with a shell to enter commands for building (compiling and linking) and running your program. It automatically clones your GitHub repository. However, it does not automatically save your code changes back to GitHub; you must use git commands to do so.
  • Development Environment: Tools While GitHub Codespaces is great for short-term exercises, you'll want to work on long-term projects directly on your computer. Follow the instructions in the guide to set up your development environment. Department servers have older versions of g++ and cmake, so avoid relying on them.

  • O'Reilly Online Learning The course textbook is available in O'Reilly Online Learning.

    You do not have to be on the campus network (e.g., via VPN) to access O'Reilly Online Learning.

    To access content, click the "Institution not listed?" link below the dropdown and enter your UA email. You will then create an account and use that account from now on.

    For more information: Library LibGuide

  Agenda

  • Exercise 1: OOP Survey

  • Exercise 2: Syllabus Crossword

    1. Fill out the crossword in your browser. Do not print and fill out on paper.
    2. Print to a PDF using the Print Button or the Print feature in your browser. Try to include the headers and footers in the PDF.
    3. Upload the PDF of the completed crossword to Brightspace in Assessments/Assignments.

  • Exercise 3: Development Environment Survey

    The survey is available from the link of this exercise. There is nothing to upload to Brightspace.

    This exercise is due by 1 pm on Thu, Jan 15.

  • Notes: Software Design

  Unless otherwise noted, exercises are due by 3:30 pm on Wed Jan 14

• Welcome Posted: Jan 06

  Greetings and welcome to CPSC 421 Object-Oriented Programming for Spring 2026.

  • Syllabus The syllabus for the course is on the main course page. It is a draft that I will finalize before our first class meeting.
  • Survey The first exercise is to fill out the class survey. The survey is due after our first class meeting, but you can complete it before.
  • Development Environment Development Environment: Tools is a guide for setting up your programming development environment for the class. It is a good idea to start now as you will need this early in the course.

  • GitHub In the class, we use GitHub and GitHub Classroom to manage source code for projects, exercises, and examples. You are required to have a GitHub account.

    Optionally, you can apply for the Student Github Developer Pack and get a free GitHub Pro account. To apply, your account email can be a school account or a personal account if you upload documents to prove your current enrollment status.

  See you on Tuesday, Jan 13 at  2:00 - 3:15 pm in Arts & Sciences (CAS) room 136