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

Archive

• Finals Week Posted: May 5

  • Final Exam May 7, 2:30 - 4:30 pm

  • Final Exam Practice Crosswords

    By request, I combined the crosswords that cover the Final Exam material. I left out anything that is part of XMLFramework, and that is not part of the written exam. For example, there are no Design Pattern crossword questions. Due to crosswordlabs.com limits, they had to be split into multiple crosswords:

    • CPSC 421 OOP Final Exam Crossword I
    • CPSC 421 OOP Final Exam Crossword II
    • CPSC 421 OOP Final Exam Crossword III
    • CPSC 421 OOP Final Exam Crossword IV
    • CPSC 421 OOP Final Exam Crossword V

    Do not use these as your only studying. Go over the topics listed that will be on the exam. You can also practice using any of the individual crosswords and can clear previous answers.

  • Finals Week Schedule Includes my office hours

  • XMLFramework Due by 11:59:59 pm on Friday, May 10

    All @TODOs are worth the same amount. You can leave 6 @TODOs and still get full credit. Any less than 6 @TODOs are extra credit.

  • Project 4 I posted the issues for template and handler. Scores posted in Brightspace.

• Week 15 Class 28 Thu May 02 Posted: May 02

  Announcements

  • Office Hours My Office Hours on Thursday, May 2 are from 10:30 - 11:00 am and 3:15 - 4:15 pm.
  • Project 4 Grading in progress.
  • Exercise 98: Library Due 4:30 pm on Friday, May 3. See previous class meeting in the Archive for details.
  • Final Exam May 7, 2:30 - 4:30 pm
  • XMLFramework Due by 11:59:59 pm on Friday, May 10
  • Finals Week Schedule

  Agenda

  • Notes: Design Pattern Message Queue
  • Exercise 99: Design Pattern Message Queue Crossword
  • Notes: Conclusion

  Unless otherwise noted, exercises are due by 4:30 pm on Fri May 03

• Week 15 Class 27 Tue Apr 30 Posted: Apr 30

  After Class

  • Office Hours

    My 10:30 - 11:30 am Office Hours will be from 10:30 - 11:00 am only on Thursday, May 2.

    I will have additional Office Hours from 3:15 - 4:15 on that day.

  Announcements

  • XML Framework

    Your XMLParser reads from standard input, or file descriptor 0. If you want to read from a file, then you can redirect from the file to file descriptor 0. An example program, filein.cpp shows how to do this.

    I posted a Pull Request for adding the libarchive dependency to the build. This is needed if your are plugging in your own XMLParser from the srcFacts project. If you do not see the pull request, you may have created your repository after the change was made.

  • Final Exam

  Agenda

  • Notes: C++ Templates

    View instantiated templates with clang:

    View instantiated templates online: cppinsights.io

    Benchmark: Function Pointers vs. Templates

  • Exercise 95: C++ Templates Crossword

  • Notes: Design Pattern Proxy

    Changes the behavior of the service but preserves the interface

  • Exercise 96: Design Pattern Proxy Crossword

  • Notes: Libraries

    Creating a shared and static library with the gnu compiler (gcc)

    Libraries

  • Exercise 97: Libraries Crossword

  • Exercise 98: Library

    This exercise is optional as I will drop the lowest Exercise score. This exercise is due by 4:30 pm on Friday, May 3.

    In an asciinema terminal session, perform the following on the Increment example. You can do so in Linux or in macOS.

    All commands must be typed in (not copy and pasted). Be sure to remember to use tab completion for filenames.

    1. Compile each source file separately
    2. Link the object files into the executable incr
    3. Run the executable incr
    4. Create a static library for increment()
    5. Show what is in the static library
    6. Link the static library to the executable incr
    7. Run the executable incr
    8. Create a shared library for increment()
    9. Link the shared library to the executable incr
    10. Run the executable incr showing that it cannot find the library
    11. Show the shared libraries that incr uses
    12. Use LD_LIBRARY_PATH so that incr can find the shared library
    13. Install the shared library into /usr/local/lib
    14. Show that incr still cannot find the library
    15. Run ldconfig
    16. Run the executable incr showing that it can find the library
    17. Show what libraries incr uses
  • Notes: Design Pattern Message Queue

  Unless otherwise noted, exercises are due by 4:30 pm on Wed May 01

• Final Exam Posted: Apr 30

  The Final Exam is in our regular classroom Final Exam: May 7, 2:30 - 4:30 pm.

  You are responsible for the following:

  • lambda functions - Be able to write with capture and parameters
  • UML multiplicity, generalization (inheritance), composition, and aggregation. Understand the difference between composition and aggregation and when we would use one over the other. Know the UML arrows for them.
  • Extension points: Three implementations: A) Direct inheritance from a Base class, B) Inheritance from Handler used by a Base class, C) C++ Templates. Be able to compare and implement at least two of these approaches on a small code example.
  • RAII - What it means, why it is important, how to implement
  • SOLID - Know the list of principles, both abbreviations and full names
  • Coupling - Definition, list of types of coupling, why decoupling is important
  • API Definition
  • Dependency Injection - general concepts
  • PIMPL - general concepts
  • Dispatch: Static vs. Dynamic, Given code and output, change code to generate the proper output
  • Extra: vtable and how it works

  The exam has various types of problems, including short answers, definitions, comparisons, drawing diagrams, and coding.

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

  The following exam answers are taken from your work on the XMLFramework Project. You will not answer them on the Final Exam

  • UML multiplicity, generalization (inheritance), composition, and aggregation. Know the syntax of the diagrams for each. Given code, state the relationship, and draw a UML diagram.
  • Design Patterns - general concepts, specific patterns: Template Method, Factory Method, Composite, Command, Adapter, Facade, Singleton.
  • exception handling Given exception handling code, show the result. Add exception handling to a code example.
  • Software Architecture - Given a problem, compare and contrast solutions using these two architectures.
  • C++ Inheritance specifiers: override and final
  • C++ Constructor Specifiers: explicit, mutable, default, delete

