Cpt S 321讲解、c/c++编程设计辅导

Cpt S 321 – Final Exam
Spring 2024
30 points total
Total pages: 6

First name:
Last name:
WSU ID:

Read the instructions carefully until the end before asking questions:
- This is an individual exam: you are not allowed to communicate with anyone regarding the exam questions.
- If something is unclear, ask for clarifications via the Canvas Discussion (no code allowed). If it is still unclear after my answer, then write down any assumptions that you are making.
- At the end, make sure you download your exam code in a clean directory to ensure that it works.
- No late submissions are allowed.
- What to submit (failure to follow the submission instructions below will result in receiving 0 automatically for the exam):
1.In your in-class exercises GitLab repository create a new branch called “FinalExam” and commit the following:
- i) a .PDF version of your class diagram. The design document must be placed in a folder “Design_Documents” at the root of your project and the name must contain your name and a description of the diagram (ex.: “Venera_Arnaoudova-final-ClassDiagram.pdf”).
- ii) your code.
Tag what you want to be graded with “FinalExam_DONE” tag.
2.Your GitLab readme file must:
oexplain what features you implemented for the exam and the ones that you are missing.
oprovide a link to a video capturing your screen where 1) you show us how you download your code from the GitLab repository in a clean directory, and 2) you execute your application from that clean download and you show us the different features that you implemented.
3.Answer questions 1, 2.1, 2.2, and 2.3 in this document and submit it via Canvas as a .PDF file. Name it in the following format: “FirstName_LastName-final-answers.pdf”

Q1. (5 points) Consider the GRASP, SOLID, and Design Patterns (DP) that we have learned in class. Select 2 patterns that belong to different categories (ex. one DP and 1 SOLID principle) and illustrate how the two different patterns can work towards the same high-level goal. Also discuss the similarities and differences of how the two patterns achieve that goal.
Pattern 1: Category:

Pattern 2: Category:

High-level goal of the two patterns:

Q2. (25 points)
You are contacted by a small educational company to build an application in C# with a GUI that will help parents teach young children to eat healthy by helping them understand what a balanced diet means. (You will focus mainly on the domain logic so do not worry about all the GUI controls that need to be put in place for this prototype.)
The idea is the following: Children can plan their 3 daily meals by choosing food from different categories. Categories can be:
Fruits (apples, raspberries, watermelon, etc.); they provide vitamins, dietary fibers, etc.,
Vegetables (cucumbers, carrots, etc.); provide vitamins, dietary fibers etc.),
Protein (eggs, fish, lentils, etc.); great for our muscles but need to track the fat,
Grains (oatmeal, whole wheat bread, brown rice, etc.); great source of dietary fibers, and
Dairy (milk, cheese, yogurt, etc.; provide Calcium).
Some food items can be part of different categories. For example, lentils are both proteins and vegetables.

Being this a teamwork between parents and children, some of the features will be designed for parents, other children but the prototype does not need to create different user profiles to distinguish between the two. For now, all features will appear in the same application.
Here is a summary of the features, that you need to design and implement for the prototype:
Features for parents:
1.Create a daily goal for food categories: The goal depends on many factors including child age and physical activity. Assume that parents will use existing guides such as the one designed by USDA. As an example, for a 5-year-old child the daily goal is 1 cup of fruits, 1.5 cups of vegetables, 3 ounces of proteins, 4 ounces of grains, and 2.5 cups of dairy.
2.Create a food item: Parents should be able to create food items that they can buy so that children can use them in the meal planning. This feature allows parents to create a food item (ex. apple) and specify the quantity (ex. 1 count) and associated serving size for categories that is fulfils (ex., 100% of the fruit category).
3.Change an existing food item: Parents should be able to select an existing food item and change its characteristics. For example, change the quantity of apples to be 0.5 (half an apple) instead of 1 (full apple).
4.Delete an existing food item: Parents should be able to select an existing food item and delete it.

Features for children:

5.Create a plate: Children should be able to start planning a meal for a specific date and type of meal (breakfast, lunch, dinner, for now; snacks to come later). By default, the meal planner will show the different categories of food that children want to have and the levels of completion of the categories based on the state of the current meal – all of which are 0% completed at this stage.
6.Add a food item to a plate: Children can select a type of food item (ex., apple) and the associated number of servings from it (ex., 1 time the quantity of an apple) and add it to a specific plate (i.e., meal plan).
7.Remove a food item from a plate: Children should be able to select an existing meal plan and a specific food item and remove the food item from the meal plan.
The application will contain multiple parts in the GUI view as follows:

8.Showing the current state of the application where children can see all the meals that they have planned or are in the process of planning together with the status of the meals based on:
a.Individual meal goals: we want to see the fulfilled percentages in each food category.
b.The daily goals (such as the one listed in feature 1): we want to see cumulative percentages, per category type, for all meals planned in a specific day.
9.Creating food items that contains all the necessary controls to allow parents to perform all the features listed above.
10.Create meal plans that contains all the necessary controls to allow children to perform all the features listed above.

Q.2. Part 1. Design.
To show your design and choices you are making, you can use the table below. If you choose the fill out the table below, indicate the principles, patterns, and good practices that we learned about in class that you plan to use for your design. Add more rows if needed.
If you choose not to fill out the table, you can communicate your choices on your class diagram.
Principle/Pattern name (type)
Ex.: “Polymorphism (GRASP)” Classes that are involved
Ex.: “Animal, Cat, Dog” Additional comment
Ex.: Cat and Dog inherit from Animal

Draw the class diagram for your design to show how different classes are connected. Also highlight any additional design choices that you have made that were not discussed in the table by annotating your diagram with comments. Use draw.io to make the class diagram, export it as a .PDF file (or a .PNG), and include it in your submission. Name the file in the following format: “FirstName_LastName-diagram.pdf”. Provide a direct link to your class diagram here:

Q.2 Part 2. Implementation.
Implement a prototype application using C# and a GUI of your choice (WinForms or Avalonia) and best coding practices; provide a link to your GitLab tag (make sure me and the TAs are maintainers) here:

Grading schema and point breakdown for Q2 (25 points total):
●9 points: The design is easy to maintain and extend and make use of good design principles and practices. Both questions Q2.1 and Q2.2 will be used to evaluate the design. A design document showing a class diagram that represents your design should be present in your repository. Feel free to add other types of diagrams if need be. Feel free to use any software (such as draw.io) to make the class diagram – don’t forget to export it as a .PDF to include in your submission.
●11 points: Your software fulfills all the requirements above with no inaccuracies in the output and no crashes. (1 point for each of the 9 features: 1-7, 8.a, 8.b, 9, and 10.)
●1 point: For a “healthy” version control history, i.e., 1) the prototype should be built iteratively, 2) every commit should be a cohesive functionality, and 3) the commit message should concisely describe what is being committed.
●1 point: Code is clean, efficient and well organized. This includes identifying opportunities for refactoring your code and applying those refactorings. Make sure that the refactoring commits clearly describe the type of refactoring that is applied.
●1 point: Quality of identifiers.
●1 point: Existence and quality of comments.
●1 point: Existence and quality of test cases. (Thinks about the different types of tests!)

General Homework Requirements
Quality of Version Control ●Should be built iteratively (i.e., one feature at a time, not in one huge commit).
●Each commit should have cohesive functionality.
●Commit messages should concisely describe what is being committed.
●Use of a .gitignore.
●Commenting is done alongside with the code (i.e, there is commenting added in each commit, not done all at once at the end).
Quality of Code ●Each file should only contain one public class.
●Correct use of access modifiers.
●Classes are cohesive.
●Namespaces make sense.
●Code is easy to follow.
●StyleCop is installed and configured correctly for all projects in the solution and all warnings are resolved. If any warnings are suppressed, a good reason must be provided.
●Use of appropriate design patterns and software principles seen in class.
Quality of Identifiers ●No underscores in names of classes, attributes, and properties.
●No numbers in names of classes or tests.
●Identifiers should be descriptive.
●Project names should make sense.
●Class names and method names use PascalCasing.
●Method arguments and local variables use camelCasing.
●No Linguistic Antipatterns or Lexicon Bad Smells.
Existence and Quality of Comments ●Every method, attribute, type, and test case has a comment block with a minimum of

, , , and filled in as applicable.
●All comment blocks use the format that is generated when typing “///” on the line above each entity.
●There is useful inline commenting in addition to comment blocks that explains how the algorithm is implemented.
Existence and Quality of Tests ●Normal, boundary, and overflow/error cases should be tested for each feature.
●Test cases should be modularized (i.e, you should have a separate test case for each feature or scenario that you test - do not combine them into one large test case).

Cpt S 321讲解 、c/c++编程设计辅导

Cpt S 321讲解、c/c++编程设计辅导