End Note Posted: Dec 19
Remember that all previous posts are in the Archive.
Finals Week Posted: Dec 11
Special Note
I created a crossword, CPSC 480 Final Exam Terminology Review Crossword, for the purpose of helping you review the terminology you are responsible for on the Final Exam.
This crossword is completely optional. However, if you do submit it by your Final Exam time, I will replace one of your lowest Exercise scores with this crossword score.
Once you complete the crossword (and save it to a PDF), you can clear the answers and use it to repeatedly practice the terms, keeping time to see how fast you can fill it out. This is a standard way to practice for certification exams.
Note that this is not the only contents of the Final Exam, so do not use it as your only study guide. Be sure to review the topics given in Final Exam.
Announcements
Final Exam Dec 12, 12:15 - 2:15 pm
Make sure to know the terminology.
Added proper git commit messages to the list.
Week 14 Class 26 Thu Dec 07 Posted: Dec 07
Announcements
Final Exam Dec 12, 12:15 - 2:15 pm
Make sure to know the terminology.
Added proper git commit messages to the list.
Class
Exercise 70: Team Streaming Meeting V
Have a "standup meeting" with your team. Go over:
Upload a text file, PNG, or PDF with a short paragraph describing what you discussed, and possibly accomplished, during your team meeting. This part is due by the end of class.
Unless stated otherwise, all exercises are due by 3:30 pm on Fri Dec 08
Week 14 Class 25 Tue Dec 05 Posted: Dec 05
Announcements
Class
Exercise 64: Maintenance Categories
The quiz in the title link requires identifying commit types based on the commit message. Classifying changes into new features or particular maintenance categories based solely on the commit message is inaccurate. Accurately doing so requires considering the code changes (including added code comments), any related issues, and any related discussion to know the reason for the change, e.g.:
In this exercise, all commits are not for new features but for maintenance, with the only categories considered being corrective, adaptive, and perfective.
One other consideration is the purpose of the change:
cmake
, and are not corrective but adaptive.You will see if you are correct as soon as you submit the quiz. You can make changes to your answer.
Exercise 66: Commit
So far, your teams have created the following:
So overall, all that the teams have accomplished on the project is to create issues. That is just the start. If you did not push, then push your commits. If you were "waiting" to do any real work until after all the issues are created, stop taking a waterfall approach.
About the branch names that do not follow the assignment branch naming guidelines, git
does not store who created a branch, just who made the first commit (a branch in git is just a pointer to a commit), so these naming issues reflect on the team, not just individual team members.
Make a worthwhile commit to a branch. If you have any questions on how to do so, figure that out during your team meeting.
If you have already made a commit to the project, you will receive full credit for your contribution.
Exercise 67: Team Streaming Meeting IV
Have a "standup meeting" with your team. Go over:
If a team member is going to do something next, make sure it is an issue and that they are assigned to it.
Upload a text file, PNG, or PDF with a short paragraph describing what you discussed, and possibly accomplished, during your team meeting. This part is due by the end of class.
Unless stated otherwise, all exercises are due by 3:30 pm on Wed Dec 06
The Final Exam is in our regular classroom Final Exam: Dec 12, 12:15 - 2:15 pm.
Special Note: See the course page for a crossword to review for the Final Exam
You are responsible for what we have covered since the Midterm:
The exam has various problem types, including short answers, definitions, comparisons, and application to a code example/scenario.
If I did not cover it in class, it is not on the exam.
Week 13 Class 24 Thu Nov 30 Posted: Nov 30
Announcement Project 4: Streaming
git pull
before you do anything else in a branch. If you have a local branch you did not push, then push it immediately and let me know so I can update it. Any codespaces started before this change will have to be deleted.Class
Build and run the current tests for the Streaming project. This must include the following:
cmake
make
make run
make test
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.
The exercise is due by 3:30 pm on Fri Dec 01
Exercise 62: Team Streaming Meeting III
Have a "standup meeting" with your team. Go over:
If a team member is going to do something next, make sure it is an issue and that they are assigned to it.
Upload a text file, PNG, or PDF with a short paragraph describing what you discussed, and possibly accomplished, during your team meeting.
This is due by the end of class.
Unless stated otherwise, all exercises are due by 3:30 pm on Monday, Dec 4.
Week 13 Class 23 Tue Nov 28 Posted: Nov 28
After Class
Project 4
I did not include the GitHub Codespace configuration in the template repository. This is in the file .devcontainer.json
I added it to all the branches of your repositories. Use a git pull
before you do anything else in a branch. If you have a local branch that you did not push, then push it immediately,
and let me know so I can update the branch.
Any codespaces started before this change will have to be deleted. Then create a new one.
Announcements
Class
Exercise 58: Team Streaming Meeting II
Have a "standup meeting" with your team. Go over:
If a team member is going to do something next, make sure it is an issue and that they are assigned to it.
Upload a text file, PNG, or PDF with a short paragraph describing what you discussed, and possibly accomplished, during your team meeting.
This is due by the end of class.
Unless stated otherwise, all exercises are due by 3:30 pm on Wed Nov 29
Week 12 Class 22 Tue Nov 21 Posted: Nov 21
Announcements
Class
Exercise 54: 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:30 pm on Wed Nov 22 to finish the description.
Unless stated otherwise, all exercises are due by 3:30 pm on Monday, Nov 27
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:
Notes:
The only allowed changes to the code are:
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:
Week 11 Class 21 Thu Nov 16 Posted: Nov 16
Announcements
Spring 2024 Career Fair Register
Career Fair & Interviewing Prep Workshop will be on:
Code Analysis TDD First Pass
I unintentionally created two different Exercises, 40 and 46, in Brightspace for the Code Analysis TDD First Pass. The grades and feedback I posted were in Exercise 46.
To fix this, for Exercise 40 I gave you the same grade as you had in Exercise 46, but made Exercise 40 optional. In other words, I now drop the 2 lowest exercise scores.
Class
Exercise 51: Software Refactoring Crossword
Since we did not get through all the material, this is due after the next class.
Exercise 52: Team Rename Method Refactoring
Commits must be started during class time.
Unless stated otherwise, all exercises are due by 3:30 pm on Monday, Nov 20
In this exercise, you will go through a workflow to perform a refactoring. The overall process includes:
The following workflow must be followed to receive credit. Use the exact same commit messages as shown.
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.length()
definition to the new method size()
. Successfully build the program. Once done, commit using the commit message:
Push your changes to GitHub.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.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 GitHublength()
in ToDoList.cpp. Compile, build, and run successfully. Commit using the command:
Push your changes to GitHubAt this point, the refactoring is complete.
Create a pull request at GitHub. You want to pull from the branch issue1
into the branch main
.
Accept the pull request at GitHub. Typically, this would be done by another team member, but in this case, you can accept your own pull request.
In your GitHub Codespaces or on your local machine, switch to the branch main
and pull the changes. You should see the rename in the code on the branch main
.
issue1
has done its job and is no longer needed. All your commits on this branch are now in the branch main
.Week 11 Class 20 Tue Nov 14 Posted: Nov 14
Announcements
Project 3 I posted the following for the first commit on Project 3:
In Brightspace are the scores and feedback. Also take a look at the generated report in your repository.
At this point, all students are allowed to move on from the first commit.
Project 3 Overall Feedback
if ()
instead of if()
.return
statement in your test program should not be part of the last block, because it is not part of the last block.Class
If you do not follow a project's coding standard, whether explicitly defined or implicit in the code, you will not be viewed favorably by the other developers.
Exercise 49: Team DIP & Mock Objects II
Your notes must be uploaded by the end of class time to receive credit. All commits are due by 3:30 pm on Wednesday, Nov 15.
A couple of notes about this exercise and real development
main
, dip
, and mock
, and duplicate the tests on all of them. You would choose a method, e.g., mock
, and use that one. We did our work on three branches so you could compare the techniques.main
branch.Unless stated otherwise, all exercises are due by 3:30 pm on Wed Nov 15
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.
Record In your notes, explain why you cannot practically write a test for this issue without using dependency inversion.
dip
. Verify that you are on the correct branch.git
commands you entered. Order does not matter, and you don't have to repeat them.Clock
in the files IssueClock.hpp and IssueClock.cpp, and a test program in the file IssueClockTest.cpp. You will need to add these files so that Git will version control them:
Do not commit yet.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:
assert(false)
with a return. Make sure the test builds and runs, but it will fail.Commit your work with the commit message:
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:
mock-cmake
Commit your work with the commit message:
Week 10 Class 19 Thu Nov 09 Posted: Nov 09
After Class
Project 3 I posted the following for the first commit on Project 3:
In Brightspace are the scores and feedback. Also take a look at the generated report in your repository.
At this point, all students are allowed to move on from the first commit.
Announcements
Class
Exercise 44: Team DIP & Mock Objects
The GitHub Classroom invitation will be on Brightspace by class time.
The Notes are due at the end of class. Only those with Notes submitted will get credit.
All code changes are due by 3:30 pm on Friday, Nov 10.
Unless stated otherwise, all exercises are due by 3:30 pm on Fri Nov 10
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 DIPmock
Session testing with DIP using mock objectsTo 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.
main
: Session Testing without DIPtime
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.dip
: Session Testing with DIPdip
. Make sure to verify that you are on the correct branch.std::chrono
real-time clock, all clock duties have moved to the class Clock
. This implies:
Clock
dependency must be set up when the Session is createdTwoSecondClock
.
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.mock
: Session Testing with Mock Objectsmock
. Make sure to verify that you are on the correct branch.Week 11 Class 20 Tue Nov 07 Posted: Nov 03
Announcements
Class
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 two different use cases. If you do not have enough on the diagram, convert another User Story to a Use Case.
There is a GitHub Classroom team repository, Use Case Text for this exercise. It is empty except for a README.md.
The filename for a use case has a .md
extension, with the filename based on the title. To form a filename from the use case title, capitalize all words and remove any spaces. For example, the "Copy a Style" use case would be stored in the file CopyAStyle.md
. If you have any special characters in your use case title, remove them.
Since you are creating a new file in the repository, you will have to add the file to the repository. First, create a file with the proper name:
Add that file to Git, i.e., put that file under version control:
Commit the file and push:
Make sure to verify on GitHub that the file is there.
Now, you can add the markdown content and commit as you did in other exercises. Keep in mind the use of proper git
commit messages so that your teammates can tell what you are adding.
If you are doing this on paper, you must email me a photo by the end of class, and add the file to the repository by 3:30 pm on Wednesday, Nov 8.
Week 9 Class 17 Thu Nov 02 Posted: Nov 02
After Class:
sortTDD Posted score and any feedback in Brightspace. I also added the generated report Report.md in your repository. Generated from your source code, it shows various parts of your program, and builds and tests every commit. This is a shortened version of what I will generate for Project 3.
CPSC 489-010 T: DevOps Spring 2024
I will be offering a Special Topic course on DevOps in Spring 2024. The prerequisite for the course is "Permission of Instructor". I will grant permission to anyone who has passed CPSC 480 Software Engineering. The course description:
A comprehensive overview of the culture and practice of DevOps, the automated, continuous, and secure integration of version control, testing, packaging, configuration management, and containers.
"DevOps", a compound of "development" and "operations", is an approach to build and deploy software. Leveraging automation, it ties together version control, software testing, packaging, configuration management, and containers for continuous integration to distribute software updates frequently and with high quality. DevOps combines version control (e.g., git), containers (e.g., Docker), continuous integration tools, system administration, SSH and SSH keys, program build tools, and installer packages (e.g., deb and rpm), combined with software validation and testing.
Announcements
Class Meeting on Tuesday, Nov 7
I will be in Salt Lake City on Monday, Nov 6, and Tuesday, Nov 7, for the 2023 NSF CIRC PI meeting where the srcML grant, "Enabling Automated Language Support for the srcML Infrastructure" [2016465], is a highlighted project. As a PI on an NSF grant, I am required to attend this meeting.
Although I will be away on Tuesday, there will be a class meeting. A Team Exercise that counts double is due by the end of the class meeting. Mr. Kyle Rossi, my RA, will be present to handle any questions. My Office and Advising Hours are canceled on those days.
Class
Exercise 41: 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.
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.
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:
Make sure to use these guidelines as you implement any projects or exercises.
Follow a TDD process to implement the project below. An invitation link to create the GitHub Classroom repository is on the Brightspace course page.
Due Dates:
By Thursday, Nov 9, 11:59:59 pm, create your repository (via GitHub classroom) and make one pass through the TDD workflow (red, green, refactor) with a single commit. Students who miss this deadline will have their overall score for Project 3 reduced by 10 points (one letter grade). I strongly advise that you start right away.
After you make that one pass, wait until I provide feedback on your initial workflow by giving you a score for Exercise 40: CodeAnalysisTDD First Pass. If you don't have a score, I have not examined your first commit. If you are waiting to continue, send me an email.
The rest of the project is due by 11:59:59 pm on Nov 16.
The input for a source-code static analysis tool can come from multiple sources, including solitary 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, and LOC (lines of code). For the source code:
the resulting XML is:
Note: You may need to scroll the above 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, i.e., 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 variety of input sources and program options for the metadata follows the Rules stated below.
Implement the following rules following a Test-Driven Development (TDD) approach. Write a test in CodeAnalysisTest.cpp, and implement the minimal code necessary to get it working in CodeAnalysis.cpp, refactor/clean up the code to make it clear and logical, 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 committing. Any commit that does not build will result in a 0 for that step, and every commit will be checked.
The following rules are unordered. Do not refer to them by number.
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.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.All error messages are written to standard error (i.e., std::cerr), on their own output line, and the function should return an empty string.
The workflow for implementing one rule:
All implementation should result in code that is as clean and clear as possible. For this case:
std::string_view
to std::string
.""
, use the empty()
method.The project is built and graded in a Docker container running Ubuntu 22.04 using the GCC compiler. This is the default for GitHub Codespaces and WSL.
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
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.
Your score will depend on the following:
Week 9 Class 16 Tue Oct 31 Posted: Oct 31
Announcements
Midterm I posted scores and feedback in Brightspace. Two documents are in Brightspace Assignments:
I was solely responsible for grading the midterm, and the TA played no part in the process.
If you have any inquiries, 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 (e.g., questions 4-8) will result in a score of 0 for that question.
Project 2 Scores in Brightspace, feedback in the repo.
Class
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:
Class example: codeTDD010
The starting code already had a commit (you won't see this) for the first pass through the TDD workflow:
Exercise 39: Team Code Coverage II
Correct and finish up the Exercise 36: Team Code Coverage. If you correct what you did wrong in Exercise 36 I will update your Exercise 36 score.
Many of you had trouble following the instructions for the "the command line for the compile up to the first argument after the --coverage
". First of all, it is nothing like (scroll for the full effect):
And it is nothing like this, and for certain nothing like this
When you are asked to extract information or data, don't just dump the entire thing. Reference: flipping the bozo bit
Unless stated otherwise, all exercises are due by 3:30 pm on Wed Nov 01
Week 8 Class 15 Thu Oct 26 Posted: Oct 26
After Class
Midterm I posted scores and feedback in Brightspace. Two documents are in Brightspace Assignments:
I was solely responsible for grading the midterm, and the TA played no part in the process.
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 upcoming exams, failure to answer the question in the designated place (Questions 4-8) will result in a score of 0 for that question.
Announcements
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 is a textbook for CPSC 489-010 T: DevOps for Spring 2024.
True Story: I was preparing the Code Coverage exercise for today, and thinking about the best way to integrate code coverage into CMake when I got a notice that the new edition was out, with an added chapter on Dynamic Code Analysis, which includes code coverage.
One reason I mention it is that the new edition resulted in a separate FREE first 5 chapters. So take a look if you want more information on CMake.
Class
srcML Testing
Exercise 36: Team Code Coverage
Unless stated otherwise, all exercises are due by 3:30 pm on Fri Oct 27
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.
The following assumes you are in your build directory.
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 .
To produce the gcov
report, do the following:
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.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.--coverage
.
Record in your notes the command line for the compile up to the first argument after the --coverage
.CMAKE_VERBOSE_MAKEFILE
as it is annoying getting that much output with every make
command: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..gcda
and .gcno
files. A command to do this is (I strongly recommend copy and paste):
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.
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:
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.
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 make
s 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:
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 8 Class 14 Tue Oct 24 Posted: Oct 24
Class
Unless stated otherwise, all exercises are due by 3:30 pm on Wed Oct 25
The project, Vector Angle, calculates the degree angle between two vectors. It uses the function dotProduct()
, of which there is a test program dotProductTest.cpp.
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 after that.
Your assignment is to add test cases to the file dotProductTest.cpp and get the tests to run successfully.
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:
Keep in mind the following:
I encourage as many team members to commit a test case as possible based on the machines available. 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 pull to update what they have:
For today, add test cases one at a time to prevent merge issues.
Each team member must submit notes, including for each test case:
dotProduct()
and does not include empty lines or comment lines.Each team member's notes are due by the end of the class along with the commits with the test cases. Your score is based on the notes, and on the commits in the team repository.
Announcements
Project 2: Preliminary feedback posted in GitHub
Class
Week 7 Class 13 Tue Oct 17 Posted: Oct 17
After Class
Project 2: Preliminary feedback posted in GitHub
Announcements
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.
Class
To set your prompt to something more reasonable:
There is a new file in this example, .devcontainer.json
Your codespace runs in a container. Typically, this is a default Linux container based on an image mcr.microsoft.com/devcontainers/cpp provided by Microsoft. However, it can be extended, or a custom container can be used instead. In this case, I created a custom-made container, srcml/codespaces, built using a Docker file, that extends the base container with a more recent cmake
, and additional packages for gh
, ninja
, and asciinema
.
Setup | Debug | Release |
---|---|---|
As a team, create estimates for the user stories by playing planning poker using the procedure described on pages 48-49 of the book.
Estimate the rest of your user stories. If you have estimates for all of your user stories, estimate more tasks.
When the team reaches a consensus for the estimate, place the estimate at the bottom of the User Story on a separate line, e.g., "Estimate: 1 day" or "Estimate: 3 days".
No notes to turn in on this one. Only attendance and participation is required.
Week 6 Class 12 Thu Oct 12 Posted: Oct 12
Announcements
Class
Make Reminders
$@
, $<
, and $^
srccomplexity
Make prerequisite graph for srcComplexity:
Exercise 30: Makefile II
Continue to work on the Makefile program adding the new commits as presented in class to what you previously had.
make
git commit -am "<Insert Commit Message>"
git push
Note: GitHub Codespaces automatically clones the repository for you. If you work on this on your own machine, then you will have to authenticate with GitHub and clone the repository one your own machine.
All commits made in class are viewable as they are made by following along in GitHub:
As before:
General build:
Debug build:
Release build:
Unless stated otherwise, all exercises are due by 3:30 pm on Fri Oct 13
The Midterm Exam is Thursday, Oct 19, during our regular class time and in our regular classroom. The Midterm covers Chapters 1 - 6.5 of the Head First Software Development book, plus my notes and in-class examples.
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:
It is a good idea to review the "Dumb Questions" and the answers.
Questions are from 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.
As a team, create estimates for the user stories by playing planning poker using the procedure described on pages 48-49 of the book.
Estimate the rest of your user stories. If you have estimates for all of your user stories, estimate more tasks.
When the team reaches a consensus for the estimate, place the estimate at the bottom of the User Story on a separate line, 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:
If the team cannot reach a consensus, table that User Story and go on to another one.
Modify the above when you estimate a task instead of a user story.
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 6 Class 11 Tue Oct 10 Posted: Oct 10
Announcements
Class
Make
$@
, $<
, and $^
srccomplexity
Make prerequisite graph for srcComplexity:
Exercise 27: Makefile
Use the GitHub Classroom Makefile Exercise link on Brightspace to create the repository for the Makefile program. Then use GitHub Codespaces to implement the Makefile. The workflow is:
Precondition: The starting Makefile is valid
make
git commit -am "<Insert Commit Message>"
git push
Note: GitHub Codespaces automatically clones the repository for you. If you work on this on your own machine, then you will have to authenticate with GitHub and clone the repository one your own machine.
All commits made in class are viewable as they are made by following along in GitHub:
The Makefile is currently empty. Implement a Makefile to build the project by following along in class, or viewing the commits shown in class.
Due by 3:30 pm on Friday, Oct 13
Unless stated otherwise, all exercises are due by 3:30 pm on Wed Oct 11
As a team, create estimates for the user stories by playing planning poker using the procedure described on pages 48-49 of the book.
Estimate the rest of your user stories. If you have estimates for all of your user stories, estimate more tasks.
When the team reaches a consensus for the estimate, place the estimate at the bottom of the User Story on a separate line, 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:
If the team cannot reach a consensus, table that User Story and go on to another one.
Modify the above when you estimate a task instead of a user story.
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 10 Thu Oct 05 Posted: Oct 05
Announcements
Project 1 By Friday I will post:
Guide: Development Environment Tools
We are starting to get into the part of the course where writing and building code is part of the lecure, exercises, and eventually projects. Although GitHub Codespaces is available, you will find it more convenient to develop natively on your own machine.
Class
Exercise 24: (OPTIONAL) A third developer, Carol, requests the lock()/copy() right after Bob does.
Use SequenceDiagram.org to extend the sequence diagrams for File Locking and Version Merging.
The originals are in a GitHub Classroom Repository. Create your repository using the link in Brightspace.
Notes: Version Control (Continued)
Unless stated otherwise, all exercises are due by 3:30 pm on Monday, Oct 9
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:
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.
Project 2 is due by 8 am on Monday, Oct 16 Wednesday, Oct 18. 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). 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:
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 that 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 have you 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 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 very 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 is taking 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, put in a section with all of your user stories, with the title, description, estimate, and priority. You will need estimates for all of your user stories.
Week 5 Class 9 Tue Oct 03 Posted: Oct 03
After Class
My Office Hours from 10:30 - 11:30 on Thursday, Oct 5 are cancelled due to special College Meeting. My 1 - 2 pm Office Hours will be held as usual.
Class
Exercise 22: Version Control Crossword I
Due by 3:30 pm on Friday, Oct 6
As a team, create the first iteration. Consider all of the user stories with estimates.
You have 1 developer and a one-month iteration with a 70% velocity. To get priorities, select the number of user stories:
Note: You may get a warning from your browser that the information is not secure. You can safely ignore that.
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:
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 4 Class 8 Thu Sep 28 Posted: Sep 28
Announcements:
Project 1: Requirements Report Due 11:59:59 pm Thursday, Sep 28
The report should be readable and consistent both in markdown and displayed as a web page at GitHub.
Class
Exercise 21: Tasks
Each team member will create a list of all the user stories (titles only) with the tasks for each user story. Include any estimates that you have. Upload this as a PDF to Brightspace.
Unless stated otherwise, all exercises are due by 3:30 pm on Monday, Oct 2
As a team, create estimates for the user stories by playing planning poker using the procedure described on pages 48-49 of the book.
If you have not completed all the tasks for one of your user stories, do that first. Then, estimate the rest of your user stories. If you have estimates for all of your user stories, estimate more tasks.
When the team reaches a consensus for the estimate, place the estimate at the bottom of the User Story on a separate line, 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:
If the team cannot reach a consensus, table that User Story and go on to another one.
Modify the above when you estimate a task instead of a user story.
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 7 Tue Sep 26 Posted: Sep 26
Announcements:
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.
Project 1: Requirements Report Due 11:59:59 pm Thursday, Sep 28
Class
As a team, create estimates for the user stories by playing planning poker using the procedure described on pages 48-49 of the book.
First, pick a user story that you have an estimates. Estimate each task for that user story. Indicate if the sum of the task estimates agrees with the previous user story estimate. Update the user story estimate if needed.
When the team reaches a consensus for the estimate, place the estimate at the bottom of the User Story on a separate line, 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:
If the team cannot reach a consensus, table that User Story and go on to another one.
Modify the above when you estimate a task instead of a user story.
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 3 Class 6 Thu Sep 21 Posted: Sep 21
Announcements:
Resume
If you bring a printed copy of your resume to me during my Office Hours or Advising Hours on Tuesday, September 19, or Thursday, September 21, I will be happy to review it and provide suggestions for improvement. I am also available for one-on-one remote Teams meetings during these hours, although in-person students will be given priority.
Project 1: Requirements Report Due 11:59:59 pm Thursday, Sep 28
Class
Exercise 16: Tasks
During your team meeting, assign the user stories evenly among the team members.
Each team member will take the user stories they are assigned and create tasks. List them all in one document. Upload a PDF to Brightspace.
This exercise is due by 3:30 pm on Monday, Sep 25.
At no time are you to take home the user stories from the team folder.
Unless stated otherwise, all exercises are due by 3:30 pm on Fri Sep 22
As a team, create estimates for the user stories 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 User Story on a separate line, 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:
If the team cannot reach a consensus, table that User Story 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 3 Class 5 Tue Sep 19 Posted: Sep 19
Announcements:
Resume
If you bring a printed copy of your resume to me during my Office Hours or Advising Hours on Tuesday, September 19, or Thursday, September 21, I will be happy to review it and provide suggestions for improvement. I am also available for one-on-one remote Teams meetings during these hours, although in-person students will be given priority.
GitHub (Repost) We use GitHub and GitHub Classroom in the class to manage source code for projects, exercises, and examples. You are required to have a GitHub account.
Optionally, you can apply to the GitHub Global Campus and get a free GitHub Pro account.
To apply, your account email can be a school account, or a personal account if you upload documents to prove your current enrollment status.
Estimates
Class
Exercise 12: Project 1 Setup
Sign into your GitHub account.
Then, use the GitHub Classroom invitation link in Brightspace for Project 1 to create your repository.
Unless stated otherwise, all exercises are due by 3:30 pm on Wed Sep 20
Project 1 is due 11:59:59 pm Thursday, Sep 28, 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:
In other words, all the work and processes followed while creating the user stories and their estimates. The details of the process and procedure and the general observations 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.
Format
Score
The report content, format, and involvement in team activities are all considered for your score.
Think very carefully about the presentation of the report, including how you are using Markdown. Remember, the User Stories are an unordered set not an ordered list.
Note: If your feedback for Team User Story Estimates states "Need more User Stories, " your team must create more user stories. So, split the current user stories into as fine-grained a user story as possible. Also, see what is missing. Use some of your Team Meeting to do this, but also have the team members take cards home and fill them out for the next meeting.
As a team, create estimates for the user stories 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 User Story on a separate line, 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:
If the team cannot reach a consensus, table that User Story 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 2 Class 4 Thu Sep 14 Posted: Sep 14
Announcements:
Engineering, Engineering Technology, and Computing Career Fair September 26th (Tuesday) from 10am to 3pm in Student Union. Pre-registration closes at 8am on September 18th.
If you bring a printed copy of your resume to me during my Office Hours or Advising Hours on Tuesday, September 19, or Thursday, September 21, I will be happy to review it and provide suggestions for improvement. I am also available for one-on-one remote Teams meetings during these hours, although in-person students will be given priority.
Exercise 10: Team User Stories II
Class
Unless stated otherwise, all exercises are due by 3:30 pm on Fri Sep 15
As a team, create estimates for the user stories by playing planning poker using the procedure described on pages 48-49 of the book.
When the team reaches a consensus for the estimate, place the estimate at the bottom of the User Story on a separate line, 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:
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.
Week 2 Class 3 Tue Sep 12 Posted: Sep 12
Announcements:
Exercise 7: Team User Stories
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.
Examples:
"Profile Settings" "Update profile settings"
Benefits of Action-Oriented Titles:
Class
Unless stated otherwise, all exercises are due by 3:30 pm on Wed Sep 13
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.
Week 1 Class 2 Thu Sep 07 Posted: Sep 07
Announcements:
Class
Unless stated otherwise, all exercises are due by 3:30 pm on Fri Sep 08
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. 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.
Week 1 Class 1 Tue Sep 05 Posted: Sep 05
Special Announcement
We meet in our regular classroom from this class meeting on.
Announcements:
Class
Unless stated otherwise, all exercises are due by 3:30 pm on Wed Sep 06
Form a team of 3 or 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. The choices are one of the Three Stooges (Moe, Larry, Curly, Shemp, Curly Joe), one of the Marx Brothers (Chico, Harpo, Groucho, Gummo, Zeppo), or one from Star Wars. Pick at least 4 names.
Email Dr. Collard and the TA the following:
Example content of the email (but don't indent):
John,Doe,johndoe@uakron.edu
Jane,Doe,janedoe@uakron.edu
Brian,Doe,briandoe@uakron.edu
Suzy,Doe,suzydoe@uakron.edu
Harpo
Moe
Yoda
Zeppo
The purpose of a team is not just to divide the work but also to raise the overall quality. More than one person should 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 and CC list. Exercises are not accepted and do not receive points if they do not have the proper form and content.
Class meetings return to our regular classroom starting this week.
Week 0 Class 0 Thu Aug 31 Posted: Aug 31
Special Announcement
Our Second Class Meeting on Thursday, Aug 31 will also be online through Microsoft Teams.
We will return to the classroom starting next week.
Announcements:
Class
Exercise 3: App Idea - Submit via Brightspace in PDF form. Due by 3 pm on Mon, Sep 4
All applications start with an idea or a need. In the role of a user, write a description of an application. The description includes who would use it and its features. The application can be one that you create yourself or an existing program.
Guidelines:
Comments:
Week 0 Class -1 Tue Aug 29 Posted: Aug 29
After Class
Our Second Class Meeting on Thursday, Aug 31 will also be online through Microsoft Teams.
We will return to the classroom starting next week.
I revised the posted information on the GitHub accounts
Special Announcement
Our First Class Meeting on Tuesday, Aug 29 will be online through Microsoft Teams.
I am in Isolation for COVID and cannot come onto campus.
You can participate from anywhere, or even from the classroom.
Announcements
GitHub We use GitHub and GitHub Classroom in the class to manage source code for projects, exercises, and examples. You are required to have a GitHub account.
Optionally, you can apply to the GitHub Global Campus and get a free GitHub Pro account.
To apply, your account email can be a school account, or a personal account if you upload documents to prove your current enrollment status.
You will need your GitHub account for Thursday's class.
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 content, click the "Institution not listed?" link below the dropdown and enter your UA email. You will then create an account and use that account from now on.
For more information: Library LibGuide
Exercises
Exercise 2: Software Development Diagram
Draw the Software Development Diagram that I present in class. Upload a PDF or JPG into Brightspace.
All exercises are due by 3 pm on Wed Aug 30
Our First Class Meeting on Tuesday, Aug 29 will be online through Microsoft Teams.
I am in Isolation for COVID and cannot come onto campus.
You can participate from anywhere, or even from the classroom.
Greetings and welcome to CPSC 480 Software Engineering (SE) for Fall 2023.
See you on Tuesday, Aug 29 at 9:15 - 10:30 am in Arts & Sciences (CAS) room 143