• Week 14 Class 26 Thu Apr 25 Posted: Apr 25

  After Class

  • XML Framework

    Your XMLParser reads from standard input, or file descriptor 0. If you want to read from a file, then you can redirect from the file to file descriptor 0. An example program, filein.cpp shows how to do this.

    I posted a Pull Request for adding the libarchive dependency to the build. This is needed if your are plugging in your own XMLParser from the srcFacts project. If you do not see the pull request, you may have created your repository after the change was made.

  Announcements

  • XML Framework
  • Advising Hours 3:15 - 4:15 pm today are cancelled

  Agenda

  • Exercise 93: Complete at least one @TODO on the Framework project.

  • Notes: Design Pattern Singleton

    Ensure a class only has one instance and provide a global point of access to it

  • Exercise 92: Design Pattern Singleton Crossword

  • Notes: Design Pattern Visitor

    Add operations to classes without changing them

    OutputList Example from the notes

    Git Commands Git branch commands

    GitHub Classroom invitation link in Brightspace if you want to run this in GitHub Codespaces.

  • Exercise 94: Design Pattern Visitor Crossword

  • Notes: C++ Templates

    View instantiated templates with clang:

    View instantiated templates online: cppinsights.io

    Benchmark: Function Pointers vs. Templates

  • Exercise 95: C++ Templates Crossword

    Due after next class.

  Unless otherwise noted, exercises are due by 4:30 pm on Monday, Apr 29

• Week 14 Class 25 Tue Apr 23 Posted: Apr 23

  Announcements

  • Posted correct answers for Exercise 76: Design Pattern Factory Method Quiz and Exercise 76: Design Pattern Factory Method Quiz Redux. You should be able to use the links to see what you missed.
  • Posted updated scores for Exercise 76. Note that the exercise "Redux" was due on Friday.

  Agenda

  • XMLFramework Project

    GitHub Classroom invitation link in Brightspace.

    XMLFramework

  • Exercise 90: XMLFramework Quiz

  • Notes: Design Pattern Facade

    Provide a unified interface to a set of interfaces in a subsystem

    Facade defines a higher-level interface that makes the subsystem easier to use

  • Exercise 89: Design Pattern Facade Crossword
  • Use Case for Namespace alias Definition Use

  • Notes: Software Architecture

    Pipe & Filter Example:

  • Exercise 91: Software Architecture Crossword

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Apr 24

• XMLFramework Posted: Apr 23

  The project is critical to your overall grade in the course, and parts count toward 25% of the questions on the Final Exam. Consider this a take-home part of the Final Exam. No matter how you performed on the previous projects, you need to work on this project.

  The project is due by 11:59:59 pm on Friday, May 10. The project consists of the following:

  • Parsing XML with a variety of push and pull parsers
  • XPath evaluation - XPath is an addressing language for XML
  • XSLT transformation - XSLT is a transformation language for XML
  • Combining these operations as needed by the applications

  The open-layered architecture framework, XMLFramework, supports all of this and includes:

  • Applications
    • Applications using XMLFramework
    • xmlpipeline.cpp - CLI for using the framework
  • XMLFramework
    • As described above
  • XMLToolkit
    • Set of C++ classes for processing XML
    • Used to implement XMLFramework, but can be used directly
    • Where your XMLParser lives
  • XMLLibrary
    • Set of C functions for processing XML
    • Used to implement the XMLToolkit, but can be used directly

  There is a lot of code in the project already. The primary task is to finish the remaining @TODOs. Some examples are:

  The @TODOs that involve integrating your XMLParser into the framework are not required but, if completed, will count as extra credit for the projects.

  The work involved is:

  • (50%) Complete any @TODOs
  • (20%) Fill in all classes @pattern and @role comments. A class can participate in multiple roles in multiple patterns.
  • (10%) Document the use of design patterns in the markdown file DESIGN.md. Each instance of a design pattern in XMLFramework must be listed, including the collaborators.
  • (10%) Document the architectures used in the XMLFramework in the markdown file ARCHITECTURE.md
  • (10%) Draw a UML diagram of the entire project in the file UML.pdf

  Notes:

  • The GitHub Classroom invitation link is on Brightspace.
  • The answers to some questions on the Final Exam are from your work on this project. For example, instead of creating a UML diagram during the Final Exam, your UML diagram from this project is your Final Exam answer. You must do these parts as they also count toward the Final Exam.
  • The project has a complete CMake build. You can add files to the subdirectories, and the CMake build will handle them automatically. Each file in the apps directory is assumed to be a single executable. If you add files, make sure you also commit and push them to GitHub. Always verify at GitHub that the correct files are there.
  • In XMLFramework, the app, xmlpipeline, uses CLI11 for parsing command-line options. When you run cmake, the file is downloaded. Depending on many settings in Windows, the download may be unsuccessful and quietly result in an empty file. If this happens, let me know.
  • To quickly find code, git grep works well. For all the lines of code that contain @TODO, enter the command git grep "@TODO" in the project's top directory. To see only the filenames, git grep -l "@TODO". The command depends on the directory where you issue the command, e.g., if in the directory framework, the results are for that directory and its subdirectories. To view a report of which @TODOs are left, use the build target: make todo. This command is entered in the build directory.

• Week 13 Class 24 Thu Apr 18 Posted: Apr 18

  After Class

  • Project 4

    For the handler part, I added the exact git commands to rename the files.

  Announcements

  • Office Hours My 10:30 - 11:30 office hours today are moved to 3:15 - 4:15 pm.

  • Exercise 76: Design Pattern Factory Method Quiz Redux

    See last class for details. Due by 4:30 pm on Friday, April 19.

  Agenda

  • Notes: Design Pattern Adapter

    Convert the interface of a class into another interface clients expect

    Adapter lets classes work together with incompatible interfaces

  • Exercise 85: Design Pattern Adapter Quiz

    • Do not start until instructed to in class
    • Note that you can save a link to edit your answers
    • Allowed to take the quiz multiple times

  • Exercise 86: Design Pattern Adapter Crossword

  • Notes: Dependency Injection
  • Exercise 87: Dependency Injection Crossword
  • Notes: PIMPL
  • Exercise 88: PIMPL Crossword

  • Notes: Design Pattern Facade

    Provide a unified interface to a set of interfaces in a subsystem

    Facade defines a higher-level interface that makes the subsystem easier to use

  Unless otherwise noted, exercises are due by 4:30 pm on Monday, Apr 22

