CPSC 480 Software Engineering (SE) Fall 2024

News

---

• Week 13 Class 24 Tue Nov 19 Posted: Nov 19

  Announcements

  • Project 4: Streaming

  • Guide: Guard Clauses

    For removing functionality:

    • Comments may have to be adjusted
    • Remove the test case
    • Remove the code, do not just comment-out the code
    • Remove any comments associated with the removed code

  Class

  • Exercise 60: Replace Nested Conditional with Guard Clause

    Fix your Replace Nested Conditional With Guard Clause repository using the feedback (Report.md in the branch feedback) for Exercise 54: Team Replace Nested Conditional with Guard Clause Refactoring.

  • Notes: Software Engineering Paradigms
  • Exercise 61: Software Engineering Paradigms I Crossword
  • Notes: Waterfall Software Process Models

  • Exercise 62: Waterfall Software Process Models Crossword

    We did not finish the Waterfall notes, so the due date for this crossword is delayed.

  • Exercise 63: Team Streaming Meeting I

    Each member of the team must create an issue for Project Streaming. By the end of the class period, at least the subject of the issue is required. You have until 3 pm on Wed Nov 20 to finish the description. The description cannot be just a single sentence.

  Unless stated otherwise, all exercises are due by 3 pm on Wed Nov 20

• Project Streaming Posted: Nov 19

  Your company purchased a streaming video service. The plan is to use this code (and the associated data-mining platform) for a future software product.

  Your team is in charge of the software. The immediate goal is to bring this codebase up to company standards by filling in the (primarily missing) unit test cases and performing refactorings. You are not to add any new features or change the code's behavior in any way, only to improve the design and implementation quality of the current functionality.

  Each team has a GitHub Classroom repository. An invitation link to create the repository is on the Brightspace course page. All work is through the project repository via issues, branches, and pull requests. Discussions will take place via the issue tracking system in GitHub.

  You have the following overall work to do:

  • Create unit test cases. Create an issue in the repository for each set of unit test cases. Then, assign them to a member of the team. Note that you need a complete set of test cases before you perform refactoring on a class.

  • Perform Refactorings Contribute refactorings by creating issues in the repository. These issues must motivate why the refactoring is necessary and include the name of the refactoring.

  • Adaptive Maintenance Current code does not take advantage of the features of C++11. In many ways, these are also refactorings, but there is no standard catalog for them. Treat them as refactorings in terms of issues and branches. You can also take advantage of the features of C++14 and C++17.

  For each of these activities:

  • Team members assign themselves issues from the group repository
  • For each issue, create a topic branch with the number of the issue, e.g., issue1. Work for that issue occurs on that branch.
  • Work from the branch is contributed to the main branch via pull requests. No direct work occurs on the code in the main branch.
  • After you perform a refactoring and pull the changes into the main branch, the associated issue is closed. Also, if the team decides that the refactoring is not a good idea, close the issue.
  • Note that if the refactoring causes methods to be created or removed, the unit test may also need refactoring
  • The existing code's coding style (indentation, use of whitespace) meets the company coding standards, and any changes must preserve the current coding style.

  Notes:

  • Each team member must implement one issue for adding test cases. If there are more test case issues to implement than team members, then a team member may do more than one. If there are more team members than test case issues, two team members can work on the same test file.
  • There is a list of refactorings to perform. There are more than 11, so each team member should do about 3 or 4. Do not do more than that so each team member has enough to do.
  • The Big Refactoring must be completed.
  • The person who creates an issue does not have to be the same as the person who performs the changes.
  • As much as possible, discussion on technical issues is through the issue tracking system of GitHub.
  • Your score on this assignment depends on your contribution, including creating issues and performing refactorings. Therefore, use your own GitHub account to contribute issues, contribute to discussions on issues, and make pull requests.
  • For purposes of grading, do not delete any branches.

  The only allowed changes to the code are:

  • Add test cases
  • Create functions in the test files to make test cases easier to write
  • Apply Fowler refactorings
  • Apply adaptive maintenance changes for C++11, C++14, and C++17.

  Note that you cannot delete any classes. You can, however, add classes.

  Points are deducted from all members of the team for any additional functionality added to the project

  Technical Notes:

  • The only branches that you should have are issue branches and main, and changes must be pulled into the main branch to count for the project
  • The project has CMake build files
  • The project uses an external C++ Testing Framework called Catch2. CMake automatically downloads the file catch.hpp. You can also directly download the file. Do not add the file catch.hpp to your repository.

Archive