首页
网站开发
桌面应用
管理软件
微信开发
App开发
嵌入式软件
工具软件
数据采集与分析
其他
首页
>
> 详细
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).
软件开发、广告设计客服
QQ:99515681
邮箱:99515681@qq.com
工作时间:8:00-23:00
微信:codinghelp
热点项目
更多
cis432代做、代写python/java程...
2024-05-04
eeen3007j代写、c++程序设计代...
2024-05-04
代写data程序、代做c/c++, jav...
2024-05-04
comp2006代做、代写c++程序语言
2024-05-04
comp26020代做、java/c++设计编...
2024-05-04
csci251 advanced programming...
2024-05-03
cs 6290: high-performance co...
2024-05-03
assignment 2: executing and ...
2024-05-03
ecse427/comp310 programmin...
2024-05-03
cs 452 (fall 22): operating...
2024-05-03
comp9414 23t2 assignment 2 ...
2024-05-03
dpst1091 23t1 assignment 2 ...
2024-05-03
program代做、代写python设计编...
2024-05-03
热点标签
finm8007
comp2006
comp26020
comp1721
eeen3007j
cis432
csci251
comp5125m
com398sust
32022
mth6158
comp328
finn41615
2024
mec302
mgmt3004
mgt7158
com160
as.640.440
econ3016
finm7405
econ7021
fin600
infs4205/7205
mktg2510-
f27sb
csse2310/csse7231
rv32i
eecs 113
comp1117b
cs 412
comp 315
econ7300
comp2017
ecs 116
fit5046
com6511
comp30024
acs341
econ1020
isys3014
acc408
comp1047
csc 256
cs 6347
finm7008
comp34212
csmde21
estr2520
comp285/comp220
mds5130/iba6205
finc6010
is3s665
busi2194
125.785
iom209
msin0041
econ339
cmt218
mast10007
comp5349
ecx2953/ecx5953
bios706
comp3310
mth6150
comp30027
comp20005
eec286
busi2211
bff2401
fnce90046
visu2001
mang6554
finc6001
125785
data423-24s1
engi 1331
fint2100
(520|600).666
can202
cs 61b
mast20029
info20003
stat512
econ3208
cmpsc311
engg1340
ecmt1010
fit5216
basc0003
ee3121
acct2002
comp5313
busi2131
ise529
elec372/472
csit940/csit440
cenv6141
comp3027/comp3927
ftec5580
comp1433
msci223
mark203
en3098
eden1000
ece6483
econ4410
mats16302
cs 6476
com6521
comp222
comp3211
comp10002
csc1002
chc6186
cs 161
comp27112
comp282
swen20003
comm1190
elec9764
acfi3308
acct7101
fin6035
comp2048
geog0163
comp2013
coen 146
dts101tc
sehh2042
comp30023
comp4880/8880
cs 455
07
stat0045.
fil-30023
celen085
psyc40005
math40082
are271
comp9311
ee5311
imse2113
comp 2322
acct2102
fnd109
int102
is3s664
is6153
data4000
accfin5034
fit5212
cs536-s24
fit5225
ecos3006
mes202tc
finc5001
stat3061
csc171
cs1b
7ssmm712
bu.450.760
cs170
comp3411
swen90004
cpt206
comp5313/comp4313—large
bl5611
kxo206
comp532
elec207
kxo151
cs 2820
cpt108
math2319
dts204tc
qm222
comp2511
ccs599
infs1001
mat2355
eeee4123
25721
ifn647
pols0010
hpm 573
qbus6860
comp9417
csci 1100
stat0023
cse340
comp2003j
cs 2550
cs360
fin 3080
ierg 4080
cs6238
cit 594
finm7406
hw6
联系我们
- QQ: 9951568
© 2021
www.rj363.com
软件定制开发网!