• Week 13 Class 23 Tue Apr 16 Posted: Apr 16

  Announcements

  • Project 3 All issues are posted. Scores are posted in Brightspace.

    The total possible points are 110, but the maximum score that can be achieved is 100.

    You can leave the issue "Incorrect identity output for XML declarations" open (i.e., you do not have to fix it).

  • Project 4 Due Monday, Apr 22

  • Exercise 76: Design Pattern Factory Method Quiz Redux

    If you did the quiz in Exercise 76, I am giving you a chance to improve your score. Use the link to take the quiz again. If you score higher than the first quiz, I will update that score.

    • This is not another exercise, but a redo of Exercise 76
    • For this to apply, you must have previously completed the quiz in Exercise 76
    • If you get a lower score this time around, it will not effect your current score

    Due by 4:30 pm on Friday, April 19.

  Agenda

  • Notes: C++ Inheritance Specifiers

    • C# Contextual Keywords
    • C++ Keywords
  • Exercise 80: C++ Inheritance Specifiers Crossword

  • Notes: Design Pattern Strategy

    Define a family of algorithms, encapsulate each one, and make them interchangeable

    Strategy lets the algorithm vary independently from clients that use it

  • Exercise 81: Design Pattern Strategy Crossword
  • Notes: C++ Constructor Specifiers
  • Exercise 82: C++ Constructor Specifiers Crossword

  • Notes: Design Pattern Composite

    Compose objects into tree structures to represent part-whole hierarchies

    Composite lets clients treat individual objects and compositions of objects uniformly

  • Exercise 83: Design Pattern Composite Crossword

  • Benchmark: Create a String for Attributes with/without Reserve

    • Write without the optimization
    • Verify it works (with an automated testsuite if possible)
    • Perform the optimization
    • Measure and check that the optimization is an improvement

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Apr 17

• Week 12 Class 22 Thu Apr 11 Posted: Apr 11

  After Class

  • All issues for Project 3 are posted.

  Announcements

  • Project 3 Issues are rolling out for v3a. Still checking your extension points (for v3a), identity, and xmlstats.

  Agenda

  • Notes: Design Pattern Factory Method

  • Exercise 75: Design Pattern Factory Method Crossword

    Due by 4:30 pm on Fri Apr 12

  • Exercise 76: Design Pattern Factory Method Quiz

    Complete the quiz. Any incorrect answer is a point off out of 10, so answer very carefully.

    You will see the correct responses after the due date.

  • Exercise 77: Exceptions

    Take the code for Exceptions.cpp and perform the following changes:

    • Change the maximum length in function g() to 200 in both the code and the output message
    • Change the "not allowed" value from 50 to 75 in function h() in both the code and the output message
    • Change the domain of function f() to allow the negative value -1 (-2 and smaller is still not allowed)

    Run the program once for each exception, and show that the exception is thrown.

    To demonstrate these changes, you will record a terminal session using asciinema. You can use GitHub Codespaces for this as it has asciinema installed.

    Use the GitHub Classroom Exceptions invitation link in Brightspace.

  • Notes: SOLID
  • Exercise 78: SOLID Crossword
  • Notes: Design Pattern Command
  • Exercise 79: Design Pattern Command Crossword
  • Notes: C++ Inheritance Specifiers

  Unless otherwise noted, exercises are due by 4:30 pm on Monday, Apr 15

• Week 12 Class 21 Tue Apr 09 Posted: Apr 09

  Announcements

  • Project 2 Scores Posted in Brightspace. See the Feedback for scores for each part, and the point distribution.

  • Project 2 Class Diagrams The generated issue for Void or void in the UML Class Diagram was incorrect. I deleted those issues. I added a new, proper issue, if it still applied.

    Note that I did not take off points this issue. But please fix this in your class diagrams in the future.

  • Project 3 Issues are rolling out for v3a. Still checking your extension points (for v3a), identity, and xmlstats.

  • Exercise 69: FileIO

    Points:

    • -2 If the specifier delete was not used
    • -1 No comment for the destructor
    • -10 More than one change performed
    • -10 Does not pass valgrind without memory leaks

    Other feedback:

    • Do not use the term "virtual" in a comment. The keyword virtual already indicates that
    • The comment to use for the destructor is: // destructor
    • Adding the proper destructor and at the same time deleting a header comment is considered two changes

  Agenda

  • Project 4

  • Notes: Errors and Exception Handling

    RAIIDataMembers

  • Exercise 72: std::exception Hierarchy Crossword

  • Notes: API
  • Exercise 73: API Crossword
  • Notes: Handlers
  • Exercise 74: Handlers Crossword
  • Notes: Design Pattern Factory Method
  • Exercise 75: Design Pattern Factory Method Crossword We did not finish these slides, so the crossword is due after the next class meeting.

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Apr 10

• Project 4 Posted: Apr 09

  Project 4 continues the work on srcFacts. It is due at 11:59:59 pm Thursday, Apr 18 Monday, Apr 22, and involves the following stages which must be performed in order:

  Tag v4a Correct the issues in XMLParser that affect srcfacts, xmlstats, and identity, Class Diagram, and Sequence Diagram.

  Tag template Redesign XMLParser to use the Template Design Pattern. In this design pattern, extension points are virtual methods. Create a new class srcFactsParser (in the new files srcFactsParser.hpp and srcFactsParser.cpp) that inherits from the class XMLParser. Do the same thing for the new class IdentityParser (in the new files IdentityParser.hpp and IdentityParser.cpp) and the new class XMLStatsParser (in the new files XMLStatsParser.hpp and XMLStatsParser.cpp). The pull request template will add these classes to your repository and update the CMakeLists.txt file so that they are part of the build. Update your class and sequence diagrams to show this new design.

  As before, our XML parser needs to provide access to all parts of XMLvia the following extension points from XML notes slide 34

  XML Extension Point	Attributes
  Start Document
  XML Declaration	version, encoding, standalone
  Element Start Tag	qName, prefix, localName
  Element End Tag	qName, prefix, localName
  Characters	characters
  Attribute	qName, prefix, localName, value
  XML Namespace	prefix, uri
  XML Comment	value
  CDATA	characters
  Processing Instruction	target, data
  End Document

  Tag handler Extract a handler from XMLParser called XMLParserHandler, a new class that only handles the user-defined processing (what we previously had as callbacks). Put the entire XMLParserHandler class in the file XMLParserHandler.hpp. Change srcFactsParser, IdentityParser, and XMLStatsParser to inherit from XMLParserHandler instead of XMLParser, and rename them by replacing "Parser" in the name with "Handler". You can rename the srcFacts files using git:

  The IdentityParser files:

  And the XMLStats files:

  Note you will have to commit and push these changes.

  You will also have to rename these files in your CMakeLists.txt. Update your class and sequence diagrams to show this new design.

  One prevalent issue in these conversions is that changing XMLParser and srcFacts will cause identity and xmlstats to break until they are converted. To avoid this, understand that make uses the default target all and means make all. So instead of building all executable targets, build them separately as needed, e.g., make srcfacts, make xmlstats, or make identity.

  Keep in mind:

  • You are required to implement these steps in the order given, i.e., tag v4a, tag template, and then tag handler
  • At every commit, ensure the project compiles, builds, and produces the correct answer. Note that it may be only one of the executable targets that builds during conversion.

