CHC6186代写、Java程序设计代做
CHC6186 Advanced Object-Oriented Programming
Coursework
For this coursework, you will produce in Java two versions of the game Numberle. One version will
have a Graphical User Interface (GUI) and the other version will have a command-line interface (CLI).
The GUI version will be constructed according to the principles of Model View Controller, and the CLI
version will use the same model. The two versions will from now on be called the GUI version and
the CLI version.
Learning Outcomes
This coursework will assess the following learning outcomes.
● Create a software artefact by applying the methodologies of advanced object-oriented
programming to a requirements specification
● Consult on-line code libraries to find the classes and methods most appropriate for solving a
problem
● Create appropriate documentation that clearly communicates the intended behaviour of a
program
This coursework is worth 50% of your module mark; the remaining 50% comes from your exam.
How to Play Numberle
Numberle is a mathematical equation guessing game where players must accurately guess a randomly
generated equation within six tries.1 Players enter their own equation, aiming to match the target
equation. In total, players have 6 attempts to guess the target equation. When calculating, players
can use numbers (0-9) and arithmetic signs (+ - * / =).
For this coursework, the length of the mathematical equation is fixed at 7 characters. (However, the
character number of the link numberle.org is originally 8, but you can change it to 7 characters by
clicking the top left setting button) In each attempt, the player enters their own correct equation to
find out what numbers and arithmetic signs are in the equation. If the number or sign is in the
equation, but in the wrong place, it will be highlighted in orange. If it is in the exact place, then it will
be highlighted in green. If there is no number or sign in the equation at all, the color will be gray. In
this coursework, arithmetic expressions are
evaluated using BODMAS. BODMAS stands for
"Brackets, Orders (exponents), Division and
Multiplication, Addition and Subtraction." This
means that operations within brackets are
performed first, followed by any exponents, then
division and multiplication (from left to right), and
finally addition and subtraction (from left to right).
The website is implemented in Javascript. Any
attempt to submit Javascript will receive a mark
of zero and any Java based on the website’s
Javascript will be treated as plagiarism in the
normal way. The website colours may be used.
1
https://numberle.org
Functional Requirements
For greater clarity, the description of the GUI and the CLI versions of the game can be summarised in
the following list of functional requirements.
FR1 For the GUI version, a confirmatory message or a message box should be displayed to
indicate whether the player has won (guessed the mathematical equation) or lost (run out
of guesses), even though the game status is clear from the tile coloring on the last filled
row.
FR2 For the CLI version, a confirmatory message indicating the player has won or lost is
required.
FR3 The behaviour of the program shall be controlled by three flags:
• One flag should, if set, cause an error message to be displayed if the equation is not
valid; this will not then count as one of the tries.
• Another flag should, if set, display the target equation for testing purposes.
• A third flag should, if set, cause the equation to be randomly selected. If unset, the
equation will be fixed.
FR4 Both GUI and CLI versions of the program should allow players to input their guesses for
the mathematical equation, consisting of numbers and arithmetic signs.
FR5 The Model should load a list of valid equations from a fixed location (from one provided
file equations.txt). This list will serve as potential guesses for the player.
FR6 The GUI should display a keyboard in which digits or signs are displayed in dark grey if it
has been revealed that they do not occur in the mathematical equation, green if a correct
location of a digit or a sign has been found, and orange if the digit or sign has been
guessed but never at the correct location. See below for an example; this functionality is
like the GUI shown on the website.
The CLI should indicate available digits or signs by listing them in four separate categories
in a certain order.
FR7 The GUI version should have a button to ask for a new game which will be enabled only
after the first valid guess has been made. This is not required for the CLI version.
Non-functional Requirements
The following non-functional requirements also apply
NFR1 The GUI version and CLI version should be two separate programs ie there should be two
files each with a main method in them and which file is run determines which version
activated.
NFR2 The GUI version must be constructed according to the principles of MVC, as restated
below. Because of this requirement, code that belongs in the View but is placed in the
Model will usually not be counted towards the marks for the View. Similar rules will apply
for other misplaced code.
NFR3 The CLI version will use the Model part of the GUI version directly without using the View
or Controller; nor should it define a new view or controller.
NFR4 The code must be documented with asserts, unit testing, class diagram, comments as
described below.
NFR5 The code must be of good quality as described in the marking scheme below.
NFR6 The flags mentioned in FR3 should be in the Model. It is not necessary for them to be
changeable at run time.
NFR7 The model should also have a constant indicating the number of allowable guesses.
Marking Scheme (See rubric as well).
Model. This should have an interface designed to be convenient for the Controller, View
and JUnit class to use with no superfluous public methods, no references to two classes
and contain no GUI code. It may consist of several classes but there must be a class called
Model or similar that provides the interface and this class should extend Observable. File
reading should also be done in the Model. A high mark will be earned for a Model that
implements all the required functionality and respects all these constraints. A pass mark
will be earned for a Model that implements only some of the required functionality or fails
to respect these constraints.
20%
Controller. This should forward only valid requests to the Model, querying the Model if
necessary to find out if the request is valid, and must also enable / disable buttons as
described above in the functional requirements. It must have no GUI code, though it may
send messages to the View. A high mark will be given to a controller that respects all these
constraints and a pass mark will be given to a controller that respects only some of them
10%
View of GUI version using the Swing framework. It should implement Observer and
therefore have an update method that is called when the Model changes. This will be
marked according to how many of the functional requirements have been met. A high
mark will be given to a view that implements all the requirements and a pass mark will be
given to a view that implements only some of them.
10%
CLI version of the program, using the Model. 10%
Specification of Model with asserts. This should include invariants for the class as well as
pre and post conditions for each public method in the model. This will be marked
according to how many of the relevant conditions are included and whether the ones that
are included are correct. Partial credit will be available for describing them in English. A
high mark will be given to a specification that includes all the relevant constraints. A pass
mark will be given to a specification that includes only a few of them.
10%
Unit testing of the Model in JUnit. There should be three tests, significantly different from
each other. You should explain in comments the scenario ie the situation you are testing
for. You should use write (and then call) methods for the Model that set it into the state
desired for the test. It should be easy to see what state the Model is being set to by
reading the code for the unit tests. A high mark will be given to significantly different tests
10%
that are easy for the marker to interpret. A pass mark will be given to unoriginal second or
third tests or to three tests that are difficult to understand. Your Model may use a
separate Board class but the testing should be of the Model class and the specification
should be applied to that class also.
Use of the code quality practices described in Lecture 1, plus the additional practices of
light relevant commenting and correct formatting. Short elegant programs are preferred,
and code smells are to be avoided. Note that high marks for this category will only be
possible if the GUI fulfils most of the requirements. A high mark will be awarded if all the
practices are observed and a pass mark will be awarded if only some of them are.
10%
Class diagram. This should show how the Model, View and Controller are related to each
other, as well as how they interact with library classes such as Observable. Simplicity and
clarity will be reward. It will be marked according to its accuracy as a representation of the
program. A high mark will be awarded for an accurate diagram and a pass mark will be
awarded for a less accurate diagram.
10%
Video presentation that shows you displaying the code and using the program. It will be
marked according to timing, presentation and how well you show that you have met the
FRs and NFRs in both versions.
10%
Submission
Requirements
1. Your submission should contain three files (.pdf, .zip, and .mp4).
2. The first file is a .pdf document with screenshots of the implementation (Java code), testing,
and design with a class diagram.
3. The second file is a .zip file with the Java project.
4. The third file is a .mp4 video that is less than 1 GB. If the video is not viewable, it will not
receive marks. The video must be a maximum of five minutes long during which you must
display most of the relevant functionality and refer to your code. Any recording software can
be used so long as it captures your screen and your voice.
5. Additionally, you are required to regularly upload your code to GitHub as per the university
counterpart's requirement. Provide the GitHub repository link in the PDF document.
6. The PDF document is the version that will be marked, but the .zip and .mp4 are requested so
that we may run the code.
File Naming Convention
You must save the files with the following names:
• {YourStudentNumber}-coursework.pdf
• {YourStudentNumber}-coursework.zip
• {YourStudentNumber}-coursework.mp4
For example:
• 202007081314-coursework.pdf
• 202007081314-coursework.zip
• 202107081314-coursework.mp4
Submission Deadline:
You must upload from the student website (student.zy.cdut.edu.cn) before 17:00, May 6th
(Monday).
Some students will be selected to give a Zoom presentation, after the exam period. If you are asked
to give a Zoom presentation then you must do so.
Formative Feedback
We are giving you the opportunity to receive feedback on the design of your program. To receive
this feedback, you need to upload a detailed UML class diagram of your code to student website
before 17:00 on Friday March 25th. As this is a formative feedback deadline, it will not be possible
for you to seek deadline extensions. You will be given a short amount of written feedback on your
design within a week. The Week 5 teaching session will go through a worked example in order to
help you produce the class diagram.
The class diagram should have all methods and attributes showing. In addition, you should indicate
which methods call which other methods. A class diagram with insufficient detail or syntactically
nonsensical or not realisable as an actual Java program will make it more difficult for us to give you
feedback and will receive a low mark if submitted with the final report.
Academic Conduct
This is an individual piece of work and you will have to work on your own and submit your own
original attempt at the assignment. Any code that has been copied from any source (e.g. Stack
Overflow, online tutorial, textbooks, other students etc.) must be properly referenced to avoid any
suspicion of plagiarism. Refer to the Module Handbook for further information on this. If you need
help you can always ask for advice and guidance from the module leader by email; online sessions
can be arranged for further clarification.
Rubric The work shall be marked according to the following rubric.
D C B A
Model only basic functionality
implemented or slightly more
than basic but references to View
or Controller or superfluous
methods
no superfluous methods and no
references to View or Controller
but only the basics of
functionality implemented
no superfluous methods and
no references to View or
Controller but only the basics
of functionality implemented
convenient to use with no superfluous methods, all required
functionality and no references to View or Controller, extends
Observable, calls setChanged and notifyObservers
Controller zero of the requirements: only
valid requests, querying Model
first, enables/disables buttons
without GUI code
one out of only valid requests,
querying Model first,
enables/disables buttons without
GUI code
two out of only valid requests,
querying Model first,
enables/disables buttons
without GUI code
only valid requests, has references to both Model and View,
converting UI interactions into methods to change the Model,
querying Model first, enables/disables buttons without GUI code
GUI View no view update method or
update method implementing
very few of the FRs
update method in view
implementing some of the FRs
update method in view
implementing most of the FRs
update method in view implementing all the FRs, uses Swing, has
Model and Controller as attributes, displays board and allows
Controller to change the view e.g. enable/disable options,
implements Observer and calls addObserver
CLI class CLI version implementing very
few of the FRs
CLI version implementing some of
the FRs
CLI version implementing
most of the FRs
CLI version implementing all the FRs, using same Model as the
GUI version, but no Controller and is demonstrated on the video
Specification
of
Model with
asserts
a few pre/postconditions
described in English
suitable pre/post conditions for
most public methods but in
English
suitable pre/post conditions
for most public
methods expressed in some
logic
suitable pre/post conditions for all public methods and class
invariants all expressed as statements of formal logic
Unit testing
of
Model with
JUnit
one test with the scenario poorly
described or not at all
tests all essentially similar or only
one or two or scenario being
tested poorly described
third test not significantly
different or scenario being
tested not described with
sufficient care
three significantly different tests of the model with all scenarios
exactly described and with all inputs satisfying the preconditions
Code quality
practices
most code quality practices not
observed
some code quality practices
observed but many not
most code quality practices
observed but some clearly not
all code quality practices observed including light correct
commenting, suitable identifier names (constants, methods,
classes etc) in appropriate cases, indentation, lack of code
smells (long methods, repeated code, lack of modularity)
Class
diagram
Inadequate class diagram with
serious mistakes in attributes and
relationships between classes
Adequate class diagram with
mistakes in both attributes and
relationships between classes
Good class diagram with only
a few mistakes in attributes,
visibility or relationships
between classes
Excellent class diagram with all attributes indicated with correct
visibilities and correct relationships between classes all shown
Video
Presentation
Very poor presentation with
insufficient coverage of FRs and
NFRs, poorly presented and
overly long
Passable presentation covering
FRs or NFRs or well-presented or
at least appropriate length
Quite good presentation but
missing some details of FRs
and NFRs or poorly presented
or overly long
Excellent presentation with full explanation of most FRs and
NFRs, referencing the code, well presented and within time limit
请加QQ:99515681 邮箱:99515681@qq.com WX:codinghelp
- 电报群发最强引流软件,Telegram自动拉群发工具/TG营销提升
- 外贸探险家:WhatsApp拉群工具,我这个小白的外贸探险之旅
- AD1833ACSTZ: Enhancing Audio Processing with Advanced Digital-to-Analog Conversion | ChipsX
- 内蒙古工程机械:驾驭力量,筑梦草原
- 中国品牌崛起,爱可声助听器在欧美市场崭露头角
- 电报群发软件,telegram营销软件,海外获客需要做哪些步骤?
- 戴尔员工并不是唯一一个被迫减少远程工作的员工
- 聪明选择WhatsApp工具是我外贸起步时不可或缺的趋势智能助手
- 新人爆粉工具!Instagram脚本群发营销工具,Ins自动采集打粉神器!
- 希腊买房移民涨价倒计时:世贸通移民教您如何赶上移民末班车
- 虚拟商城的跨境电商 Line 群发云控笑料奇遇:在虚拟商城的幻境中,经历一场TG-WS-LINE频道号,直登号,协议号,老号
- 抖音相关负责人:没有洽谈接手阿里大文娱
- Morgan Stanley包容性风险投资实验室为规模最大、全球化程度最高的一批初创企业举办演示日活动
- NTT在中国香港领先推出全新液体冷却技术及高效能运算即服务解决方案
- 代写program、代做Python设计编程
- Ins高效筛选助手,Instagram群发代发工具,让你的营销更高效!
- Instagram营销软件 - ins私信博主/ig批量养号/ins自动登录
- 高效互动,客户粘性 UP!商家选择 telegram 群发协议,品牌与用户深度互动无阻!
- Instagram营销软件,ins拉群引流群发助手/ig采集工具
- instagram群发采集神器,高效引流爆粉,助你成为社交达人!
- 以前没有WhatsApp拉群工具 我的推广活动就像是在大海里撒网 茫茫人海 难以寻觅到真正有意向的顾客 投入的时间和精力都像是石沉大海 难以泛起一丝波澜
- COMP 330代做、Python设计程序代写
- 在腾讯2023年会上马化腾回应了64亿元在北京海淀区拿地的事情
- 首次出海!星期零亮相2024日本东京国际食品饮料展览会
- 数字狂欢夜WhatsApp拉群工具助我业务飞速发展,客户询盘数暴涨200%
- 电报/TG群发神器推荐, Telegram营销软件,TG群发助手
- 宁夏构建西部医疗健康行业大模型生态,引领医疗创新与数字化转型
- 中原星谷启动中部区域商业航天新篇章
- ins群发软件,ins营销软件,ins拉群软件天宇爆粉【TG:@cjhshk199937】
- 风气扬帆|第九届上海空气新风展报名通道开启,邀您共赴空净行业盛会!
推荐
- B站更新决策机构名单:共有 29 名掌权管理者,包括陈睿、徐逸、李旎、樊欣等人 1 月 15 日消息,据界面新闻,B站上周发布内部 科技
- 丰田章男称未来依然需要内燃机 已经启动电动机新项目 尽管电动车在全球范围内持续崛起,但丰田章男 科技
- 全力打造中国“创业之都”名片,第十届中国创业者大会将在郑州召开 北京创业科创科技中心主办的第十届中国创业 科技
- 智慧驱动 共创未来| 东芝硬盘创新数据存储技术 为期三天的第五届中国(昆明)南亚社会公共安 科技
- 如何经营一家好企业,需要具备什么要素特点 我们大多数人刚开始创办一家企业都遇到经营 科技
- 创意驱动增长,Adobe护城河够深吗? Adobe通过其Creative Cloud订阅捆绑包具有 科技
- 老杨第一次再度抓握住一瓶水,他由此产生了新的憧憬 瘫痪十四年后,老杨第一次再度抓握住一瓶水,他 科技
- 升级的脉脉,正在以招聘业务铺开商业化版图 长久以来,求职信息流不对称、单向的信息传递 科技
- 苹果罕见大降价,华为的压力给到了? 1、苹果官网罕见大降价冲上热搜。原因是苹 科技
- 疫情期间 这个品牌实现了疯狂扩张 记得第一次喝瑞幸,还是2017年底去北京出差的 科技