首页 » 代码代写 » 代码代写|Cpt S 321 – Final Exam Fall 2022

代码代写|Cpt S 321 – Final Exam Fall 2022

这是一篇来自美国的关于用c#创建一个应用程序,它将帮助教幼儿如何使用形状学习字母表的代码代写

 

Please read the entire description carefully before you start working.

You are contacted by a small educational company to build an application in C# with a GUI that will help teach young children how to learn the alphabet using shapes.

The idea is the following: Children can create letters using shapes. Shapes can be of the following type: big line, little line, big curve, little curve and are associated with a color and texture.

Here is a summary of the features that you need to design and implement for the prototype:

  1. Create a shape: Children should be able to select a shape and values for color (ex. yellow, red, green) and texture (ex. wood, sand, leather).
  1. Change an existing shape: Children should be able to select an existing shape and change its characteristics.
  1. Create a letter using shapes: Children should be able to create a letter by first selecting the type letter (for example C) and then selecting already created shapes. For example, to write the letter C a Big Curve would need to be created first and the creation of the letter is a 2 step approach: 1) select the letter C and then select the previously created Big Curve. To write E, one big line and 3 little lines are needed and would need to be created first and selected. In the process of creating a letter, if a shape is selected that cannot be used (e.g. selecting a Big Line when building the letter C) an appropriate message need to be displayed.
  1. Delete a letter: Children should be able to select an existing letter and delete it after which the letter and the associated with it shapes will no longer exist.
  1. Undo last action: Children should be able to undo the last performed action (which can only be one of the above listed actions).

The application will contain multiple parts in the GUI view as follows:

  1. Showing the current state of the application where children can see all letters that they have created as well as all shapes that have not yet been placed in letters.
  1. Creating shapes and grouping them into letters that contains all the necessary controls to allow children to perform all the features listed above.
  1. Applying filters on existing shapes and letters. This part allows children to apply filters on letters and shapes using different characteristics such as “what are the letters with more that <N> shapes” or “what are the letters that contain <Color> shapes” where <N> is a number and <Color> is a color that children must input. The implementation for filtering must use LINQ.

Important: For the first prototype, in the GUI, you can show shapes, letters, and their characteristics with text and not worry about actual graphics. For example, a Big Curve shape with yellow color and sand texture can be displayed with the following text: “Big Curve (Color: yellow; Texture: sand)” and a letter C that is created with this shape can be displayed with the following text: “C [Big Curve (Color: yellow; Texture: sand)]”.

The main point for the GUI here is to show that it can be updated properly. The actual graphical design has little to no importance.

Grading schema and point breakdown (30 points total):

  • 5 points: A design document showing a class diagram that represents your design. You must also indicate all Design Patterns and Principles that you use either by annotating the diagram or by listing them in an additional document (make sure you place any additional design documents in the same folder). 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.
  • 9 points: Your software fulfills all the requirements above with no inaccuracies in the output and no crashes.
  • 3 points: 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.
  • 4 points: Code is clean, efficient and well organized.
  • 2 points: Quality of identifiers.
  • 2 points: Existence and quality of comments.
  • 2 points: Existence and quality of test cases. Normal cases and edge cases are both important to test.
  • 1 point: summary of the features implemented and features missing (if any).
  • 2 points: Video showing that you run the application from a clean download.

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 <summary>,<returns>, <param>, and <exception> 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).

程序辅导定制C/C++/JAVA/安卓/PYTHON/留学生/PHP/APP开发/MATLAB


本网站支持 Alipay WeChatPay PayPal等支付方式

E-mail: vipdue@outlook.com  微信号:vipnxx


如果您使用手机请先保存二维码,微信识别。如果用电脑,直接掏出手机果断扫描。