• Week 11 Class 20 Thu Apr 04 Posted: Apr 04

  After Class

  • For Project 2 Class Diagrams, the generated issue for Void or void in the UML Class Diagram was incorrect. I deleted those issues.

    I fixed the problem, and then generated a new, proper issue, if it applied.

    Note that I am not taking points off for the Void issue. But please fix this in your class diagrams in the future.

  Announcements

  • Project 2: Class Diagram

    I posted the feedback as issues in GitHub with the label v2class.

  • Project 3 Due date extended to Thursday, Apr 4
  • Office Hours Special Office Hours from 3:15 - 4:15 pm Thursday, Apr 4
  • Exercise 64: Dynamic Dispatch Due by 4:30 pm on Friday, Apr 5.
  • Exercise 65: VTable Diagram Due by 4:30 pm on Friday, Apr 5.

  Agenda

  • Exercise 68: Names II

    Using the feedback in the Report.md, fix your Names code.

    If you have no changes to make (based on the feedback), leave the code alone.

  • Notes: Virtual Destructors

  • Exercise 69: FileIO

    The program ReadFile supports multiple ways to read from standard input. You run the program with the option on the command line. The options include get, read, and fileread:

    

    All is well and good, but the program has memory leaks with some options. Use valgrind to determine what the problem is, fix it, and commit your fix. Do not make any other changes.

    Valgrind performs dynamic analysis, which means it collects data during the execution of a program. For valgrind, running with one option (e.g., using the option get) may find an issue, but running with another option (e.g., using the option read) may not. To be sure, we have to run the program with all options.

    The build command is:

    To run with valgrind for option get:

    That command is a single line displayed using the line continuation character ("\"). You can copy and paste the entire command.

    You must run the command with each option, get, read, and fileread.

    The fix consists of only one change to the code. Your code must pass with a clean valgrind report for all three options.

    The GitHub Classroom link is in Brightspace.

  • Notes: rValue References
  • Exercise 70: rValue References Crossword
  • Notes: Errors and Exception Handling

  • Exercise 71: Errors and Exception Handling Crossword

    RAIIDataMembers

  • Notes: API

  Unless otherwise noted, exercises are due by 9:30 pm on Monday, Apr 8. Note the special time.

• Week 11 Class 19 Tue Apr 02 Posted: Apr 02

  After Class

  • Project 2: Class Diagram

    I posted the feedback as issues in GitHub with the label v2class.

  Announcements

  • Project 2

    Feedback posted in issues at GitHub. Scores will be posted in Brightspace, but are not posted yet.

    I will post any feedback about your diagrams in Brightspace. Wait for the announcement.

    I am not requiring you to fix all the issues from Project 2 for Project 3. However, you will want to fix issues regarding missing function declaration/definition comments, header comments, EOF problems, indentation, naming, and spaces at EOL, and make those changes to your current code.

  • Project 3 Due date extended to Thursday, Apr 4

  • Exercise 56: Names

    Score in Brightspace. Feedback in Report.md in the repo.

    We will have a future Exercise: Names II where the issues I brought up are fixed. You can get started on that at any time.

  • CPSC 480 Software Engineering (SE)

    I also cover the SE course, which is offered in Fall, 2024. It will not be offered in Spring, 2025.

  • Exercise 63: Static Dispatch

    The instructions for Exercise 63 stated:

    

    Filling them in and not commenting them out is the wrong answer. Review instructions before working on an assignment.

  Agenda

  • Exercise 64: Dynamic Dispatch

    The repository Base has a set of various method call situations, and a way at run time (using assert()) to verify which method is actually called.

    • If the call is performed using dynamic dispatch then complete the assert() in the code that indicates (via a string) which method is called, e.g., for m2() is it "Base::m2()", "Derived::m2()", or "DerivedDerived::m2()"?
    • If the call is performed using static dispatch then comment out the assert(), e.g.,

    Handle each assertion one at a time in order, compiling and running the program (i.e., make run) after each assertion is completed. The assertion you edited should pass, and you should be onto the next assertion.

    You are required to commit for each block of statements in the main program.

    Due by 4:30 pm on Friday, Apr 5.

  • Notes: VTables

    There is no standard diagram to show a vtable. These are my own created using dot notation with GraphViz. GraphViz is for general graph visualization. You can create UML diagrams in GraphViz, but you have to much more work yourself, unlike yuml. Many of the more complex UML Class Diagrams that are in the notes, especially for design patterns are done using GraphViz as it provides more control over the arrangements of the nodes (classes). The vtable diagrams in the notes were originally done as modified UML Class Diagrams in yuml, e.g., VTable Base Pointer but I converted them to GraphViz, with initial conversion using ChatGPT.

  • Exercise 65: VTable Diagram

    In this exercise, you will complete a VTable diagram with a new class, Rectangle, which inherits from the class Shape.

    The diagram already has all classes and all method definitions. You just have to complete the vtable so that the method pointers in the vtable point to the correct function.

    The easiest way to work with the diagram is with GraphVizOnline. Start with the base diagram, and add the dot notation for the vtable method pointers to the correct methods. You can use the Shape and Circle VTable Diagram for an idea of how to get the edges from the Rectangle vtable to the functions.

    To get credit, all edges must be correct.

    You can also convert the VTableRectangle.dot file using the command-line tool, dot

    The dot program is available on macOS and WSL/Linux with the package graphviz. I also added it to the GitHub Codespaces image.

    Note that dot is part of a number of graph-drawing algorithms (see man dot). This one uses fdp to control the placement of the nodes.

    Due by 4:30 pm on Friday, Apr 5.

  • Notes: Design Patterns
  • Exercise 66: Design Patterns Crossword
  • Notes: Design Pattern Template Method
  • Exercise 67: Design Pattern Template Method Crossword

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Apr 03

• Week 10 Class 18 Thu Mar 21 Posted: Mar 21

  After Class

  • Exercise 62: Dispatch Crossword

    The answer to 10 down is "typeinfo".

    I will not count it incorrect if this is blank.

  Announcements

  • Exercise 57: UML Class Relationships Crossword The answer to the clue "Grady Booch feels that UML is not supposed to be a _____ representation" is "precise". It wasn't in the notes. So I will not count off if you don't get it right.
  • Project 3 Your repository now has a pull request for xmlstats and identity.
  • Office Hours Special 3:15 - 4:15 pm Office Hours
  • Project 3 For a lambda function, if you have many variables to capture you can capture all variables in scope using the capture default [&]. Only do this if you are going to pass a high percentage of the variables in scope (see Stamp Coupling).
  • Coupling "Creating visual representations of programming concepts can be quite challenging" - ChatGPT

  Agenda

  • Notes: UML Association
  • Exercise 60: UML Association Crossword
  • Notes: UML Generalization
  • Exercise 61: UML Generalization Crossword
  • Notes: Dispatch
  • Exercise 62: Dispatch Crossword

  • Exercise 63: Static Dispatch

    The repository Base has a set of various method call situations, and a way at run time (using assert()) to verify which method is actually called.

    Each assertion needs to have one of the following done:

    • If the call is performed using static dispatch then complete the assert() in the code that indicates (via a string) which method is called, e.g., for m1() is it "Base::m1()", "Derived::m1()", or "DerivedDerived::m1()"?

    • If the call is performed using dynamic dispatch then comment out the assert(), e.g.,

    Handle each assertion one at a time in order, compiling and running the program (i.e., make run) after each assertion is completed. The assertion you edited should pass, and you should be onto the next assertion.

    You are required to commit for each block of statements in the main program.

    The GitHub Classroom Invitation Link for Base is in Brightspace.

  Unless otherwise noted, exercises are due by 4:30 pm on Mon Apr 1

• Week 10 Class 17 Tue Mar 19 Posted: Mar 19

  After Class

  • Exercise 57: UML Class Relationships Crossword The answer to the clue "Grady Booch feels that UML is not supposed to be a _____ representation" is "precise". It wasn't in the notes. So I will not count off if you don't get it right.
  • Project 3 Your repository now has a pull request for xmlstats and identity.
  • Office Hours 3:15 - 4:15 pm Office Hours are cancelled for today

  Announcements

  • Midterm Scores and feedback in Brightspace. A copy of your completed exam and feedback are in Assignments under Midterm Feedback.
  • Project 3

  Agenda

  • Exercise 56: Names

    The UML Class Diagram shows Name with attributes that are single-value optionals.

    Convert the source code class to use std::optional instead of the pair of std::string and a flag.

    The link for GitHub Classroom is in Brightspace.

    Reminder The type String in a UML Class Diagram does not necesarily map to a std::string in a C++ program. It could map to a std::string_view, or even a c-string. Which source-code type a UML type maps to is part of the code implementation, and not part of the model.

    

  • Notes: UML Class Relationships
  • Exercise 57: UML Class Relationships Crossword
  • Notes: Dependencies
  • Exercise 58: Dependencies Crossword
  • Notes: Coupling
  • Exercise 59: Coupling Crossword
  • Notes: UML Association

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Mar 20

• Week 9 Class 16 Thu Mar 14 Posted: Mar 14

  Announcements

  • Midterm
  • Project 3

  Agenda

  • Exercise 51: IoC Crossword Due by 4:30 pm on Fri, Mar 15.

  • Exercise 52: Lambda

    Follow along in your commits as we explore what we can get from the context of the lambda definition.

    Lambdas-020

  • Notes: RAII

    ResourceDemo

  • Exercise 53: RAII Crossword
  • Guide: Valgrind

  • Exercise 54: Memory I

    The file Memory.cpp in the repository Memory contains many memory resource problems described in the notes.

    Compile and run the program on your platform (i.e., your compiler and operating system). You may or may not see a memory-related issue during the build and run.

    Go to a system where you can run valgrind. Following the instructions in the Guide: Valgrind, compile and run valgrind on the program.

    Fix the memory resource problems in Memory.cpp without using std::unique_ptr. Do this for each section one by one committing each section separately. Get the code to the point where it compiles and runs successfully, and you have a clean Valgrind run. Once done, tag this in Git as fixmemory.

  • Exercise 55: Memory II

    Replace the raw pointers (e.g., int* p) with std::unique_ptr<int>. Ensure it runs successfully and you have a clean Valgrind run. The include file for std::unique_ptr is <memory>. Once done, tag this in Git as smartpointer

  Unless otherwise noted, exercises are due by 4:30 pm on Mon, Mar 18.

• Week 9 Class 15 Tue Mar 12 Posted: Mar 12

  Announcements

  • Project 3

  Agenda

  • Notes: UML Multiplicity
  • Exercise 48: UML Multiplicity Crossword

  • Exercise 49: Convert II

    Following my example in class, mark the concerns and rearrange the code to rearrange the concerns in the file.

    Convert-020

  • Notes: Lambda Functions
  • Exercise 50: Lambda Functions Crossword
  • Notes: IoC

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Mar 13

• Project 3 Posted: Mar 12

  The main problem with the design for the srcFacts project is the complicated section of code (large while loop with nested-if) surrounding the srcFacts concerns. We have moved much of the low-level parsing details out of srcfacts.cpp (and into XMLParser), but that overall code structure remains.

  Change the design of XMLParser to use full IoC (Inversion of Control). IoC lets you move the large while loop with nested-if entirely into an XMLParser method parse(). The only things that srcFacts will have to do (and the only public methods of the new XMLParser) are the parse() method and (depending on your implementation) methods to register handlers.

  Your XML parser needs to provide access to all parts of XML, even if srcFacts does not use it, via the following extension points from XML notes slide 34

  XML Extension Point	Attributes
  Start Document
  XML Declaration	version, encoding, standalone
  Element Start Tag	qName, prefix, localName
  Element End Tag	qName, prefix, localName
  Characters	characters
  Attribute	qName, prefix, localName, value
  XML Namespace	prefix, uri
  XML Comment	value
  CDATA	characters
  Processing Instruction	target, data
  End Document

  There is no explicit stage to fix the code from the Project 2 feedback. Fix any style issues in XMLParser or any issues that will cause a problem with Project 3.

  Tag v3a: Redesign XMLParser to use IoC with lambda handlers for the extension points. For srcFacts, this means that the lambda functions in srcFacts.cpp contains all the processing of the XML data results, e.g., tag names with none of the XML parsing. Update your Class Diagram and Sequence Diagram to reflect this new design. Rules apply:

  • Each extension point has a single handler
  • All data passed to the handlers must be via parameters
  • Handlers cannot call XMLParser methods

  Tag v3xmlstats: Create the application xmlstats that produces a markdown report (similar to what srcFacts does) that indicates the number of each part of XML. E.g., the number of start tags, end tags, attributes, character sections, etc.

  Tag v3identity: Create the application identity which is an identity transformation. A transformation is a program that converts data in one format to data in a related format, typically the same format. In this case, it converts from XML to XML. It is an identity transformation because the output XML should be the same (as much as possible) as the input XML. The XMLParser will parse the input, and your callbacks will output the XML format. You can assume that there are no CDATA parts, but you must escape all >, <, and & in Character and CDATA content.

  Note: Any changes to XMLParser must work with srcfacts, xmlstats, and identity:

  • You cannot have a special XMLParser for each application
  • Any srcfacts, xmlstats, or identity-specific concerns cannot remain in XMLParser

  All tags for Project 3 are due Tuesday, Apr 2 Thursday, Apr 4.

  Keep in mind:

  • Complete tag v3a first. After that, you can complete tags v3xmlstats and v3identity in any order.
  • I will provide pull requests for the programs xmlstats and identity that add the needed files to the build.
  • At every commit, ensure the project compiles, builds, and produces the correct answer.

• Midterm Class Meeting Posted: Mar 7

  • Midterm Exam
  • In our regular classroom
  • Paper is provided
  • No computer needed

• Week 8 Class 14 Tue Mar 05 Posted: Mar 05

  Announcements

  • Midterm Exam

  • Requesting Technical Help Guidelines

    • Be specific. Provide details. Which variables? Which potential fields?
    • Prefer text over images
    • Put yourself in the place of the person you are asking help from
    • Use proper greetings

  Agenda

  • Exercise 45: Convert

    Following my example in class, mark the concerns and rearrange the code to rearrange the concerns in the file.

    Convert-020

  • Notes: Callbacks
  • Exercise 46: Callbacks Crossword

  • Exercise 47: Sorts

    For each @TODO:

    • Uncomment the std::sort() call and test
    • Write a predicate function appropriate to the sort directly in sorts.cpp
    • Pass the predicate function for the comparison argument

    Rules:

    • No templates
    • No function objects (functors)
    • No additional files

    By 4:30 pm on Wed Mar 7 finish one of the @TODOs. The rest are due by 4:30 pm on Mon Mar 11.

  Unless otherwise noted, exercises are due by 4:30 pm on Mon Mar 11

• Week 7 Class 13 Thu Feb 29 Posted: Feb 29

  After Class

  • Fixed the name of the feedback file. It is feedback.hpp

  Announcements

  • Midterm Exam

  • Exercise 34: Utilities II

    Feedback in the main branch of your repository in the file feedback.hpp.

    If there were any compilation errors, those are in the file error.log.

    Violations of the zero-tolerance policy did not get a feedback.hpp.

  Agenda

  • Exercise 41: Utilities III

    Another pass. As before, your improved score on Utilities III will replace (if higher) your score on Utilities II.

    Your program must compile successfully. Any code that does not will receive a 0.

    Note that the zero-tolerance policy is still in effect.

  • Notes: Encapsulation
  • Exercise 42: Encapsulation Crossword
  • Notes: Constructors and Initialization
  • Exercise 43: Constructors and Initialization Crossword

  • Exercise 44: Member Initialization List

    Following my example in class, convert all the constructors in all files to use member initialization lists.

    CMake builds an executable for each .cpp file.

    The GitHub Classroom link is in Brightspace.

    OOPS24-member-initialization-lists-020

  • Exercise 45: Convert

    Following my example in class, mark the concerns and rearrange the code to rearrange the concerns in the file.

    Convert-020

    We did not really start this, so this will be due after the next class, and you don't have to commit anything until then.

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

• Midterm Exam Posted: Feb 29

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

  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 - Explain what it is and how it works
  • Structure Diagram Given code or description, draw.
  • Coding Style Given 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, 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

  Note that Method Stereotypes and Callbacks are not on the exam.

  The exam has assorted problem types, including short answers, definitions, comparisons, drawing diagrams, and coding.

  Questions are from what I covered in class, the book, the exercises, and the projects. If I did not cover it in class, it is not on the exam.

• Week 7 Class 12 Tue Feb 27 Posted: Feb 27

  Announcements

  • Project 1 All parts have scores in Brightspace.
  • Project 2 Added due dates

  • Generating the Concerns Visualization

    I installed the concerns program (the one that generated your concerns.html file) in GitHub Codespaces. From now on understand that if I update the GitHub Codespaces image, it does not change the one you are already using. You have to ecreate a new one to see the new features.

    To run the concerns 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:

  • srcml in Codespaces

    As part of the install of concerns in codespaces, I also installed a 1.1 beta version of srcml. You can convert files to the srcml format:

    You can also create the srcML format from a code fragment, and run it directly with srcfacts:

  Agenda

  • Notes: Cohesion
  • Exercise 37: Cohesion Crossword

  • Demo: Cohesive Declarations

    CohesiveDeclaration

  • Exercise 39: Cohesive Declarations

    Perform the commits for each choice of ordering declarations.

  • Notes: Method Stereotypes
  • Exercise 40: Method Stereotypes Crossword
  • Notes: Encapsulation

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Feb 28

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

    

  • Notes: Cohesion

  Unless otherwise noted, exercises are due by 4:30 pm on Monday, Feb 26.

• Week 5 Class 10 Thu Feb 15 Posted: Feb 15

  After Class

  • Project 2

  • 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 receive it:

    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

  Announcements

  • Project 1

    • I updated the scores for Project 1 v1b and v1c in Brightspace
    • Feedback are issues in your GitHub repository
    • Issues are labeled with the part of the project they relate to, e.g., v1c
    • Many of the checks for v1b were based on your code at label v1c
    • For v1d, some of the issues are generated, but not all
    • No score yet for v1d as not all checks are done
    • Most problematic for v1d are srcFacts and srcML concerns in the xml_parser files
    • Another major area is low-level parsing code in srcfacts.cpp that really belongs in xml_parser files
  • After Class Not always announced

  • Exercise 29: TRACE

    • Building with TRACE on
    • Naming of everything is important. Even name of files.
    • Filenames such as file1.cpp.xml, file2.cpp.xml, and file3.cpp.xml have little meaning
    • Better filenames: line.cpp.xml, block.cpp.xml, and doxygen.cpp.xml
    • Even better: lineComment.cpp.xml, blockComment.cpp.xml, and doxygenComment.cpp.xml or line_comment.cpp.xml, block_comment.cpp.xml, and doxygen_comment.cpp.xml
    • Practice good naming. Overall, it will save you time and attention
  • Project 2

  Agenda

  • Notes: Scope
  • Exercise 30: Scope Crossword
  • Notes: Iterator
  • Exercise 31: Iterator Crossword
  • Notes: Sequence Diagram

  • Exercise 32: Sequence Diagram

    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)

    

  • Exercise 33: Utilities

    Provide a function declaration in the file Utilities.hpp and a 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. Only provide the declaration and example call using 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. But, since you are not providing a function definition, the program will not link or run successfully.

    To compile the program without linking:

      g++ --std=c++17 -c UtilitiesExamples.cpp
    

    For each function declaration, include a doxygen comment that describes the function and describes what data is IN, OUT, or IN/OUT.

    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
    • Use of any other files
    • Use of C++ standard library functions
    • Use of templates

  Unless otherwise noted, exercises are due by 4:30 pm on Monday, Feb 19

