CPSC 421-020 Object-Oriented Programming Spring 2026

Archive

• 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: Buffering and Exercise 10b: Software Design Characteristics Quiz.

    • Due to numbering conflict, renumbered Exercise 10: Buffering
    • 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-020

    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-020

  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-020

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

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

    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-020

    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-020 OOP 3:30 - 4:45 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-020

    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-020 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 slide 30 . 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  3:30 - 4:45 pm in Arts & Sciences (CAS) room 136