CPSC 480-010 Software Engineering (SE) Fall 2024

Archive

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

• Week 12 Class 23 Thu Nov 14 Posted: Nov 14

  After Class

  • Project 3: Code Analysis TDD Exercise 59

    See Report8.md in the feedback branch of your repository. Score and some feedback in Brightspace.

    Note that this is the last exercise for progress on Project 3. The only remaining due date is the end-of-project due date.

  Announcements

  • Project 3: Code Analysis TDD We were informed today that the heating system in the building BCAS, i.e., CAS, i.e., where we have class, will be without heat:

    Please communicate to your faculty, staff, and students that the building is expected to be without heat again overnight and during the morning tomorrow. Please have them prepare for cold temperatures in the building.

    …The boilers were turned off overnight Tuesday - Wednesday due to an alarm condition. The HVAC and Mechanical teams have been working on the problem, but do not have a solution at this time.

    As Prof. O'Neil told us:

    if you’re in BCAS tomorrow dress warm

  • Project 3: Code Analysis TDD Exercise 55 and Exercise 56

    See the Report6.md and Report7.md in the feedback branch of your repository. Score and some feedback in Brightspace.

  • Project 3: Code Analysis TDD Due date for Friday cancelled

  Class

  • HFSD Chapter 10
  • Exercise 57: HFSD Chapter 10 Crossword
  • HFSD Chapter 11
  • Exercise 58: HFSD Chapter 11 Crossword
  • Notes: Software Engineering Paradigms

  Unless stated otherwise, all exercises are due by 3 pm on Fri Nov 15

• Week 12 Class 22 Tue Nov 12 Posted: Nov 12

  Special Announcement

  We were informed today that the heating system in the building BCAS, i.e., CAS, i.e., where we have class, will be without heat:

  Please communicate to your faculty, staff, and students that the building is expected to be without heat again overnight and during the morning tomorrow. Please have them prepare for cold temperatures in the building.

  …The boilers were turned off overnight Tuesday - Wednesday due to an alarm condition. The HVAC and Mechanical teams have been working on the problem, but do not have a solution at this time.

  As Prof. O'Neil told us:

  if you’re in BCAS tomorrow dress warm.

  After Class

  • Project 3: Code Analysis TDD Exercise 55: Project 3 Feedback 6 Score in Brightspace with some feedback, report in feedback branch, file Report5.md

  Announcements

  • Exercise Policy Change You must report any issues with the score or feedback of an exercise by the end of the day of the next class meeting. Scores will not be changed for any exercise after that point.
  • Project 3: Code Analysis TDD Added a column to the due date table.

  • Project 3: Code Analysis TDD Exercise 51: Project 3 Feedback 5 Score in Brightspace, feedback in Report5.md

    The code used to generate the report is the latest commit until the report's generation time. This time is typically within 30 minutes of the due date. Your score on this exercise verifies that:

    • The code compiles and builds
    • The test program runs successfully
    • There is no build directory in the repository

    And that you implemented the required minimum number of rules.

    It does not reflect complexity, formatting, style, or other things that you got some feedback on previously. Follow all guidelines in the project instructions, the overall notes that I posted after each exercise, and your previous individual Project 3 exercise feedback.

  • std::endl Prefer '\n' to std::endl. Students think that std::endl adds a newline, i.e., that:

    is equivalent to:

    However it is not, as it also flushes the output buffer, i.e.,

    Don't flush the output buffer unless you need to.

  • Redirecting an Output Stream

    Testing the output of code to std::cout (standard output) or std::cerr (standard error) is not immediately testable in a unit test. We need to "grab" this output and store it in a std::string so we can verify the result. The way to do this is to redirect the output to a string. The following program is an example of how to do that:

    TestStreamOutput

  Class

  • Notes: Software Refactoring
  • Exercise 52: Software Refactoring I Crossword
  • Exercise 53: Software Refactoring II Crossword
  • HFSD Chapter 10
  • Exercise 54: Team Replace Nested Conditional with Guard Clause Refactoring

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

• Exercise 54: Team Replace Nested Conditional with Guard Clause Refactoring Posted: Nov 12

  The function processOrder() has a calculation to process orders. It has error codes for each restriction, including if the quantity is non-positive, if the order is empty, if the product name is invalid, and if the quantity exceeds the maximum.

  In this exercise, you will perform the refactoring Replace Nested Conditional with Guard Clause and then change the functionality.

  Commit messages must be exactly as given in the instructions.

  Report

  Instead of an upload to Brightspace, fill out this form. Note you can edit it later, so get as much of the form filled out as possible during class time.

  Perform Refactoring

  1. Create a branch named refactor of the original code.
  2. In the branch refactor, perform a Replace Nested Conditional with Guard Clause Refactoring.

  As you make changes, build and run the test program often to ensure you are not changing the code's behavior.

  Commit your changes with the commit message:

  Push as soon as you make the commit.

  Remove a restriction on main

  1. Move to the branch main.

  2. The customer wants to allow empty orders. Change the code, comments, and test to remove the error for an empty order.

     Make sure the program builds and that all tests pass.

     Use the following commit message exactly as given:

     Push as soon as you make the commit.

  Remove a restriction on refactor

  1. Move to the branch refactor.

  2. The customer wants to allow empty orders. Change the code, comments, and test to remove the error for an empty order.

     Make sure the program builds and that all tests pass.

     Use the following commit message exactly as given:

     Push as soon as you make the commit.

• Week 11 Class 21 Thu Nov 07 Posted: Nov 07

  After Class

  • Project 3: Code Analysis TDD Deadline 4 feedback in Exercise 50 and Report4.md.

    My other TA did the initial check and entered the initial comment. I then went over them and gave specific feedback.

    I strongly encourage you to read and follow the feedback very carefully.

  • Project 3: Code Analysis TDD Deadline 3 feedback in Exercise 49 and Report3.md.

  Announcements

  • Project 3: Code Analysis TDD Deadline 2 feedback in Exercise 46 and Report2.md.

    Stop doing the following:

    • Ternaries. They have their place. This is not it.
    • Fake attribute values
    • Changing the header comment (!)
    • Changing the first test case (!!)
    • Changing the CMakePresets.json file (?)
    • Adding multiple blank lines
    • Not indenting correctly
    • Violating the guideline Output of a particular attribute must occur only once in the code
    • Using assertions in CodeAnalysis.cpp
    • Missing space after the keyword if
    • Not refactoring at each commit
  • Project 3: Code Analysis TDD Remember the next deadline

  • Team Exercises

    • Answer the question asked
    • touch, cd, are not Git commands
    • Git push is not a Git command

  Class

  • HFSD Chapter 9
  • Exercise 44: HFSD Chapter 9 Crossword
  • Exercise 47: Git Commit Messages Crossword
  • Notes: Refactoring
  • Exercise 48: Team Rename Method Refactoring

  Unless stated otherwise, all exercises are due by 3 pm on Fri Nov 08