• Project 2 Posted: Feb 15

  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 will be 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 22 26

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

  From now 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 Mar 4

  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 4

  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 5

  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, nor xml_parser.cpp.

• Week 5 Class 9 Tue Feb 13 Posted: Feb 13

  After Class

  • For the crossword: "test-case" (instead of "unit-test")

  • Exercise 29: TRACE

    Enabling the TRACE may cause code to be compiled that breaks the build.

    One problem may be that std::setw in TRACE in xml_parser.cpp is not declared. This is due to a missing include file, iomanip in xml_parser. So include it and see if that fixes the problem.

    The other potential problem is the lack of qName or prefix or localName where the TRACE is called. This is mostly due to not making that data available, e.g., in the main program.

    If you cannot get this working, for now you can build and run the code from before tag v1d. For now:

    1. Checkout the code from tag v1d: git checkout v1c
    2. Build and run with TRACE enabled:cmake . -DTRACE=ON
    3. Create your asciinema screencast
    4. Checkout the main code again: git checkout main
    5. Disable the TRACE: cmake . -DTRACE=OFF
  • Project 1: v1b Scores were added to Brightspace, and feedback are the issues in your GitHub repository with the label v1b

  Announcements

  • Project 1: v1e Due date moved to Thursday, Feb 15
  • Guide: git Commit Messages

  Agenda

  • Guide: Build Configurations
  • Notes: Naming
  • Exercise 27: Naming Crossword

  • Notes: Method Naming Standards

    We will follow these naming standards in this course.

  • Exercise 28: Method Naming Standards Crossword

  • Exercise 29: TRACE

    Demonstrate the running of your program with TRACE on for:

    • A line comment
    • A short block
    • A Doxygen block comment

    You will have to create the srcML for each of these. 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 State
  • Notes: Scope
  • Exercise 30: Scope Crossword Due after next class

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Feb 14

