SE 3800, Assignment 4
Implementing User Stories from Assignment 3

Working in groups, implement the stories your team wrote for assignment 3. In particular:

• Develop it as a C++ console app that reads standard input and writes all results to standard output.
• Use just the C++ Standard Template Library (not Boost libraries) in your solution.
• Implement an API for word-in-a-word as a collection of classes. (In a real project, this would be exported as a separate library, but do not create a library for this project. Simply create a namespace for the library. You will then use that library to implement a command line interface.
• It is not required that you implement a GUI version of the game. Doing so would mean finding a GUI library to use and learning to write code using that library. This would be too much work for this assignment.
• Use command line arguments to determine which mode the program is currently being used in such as checking if a list of words is "in" a word, listing all words that appear in a word, finding a target word that uses all words in a specified vocabulary, etc.
• You must implement --help command line argument that displays all options you have implemented.

          int main(int argc, char *argv[]) {
            if ( argc > 0 && string(argv[0]) == "--help" ) {
              print_help_message();
              return 0;
            }
            ...
          }
  

• You will need to write Google Tests to test your API. Strive for at least statement coverage.
• You will need a dictionary file. You can type your own, but here are some sources:
  • http://www.gwicks.net/dictionaries.htm - this contains word lists for other languages as well.
  • https://github.com/dwyl/english-words, especially words.txt
  • https://www.bragitoff.com/2016/03/english-dictionary-in-csv-format/: includes definitions as well

The point of this assignment and the next is to give you experience building a complete CI framework for a system. The focus is not on producing a program with lots of features, but to have a robust testing framework for a program with just a few features. Implementing features is an important part of this - designing systems for testability is an important skill - but keep your implementation focused on just enough features to provide a rich example for testing and CI.

Additional Notes

• Each person on the team is to implement at least one "feature" or other major system component.
  • That is, each person might implement all of the stories associated with some command-line argument. This assumption is that this is one or two stories, but that depends on how you wrote the stories. Ask questions if you are unsure of how much to implement.
  • Another possible model is one person implements the API and the other the (console-based) user interface.
• All team members must collaborate on the design. Your design must be object-oriented, should emphasize domain classes, and must follow the programming standard. In particular, make sure you have no "doit" classes. There are no other design requirements.
• Ensure your solution is generally not case-sensitive, adequately prompts the user for input, and clearly labels the output. It is traditional that options (like --help) are case-sensitive.
• One student is to create a git repository for the project in GitLab (within the SE 3800 group). That is, visit https://gitlab.com/msoe.edu/se/se3800f22 and click on the "New project" button in the upper right corner. Name your repository using the pattern

          se3800word_username1_username2
  

  where word is actual text (that is, this is an assignment related to dates) and where usernameX are the usernames of the team members. Repository names must be lower case. Add an extra username3 if appropriate. Invite your teammate(s), giving them Maintainer access.
• In addition to source files at the top level, check in files needed to build the system using your IDE. Do not check in build outputs such as .o/.gcno/.gcda files and executables.
  • To invite other team members, set the role permission to Maintainer or Developer, set the access expiration date if you like, then enter the email address (with the @msoe.edu) in the Select members to invite box. Sometimes when you enter the name first, that box gets cleared when you set the role and date.
• Create a file "readme.md" at the top level of your repository. At a minimum, include the following:
  • authors
  • build directions
  • testing directions; be explicit: what command runs the tests and what do you expect to see.
  • the version of C++ and G++ that are supported; get the version by typing g++ --version
  • a short description (a sentence or two) describing what your system does
  • any known limitations of your implementation (bugs, etc.)
• Create (and check in) makefiles, Docker files, and configuration files to ensure the build is done on each commit.
• Ensure each commit has meaningful commit messages. "Writing tests" or "wrote class X" is rarely helpful; describe what progress was made. Ideally, commit messages would trace back to the user story, but that is optional. If you forget to write a meaningful message, use the git option to update previous commit messages.
• Ensure your code is readable. There should be appropriate white space, but no tabs (other than the makefile). Follow the published the coding standard including the name of who authored each file.
• Each group member is to write their (approximately equal) share of the code.
• You must write tests covering the requirements. Note that building automated tests around sending standard input and reading standard output is not a good idea; design your system so all of the key operations can be tested using simple strings. Consider the cube example shown earlier: the cube function itself was tested via the Google Test framework and the user interface simply called the operations. Design your system so you can do a similar thing for this program, with automated tests covering the key functionality (such as computing days in the year, displaying calendars, etc.) and simple runs to show that the program responds to command-line arguments correctly.
• Clearly document who wrote which portions of the system. It would be simplest if only one person wrote each file, but if two people do write one file then be sure to clearly document who did what in that file.
• Be sure your the final version of your implementation is checked in by the due date.
• Create an "evidence document" showing what was accomplished. Capture screen shots of things like console output and windows to
  • show the system appearance from the user's point of view,
  • demonstrate that the system runs and produces appropriate results (covering all implemented functionality, being especially careful to document what the output shows for any "additional" features you've implemented beyond the ones described in the assignment 3 writeup.
  • show that the system passes all automated tests - you can configure the system to run automated tests using a special option or just create a special build to run the tests
• If you use branches (which are not required for a small project like this), then be sure to merge all code into Master for grading.

Be sure to include both simple test cases (easily verified by inspection) and more complex cases. However, tests are not sufficient by themselves; include a number of console examples to show how the user sees the system.

Screen shots should be done using the Windows Snipping tool or equivalent. Upload the evidence document to Canvas as a .PDF. In addition, upload a .PDF to Canvas with the stories you implemented, clearly documenting any deviation from stories submitted for assignment 3. Note you will not upload your code to Canvas, just the PDF. I will refer to the repository for the code.