• Exercise 48: Team Rename Method Refactoring Posted: Nov 07

  In this exercise, you will go through a workflow to perform a refactoring. The overall process includes:

  1. Setting up an issue at GitHub
  2. Creating an issue branch
  3. Performing the Rename Method refactoring
  4. Creating a pull request
  5. Accepting the pull request
  6. Closing the issue
  7. Deleting the issue branch (but don't do)

  The following workflow must be followed to receive credit. Use the same commit messages as shown.

  Set Up the Issue

  1. Create An Issue In GitHub, create an issue in your repository for the refactoring. The title of the issue is: Explain what you will do as well as possible for the body of the messages.
  2. Assign Yourself to the Issue Once the issue is created, assign yourself to it so that others know you are working on it.

  Set Up a Branch for the Issue

  1. Create an Issue Branch Instead of working on the branch main, you are going to work on the branch issue_n_ where n is the issue number, e.g., if the issue number is 1 then the branch name is issue1. First, make sure you are in the branch main. Then, create the branch: Branches can be created via GitHub. However, please create this issue via the command line.
  2. You have created a new branch locally, but it does not yet exist at GitHub. To do so, you need to push it to GitHub. When you do so, you will see an error message. Enter the command that it shows you.
  3. Verify at GitHub that your branch exists.

  Perform a Rename Method Refactoring

  Report For your report of the following, keep a list of all the git commands you enter. Keep them in order. Do not put any name, title, etc. For commits, enter the git commit short hash (first 7 characters) on the line after the git commit.

  1. You are going to perform a refactoring. The code must compile, build, and produce exactly the same result at every commit.
  2. Create a new method declaration in the ToDoList.hpp file. This is not a definition, only the declaration. Compile the program and get it to build successfully. Once done, commit using the commit message: Push your changes to GitHub.
  3. Create a new method definition in the ToDoList.cpp file. This method definition will not have any contents and will return a 0. In other words, the shortest/smallest implementation that will get the program to build. Once done, commit using the commit message: Push your changes to GitHub.
  4. Copy the contents of the old method length() definition to the new method size(). Successfully build the program. Once done, commit using the commit message: Push your changes to GitHub.
  5. At this point, both size() and length() do the same thing. Now, change length() (the old method) to call size() (the new method). The definition of length() should only have the call to size(). Note that you must pass along the parameters and handle any return statements. Push your changes to GitHub.
  6. One-by-one, replace any calls of the method length() with a call to method size(). Again, this must be done one call at a time. After each change, compile, build, and run successfully. Commit each time using the git command: Push your changes to GitHub
  7. After all calls to length() are replaced, delete the definition (not declaration) of length() in ToDoList.cpp. Compile, build, and run successfully. Commit using the command: Push your changes to GitHub
  8. Now delete the declaration of length() from ToDoList.hpp. Compile, build, and run successfully. Commit using the command: Push your changes to GitHub.

  At this point, the refactoring is complete.

  Create a Pull Request

  Create a pull request at GitHub. You want to pull from the branch issue1 into the branch main.

  Accept the Pull Request

  Accept the pull request at GitHub. Typically, this would be done by another team member, but in this case, you can accept your pull request.

  Switch to the main branch in your cloned repository and pull the changes. The rename should appear in the code on the main branch.

  Close the Issue

  1. At this point, you have completed the issue and can close it. Do so at GitHub.

  Delete the Branch

  1. The branch issue1 has done its job and is no longer needed. All your commits on this branch are now in the branch main.
  2. We could delete this branch, but do not do so for purposes of this assignment.

• Week 11 Class 20 Tue Nov 05 Posted: Nov 05

  Announcements

  • Project 3: Code Analysis TDD Remember the deadlines

  • Exercise 43: Project 3 Feedback 1

    In the branch feedback I posted a report, Report1.md. I generate this report from your code and commits. It displays the parts of the files of interest, computes complexity, and builds and runs every commit.

    Just a clarification: if you receive a 10 / 10 on this exercise, it does not mean you get 100% on that part of the project. It means that you followed the procedure. See the feedback (in the Grades) if I noticed any other issues.

    If I pointed out issues in the Brightspace feedback, you can fix those in separate commits, using the commit message that starts with "Fix".

    Most of the future due dates changed from midnight to 10 pm. See the project for details.

    General Comments:

    • The build directory must not be in the repository
    • Indentation is a fixed indentation size: 4, 8, 12, 16, … or 8,16,24,…. Even ChatGPT thinks so. Do not indent 4 then 2 spaces. Fix this immediately. And, if you do so in the future, it is a 0 for that exercise and that part of the project.
    • Each rule must have a separate test. Make the test the simplest that you can to test the feature.
    • Keep in mind the rule about a single attribute output, unit.addAttribute(), for every unique attribute.
    • The commit message should not mention the test. In a TDD process, we assume the test with every commit that adds functionality.
    • Follow the exact code formatting and style
    • Perform refactoring as part of the test and implementation of every commit
    • Treat each rule implementation (and its corresponding commit) as the last commit you will make to this repository. There is no "cleanup" stage that is not part of a TDD commit.

    • Think before every commit:

      • ✓ Added a new test to the test file
      • ✓ Added implementation to get that test to pass
      • ✓ All tests still pass
      • ✓ Refactored the code given the refactoring guidelines
      • ✓ Style of the added tests and implementation follow the coding style of the existing code
      • ✓ Did not add any incorrect files. For Project TDD, this means adding no files.

  Class

  • Guide: Issues with Code Coverage
  • Git Commit Messages
  • HFSD Chapter 9

  • Exercise 44: HFSD Chapter 9 Crossword

    We did not complete the material in HFSD Chapter 9, so this crossword will be due after the next class.

  • Exercise 45: Team DIP & Mock Objects II

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

• Exercise 45: Team DIP & Mock Objects II Posted: Nov 05

  If you haven't completed the previous Mock Clock exercise, do so before completing this one.

  A team member created an issue in your repository. You have been asked to add a test for this issue. Go to the Issues for your repository at GitHub and read it.

  Session Testing

  Record In your notes, explain why you cannot practically write a test for this issue without using dependency inversion.

  Session Testing with DIP

  1. Move to the branch dip. Verify that you are on the correct branch.
  2. As you work on this branch, record a list of git commands you entered. Order does not matter, and you don't have to repeat them.
  3. Create a new Clock in the files Issue1Clock.hpp and Issue1Clock.cpp, and a test program in the file Issue1ClockTest.cpp. You will need to add these files so that Git will version control them: Do not commit yet.

  4. The branch dip-cmake has an updated version of CMakeLists.txt that knows about the SessionIssue1Test. In the branch dip, enter the following git command to pull this updated CMakeLists.txt into your code:

  5. Create a minimal test program in SessionIssue1Test.cpp. This body of the main should be assert(false) with a return. Make sure the test builds and runs, but it will fail.
  6. Complete the verification with the test program and the new clock.

  7. Commit your work with the commit message:

  Session Testing with DIP and Mock

  As you work on this branch, record a list of git commands you entered. Order does not matter, and you don't have to repeat them.

  Repeat the Software Testing with DIP, but this time on the branch mock. Note the following:

  • The files Issue1Clock.hpp and Issue1Clock.cpp are not needed
  • The pull is from the branch mock-cmake

  Commit your work with the commit message:

• Git Commit Messages Posted: Nov 05

  The article How to Write a Git Commit Message has guidance on commit messages in general and Git projects specifically. Especially note the 7 rules. As the writeup mentions, these ideas are not new.

  A message with only a subject line is adequate for our projects. The rules that only concern the subject are:

  • Limit the subject line to 50 characters
  • Capitalize the subject line
  • Do not end the subject line with a period
  • Use the imperative mood in the subject line (command or instruction)

  Make sure to use these guidelines as you implement any projects or exercises.

• Week 10 Class 19 Thu Oct 31 Posted: Oct 31

  After Class

  • Exercise 43: Project 3 Feedback 1

    In the branch feedback I posted a report, Report1.md. I generate this report from your code and commits. It displays the parts of the files of interest, computes complexity, and builds and runs every commit.

    Just a clarification: if you receive a 10 / 10 on this exercise, it does not mean you get 100% on that part of the project. It means that you followed the procedure. See the feedback (in the Grades) if I noticed any other issues.

    If I pointed out issues in the Brightspace feedback, you can fix those in separate commits, using the commit message that starts with "Fix".

  • Attribute

  

  For the Attribute assignment, I made a fix to the assignment repository. Your repositories are forks of the assignment repository.

  The fix is to the testRun.sh and testRunEmpty.sh files. When run by themselves, it works fine. But when you use the make test-run and make test-run-empty, it always fails.

  If you created your repository after I made this change, you will have the fix. However, if you created it before the change you will need the fix.

  To get this fix, sync with the fork on GitHub. You will have to do a git pull in your cloned repository to get the changes.

  • gh

    

    All of your Attribute repositories are forks of UACPSC/cpsc-480-se-fall-2024-attribute-Attribute-1 as you can view in GitHub. The GitHub command-line program, gh, and/or git has a default repository for many of its commands. This default is not your repository, but the original UACPSC/cpsc-480-se-fall-2024-attribute-Attribute-1. This is not the behavior that we want.

    To change use the command:

    and select your repository for the default.

  Announcements

  • Renumbering We renumbered a couple of exercises that shared the same number.
  • Guide: Issues with Code Coverage
  • Project 3: Code Analysis TDD

  Class

  • Exercise 41: Attribute

    Use the Refactoring Guidelines from Project 3 to improve the attribute.cpp file. Each improvement must be in a separate commit with a valid commit message. There are two targets for testing to help sure you do not change the behavior of the code: make test-run and make test-run-empty.

    Make sure to run both tests and that the tests pass after any change and especially before the commit.

    Example: attribute-010

    GitHub Classroom invitation link is in Brightspace.

  • HFSD Chapter 8
  • Exercise 39: HFSD Chapter 8 Crossword
  • Exercise 42: Team Mock Clock

  Unless stated otherwise, all exercises are due by 3 pm on Monday, Nov 4.

• Project 3: Code Analysis TDD Posted: Oct 31

  To implement the project below, follow the TDD process. The Brightspace course page has an invitation link to create the GitHub Classroom repository.

  Create your repository (via GitHub classroom) and implement each one of the Rules separately with a single pass through the TDD workflow (red, green, refactor). Each rule (and error message) is implemented in a single commit.

  Due Dates

  The purpose of many class exercises and projects in this class is to practice good workflows of actual, real, 40-hours-a-week software development. Due to time limitations, each part of a project cannot be very long. Treating this as a "race" at the last minute is not part of SE or any good workflow. It tends to produce less-than-optimum software in both external quality, i.e., bugs, and internal quality, i.e., poor design.

  Therefore, the project has progressive due dates regarding the number of rules implemented. Each failure to meet a due date will result in a 10-point reduction in your score out of 100. The following are due dates, not the day you have to work on them, unless you wait until the last day.

  No.	Due Date	Total Rules Implemented	Exercise Feedback
  1	Monday, Nov 4 11:59:59 pm	1	43
  	Stop Wait until I provide feedback on your initial workflow by giving you a score for the corresponding exercise. If you don't see a comment, I have not examined your first commit. If you are waiting to continue, send me an email.
  2	Wednesday, Nov 6 10:00:00 pm	3	46
  3	Thursday, Nov 7 10:00:00 pm	4	49
  4	Friday, Nov 8 10:00:00 pm	5	50
  5	Monday, Nov 11 10:00:00 pm	7	51
  6	Tuesday, Nov 12 10:00:00 pm	8	55
  7	Wednesday, Nov 13 10:00:00 pm	9	56
  8	Thursday, Nov 14 10:00:00 pm	10	59
  9	Friday, Nov 15 10:00:00 pm	11
  	Monday, Nov 18 11:59:59 pm	All rules and all error messages

  Due dates are given for each step. No work will be accepted after the last due date.

  All commits must appear in the repository on GitHub. Commits or code changes in GitHub Codespaces do not count.

  Project

  The input for a source-code static analysis tool can come from multiple sources, including individual files (e.g., main.cpp), directories of source-code files (e.g., src/), source-code archives (e.g., project.tar.gz, file.zip), and standard input (i.e., stdin, e.g., std::cin). In addition, solitary files and source-code archives can include a URL, e.g., https://mlcollard.net/fragment.cpp

  To perform the code analysis, the source code is wrapped in a single XML element with metadata about the source code, including filename, programming language, URL, hash, LOC (lines of code), and timestamp. For the source code:

  the resulting XML is:

  Note: Scroll to see all the attributes.

  The attribute hash is of the source and is a SHA1 160-bit (20 bytes) represented in 40 hex characters, which is what Git uses. The xmlns:code="http://mlcollard.net/code" is not an attribute but an XML namespace declaration, handled automatically by XMLWrapper.

  The general attribute rules are:

  • The order of the attributes in your output must follow the order above.
  • If the value for an attribute is empty, the attribute is not displayed

  The attribute's variety of input sources and program options follows the Rules stated below.

  Assignment

  Implement the following rules following a Test-Driven Development (TDD) approach. Write a test in CodeAnalysisTest.cpp, implement the minimal code necessary to get it working in CodeAnalysis.cpp, refactor/clean up the code to make it clear and logical, and then commit with an appropriate commit message.

  All commits must result in a program that compiles and passes all tests. This means you must successfully compile and pass the test program before a commit. Any commit that does not build will result in a 0 for that step, and every commit will be checked.

  • The code to implement is in the function formatAnalysisXML().
  • Do not change or create tests for the function filenameToLanguage().
  • Do not create any new functions.
  • Using libraries or including files beyond those already defined is unnecessary and strictly forbidden.

  Rules

  The following rules are unordered. Do not refer to them by number.

  • The minimum LOC is 0. If the option loc is non-negative, add the attribute loc.
  • If you cannot figure out the attribute language based on any other rule, use the default language.
  • When the option hash is not empty, use it for the attribute hash.
  • When the source url is not empty, use it for the attribute url.
  • When used, the option url has priority over the source url for the attribute url.
  • The option language has priority over any other way of determining the attribute language.
  • The option filename has priority over any other way of determining the attribute filename.
  • For a non-archive source-code file, the file extension of the disk filename determines the language, e.g., for the disk filename main.cpp, the language is C++. Use the provided function, filenameToLanguage(), to convert from a filename to a language for the attribute language.
  • For a file in a source-code archive, the file extension of the entry filename determines the language, e.g., for the entry filename main.cpp, the language is C++. Use the provided function, filenameToLanguage(), to convert from a filename to a language for the attribute language.
  • For a source-code archive, use the entry filename instead of the disk filename for the attribute filename.
  • For a non-archive source-code file use the disk filename for the attribute filename.
  • For standard input (i.e., std::cin) of non-archive source code, the disk filename is a single dash "-" and the entry filename is the literal string "data". In this case, you must use the option filename for the attribute filename.
  • For standard input (i.e., std::cin) of a source-code archive, the disk filename is a single dash "-". In this case, use the entry filename for the attribute filename.
  • When the timestamp is not empty, use it for the attribute timestamp.

  Error Handling

  All error messages are written to standard error (i.e., std::cerr) on a separate output line, and the function should return an empty string.

  • If the file extension is used to determine the language, and there is no mapping for that language, output the error message “Extension not supported”
  • When the input is from standard input, and a language cannot be determined, output the error message “Using stdin requires a declared language”

  Workflow

  The workflow for implementing one rule:

  1. Add a single new test case for a single specific rule in the test program CodeAnalysisTest.cpp
  2. Successfully compile and build
  3. Run the test program and verify that the test case fails
  4. Add the implementation only for the new test case in the file CodeAnalysis.cpp
  5. Successfully compile and build
  6. Run the test program and verify that all tests pass, including the new test case
  7. Refactor the test and the added code
  8. Successfully compile and build
  9. Run the test program and verify that all tests still pass, including the new test case
  10. Commit with the appropriate commit message

  Refactoring Guidelines

  All implementation should result in code that is as clean and clear as possible. For this case:

  • Output of a particular attribute must occur only once in the code.
  • Ideally, each rule implementation should only require one additional if-statement.
  • Prefer simple conditions over complex conditions.
  • Prefer initialization and if-then over if-then-else.
  • Separate the logic of calculating an attribute value from the output of the attribute value.
  • Initialize variables on declaration instead of declaring and then initializing.
  • Prefer std::string_view to std::string.
  • Instead of comparing strings to "", use the empty() method.

  Evaluation Environment

  The project is built and graded in a Docker container running srcml/codespaces, which is the same environment as GitHub Codespaces for this project. It is based on Ubuntu 22.04 and uses the GCC compiler.

  On macOS, clang is the default compiler and the one you want to use in most cases. This should not cause a problem with this program. However, before you commit, I recommend ensuring your code can build and pass the tests with GCC and the default compiler, clang.

  Add GCC via homebrew:

  brew install gcc
  

  The preset macos-gcc (in the file CMakePresets.json) provides settings to compile with GCC:

  cmake .. --preset macos-gcc
  

  This preset only appears in macOS and not in Linux or Windows.

  To return to using clang:

  cmake .. --fresh
  

  Instead of flipping back and forth in the same build directory, use two build directories, one for clang and one for GCC. Be sure to build and test in both build directories before you commit. Note It might seem like a pain to have two build directories, but it is not uncommon in real software development and is a good skill to have.

  Grading

  Your score will depend on the following:

  • Meeting the deadlines.
  • Following the TDD process. This must be reflected in your commit history, both when commits are made and the commit messages.
  • Successful implementation of the rules.
  • Following the commit message guidelines.
  • Coding style, including use of if-statements. The function logic should be as simple as possible. Pay attention to the coding style criteria given in class.
• Exercise 42: Team Mock Clock Posted: Oct 31

  The following exercise shows multiple ways of building tests for a Session class. The Session class performs activities over a period of time and then issues a report that includes the time period of the session. The session details are not shown here, only the reported session time.

  Each approach is on a different branch:

  • main Session testing without DIP (Dependency Inversion Principle)
  • dip Session testing with DIP
  • mock Session testing with DIP using mock objects

  To see what branch you are on, use the git command:

  To switch to another branch, e.g., dip, use the git command:

  To see what files are on that branch, use the bash command:

  Spend a minute switching among the various branches. Use the git branch to verify what branch you are on. If you look at the files on each branch, you will see common filenames and files that only exist on an individual branch. All of the necessary files already exist on each branch, so no files are added during the exercise.

  Branch main: Session Testing without DIP

  

  1. Build the code and run the 2-second session test. You can use the time command: Record the timing of three runs of the test program, and note the median value. From the time command, use the real time. Compare the timings to others on your team.
  2. The test for the 5-second session in Session5SecondTest.cpp is incomplete. Complete it following the example in Session2SecondTest.cpp. Build the code, get the test case to pass, and run the 5-second session test: Record the timing of three runs of the test program, and note the median value. Compare the timings to others on your team. Commit your code changes with the commit command:
  3. Let's say we would have a 1-hour session test. Record how long you think it would take to run the test. It should be obvious why we will not have a 1-hour session test using this approach.

  Branch dip: Session Testing with DIP

  

  1. Change to the branch dip. Make sure to verify that you are on the correct branch.
  2. View the files Session.hpp, Clock.hpp, Session2Second.cpp, and TwoSecondClock.cpp, and note that instead of the class Session directly using the std::chrono real-time clock, all clock duties have moved to the class Clock. This implies:
     • The class Session now has a dependency on the class Clock
     • This class Clock dependency must be set up when the Session is created
     • The actual clock used is the TwoSecondClock. Build and run the existing test Session2SecondTest. Record the timing of three runs of the test program, and note the median value. Compare the timings to others on your team.
  3. The test for the 5-second session in Session5SecondTest.cpp is incomplete. Complete it following the example in Session2SecondTest.cpp. Build the code, get the test case to pass, and run the 5-second session test: Record the timing of three runs of the test program, and note the median value. Compare the timings to others on your team. Commit your code changes with the commit command:
  4. Now, we can write a practical 1-hour session test. The test for the 1-hour session in Session1HourTest.cpp is incomplete. Complete it following the example in Session2SecondTest.cpp. Build the code, get the test case to pass, and run the 1-hour session test: Record the timing of three runs of the test program, and note the median value. Compare the timings to others on your team. Commit your code changes with the commit command:
  5. Note that this approach to DIP requires a lot of clock classes, one for each timing sequence period.

  Branch mock: Session Testing with Mock Objects

  

  1. Change to the branch mock. Make sure to verify that you are on the correct branch.
  2. Writing all these clocks creates a lot of classes. One workaround is to use a configurable clock class, where each clock object can have a different time period. The provided MockClock does just that. Build and run the Session2SecondTest.
  3. The test for the 5-second session in Session5SecondTest.cpp is incomplete. Complete it following the example in Session2SecondTest.cpp. Build the code, get the test case to pass, and run the 5-second session test: Commit your code changes with the commit command:
  4. The test for the 1-hour session in Session1HourTest.cpp is incomplete. Complete it following the example in Session2SecondTest.cpp. Build the code, get the test case to pass, and run the 1-hour session test: Commit your code changes with the commit command:

• Week 10 Class 18 Tue Oct 29 Posted: Oct 29

  Announcements

  • Exercise 34: AddTest

    • Never include .cpp files. That does not fix the build
    • Do not put function definitions in .hpp files, especially when they already exist in the .cpp file. That breaks the build
    • When someone shows you where to put the test cases, and carefully explains it to you, follow what they say or All of your code will be thrown out

  Class

  • Exercise 38: AddTest II

    Add another test to your add-test-* repository.

    Before you start, accept the pull request to setup your repository for this and future tests. The pull request removes the individual test files. All tests are now only in testAdd.cpp.

    Make sure to pay attention to the feedback from Exercise 34: AddTest. Note that I will not be as lenient on this excercise.

    If you never did this, then you have to do Exercise 34 first.

  • Test Directory Structure Comparison

  • Exercise 37: sortTDD

    Code along in class (or later on) to the sortTDD example. The GitHub Classroom link is in Brightspace.

    The TDD workflow for this code is:

    1. Add a single new test case for a single specific rule in the test program sortTest.cpp
    2. Successfully compile and build
    3. Run the test program and verify that the test case fails (red)
    4. Add the implementation only for the new test case in the file sort.cpp
    5. Successfully compile and build
    6. Run the test program and verify that all tests pass, including the new test case (green)
    7. Refactor the test and the added code
    8. Successfully compile and build
    9. Run the test program and verify that all tests still pass, including the new test case (refactor)
    10. Commit with a commit message about the added functionality

    Class example: sort-tdd-010

    The starting code already had a commit (you won't see this) for the first pass through the TDD workflow:

  • HFSD Chapter 8

  • Exercise 39: HFSD Chapter 8 Crossword

    Delayed until after next class.

  • Exercise 40: Team Code Coverage II

    Finish up the Exercise 36: Team Code Coverage.

    As with almost all Team exercises, you must upload your work by the end of class.

  Unless stated otherwise, all exercises are due by 3 pm on Wed Oct 30

• Week 9 Class 17 Thu Oct 24 Posted: Oct 24

  Announcements

  • Midterm I posted scores and the graded exam in Brightspace Assignments.

    I am solely responsible for grading the midterm. The TAs did assist me with uploading the PDFs and entering the scores into Brightspace.

    If you have any inquiries, feel free to email or visit during my office hours. I do not respond to exam-related queries in the classroom right before or after class.

    Note: In the Final Exam, failure to answer the question in the designated place (Questions 4-9) will result in a score of 0 for that question.

  • Midterm General notes:

    • Planning is not design. Design is software design. And by software design, I mean what classes, methods, source-code file structure, APIs used, etc.
    • Iteration planning is part of requirements
    • Requirements, design (see previous), code, and test are part of every iteration
    • Once we have an iteration plan, we begin the current iteration. During the current iteration we do nothing for future iterations.
    • Iteration plans are revised at the start of every iteration
    • "Good-enough design" is not "good-enough software". "Perfect design" must meet requirements, but then all software must meet requirements no matter what the design.

  • Exercise 31: Makefile

    I generated a report Report.md in your repo for Exercise 31. However, I forgot to commit it.

    Take a look even if you did not get any points off.

    Example report for build-files-010

  • Professional CMake: A Practical Guide by Craig Scott is the best book on CMake for developers. Besides just covering the CMake features, it also has sections in each chapter with good practices and practical advice. One of the best books of its kind. It was a textbook for CPSC 489-010 T: DevOps in Spring 2024.

    Recently, the first 5 chapters were released as free download.

    So take a look for any questions on cmake.

  • LOC

    LOC is a software term for Lines of Code. It is a number. It is not the line numbers, and it is definitely not the code.

  Class

  • Guide: Build Configurations

  • Exercise 33: Build Configurations

    Enter in the same values as I did into the Build Configurations table. Then, save a copy of the web page as a PDF and upload to Brightspace.

  • srcML Testing parser testfile, libsrcml testfile, client testfile

  • HFSD Chapter 8

  • Exercise 37: sortTDD

    NOTE We did not get to this in class. We will do this next class.

    Code along in class (or later on) to the sortTDD example. The GitHub Classroom link is in Brightspace.

    The TDD workflow for this code is:

    1. Add a single new test case for a single specific rule in the test program sortTest.cpp
    2. Successfully compile and build
    3. Run the test program and verify that the test case fails (red)
    4. Add the implementation only for the new test case in the file sort.cpp
    5. Successfully compile and build
    6. Run the test program and verify that all tests pass, including the new test case (green)
    7. Refactor the test and the added code
    8. Successfully compile and build
    9. Run the test program and verify that all tests still pass, including the new test case (refactor)
    10. Commit with a commit message about the added functionality

    Class example: sort-tdd-010

    The starting code already had a commit (you won't see this) for the first pass through the TDD workflow:

  • Exercise 36: Team Code Coverage

    NOTE Nothing to turn in for this. Your attendance will count for this.

    • If more than one person is going to commit for the exercise, one person cannot commit twice in a row.
    • The assignment is setup for GitHub Codespaces. You are welcome to try on macOS or in Linux (including WSL), but there is no guarantee that it will be setup properly without installing additional packages. If you have an issue on your local machine, turn to GitHub Codespaces.

  Unless stated otherwise, all exercises are due by 3 pm on Fri Oct 25

• Exercise 36: Team Code Coverage Posted: Oct 24

  Setup

  First, as a team, review the test cases and the code and determine if you got 100% code coverage or not and if any of the test cases are not unique and cover the same code. Do not spend much time on this, as you pretty much said so with your previous exercise result.

  Second, we are going to use cmake to generate a Makefile instead of creating one directly. That is going to make it easier for changing the build. To convert, go to GitHub and accept the pull request. Once done, all of you will have to do a git pull to get these changes into your code.

  To prepare for the build:

  1. Create a subdirectory build
  2. Change to the build directory
  3. Run cmake from the build directory referencing the CMakeLists.txt in the parent directory.
  4. CMake will generate a Makefile. You can then run that.

  You will build and run the program from the build directory. You will edit the files of the project in the parent directory.

  The following assumes you are in your build directory.

  Generate a Code Coverage Report

  The tool gcov can, with code compiled with the appropriate flags, produce a report that shows precisely how many times each line of code is called in a run of the program, and from that, we can get code coverage. So, we want to run the gcov program with our test program and see the code coverage of the function dotProduct() in the file dotProduct.cpp .

  Note: Once you run cmake referencing the source directory, i.e., cmake .., it remembers the source directory and you can then just reference the build directory, i.e., cmake .. This is nice because your build directory might not be a subdirectory of your source, and the commands still work. However, you do have to reference the source directory, i.e., cmake .., the first time.

  To produce the gcov report, do the following:

  1. Clean your build
  2. Run cmake to add the option --coverage to the flags provided to the compiler: The CMake variable CMAKE_CXX_FLAGS is the option passed to the compiler.
  3. Run cmake so that make will output the commands it is executing (instead of hiding them from you): The CMake variable CMAKE_MAKE_VERBOSE controls whether make will show the commands it uses to build the program. Note: ninja will not work here. This is one exception to ninja being a drop-in replacement for make. Note that cmake caches its settings. They are in the file CMakeCache.txt. This is why the previous CMAKE_CXX_FLAGS setting still holds.
  4. Build the program and observe the commands. You should see the flag --coverage. Record in your notes the command line for the compile up to the first argument after the --coverage.
  5. Turn off CMAKE_VERBOSE_MAKEFILE as it is annoying getting that much output with every make command:
     
  6. Run the test program. Do this only once.
  7. This run of the program should produce a file with the extension .gcda. The one you are interested in is dotProduct.cpp.gcda. CMake has an extensive directory structure for the object code, and the .gcda file is with the object code.
  8. Now that you have found the dotProduct.cpp.gcda we must run it through gcov to get the report. Carefully view the output of the program to find where dotProduct.cpp is and the line that starts with Lines executed:. You can safely rerun this command. You will then see how much code coverage your test program produced. Record in your notes this percentage. You should find a file dotProduct.cpp.gcov in your build directory.
  9. If you want to rerun the test program, you must delete the .gcda and .gcno files. A command to do this is (I strongly recommend copy and paste):

  Code Coverage Results

  View the file dotProduct.cpp.gcov in an editor. You will see lines such as:

  Columns are separated by ":". Column 2 is the line number, and Column 3 is the source code. Column 1 is the number of times that line of code was executed, or a - if it is not an executable line (i.e., comment or whitespace). If you see a #####, that means that that line of code was never executed. So, therefore, you do not have 100% code coverage.

  Automation

  Correctly rerunning all of the above commands is repetitive and open to mistakes. So let's automate it by taking the above lines and making them targets in our CMake. Add the following code at the end of your CMakeLists.txt file.

  Commit this change to the repository with the commit message:

  Any time you make changes to the cmake file CMakeLists.txt, rerun cmake:

  Now, the sequence to run the coverage for the tests is the following:

  Improving the Code Coverage

  To fix this problem, you will have to change the file dotProduct.cpp. Look carefully at the lines of code that were not executed, any conditional statements that had to be true to reach that unexecuted line, and your test cases.

  The change to dotProduct.cpp is to rearrange some lines. Make this change, build the program, run the test program, and make sure the tests still pass. If the tests all pass, commit the change to the file dotProduct.cpp:

  Now, rerun the coverage using our new make targets. Continue making changes to your test cases until you get 100% code coverage. Record in your notes any additional test cases.

  Further Automation

  This sequence is more complex than it needs to be:

  If the build file would run the target coverage-clean before every test, then we would not have to remember to do so. Any knowledge we can put into the build file makes everything easier to repeat. So change the test target the CMakeLists.txt so that it DEPENDS on the target coverage-clean:

  Since CMakeLists.txt changed, rerun cmake.

  Now, the new sequence of commands is:

  An even further automation is to automatically run the target test whenever you run the target coverage-report. So running a new report is one command. See if you can get this working.

  Commit these automation changes to the repository:

  Test Cases

  Using the coverage, find the percentage of the code in dotProduct.cpp covered by each test case. Do this by commenting out all but one test case at a time and then running a coverage report. Record in your notes the new percentages and how they compare to what you manually calculated.

• Week 9 Class 16 Tue Oct 22 Posted: Oct 22

  Announcements

  • Project 2 Scores in Brightspace, feedback in the file Feedback.md in your GitHub repository.

  • Exercise 31: Makefile

    • All text files (including source code and build files) should end with a newline. If you don’t in the future, it is a 0.
    • Do not add generated files to the repository. Use the git commands that I show you, and verify at GitHub what has occurred.
    • Do not just enter code or build instructions. Verify that your changes work. For example, run make after every change before you commit.
    • Use 1 tab, not multiple tabs

    If you did this exercise, but received less than a 9/10, I will allow you to redo it. Email me for instructions.

  Class

  • Exercise 32: HFSD Chapter 7 Crossword

  • Make

    build-files-010

    To switch to the commit with the Makefile:

    To return to the head of the main branch:

  • Make prerequisite graph for srcComplexity:

    

  • Notes: Build Files

    • How many GCC optimization levels are there?
    • MSVC optimizations /O options (Optimize code)

  • CMake

    build-files-010

    To switch to the commit with CMakeLists.txt:

    Release build:

    Debug build:

    To return to the head of the main branch:

  • Guide: Build Configurations

  • Exercise 33: Build Configurations

    Enter in the same values as I did into the Build Configurations table. Then, save a copy of the web page as a PDF and upload to Brightspace.

    Note: We did not get to this, so this is delayed until next class meeting.

  • Guide: assert() and Unit Testing

    add-test-010

    A GitHub Classroom link for AddTest is on Brightspace.

  • Exercise 34: AddTest

    Fix the code so that both tests pass. Make sure to commit this separately.

    Then, add another single unit test following the style and formatting of the previous unit tests.

    Make sure it passes all the tests before you commit.

    A GitHub Classroom link for addTest is on Brightspace.

  • Exercise 35: Team Assert Tests

    vector-angle-010

  Unless stated otherwise, all exercises are due by 3 pm on Wed Oct 23

• Exercise 35: Team Assert Tests Posted: Oct 22

  The project, Vector Angle, calculates the degree angle between two vectors. It uses the function dotProduct(). It also includes a test program dotProductTest.cpp.

  As you recall, white-box testing is testing (creating test cases) that knows the structure of the code because it knows the implementation. The test program dotProductTest.cpp includes a single test case using a separate block and an assert().

  Your assignment is to add test cases to the file dotProductTest.cpp and get the tests to run successfully.

  The repository for this assignment is a GitHub Classroom Group Repository. That means there is one repo per team. Have one person create the Team in GitHub Classroom; the rest can join afterward.

  I assume you are using GitHub Codespaces for the rest of this. If you are not, you must clone the repository locally.

  First, build the program:

  Then, run the program:

  The test program is a separate executable, dotProductTest. To run the test program, there is a target, test. So run the test program:

  For this assignment, add tests so that when the complete test program is run, all of the code in dotProduct() is run at least once. This would be 100% code coverage.

  The workflow is:

  • Pull commits so that you start with the most recent version of the files.
  • Add a test case to dotProductTest.cpp that executes at least one line of code that was not executed using the previous test cases.
  • Build the program and deal with any syntax errors.
  • Run the test program and see if it passes. If it does not, then your test case is likely incorrect.
  • Once all tests pass, commit the change using the appropriate commit message.
  • Push the commit and verify that the new test case appears on GitHub.

  Keep in mind the following:

  • Each commit can only add one test
  • The commit message must be: "Add test …" where "…" is filled in appropriately. For the first test case already in the test program, the commit was:
  • No extra test cases are allowed. Do not add a test case covering the same code as another test case.
  • Follow exactly the programming style of the first test case. This includes indentation, formatting, use of whitespace, and blank lines.
  • You will have to push, i.e., git push for the other team members to see your test case.

  I encourage as many team members as possible to commit a test case. If using GitHub Codespaces, each team member has their own codespace. After a team member has entered a test case, the rest can use a git pull.

  Add test cases one at a time to prevent merge issues.

  Each team member must submit notes, including for each test case:

  • Parameter values used along with the expected answer
  • Lines of code each test case individually covers. This would be in the function dotProduct() and does not include empty lines or comment lines.
  • The percentage achieved of the total lines of code in the function dotProduct() by this test case

  The notes and commits of each team member are due by the end of the class, along with the test cases. Your score is based on the notes and commits in the team repository.

• Post Midterm Posted: Oct 18

  Current Assignments All exercises due by 3 pm on Monday, Oct 21

  • Make (for reference)

    build-files-010

    • GNU Make
    • Make Rule Introduction What a rule looks like
    • Special Note: recipes are indented using a tab character, not spaces. Using spaces (or an editor that expands tabs to spaces) will result in an invalid Makefile.
    • Automatic Variables including $@, $<, and $^
    • NMake Microsoft's version of Make
    • srcML Playground Generate new srcML of source code, input format for srccomplexity

    • Tab indent with a Makefile in Visual Code

      You can use the Command Palette (View > Command Palette) and type Convert Indentation to Tabs and hit Enter.

  • Exercise 31: Makefile

    Code along and make the same commits with the same commit messages as I do in class.

    I suggest you use GitHub Codespaces as all necessary packages are installed.

  • Exercise 29: Make Crossword
  • Exercise 30: HFSD Chapter 6.5 Crossword

• Week 8 Class 15 Thu Oct 17 Posted: Oct 17

  Midterm Exam In our regular classroom and at our regular time.

  I am still under COVID-19 isolation, so Mr. Kyle Rossi and Ms. Afia Asante will proctor the exam. I do not foresee any issues, but I will be in contact with Mr. Ross and Ms. Asante during the exam time.

  Note that you only have class time 12:15 - 1:30 pm and no additional time to complete the exam.

  Announcements

  • Project 2 Feedback on your calculations is in Brightspace. This is not the entire grade or feedback that we will provide later. If your feedback was that the "Calculations are not correct", I strongly suggest that you figure out what is wrong before the Midterm Exam. If you exceed the iteration capacity, you must know that is not allowed.

  • Office Hours Cancelled today.

  Current Assignments All exercises due by 3 pm on Monday, Oct 21

  • Make (for reference)

    build-files-010

    • GNU Make
    • Make Rule Introduction What a rule looks like
    • Special Note: recipes are indented using a tab character, not spaces. Using spaces (or an editor that expands tabs to spaces) will result in an invalid Makefile.
    • Automatic Variables including $@, $<, and $^
    • NMake Microsoft's version of Make
    • srcML Playground Generate new srcML of source code, input format for srccomplexity

  • Exercise 31: Makefile

    Code along and make the same commits with the same commit messages as I do in class.

    I suggest you use GitHub Codespaces as all necessary packages are installed.

  • Exercise 29: Make Crossword
  • Exercise 30: HFSD Chapter 6.5 Crossword

• Week 8 Class 15 Tue Oct 15 Posted: Oct 15

  After Class

  • Project 2 Feedback on your calculations is in Brightspace. This is not the entire grade or feedback that we will provide later. If your feedback was that the "Calculations are not correct", I strongly suggest that you figure out what is wrong before the Midterm Exam. If you exceed the iteration capacity, you must know that is not allowed.

  • Tab indent with a Makefile in Visual Code

    You can use the Command Palette (View > Command Palette) and type Convert Indentation to Tabs and hit Enter.

  Special Announcement Tuesday's Class

  I have COVID and unable to be on campus for Tuesday, Oct 15:

  • Class will be online in Teams
  • Office Hours are online in Teams. Contact me there at collard@uakron.edu

  Our class starts are 12:15 pm as typical, but the Team's meeting starts at 12 pm as Team's has a limitation to selecting non-half-hour start and end times.

  Announcements

  • Mr. Kyle Rossi A public thanks to my RA for covering class last week.
  • Last Week I attended the 40th ICSME (International Conference on Software Maintenance & Evolution) in Flagstaff, Arizona. We took an academic family picture (which wasn't as large as this one. We had social events. We had a keynote from Denae Ford, one of the editors of Equity, Diversity, and Inclusion in Software Engineering. But the real work was that I conducted (along with my colleagues) a srcML workshop. A student presented our paper. And the MIP (Most Influential Paper), the paper from the same conference 10 years ago that had the most impact on the field, used srcML and, during their talk, specifically mentioned srcML
  • eduroam

  • Project 2 Keep in mind the following:

    • Each plan includes all user stories
    • Carefully check your calculations, including the numbers you are using
    • The unit of granularity for an iteration plan is an iteration, not day-by-day
    • Do not assign work to each developer
  • Project 2 Grading I will post some type of preliminary feedback on your plans by end-of-day on Wednesday. See the "After Class" for details.

  • Exercise 23: Project 1 "Fix spelling of "calendar": I posted scores and some feedback for the optional exercise, 23. I also added those to your Project 1 score.

    A large number of you did not do this exercise. If so, you missed an opportunity to improve your Project 1 grade by a whole letter grade by not completing an optional exercise. The exercise covered a crucial git workflow for software development and engineering. essential to software development and engineering.

  • Midterm Exam

  Class

  • Make

    build-files-010

    • GNU Make
    • Make Rule Introduction What a rule looks like
    • Special Note: recipes are indented using a tab character, not spaces. Using spaces (or an editor that expands tabs to spaces) will result in an invalid Makefile.
    • Automatic Variables including $@, $<, and $^
    • NMake Microsoft's version of Make
    • srcML Playground Generate new srcML of source code, input format for srccomplexity

  • Exercise 31: Makefile

    Code along and make the same commits with the same commit messages as I do in class.

    I suggest you use GitHub Codespaces as all necessary packages are installed.

  • Exercise 29: Make Crossword
  • Exercise 30: HFSD Chapter 6.5 Crossword

  All exercises due by 3 pm on Monday, Oct 21

• Week 7 Class 14 Thu Oct 10 Posted: Oct 10

  Special Announcement Tuesday's Class

  I have COVID and unable to be on campus for Tuesday, Oct 15:

  • Class will be online in Teams
  • Office Hours are online in Teams. Contact me there at collard@uakron.edu

  Announcements

  • Exercise 27: Team Use Case Diagram

    If you received points off due to using "System" or your app as an actor (score was 7/10), I will let you correct the diagram to regain those points.

    You have until 3 pm on Friday, Oct 11. Submission is reopen for that purpose.

  • Dr. Collard: Out of Town

    Dr. Collard is in Flagstaff, Arizona, this week for 2024 ICSME. Due to that, he cancelled his Office and Advising Hours. He is available via email.

    Mr. Kyle Rossi is teaching class this week.

  • Project 2 Due Tuesday, Oct 15 at 11:59:59 pm
  • Midterm Exam Thursday, October 17

  Class

  • HFSD Chapter 7

  • Exercise 28: Team Use Cases

    We covered the UML Use Case diagram in the Use Cases notes. We also talked about the written form of use cases, from casual to fully dressed, and even had a use case example in Markdown.

    In your teams, take the use cases from your diagram and write full use case text. This includes any fields of the fully dressed that apply. Each Team Member must write at least one different use case. If you do not have enough on the diagram, convert another User Story to a Use Case.

    By the end of the class period, upload to Brightspace a PDF of the text, or a photo of your hand-written text.

• Week 7 Class 13 Tue Oct 08 Posted: Oct 08

  After Class

  • Exercise 27: Team Use Case Diagram

    If you received points off due to using "System" or your app as an actor (score was 7/10), I will let you correct the diagram to regain those points.

    You have until 3 pm on Friday, Oct 11. Submission is reopen for that purpose.

  Announcements

  • Dr. Collard: Out of Town

    Dr. Collard is in Flagstaff, Arizona, for 2024 ICSME. He cancelled his Office and Advising Hours this week. He is available via email.

    Mr. Kyle Rossi is teaching class this week.

  • Exercise 23: Project 1 "Fix spelling of "calendar" Due Today, Oct 8 at 11:59:59 pm
  • Project 2 Due Tuesday, Oct 15 at 11:59:59 pm
  • Midterm Exam Thursday, October 17

  Class

  • Notes: Use Cases
  • HFSD Chapter 7

  • Exercise 27: Team Use Case Diagram

    Create a Use Case Diagram for your project. Use the user stories as use cases. Select up to 10 of your user stories. You may have to cut down the title of a user story for the use case.

    Use yuml.me to draw the diagram.

    Each member of the team must either create their own diagram at yuml.me, or draw a diagram on paper.

    By the end of the class period, upload to Brightspace a PDF of the diagram, or a photo of your hand-drawn diagram.

• Week 6 Class 12 Thu Oct 03 Posted: Oct 03

  Announcements

  • Class Meetings Tuesday, Oct 8 and Thursday, Oct 10

    I will be in Flagstaff, Arizona, the week of Oct 7 - 11 for the 2024 ICSME (International Conference on Software Maintenance & Evolution). In addition to a paper at the conference, we are holding a srcML Meeting, which is required as part of our NSF grant.

    Although I will be away, you will still have class. My RA, Mr. Kyle Rossi, is presenting, and there will be team exercises, with Mr. Rossi assisted by my TA Ms. Afia Assante.

    My Office and Advising Hours are canceled on those days.

  • Post Page The main course page is getting quite long. A reminder that the title of each post is a link to a separate page of that post.

  • Iteration Plans

    Do not leave space in an iteration because:

    • Just in case we underestimated
    • We spread out our user stories across all our iterations
    • It is our first iteration, and we are still learning
    • There may be unforeseen technical challenges that require additional time
    • The team may need to accommodate unexpected urgent tasks or bug fixes
    • To allow for thorough testing and quality assurance of the completed user stories
    • In case there are dependencies on external teams or third-party services that cause delays
    • To allocate time for knowledge sharing and skill development within the team

    There is only one reason for having space left in an iteration: there is not another user story that would fit. If you use any of the above reasons to explain your iterations, I will deduct points.

  • Project 2: Iteration Plan

    Each student must get their own priorities. Do not reuse the ones from the Team Exercises.

  • Midterm Exam
  • Version Control We have only covered a high-level view of version control. During the rest of the semester, we will cover it in much more detail as part of dedicated notes and the overall workflow.

  Class

  • Demo: diff and patch on the Linux kernel

    • kernel
    • Disk Usage: du -hs *
    • Apply patch: patch -p 1 < ../patch-6.11

  • Exercise 23: Project 1 "Fix spelling of "calendar"

    requirements-report-example010

  • HFSD 6.5

  • Make

    build-files-010

    • GNU Make
    • Make Rule Introduction What a rule looks like
    • Special Note: recipes are indented using a tab character, not spaces. Using spaces (or an editor that expands tabs to spaces) will result in an invalid Makefile.
    • Automatic Variables including $@, $<, and $^
    • NMake Microsoft's version of Make
    • srcML Playground Generate new srcML of source code, input format for srccomplexity

  • Exercise 27: Makefile

    Code along and make the same commits with the same commit messages as I do in class.

    I suggest you use GitHub Codespaces as all necessary packages are installed. </del>

  • Exercise 26: Team Iteration II

  Unless stated otherwise, all exercises are due by 3 pm on Fri Oct 04

• Midterm Exam Posted: Oct 03

  Note: I removed Chapter 6.5, cmake, and make from the Midterm. It will be on the Final Exam instead.

  The Midterm Exam is Thursday, October 17, during our regular class time and classroom. It covers Chapters 1 - 6 6.5 of the Head First Software Development book, plus notes and in-class examples.

  • Big Bang approach to development - description, the path it takes, and disadvantages
  • Iterative approach to development - description, the path it takes, and advantages
  • Role of the customer/client
  • User Stories - all parts, description, creation, valid user story titles
  • Use Case - Diagram and text, differences with User Stories
  • Estimates and the Estimation Process, including all details of planning poker
  • Iteration and deadline planning
  • Utopian vs. Real-World days
  • Velocity - description, standard rate, what does it mean if velocity is higher or lower
  • Big Board - basics of what it shows and how developers use it
  • Good-enough design, SRP, DRY
  • Version control - jobs that it does, commit messages, branches (specific git information not on this midterm)
  • Role and importance of build artifacts (code, configuration, tools), the general purpose of make and cmake; Given a Makefile, what would happen with specific targets.

  The exam has various problem types, including short answers, definitions, comparisons, creation of user stories, and planning. The question may require you to:

  • Explain a process or terminology of a process
  • Answer specific questions about parts of the process. E.g., "Explain why the recommendation is to come up with user stories whose estimates are 15 or less."
  • Explain what process and activities you would follow for a particular scenario

  It is a good idea to review the "Dumb Questions" and the answers.

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

  A calculator is not needed for any required math and, therefore, not permitted.

• Exercise 26: Team Iteration II Posted: Oct 03

  The first iteration ended. One of the user stories had an unexpected task, and it was large enough to delay the completion of that user story. Rewrite the first iteration to remove that user story.

  Now, design a second iteration

  Use the principles in the book to decide which of the remaining user stories belong in the second iteration.

  Individually, each team member will turn in to Brightspace notes with the following:

  • Details of the calculation of the capacity of the iteration, i.e., how many days of work can be accomplished
  • Set of user stories in the revised first iteration with title, estimate, and priority
  • Set of user stories in the second iteration with title, estimate, and priority
  • Any observations

  Do not assume any dependencies between user stories.

  The notes are due by the end of class. They can be a PDF (print to file from a computing device) or a JPG (picture taken via phone).

  If you finish early, work on the estimates for your user stories. All user stories will require estimates for Project 2.

• Week 6 Class 11 Tue Oct 01 Posted: Oct 01

  Announcements

  • Class Meetings Tuesday, Oct 8 and Thursday, Oct 10

    I will be in Flagstaff, Arizona, the week of Oct 7 - 11 for the 2024 ICSME (International Conference on Software Maintenance & Evolution). In addition to a paper at the conference, we are holding a srcML Meeting, which is required as part of our NSF grant.

    Although I will be away, you will still have class. My RA, Mr. Kyle Rossi, will present, and there will be team exercises, with Mr. Rossi assisted by my TA Ms. Afia Assante.

    My Office and Advising Hours are canceled on those days.

  • Project 1 Project 1 scores are in Brightspace. The feedback is in two parts in your Project 1 repository:

    • Feedback.md
    • Corrected.md Your report with edits. This does not include fixes to what was found in Feedback.md.

    General Feedback:

    • The main process for creating estimates is planning poker. It should have been described and the procedure for using it explained in as much detail as possible. There are variations on planning poker, so the card values and what they mean should have been clearly stated.
    • I have stated multiple times that user stories form a set and are not an ordered list. Numbering the user stories is treating them as an ordered list. The set of user stories will change over time. The priorities and estimates will change over time. So any kind of ordering is temporary at best.
    • Misspelling user domain terms not only adds complications but also demonstrates a lack of respect for the customer.
    • Besides misspellings, missing words, etc., the main issue with the writing was the use of passive voice, e.g., "Five estimates (subject) have been created (verb)". Use active voice instead, e.g., "We (subject) created (verb) five estimates (object)".

  • Project 2: Iteration Plan

  Class

  • Exercise 23: Project 1 "Fix spelling of "calendar"

    requirements-report-example010

  • Notes: Version Control

    • kernel
    • Disk Usage:
    • Apply patch:
  • Exercise 22: Version Control Overview Crossword I
  • Exercise 24: Version Control Overview Crossword II
  • HFSD Chapter 6.5
  • Exercise 25: Team Iteration

  Unless stated otherwise, all exercises are due by 3 pm on Wed Oct 02

• Exercise 23: Project 1 "Fix spelling of "calendar" Posted: Oct 01

  This exercise is optional. However, completing this exercise will add points to your Project 1 score.

  The exercise is due by Tuesday, Oct 8 at 11:59:59 pm EDT.

  In your repository for the Requirements Report is the file Corrected.md. This is an edited version of what you submitted with fixes and improvements to the writing.

  To see the difference between these two files, you can use the diff command:

  The diff utility is line-oriented. Since many of your lines are quite long (the lines are wrapped when you view them), this may be difficult to read. You can also use the wdiff command:

  The codespace for Project 1 has diff and wdiff installed. You will have to start a new codespace to use wdiff. If you want to use wdiff outside of a codespace, install on WSL/Linux apt-get update; apt-get install wdiff, and on macOS brew install wdiff.

  Your workflow must be the following:

  1. Examine the remaining differences between your original report and the corrected one using diff or wdiff.
  2. Select one individual correction
  3. Make the correction
  4. Commit the correction using an appropriate commit message
  5. Push the commit to GitHub
  6. Verify at GitHub that the commit is there and the correction is made

  Each correction must be a contiguous change. That means that each commit only contains one correction. Practically, this means that each correction/commit will be on a single line.

  To get credit, your resulting Requirements.md file must be exactly the same as the Corrected.md file. You will reach this stage when diff shows no differences.

  The git commit messages must be in the proper form, such as:

  • Fix spelling in story title
  • Fix spelling of "calendar"
  • Capitalize story title
  • Simplify description
  • Fix spacing in description
  • Add missing article in story title
  • Add missing article in general process
  • Simplify sentence in user story title

  The commit messages must following good git commit message guidelines:

  • Use the imperative mood in the subject line, e.g., Fix, not Fixed, Fixing
  • Capitalize the subject line, e.g., Fix, not fix
  • Do not end the subject line with a period, e.g., Fix spelling of "calendar", not Fix spelling of "calendar".

  The score on this exercise will be 0 if the commit messages do not follow the above guidelines, or there is no effort to use an appropriate commit message.

  Note:

  There will be a lot of commits, so you want to be efficient creating them. After you do the first few corrections, you can push to GitHub and verify at GitHub periodically and not every time. And, to save time with entering commands, bring up previous commands in a shell using the up arrow ⇧ or Ctrl + P, and edit the git commit messages if necessary.

• Project 2: Iteration Plan Posted: Oct 01

  Project 2 is due on Tuesday, Oct 15 at 11:59:59 pm. A GitHub Classroom invitation link is on the Brightspace course page.

  For Project 2, take all the user stories from Project 1 and create a series of iteration plans.

  Use the examples in the book to show which parts of the user story you should show in your iteration plan (e.g., do not restate descriptions in the plans). Also, clearly state the entire new iteration plan for each plan, not just the changes. However, make sure to thoroughly discuss what the change was and what effect it had.

  This is an individual project. Each member of a team has different user-story priorities. To get individual priorities for Project 2, select the number of user stories:

  User Stories:
  

  Note: You may get a warning from your browser that the information is not secure. You can safely ignore that.

  Put these in the Priority field in the order in which you listed the user stories. In the report, do not discuss how you generated your report's priorities, i.e., pretend that the customer gave them.

  The following plans may require you to add additional user stories. This violates our rule that only the development team can create estimates. However, as part of the exercise, put in an estimate.

  Each plan is a point in time. For each plan, show the entire estimation iteration plan, including the iterations already completed.

  Plan	Events
  1	Create an initial iteration plan: 2 Weeks (14 calendar days) iteration, 2 developers, 0.6 velocity
  2	The customer adds two new user stories of the highest priority at the end of the first iteration. For the two new user stories, one is a new feature, and one is an emergency. Create a non-trivial estimate (i.e., an estimate that makes the planning interesting) for these new user stories.
  3	A user story with a non-trivial estimate takes twice as long. Assume this occurred right before the last iteration.
  4	At the beginning of the last iteration of your current plan, the other developer leaves for another project, and it is up to you to finish the project.

  After the plans, create a section with all of your user stories, including their titles, descriptions, estimates, and priorities. You will need estimates for all of your user stories.

  Regarding the format, GitHub Codespaces, checkmd, and a Final Check with an asciinema session, all of those requirements of Project 1 are also in effect for Project 2.

  Submit the URL via this form: Project 2

• Exercise 25: Team Iteration Posted: Oct 01

  As a team, create the first iteration.

  Ideally, we would have enough Team Meeting time to estimate all user stories using Planning Poker. However, we do not and almost all teams only have enough user stories for trivial iteration planning. To make up for this, I am providing estimates for the rest of your user stories. Enter the following:

  Current Maximum User Story Estimate: 2 3 5 8 13 20 40 100
  Missing User Story Estimates:
  

  Note: You may get a warning from your browser that the information is not secure. You can safely ignore that.

  Add these estimates to your user story cards.

  The other missing item are the priorities. These come from the customer. To get priorities, select the number of user stories:

  User Stories:
  

  Add these priorities to your user stories.

  You have 1 developer and a one-month iteration with a 70% velocity.

  Use the principles in the book to decide which user stories belong in the first iteration.

  Individually, each team member will turn in to Brightspace notes with the following:

  • Details of the calculation of the capacity of the iteration, i.e., how many days of work can be accomplished
  • Set of user stories in the first iteration with title, estimate, and priority
  • Any observations

  Do not assume any dependencies between user stories.

  The notes are due by the end of class. They can be a PDF (print to file from a computing device) or a JPG (picture taken via phone).

  If you finish early, use planning poker to work on more estimates for your user stories.

• Week 5 Class 10 Thu Sep 26 Posted: Sep 26

  Announcements:

  • Tasks do not have names as titles. They are numbered.
  • Tasks have a (numbered) title, a description, and an (eventual) estimate. It is essential in software development to use proper terminology as much as possible.
  • Only estimates obtained by a team consensus using a planning poker process will be put on tasks (just like with user stories).
  • Tasks are not the process a user would go through. They are what the developer would go through. They are parts of the implementation of the code.
  • Tasks should be brief. For one thing, they need to fit on a post-it note. Secondly, that extra detail does not help; you would never have enough detail.

  Class

  • Exercise 20: HFSD Chapter 5 Crossword
  • HFSD Chapter 6
  • Notes: Version Control
    • hello.cpp
    • iostream.patch
    • kernel.org
  • Exercise 21: Team Tasks II
  • Exercise 22: Version Control Overview 1 Crossword Due after the next class meeting

  Unless stated otherwise, all exercises are due by 3 pm on Fri Sep 27

• Exercise 21: Team Tasks II Posted: Sep 26

  As a team, take a user story that has an estimate, and create the tasks for that user story. Then, create the estimate for each task by playing planning poker using the procedure described on pages 48-49 of the book. Go through the estimation process at least one time.

  When the team reaches a consensus for the estimate, place the estimate at the bottom of the task, e.g., "Estimate: 1 day" or "Estimate: 3 days".

  Individually, each team member will turn in to Brightspace individual notes that include for each round of planning poker:

  • Title of the user story, task title, and description of the task
  • Any questions on or confusions with the user story/task
  • Any assumptions that you made
  • Any interesting assumptions that other team members made
  • The spread of estimates, indicating which one is yours
  • The final estimate, which is a team consensus (if the team was able to reach one in this round)

  If the team cannot reach a consensus, table that task and go on to another one.

  The notes are due by the end of class. They can be a PDF (print to file from a computing device) or a JPG (picture taken via phone). The notes are for today only. Do not start with the notes from the previous team meeting.

  The more you work with the user stories, the more you will find improvements to them. Be sure to make those improvements.

• Week 5 Class 9 Tue Sep 24 Posted: Sep 24

  Announcements:

  • Published - Feedback Read I spend time giving feedback and grades on the Team Exercises. This may be comments on current user stories (titles, etc.), assumptions, the planning poker procedure, etc. However, 50% of students never look at the feedback and continue to make the same mistakes on the exercises. There are even entire teams where no member looked at the feedback from the last team meeting.

    One of the main topics of this course is processes that lead to successful and predictable outcomes. For exercises, this involves:

    1. Requirements: Figuring out what is needed or required
    2. Implementation: Performing the exercises
    3. Validation: Checking the outcome, i.e., viewing feedback
    4. Return to 1

  Class

  • HFSD Chapter 4
  • Exercise 17: HFSD Chapter 4 Crossword
  • HFSD Chapter 5
  • Exercise 19: Team Tasks

  Unless stated otherwise, all exercises are due by 3 pm on Wed Sep 25

• Exercise 19: Team Tasks Posted: Sep 24

  As a team, take a user story that has an estimate, and create the tasks for that user story. Then, create the estimate for each task by playing planning poker using the procedure described on pages 48-49 of the book. Go through the estimation process at least one time.

  When the team reaches a consensus for the estimate, place the estimate at the bottom of the task, e.g., "Estimate: 1 day" or "Estimate: 3 days".

  Individually, each team member will turn in to Brightspace individual notes that include for each round of planning poker:

  • Title of the user story and task
  • Any questions on or confusions with the user story/task
  • Any assumptions that you made
  • Any interesting assumptions that other team members made
  • The spread of estimates, indicating which one is yours
  • The final estimate, which is a team consensus (if the team was able to reach one in this round)

  If the team cannot reach a consensus, table that task and go on to another one.

  The notes are due by the end of class. They can be a PDF (print to file from a computing device) or a JPG (picture taken via phone). The notes are for today only. Do not start with the notes from the previous team meeting.

  The more you work with the user stories, the more you will find improvements to them. Be sure to make those improvements.

• Week 4 Class 8 Thu Sep 19 Posted: Sep 19

  After Class

  • Project 1 Include all user stories, even those without estimates. If a user story does not have an estimate, leave the estimate value blank.

  Announcements

  • Engineering, Engineering Technology, and Computing Career Fair Looking for student volunteers, Resume Workshop

  • Resume

    If you bring a printed copy of your resume to me during my Office Hours on Thursday, September 19, I can review it and provide suggestions for improvement.

  • Project 1: Requirements Report

    • Project 1 is not a team project. They only thing that you share with your team is the user story cards. Everything else originates from you. Do not set a team template for this.
    • This is a report about the team results and process, not your individual results and process.
    • The first two sections will be shown to the customer. Those sections should only contain information the customer is allowed to see. You will lose a significant number of points if you do not follow this rule.
    • All user stories belong to the team. This is a report of the current state of your team project.
    • There is no "my user story". All user stories belong to the team, actually the customer.
    • The customer is not interested in tasks, only the user stories.
    • The report should be readable and consistent both in markdown and displayed as a web page at GitHub.
  • Exercise 16: Commit to Project 1 Repository I did not mention this in one of the sections, so I will extend the due date to after the next class.
  • Project 1 asciinema session I added the link for submitting your asciinema session

  Class

  • Exercise 16: Commit to Project 1 Repository

    Following the procedure given in the assignment and demonstrated in class, contribute at least one commit to the Project 1 repository. This must be a valid and useful commit.

    • Use the git CLI to make the commit. You can do this wherever you have the repository cloned. You can even do this in a GitHub Codespace
    • Good commit messages follow certain patterns, and you need to follow them on all git commits:
      • Start with an action, e.g., Add
      • Capitalize the subject line (the only line we are using)
      • Use the imperative mood, e.g., Added, Adding, Adds, Add
      • Do not end the subject line with a period

    You can see your commit messages with the git log command.

  • HFSD Chapter 4
  • Exercise 17: HFSD Chapter 4 Crossword Due after next class meeting
  • Exercise 18: Team User Story Estimates II

  Unless stated otherwise, all exercises are due by 3 pm on Fri Sep 20

• Exercise 18: Team User Story Estimates II Posted: Sep 19

  Start by reviewing your user stories, particularly the titles. Titles that do not have an action term, or have a poor action term, will reduce your score on Project 1.

  As a team, create estimates for the user stories by using the planning poker procedure described on pages 48-49 of the book.

  When the team reaches a consensus for the estimate, place the estimate at the bottom left of the User Story as indicated by the example, e.g., "Estimate: 1 day" or "Estimate: 3 days".

  Individually, each team member will turn in to Brightspace individual notes that include for each round of planning poker:

  • Title of the user story
  • Any questions on or confusions with the user story
  • Any assumptions that you made
  • Any interesting assumptions that other team members made
  • The spread of estimates, indicating which one is yours. Be very careful with this, and note that a spread is on a number line.
  • The estimate, which is a team consensus (if the team was able to reach one in this round)

  If the team is not able to come to a consensus, table that User Story and go on to another one.

  The notes are due by the end of class. They can be in the form of a PDF (print to file from a computing device), or a JPG (picture taken via your phone).

  The more you work with the user stories, the more you will find improvements to them. Be sure to make those improvements. Also, you may think of additional user stories. Be sure to add them.

• Week 4 Class 7 Tue Sep 17 Posted: Sep 17

  After Class

  • Exercise 15: Team User Stories III If you participated in the team meeting, but were not able to fill out the form or upload a photo of your coded potential user story titles due to a technical error, then send me an email.
  • Exercise 16: Commit to Project 1 Repository I did not mention this in one of the sections, so I will extend the due date to after the next class.

  Announcements:

  • Resume

    If you bring a printed copy of your resume to me during my Office Hours or Advising Hours on Tuesday, September 17, or Thursday, September 19, I can review it and provide suggestions for improvement.

  • Individual Posts Small web improvements
  • Project 1 GitHub Classroom I added gh to the image. Create a new codespace if you need it and it is not there.

  • Windows File Explorer & WSL

    To open the Windows File Explorer on the current directory in WSL:

    If you open a path it has to be in Linux format, e.g., C:\Users\JohnDoe\Documents would be /mnt/c/Users/JohnDoe/Documents.

  • Dependencies

    I see a lot of user story estimates where the assumptions include the completion of a previous user story. This is a dependency. Avoid dependencies at all costs. For example, Add … does not have to be completed before Delete …. Obviously there will be some dependencies, but they are to be at the user-story level, not the implementation level.

  • Estimates

    • Estimation in software development is not about finding the minimum time it would take you to complete a user story. It's about understanding and predicting the genuine effort required in the context of your regular 5-day workweek and 50 weeks of work in a year. Remember, an estimate is not a speed challenge but rather a measure of how long it will realistically take to thoroughly implement a user story.
    • Avoid the trap of only considering the quickest or simplest implementation. Proper estimation requires thoughtful consideration of all possible complexities. Moreover, completing a user story quickly doesn't mean the rest of the day is free; there's always another user story waiting. This is not a class assignment or a lab exercise where once you are finished you are done for the day.
    • Refrain from using phrases like "All we have to do…” when discussing software tasks. Such assumptions often oversimplify the complexities inherent in coding.
  • Project 1: Requirements Report Change in due date

  Class

  • Creating the Report
  • Git Commands

  • Exercise 16: Commit to Project 1 Repository

    Following the procedure given in the assignment and demonstrated in class, contribute at least one commit to the Project 1 repository. This must be a valid and useful commit.

    • Use the git CLI to make the commit. You can do this wherever you have the repository cloned. You can even do this in a GitHub Codespace
    • Good commit messages follow certain patterns, and you need to follow them on all git commits:
      • Start with an action, e.g., Add
      • Capitalize the subject line (the only line we are using)
      • Use the imperative mood, e.g., Added, Adding, Adds, Add
      • Do not end the subject line with a period

    You can see your commit messages with the git log command.

  • HFSD Chapter 3
  • Exercise 13: HFSD Chapter 3 Crossword
  • HFSD Chapter 4
  • Exercise 15: Team User Stories III

  Unless stated otherwise, all exercises are due by 3 pm on Wed Sep 18

• Exercise 15: Team User Stories III Posted: Sep 17

  Your management is concerned that your team does not have a complete set of user stories. The first problem is low recall, i.e., the team is not capturing all the user stories the customer needs. The second problem is that without not enough work, the organization will have to let some of the team members go cut everybody's pay.

  The customer met with their team and returned with a list of potential user-story titles. These possible new user stories fall into one of the following categories:

  Code	Description
  A	Already have as a user story
  N	Not a user story title
  P	New, but needs to be converted from plural to singular
  S	New, but needs to be split into multiple stories
  X	Not part of the description

  On the provided sheet, code each of the user stories into one of these categories.

  Create a new user story, or multiple user stories, for each of these valid potential user stories. This includes fixing any title issues and adding a description. Also, take this time to fix any existing user stories.

  Each team member will turn in both of the following:

  1. A photo of the coded potential user stories uploaded to Brightspace (also put in the folder). Sign the sheet at the top before you take a photo.
  2. Fill out the Exercise 15 Form, which contains
  • Previous number of user stories
  • New number of user stories
  • Count for each Code (A, N, P, S, X)

  If you have any additional time, then create more estimates. As you did before, keep track of details for the next team meeting.

• Week 3 Class 6 Thu Sep 12 Posted: Sep 12

  Announcements:

  • Engineering, Engineering Technology, and Computing Career Fair October 1 (Tuesday) from 10am to 3pm in Student Union. Pre-registration is open through Friday, Sept. 13, 2024, at 11:55 PM.

    If you bring a printed copy of your resume to me during my Office Hours or Advising Hours on Tuesday, September 17, or Thursday, September 19, I can review it and provide suggestions for improvement.

  • Similar Action Words

    Many action words are similar in meaning, but can vary in specificity or in details to what they imply.

    Word 1	Word 2	Explanation
    Remove	Delete	"Delete" often implies a permanent action, while "Remove" can be less final or reversible
    Accept	Approve	"Approve" generally has an authoritative connotation, while "Accept" is more general
    Connect	Invite	"Invite" is very specific, suggesting a request for participation, whereas "Connect" is broader
    Add	Create	"Create" is making something new, whereas "Add" means including something that already exists
    Register	Subscribe	"Subscribe" is ongoing engagement, while "Register" is often a one-time action
    Validate	Approve	"Approve" is a decision or permission, while "Validate" suggests checking or confirming correctness
    Link	Merge	"Merge" is combining into one, whereas "Link" connects them without combining
    Send	Submit	"Submit" is submission to a process, while "Send" is transferring information
    Pause	Stop	"Stop" is final, while "Pause" is temporary
    Stop	Cancel	"Cancel" is preventing something from starting or finishing, whereas "Stop" is halting an ongoing action

    Note that the customer may not realize the difference between these terms, and say one when they mean the other.

  • Keep Up

  
  • GitHub Authentication
  • Project 1: Requirements Report

  Class

  • Exercise 12: Create Project 1 Repository

    Create your Project 1 Repository from GitHub classroom. Log into GitHub, then use the link on Brightspace to create your repository.

    As you use the link, it will ask you to select your UA username (email address) from the list. Please do so carefully, and do not select the wrong email.

    This is due by 3 pm on Monday, Sep 16

  • HFSD Chapter 3
  • Exercise 13: HFSD Chapter 3 Crossword Due after the next class meeting
  • Exercise 14: Team User Story Estimates

  Unless stated otherwise, all exercises are due by 3 pm on Fri Sep 13

• Exercise 14: Team User Story Estimates Posted: Sep 12

  Start by reviewing your user stories, particularly the titles. Titles that do not have an action term, or have a poor action term, will be counted off on your score for this exercise.

  As a team, create estimates for the user stories by using the planning poker procedure described on pages 48-49 of the book.

  When the team reaches a consensus for the estimate, place the estimate at the bottom left of the User Story as indicated by the example, e.g., "Estimate: 1 day" or "Estimate: 3 days".

  Individually, each team member will turn in to Brightspace individual notes that include for each round of planning poker:

  • Title of the user story
  • Any questions on or confusions with the user story
  • Any assumptions that you made
  • Any interesting assumptions that other team members made
  • The spread of estimates, indicating which one is yours. Be very careful with this, and note that a spread is on a number line.
  • The estimate, which is a team consensus (if the team was able to reach one in this round)

  If the team is not able to come to a consensus, table that User Story and go on to another one.

  The notes are due by the end of class. They can be in the form of a PDF (print to file from a computing device), or a JPG (picture taken via your phone).

  The more you work with the user stories, the more you will find improvements to them. Be sure to make those improvements. Also, you may think of additional user stories. Be sure to add them.

• Project 1: Requirements Report Posted: Sep 12

  Note Include all user stories, even those without estimates. If a user story does not have an estimate, leave the estimate value blank.

  Project 1 is due Friday, September 20, Monday, September 23 at 11:59:59 pm, in the file Requirements.md in a GitHub Classroom repository. You will need a GitHub account. Once you have an account, an invitation link to create the repository is on the Brightspace course page.

  Description

  At your place of work, you need to submit a formal report describing the project's current state. Write a report of your individual and team activities, including these primary sections:

  1. User Stories

  User Stories with title, description, estimate, and space for priority

  This will be shown to the customer. This section should not contain any information that a customer should not see.

  2. General Process

  Details of the overall process and procedure that created the Estimates

  This will be shown to the customer, so only data on the User Story cards from section 1 should be shown.

  3. Background Data

  Details on spread, assumptions, issues, etc.

  How did the team interaction work, and what did and did not work well

  This will not be shown to the customer. It is for your supervisor.

  In other words, the report describes all the work and processes followed while creating the user stories and their estimates. The details of the general process and the general observations in Section 3 are in the form of a narrative, i.e., describe what you did, how you did it, and the result, ordered by time. The report's tone is professional, with a clear, consistent presentation.

  The team created the User Stories and Estimates, but this report is an individual project. In your account, make changes to User Stories if they do not follow the guidelines given in the book. These changes are especially crucial for the Title and the Description. Split User Stories if the Estimate is too large. Explain any changes in your report.

  Content Notes

  • Identify yourself clearly at the top of the page with your name, email, team name, and section
  • Do not address me at the top of the page
  • Do not sign it at the bottom

  Format

  The report uses plain-text formatting syntax Markdown. Markdown is an almost universal format for text formatting in software development. Due to its direct conversion to HTML, Markdown has replaced HTML and other plain-text formatting languages in SE.

  • While Markdown does allow using HTML, do not use any HTML in this report
  • The entire report must be in a single, self-contained file: Requirements.md
  • The report is to look good both as raw Markdown and as a web page in GitHub
  • Plain text (no .pdf, .doc, .docx, etc.)
  • UTF–8 encoding Note: An ASCII document is a UTF–8 document
  • The file, like all text and source-code files, should end in a newline
  • Do not use any unnecessary multiple-blank lines

  Creating the Report

  You will use git to work on your report. Assuming a username of jdoe@uakron.edu, the steps are as follows:

  1. Create your project repository using the link in Brightspace
  2. Copy the URL from your project page
  3. Clone your repository, e.g., jdoe@uakron.edu
  4. Move to your repository directory:
  5. Edit your document. Any text editor will do. E.g., add the title.
  6. Commit your change with a reason for your change: Commit messages start with a verb, e.g., Add, Remove, Change, Fix, Reformat, etc. Follow the style given in this example: Capitalized verb, no period.
  7. View your current commits:
  8. Push your commits to GitHub:
  9. Verify that your changes appear in GitHub
  10. Repeat steps 5-9 for each change.

  Note: All commits must have non-blank commit messages. Any non-blank commit messages will not be accepted, leading to a 0 on the entire project.

  GitHub Codespace

  A GitHub Codespace is available for this project. See the guide GitHub Codespaces.

  Final Check

  After you have committed your final change to the project, you must run your report through a report check to see if it follows many of the Markdown requirements of the project. To do so, create a GitHub Codespace for the project. When in there, enter the command:

  You should see a clean report. If it finds anything, fix it and rerun the checkmd command.

  The checkmd is a custom command created for this project to verify specific Markdown requirements. A clean run does not mean you have nothing wrong with your project.

  Final Submission Requirement

  Upload an terminal session of your report successfully passing the checkmd program.

  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.

  Submit the URL via this form: Project 1

  Score

  The report content, format, and involvement in team activities are all considered for your score.

  Think carefully about how you present the report, including using Markdown. Remember, the User Stories form an unordered set, not an ordered list.

• Week 3 Class 5 Tue Sep 10 Posted: Sep 10

  Announcements:

  • Brightspace & Exercises Uploads of assignments to Brightspace may not be available until the end of class, even when the Class Meeting is posted early.

  • Action-Oriented Titles

    The primary goal of user stories is to capture a specific need or goal of a user in the context of software development. It's about "what the user wants to do" or "achieve" with the software.

    Benefits of Action-Oriented Titles:

    • Clarity Action-oriented titles make it clear what the expected outcome or behavior of the system should be
    • Focus on Value Emphasizing actions reminds the team to focus on delivering value and functionality rather than just creating artifacts
    • Facilitates Testing It is easier to deriving test cases from action-oriented stories

  • User Story Titles and the Number Grammatical Category

    Strongly consider using a title with a singular noun for a user story, instead of a title with a plural noun, because it emphasizes the atomic nature of the action.

    Plural	Singular
    Upload Documents	Upload a Document
    Send Messages	Send a Message
    Add Products to Cart	Add a Product to Cart
    Register for Events	Register for an Event
    View Notifications	View a Notification
    Search for Jobs	Search for a Job

    In general, user stories with singular titles are going to be easier to implement. There can be exceptions, as "View Notifications" may be simpler than "View a Notification" due to not having to select just one.

    The most important aspect is clarity and understanding. If "Purchase Clothes" effectively communicates the intent without ambiguity and your team finds it more natural, it's also acceptable. The choice between singular and plural should ultimately be guided by what best serves the clarity and focus of the story in your context.

  • Development Environment: Git Setup by next class.

  Class

  • Exercise 9: HFSD Chapter 2 p 47 Cubicle Conversation
  • HFSD Chapter 2
  • Exercise 10: HFSD Chapter 2 Crossword
  • HFSD Chapter 3
  • Exercise 11: Team User Stories II

  Unless stated otherwise, all exercises are due by 3 pm on Wed Sep 11

• Exercise 11: Team User Stories II Posted: Sep 10

  

  Your team is to correct the current user stories and increase the number of user stories. Very carefully go over your user titles and descriptions. Add more user stories and see what you are missing.

  Remember to split any user stories that you can. Apply the "and" rule.

  • I want a lot of user stories. Do not make any judgments on whether they are worthwhile or not. Generate as many as you can
  • The User Stories do not belong to an individual team member. They belong to the team. So feel free to make changes to stories, even if you are not the original author.
  • For this assignment, no User Story should have a title that includes "Login" or similar terms. Assume that they have already logged in or (much better) do not have to log in.
  • You have not performed an estimation process. Do not fill in the estimate with some guess or random number.

  In addition to the team work of extracting user stories from the app description, each team member will turn in to Brightspace individual notes that includes:

  • The new total number of user stories
  • The titles of at least 3 new user stories or user stories with changed titles

  The individual notes are due by the end of class uploaded to Brightspace. They can be in the form of a PDF (print to file from a computing device), or a JPG (picture taken via your phone).

• Week 2 Class 4 Thu Sep 05 Posted: Sep 05

  Announcements:

  • Exercise Scores Posted in Brightspace. In the future I will only announce exercise grades and feedback when I have a point to make or it is delayed.

  • Pattern Recognition

    Pattern recognition and adaptation are essential skills in software development. This involves closely following examples while adjusting them to fit specific needs, whether working with APIs, formatting code, handling data, or configuration. Lacking this skill can complicate development, introduce bugs, and waste development time.

    Correct Format:

      Firstname,Lastname,Email,Section,Team
      John,Doe,johndoe@uakron.edu,010,Harpo
    

    Missing field name row:

      John,Doe,johndoe@uakron.edu,010,Harpo
    

    Spaces that are not part of the data:

      Firstname,Lastname,Email,Section,Team
      John, Doe, johndoe@uakron.edu, 010, Harpo
    

    Wrong section format:

      Firstname,Lastname,Email,Section,Team
      John,Doe,johndoe@uakron.edu,10,Harpo
    

    Very wrong section format:

      Firstname,Lastname,Email,Section,Team
      John,Doe,johndoe@uakron.edu,CPSC480-010,Harpo
    

  • Priority At a mega-level:

    Amazon Alexa is a Colossal Failure

  Class

  • HFSD Chapter 2

  • Exercise 7: HFSD Chapter 2 p42 User Story Interview

    • Be sure to save your response
    • You cannot go back and edit your response
    • The number correct is your score out of 10

  • Exercise 8: Team User Stories

    • Note that almost all Team Exercises will have individual notes due by the end of class.

  Unless stated otherwise, all exercises are due by 3 pm on Fri Sep 06

• Exercise 8: Team User Stories Posted: Sep 05

  

  Each Team is assigned a separate App with the description in Brightspace.

  As a Team, create as many User Stories as you can for that app from the app description. For now, this is just the Title and the Description. The Title is just an action that a user can perform. The Description is from 1 to 3 sentences that describes what that action is. Follow the examples given in the book.

  The User Stories are written on the provided index cards. I will provide a folder for you to put the cards in as I will collect the cards at the end of class.

  • I want a lot of user stories. Do not make any judgments on whether they are worthwhile or not. Do not stop at 6 or some specific number. Generate as many unique user stories as you can.
  • You do not "own" a user story. The user story is part of the project. If you leave the project, the user stories do not go with you.
  • For any assignment in this class, no user story should have a title that includes "Login" or any similar terms. Assume that they have already logged in or (much better) do not have to log in.

  In addition to the team work of extracting user stories from the app description, each team member will turn in to Brightspace individual notes that includes:

  • The total number of user stories created
  • The titles of at least 3 user stories

  The individual notes are due by the end of class uploaded to Brightspace. They can be in the form of a PDF (print to file from a computing device), or a JPG (picture taken via your phone).

• Week 2 Class 3 Tue Sep 03 Posted: Sep 03

  Announcements:

  • Exercise 3: App Idea I posted scores and feedback in Brightspace

    Following directions is important in any field, but particularly important in Computer Science.

    The instructions clearly stated:

    • "The description must be at least 350 words long"
    • "Do not identify yourself in the description"
    • "Submit via Brightspace in PDF form" and "Upload a PDF of your App Idea description. Only PDFs allowed." Word documents are not PDFs.
  • Archive
  • TA

  Class

  • Exercise 4: HFSD p7 Sharpen Your Pencil Answer 3 is required, but you can answer it after class
  • HFSD Chapter 1

  • Exercise 5: HFSD Chapter 1 Crossword

    • Print using browser (not a screenshot)
    • Include a timestamp with Headers and Footers (Chrome: More settings/Options; Safari: Safari/Print headers and footers)
  • Exercise 6: Teams

  Unless stated otherwise, all exercises are due by 3 pm on Wed Sep 04

• Exercise 6: Teams Posted: Sep 03

  Form a team of 4 members. The final team composition is at the discretion of the instructor.

  After forming a team, your team needs to decide on a name from the following choices:

  • Three Stooges (Moe, Larry, Curly, Shemp, Curly Joe)
  • Marx Brothers (Chico, Harpo, Groucho, Gummo, Zeppo)
  • Character from Star Wars

  Pick at least 4 names.

  Send Dr. Collard an email with the following:

  • Subject is CPSC480-010 Team
  • CC all members of the team using their UA email address
  • An attachment file, members.csv, in the CSV (Comma-Separated Values) format. Use the following as an example:

  
  Firstname,Lastname,Email,Section,Team
  John,Doe,johndoe@uakron.edu,010,Harpo
  Jane,Doe,janedoe@uakron.edu,010,Harpo
  Brian,Doe,briandoe@uakron.edu,010,Harpo
  Suzy,Doe,suzydoe@uakron.edu,010,Harpo
  
  

  • The body of the email is a list of requested team names in priority order, e.g.,

  
  Harpo
  Moe
  Yoda
  Zeppo
  
  

  The purpose of a team is not just to divide the work but also to meet a required level of quality. All members of the team must check any team assignment in this course. You, as a team, are responsible for these directions. Any emails sent as part of an assignment (including exercises) must have the correct subject, CC list, and contents. Exercises are not accepted and do not receive points if they do not have the proper form and content.

  The exercise is due by the end of class.

• Week 1 Class 2 Thu Aug 29 Posted: Aug 29

  Announcements:

  • Syllabus Added the Final Exam time and day
  • Scores I posted the feedback and scores in Brightspace for Exercises 1 & 2
  • Class Survey Results Version Control Usage, Maximum Hours Spent, Maximum Timespan, Group Size
  • Algorithms Where does a class like Algorithms fit in the Software Development phases? Apple's Hidden AI Prompts Discovered in macOS Beta
  • Notes The class notes have a bunch of default and custom hotkeys. Type a "?" to see a list.
  • Notes PDF versions of the notes

  Class

  • Notes: Context

  • Exercise 3: App Idea - Submit via Brightspace in PDF form. Due by 3 pm on Mon, Sep 2

    All applications start with an idea or a need. As a user, write a description of an application. The description should include who would use it and its features. The application can be one that you create yourself or an existing program.

    Guidelines:

    • The description must be at least 350 words long
    • Include a name for the app at the top
    • Do not identify yourself in the description
    • Assume this is a smartphone app
    • The description should be of the what not the how. Do not include any discussion of programming languages, libraries to use, or software design. Do not talk about how easy or difficult it would be to create the app. Do not describe the screens, views, or user interaction.
    • If the application already exists, be creative with your name and description

    Comments:

    • This is not the place if you have a great app idea. Your app idea may be shared with others or discussed (anonymously) with the entire class.
    • This is not the app that you or your future team will work on.
  • Notes: Roots
  • HFSD: Chapter 1 (if time)

• Week 1 Class 1 Tue Aug 27 Posted: Aug 27

  Announcements

  • Syllabus
  • GitHub In the class, we use GitHub and GitHub Classroom to manage documents and source code for projects and examples. You are required to have a GitHub account. The account email (not necessarily the account name) should be your @uakron.edu email address. If it is, you can apply for the Student Github Developer Pack and get a free GitHub Pro account.
  • O'Reilly Online Learning The course textbooks are 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, 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: SE Survey

  • Exercise 2: Software Development Diagram

    Draw the Software Development Diagram that I present in class. Upload a PDF or JPG through Brightspace.

  • Notes: Context

  • For next class: Read Chapter 1 of the HFSD (Head First Software Development) book.

  All exercises are due by 3 pm on Wed Aug 28

• Welcome Posted: Aug 06

  Greetings and welcome to CPSC 480 Software Engineering (SE) section 010 for Fall 2024.

  • Syllabus The draft syllabus for the course is on the main course page. I will finalize the syllabus 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.
  • Textbook The course has two textbooks. We start with the Head First Software Development (HFSD), available from Safari Books Online via a link at the bottom of the main course page.
  • GitHub In the class, we use GitHub and GitHub Classroom to manage documents and source code for projects and examples. You are required to have a GitHub account. The account email (not necessarily the account name) should be your @uakron.edu email address. If it is, you can apply for the Student Github Developer Pack and get a free GitHub Pro account.

  See you on Tuesday, Aug 27 at 12:15 - 1:30 pm in (CAS) room 135