• Week 4 Class 8 Thu Feb 08 Posted: Feb 08

  After Class

  • Project 1: v1d

    The added files, xml_parser.hpp and xml_parser.cpp and the require CMakeLists.txt change are all in a pull request. You can pull the pull request and GitHub, and then do a git pull in your repository.

  Announcements

  • Project 1 v1d

    • 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
  • Increment Quiz Results
  • In-Class Exercises Failure to provide both name and email on an in-class exercise will lead to an immediate 0.

  Agenda

  • Guide: Coding Standard
  • Exercise 23: Coding Standard Crossword
  • Exercise 24: srcFacts Concerns Quiz
  • Notes: Vertical Development
  • Exercise 25: Vertical Development Crossword
  • Notes: Generalizing Functions
  • Exercise 26: Generalizing Functions Crossword
  • Notes: Naming

  Unless otherwise noted, exercises are due by 4:30 pm on Monday, Feb 12

• Week 4 Class 7 Tue Feb 06 Posted: Feb 06

  Announcements

  • Rainfall I went ahead and finished the replacement of the heaviest code in rainfall.cpp with a call to the max() function.

  • Project 1

    • v1b I only gave you a score if you did not have a tag for v1b
    • v1c I added the issue Coding Practices Task List to your repository. The checklist items are in no particular order. Pick the easiest ones first.
    • I added due dates for the rest of the parts
    • I see lots of commits that are on the day that part of the project is due. Do not expect that all parts will be able to be completed on one day.
  • srcML Playground - See Notes page
  • Office Hours Remember that my 3:15 - 4:15 pm Office Hours are on Tuesday, not Thursday

  Agenda

  • Notes: Free Function Stereotypes
  • Exercise 19: Free Function Stereotypes Crossword
  • Exercise 20: Increment Quiz
  • Notes: Coding Style
  • Exercise 21: Coding Style Crossword
  • Notes: Concerns
  • Exercise 22: Concerns Crossword

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Feb 07

• Week 3 Class 6 Thu Feb 01 Posted: Feb 01

  After Class

  • I went ahead and finished the replacement of the heaviest code in rainfall.cpp with a call to the max() function. This serves as a good example for v1b.

    For your part, you do not have to implement these additional commits. You can stop at commit 06531b2 "Add include for Aggregate.hpp in main".

  • I added the issue Coding Practices Task List for v1c to your repository.

  Announcements

  • srcFacts macOS Fix The CMakeLists.txt does not find LibArchive on macOS. There is a pull request in your repo (see GitHub) that will fix that.
  • Office Hours I am swapping my 3:15 - 4:15 Office Hours and Advising Hours
  • Guide: Git Commands Added for tagging an older commit, and single line log

  • Project 1 v1a

    • Scores (out of 20 possible) are in Brightspace for Project 1

    • Feedback is in your repository in the issues. Found issues:

      • Missing tag v1a
      • Missing return statement count
      • Incorrect return statement count
      • Inconsistent variable name Returns
      • Inconsistent spacing
      • Inconsistent spacing around keywords
      • Inconsistent spacing around operators
    • Do not expect that every part (e.g., v1b, etc.) will be graded before the next part is due
    • This is a straightforward step. The rest of the steps involve a lot more coding.
  • Exercise 12 and exercise scores in general

  Agenda

  • Notes: XML
  • Exercise 17: XML Crossword
  • Notes: Rainfall Coding Practices Slide 23

  • Exercise 18: 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:

    OOPS24-Rainfall-020

  Unless otherwise noted, exercises are due by 4:30 pm on Mon, Feb 5

• Week 3 Class 5 Tue Jan 30 Posted: Jan 30

  After Class

  • Separate Compilation Crossword 19 across is "details"
  • srcFacts macOS Fix The CMakeLists.txt does not find LibArchive on macOS. There is a pull request in your repo (see GitHub) that will fix that.

  Announcements

  • Project 1 I posted due dates for parts v1b and v1c.
  • Due Dates Unless I give a specific time, due dates are 11:59:59 pm on the day indicated.
  • Feedback on Exercise 5: Rainfall II and Exercise 13: 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 Project 1. However, you should try to follow the rules:

    • 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 Slide 19

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

    OOPS24-Rainfall-020

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Jan 31

• Week 2 Class 4 Thu Jan 25 Posted: Jan 25

  After Class

  • Project 1 I posted due dates for parts v1b and v1c.

  • Project 1 I will show in class on Tuesday how to tag your commit for v1a of Project 1. You can continue to commit, as a tag can be set on any commit, even a previous commit.

    If you do want to go ahead and tag for v1a, the commands to tag, view the tags, and push the tag to GitHub are:

    On the GitHub page for your repository, where it says main, allows you to view the code at any of your tags. Verify at GitHub that the tag is there.

  Announcements

  • TA
  • Feedback on Exercise 5: Rainfall II
  • Project 1: srcFacts

  Agenda

  • Exercise 11: Build srcFacts

    Build and run the Project 1 srcfacts program. This must include 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
    • Running the program with the demo make run

    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. The URL should not contain "connect" or be a local file. Test your URL in a browser; an incorrect URL will receive a 0.

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

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

    OOPS24-Rainfall-020

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

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

• Project 1: srcFacts Posted: Jan 25

  One approach to understanding the source code of a system is to count things, e.g., the number of statements, functions, classes, expressions, LOC (Lines Of Code), etc. The program srcfacts produces a report of these counts.

  It is very difficult for a program to parse the C++ source code directly, i.e., identify the syntactic parts of the code. 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 as, for example, it can produce a report on the entire Linux kernel 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:

  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. 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. Due Feb 2

  Tag v1c: Apply the specific design changes from the Coding Practices Task List (to appear). 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 7 9

  Tag v1d: Extract a set of (free) functions to handle the low-level details of the XML parsing. Extract one function at a time, i.e., each commit can only include a single extracted function. Due Feb 12

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

  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 sucessfully 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. To install on Linux, sudo apt-get install libarchive-dev. To install on macOS, brew install libarchive. The GitHub Codespaces image already has libarchive-dev installed.

• Week 2 Class 3 Tue Jan 23 Posted: Jan 23

  Announcements

  • Feedback on Exercise 5: Rainfall I

    • Generated report Report1.md in your repository under the branch feedback

    • Scores and comments in Brightspace

  • Guides
  • Exercise 6: Development Environment Setup

  Agenda

  • Notes: Software Design Characteristics
  • Exercise 7: Software Design Characteristics Crossword
  • Exercise 8: for-statement quiz - Full credit if you complete in class
  • Notes: Rainfall Coding Practices Slide 9

  • Exercise 9: Rainfall II

    Continuing on using the workflow from Rainfall I

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

    OOPS24-Rainfall-020

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

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Jan 24

• Week 1 Class 2 Thu Jan 18 Posted: Jan 18

  Announcements

  • Grades for Exercises 1 & 2 are in Brightspace
  • OOP Survey Results
  • Development Environment: Tools Follow the directions in the guide to set up your development environment. Department servers have older versions of g++ and cmake, so do not rely on them.
  • Guide: GitHub Authentication

  Agenda

  • Setup for Exercise 5: Rainfall I
  • Notes: Software Design
  • Exercise 3: Software Design Crossword Due by 4:30 pm on Friday, Jan 19

  • Exercise 4: Design Quiz

    • Each solution in a question produces 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 Exercise 4.
  • Notes: Rainfall Coding Practices

  • Exercise 5: Rainfall I

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

    OOPS24-Rainfall-020

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

  • Exercise 6: Development Environment Setup

  Unless otherwise noted, exercises are due by 4:30 pm on Monday, Jan 22

• Exercise 5: Rainfall I Posted: Jan 17

  Take the starting rainfall.cpp code and make the same changes that I make in class.

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

     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 button 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 clone repository. So you can start working right away

     You can start a Codespace from the button <> 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

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

  After Class

  • The answer to Question 6 on the Exercise 2: Course Content is "oncampus".
  • The answer to Question 8 is "teams"

  Announcements

  • Syllabus

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

  • Development Environment: Tools Follow the directions in the guide to set up your development environment. Department servers have older versions of g++ and cmake, so do not rely on them.
  • GitHub Codespaces All exercises and projects have GitHub Codespaces as an option

  • 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

  Exercises

  • Exercise 1: OOP Survey

  • Exercise 2: Course Content 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.
  • Notes: Software Design
  • Exercise 3: Software Design Crossword Due by 4:30 pm on Friday, Jan 19

  Unless otherwise noted, exercises are due by 4:30 pm on Wed Jan 17

• Greetings and welcome to CPSC 421 Object-Oriented Programming (OOP) for Spring 2024.

  • 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 good to start early as you will need this early in the course.

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

  See you on Tuesday, Jan 16 at 12:15 pm - 1:30 pm in Arts & Sciences (CAS) room 136