代写 COMP2100/6442 Group Project
COMP2100/6442 Group Project | My Educational App
v.01 - Project Description released (24.03.2023)
Assessment weight: This project is worth 30% of your overall mark.
Code due date: Thursday, Week 11 at 11h59 pm (last commit for the code)
Report (group and individual reflection) due date: Friday, Week 11 at 11h59 pm (last commit for the
report, Wattle for individual reflection)
Presentation Slides due date: Friday, Week 11 at 11h59 pm (slides must be uploaded to Office365)
Group Presentation: Monday, Week 12 (during lecture time)
No late submission allowed
Table of Contents
Introduction
Key requirements for the App
Part 1: Basic App
Part 2: General features of the App
List of General Features
Search-related features
UI Design and Testing
Greater Data Usage, Handling and Sophistication
User Interactivity
Privacy
Creating Processes
Peer to Peer Messaging
Firebase Integration
How many features should my group implement?
Suggest a new feature | Voice your feature
Surprise!
Checkpoint
Project Submission
Code development
Report (Important!!!)
All attempted features MUST be documented
Other important items
Individual Reflection and Peer- and self-evaluation
Group Project Demonstration
Best Practices for Using Generative AI Tools for Software Construction
Frequently Asked Questions
What kind of app should we develop?
Why and how to simulate a data stream?
How should I develop the search mechanism?
What about the data?
What about the data structures?
Which design pattern should I use?
How complicated should my grammar be?
What should my app look like?
General Information (assessment, submission, presentations, etc)
Working physically apart, but remotely together!
What is the number of members per group?
Due date and late submission policy
Originality
How will projects be assessed?
Marking Criteria
Assessment Rubrics
Other relevant information
Introduction
The objective of this project is to gain some experience in the process of software construction (the
design, specification, documentation, implementation, and testing of substantial software). This project
will also give you some practice in designing and implementing a graphical user interface (GUI)
application and using several important development tools (particularly Android Studio and Git) with
Java. Most importantly, it is an opportunity to reason about and put into practice some of the
fundamental concepts covered in this course, such as Data Structures, Tokenizer/Parser, Data
Persistence, Design Patterns, Software Testing, etc.
As you complete this project, you should reflect on the overall design along with the software
engineering process that you used in bringing this project to completion. Note that this is not an
assignment about who could write the best app only, but who could best manifest what they have
learned in this course and during the implementation of this app. The journey is as important as the
final app (regular meetings, regular contributions/commits, etc).
The topic of the project: My Educational App
A mobile educational app is a software designed to help students learn remotely. The structure of
learning systems is often complex and involves many of the topics learned in this course.
A few examples of educational platforms are Moodle, a free and open-source learning management
system used by several universities in the world including ANU, the Khan Academy that provides
personalised learning experiences to students, and the Chinaooc, a course aggregator containing
more than 20,000 courses from several Universities in China. Other known platforms are Coursera,
Udemy, EdX.
You are encouraged to come up with your own ideas related to this topic and features as a group.
(B-creative!)
Although the content for your My Educational App is open, your implementation must meet several
basic requirements.
Note that we do not expect a fully operational app - simplifications can be made as long as the core
architecture is well-developed. The key assessment aspects include Data Structures, Tokenizer/Parser,
Data Persistence, Design Patterns, Software Testing, and Code Quality.
Key requirements for the App
Part 1: Basic App
In the first part of the assignment, you must create an app (with generated APK) that allows users to:
(i) login, (ii) visualise and (iii) search for information within the app.
Marks will be awarded for the following listed requirements. It is advised, although not necessary, that
you complete this basic application before proceeding to the additional/general features.
Implemented features that do not meet the requirements will net you zero marks. Use the report to
explicitly link the features your group implemented to the requirements listed.
● Users must be able to log in (not necessarily sign up). (easy)
Important: You must include the following two accounts for markers' access to your App:
Username: comp2100@anu.au Password: comp2100
Username: comp6442@anu.au Password: comp6442
● There must be data file(s) with at least 2,500 valid data instances. The data files must be used to
feed your app, simulating a data stream. For example, every x seconds, a new item is read from a
file. An item can be an action (e.g., a new set of lecture notes has been posted by a lecturer;
students are added to a course; an assessment submission; a new user signed up; etc). (easy)
Important: Include the link to the data file(s) in your report for marking purposes.
If Firebase is used to store the data instances or for any other parts of the project, you must add
comp21006442@gmail.com as a Developer to your Firebase project and add the link to your
Firebase repository to your report.)
● Users must be able to load data/information (from the data file(s) or Firebase) and visualise it (e.g.,
a list of courses and/or a list of lecturers and students as users). (medium)
● Users must be able to search for information on your app. (medium)
The application is dependent on your app theme. For instance, you may want to allow users to
search for information such as courses, lecture materials, course participants by certain criteria (e.g.
#assignments due: 2023/3--5).
a. The search functionality must make use of a tokenizer and parser with a formal grammar of
your own creation.
The underlying implementation must:
I. contain at least one fully implemented tree data structure taught in this course (e.g., Binary Search
Tree, Red-Black tree, AVL tree, B-Tree) for organising, processing, retrieving and storing data. We
will also evaluate your choice and use of data structures and your justification (not only trees, but
also other data structures such as arrays, lists, maps, etc).
II. Implement at least three design patterns covered in our course.
III. Retrieve data from a local file (JSON, XML or Bespoken) or Firebase.
Can I use pre-made solutions (e.g. databases (including Firebase) or APIs)?
You can and should; software reuse is part of software construction. However, this assignment has some
compulsory items (e.g., tree data structure), and we expect you to implement them. So, as long as the pre-made
solutions do not impact the core features, there is no problem with using them.
We remind you that we will assess what you have implemented, not what others have implemented. All used
third-party code/library/solution must be referenced (read the Originality Section).
Part 2: General features of the App
On top of the basic infrastructure, a software app is enriched by features that better present
information and provide useful functionalities relevant to its theme and purposes.
For this assignment, you can adopt features from the provided list and/or propose other features (see
next subsection "Voice your Feature"), and present your implementation for each feature in the report.
Note that these features are used for assessment purposes to demonstrate your skills by reference to
the core assessment criteria. As opposed to the development of a fully-functioning app, the actual
functionalities provided are less important. You do not need to accomplish a lot of features to achieve
a good grade, quality over quantity (see "How will projects be assessed?" Section).
Greater marks will be attributed to the excellent implementation of a few features as opposed to poor
attempts at several features. For example, achieving the entirety of the ‘peer-to-peer messaging’
category to an excellent level of quality (great code documentation, excellent use of data structures,
appropriate incorporation of design patterns, etc) will net you greater marks than poor attempts at
several features.
List of General Features
The following is a list of features, each with an [id] (in squared bracket at the start) classified by
category and level of difficulty for references. Please note that ‘[stored in-memory]’ refers to storing
data in the application’s temporary memory (and not storing the data persistently on the device itself)
suffices.
Search-related features
1. [Search-Invalid] Search functionality can handle partially valid and invalid search queries. (medium)
2. [Search-Filter] Sort and/or filter a list of items returned from a search, with the help of suitable UI
components. For instance, when searching for assignments, include checkboxes for users to select
the target course(s); include drop-down field for the selection of sorting methods, etc. (easy)
UI Design and Testing
1. [UI-Layout] UI must have portrait and landscape layout variants as well as support for different
screen sizes. Simply using Android studio's automated support for orientation and screen sizes and
or creating support without effort to make them look reasonable will net you zero marks. (easy)
2. [UI-Test] UI tests using espresso or similar. Please note that your tests must be of reasonable
quality. (hard)
a. Espresso is not covered in lectures/labs, but is a simple framework to write Android UI tests.
Greater Data Usage, Handling and Sophistication
1. [Data-Formats] Read data instances from multiple local files in at least 2 different formats (JSON,
XML or Bespoken). (easy)
2. [Data-Profile] User profile or Course material activity containing a media file (image, animation (e.g.
gif), video). (easy)
3. [Data-GPS] Use GPS information (see the demo presented by our tutors. For example, your app
may use the latitude/longitude to show information relevant to your app. An example is to display
localised based on the location of the user app. (e.g., English materials if the user is located in an
English speaking country)). (easy)
4. [Data-Graphical] Graphical report viewer. Provide users with the ability to see a report of
interactions with your app (e.g., summary of assessment results for a course or an individual
student, etc), in a graphical manner. (medium)
5. [Data-Deletion] Deletion method of either a Red-Black Tree, AVL tree or B-Tree data structure. The
deletion of nodes must serve a purpose within your application. (hard)
a. Note that this advanced feature will only be considered if the chosen tree is the most
suitable data structure (out of the data structures covered in this course) for the App you are
developing. Note that the RB-Tree deletion is not covered in lectures (see deletion
algorithm in the references of the data structure lecture [readings icon on Wattle]).
Can I use the lab code?
Yes, you can, but you must reference it and use the report to show us what you've improved in the labs
code. There are several ways to improve the code from our labs. Remember that we will only assess your
code, not ours. Only significant improvements can count towards the completion of a feature.
User Interactivity
1. [Interact-Micro] The ability to micro-interact with items/users (e.g. add to todo-list, like/follow a
post in the forum, connect to another user, etc.) [stored in-memory]. (easy)
2. [Interact-Follow] The ability to ‘follow’ a course or any specific items. There must be a section
specifically dedicated to 'things' followed (e.g., showing all updates from all courses followed in
chronological order). [stored in-memory] (medium)
3. [Interact-Share] The ability to share an item to another user (similar to social media shares with
basic information of the item. For instance, for students to share lecture notes (including the title,
thumbnail photo, and extract of the description) via private messages). [stored in-memory]. (easy)
4. [Interact-Noti] The ability to send notifications based on different types of interactions (e.g., new
announcement, assignment submissions, etc). A notification must be sent only after a
predetermined number of interactions are set (>= 2 interactions [e.g., 2 announcements have been
made or 2 follow requests have been received). Note: it is not mandatory to use the Android
Notification classes. (medium)
5. [Interact-Scheduled] Scheduled actions. At least two different types of actions must be
schedulable. For example, a user can schedule an item (e.g., release new lecture materials/the
exam page on Tuesdays at 3 pm). (medium)
Privacy
1. [Privacy-Request] Students may send requests which are then accepted or denied by the
Lecturers/other users (e.g., a request to join the course or follow another student). (easy)
2. [Privacy-Visibility] A student can only see a course’s profile that is set to Public (consider that there
are at least two types of profiles: public and private) or after being added to the course as a
student (easy).
3. [Privacy-Block] Provide lecturers with the ability to ‘block’ things. Things (e.g., forum posts
containing abusive language, etc) shall not be visible to other students but still visible to the
lecturer(s). (medium)
4. [Privacy-Anon] Provide students with the ability to make anonymous posts in a forum. The visibility
of author of anonymous posts should be determined by the viewer’s role (e.g., visible by lecturers,
tutors and the author, but not by other students). (medium)
Creating Processes
1. [Process] Your app may implement a chain of action/steps (at least 3 steps) to follow up on a
process designed to be included in your app (e.g., Group Project Submission: each group must
have n students (step 1), after reaching the target number of members, the process moves on to
the next step (step 2) which can be the provision of group information by the students (e.g., group
name, topic chosen); afterwhich a presentation date will be set by the lecturer (step 4); and then
confirmed by the group (step 5); and prior to the deadline, the presentation powerpoint will be
submitted by the group (step 6) and finally, a score will be provided by the lecturer. (hard)
2. [Process-visualise] Process visualisation. Your app may implement a graphical element to visualise
the progress of a process (e.g., stages of Group Projects or course completion). (medium)
3. [Process-Interact] Your app may allow users to micro-interact and/or add messages to each step of
the process (easy).
4. [Process-Permission] Only users with permission (e.g. all lecturers, or the user who created the
process, etc) can view messages in the processes. (easy)
Peer to Peer Messaging
1. [P2P-DM] Provide users with the ability to message each other directly in private. (hard)
2. [P2P-Block] Provide users with the ability to ‘block’ users, preventing them from direct messaging
them. (medium)
3. [P2P-Restriction] Enable users to restrict who can message them by some association (e.g. setting:
can message me only if we are currently enrolled in the same course). (hard)
4. [P2P-Template] Template messages or Macros (for peer-to-peer messaging or template posts (e.g.
a quick one-tap post)). For example, "Hi %USERNAME%, I am also taking %COURSE_NAME%.
Find me at %EMAIL_ADDRESS%, if you please. Cheers, %MY_USERNAME%". The use of tokenizer
and parser is mandatory. (hard)
Firebase Integration
1. [FB-Auth] Use Firebase to implement User Authentication/Authorisation. (easy)
2. [FB-Persist] Use Firebase to persist all data used in your app. (medium)
3. [FB-Syn] Using Firebase or another remote database to store user information and having the app
updated as the remote database is updated without restarting the application. e.g. User A (a
lecturer) posts an announcement, user B on a separate instance of the application sees the
announcement appear on their app instance without restarting their application. (hard)
Why and how to implement these features?
Each feature is designed considering one or more concepts covered in the course. Think about what
design pattern, data structure, persistence method, … you can use to implement it.
How many features should my group implement?
Each group must implement at least 6 General Features (in addition to the 4 Basic App features).
For groups that aim at achieving D and HD grades, you could refer to the indicative level of difficulty of
features and tackle more features to enrich the app. However, please make sure that you could
manage the number of planned features and review your plans periodically. Note that we expect
quality over quantity.
Suggest a new feature | Voice your feature
Is there a feature you would like to implement but is not listed here? No worries, you can post your
feature idea on our Wattle "voice your feature" forum with the information below. We will assess the
proposed features and, if it is approved, will be given a difficulty classification. Please note:
1. Any features which are approved in the forum can be pursued by any group.
2. Any feature that is refused can still be pursued but will NOT be assessed. Although it might count
towards the creativity criterion.
3. We will only accept new features until the end of Week 9.
A feature suggestion MUST contain:
- Post subject: feature name
- A description of the feature.
- Details as to what the feature would entail. (e.g., an additional tokenizer, custom B-Tree, etc.)
- Why is this feature relevant to the project and course? (short explanation, link to the course
content)
- Suggested difficulty level: (easy, medium, hard, very hard) followed by a short justification.
Please try and keep any features mentioned relevant to the course content and the core software
design criteria. Any features that stray too far from either of these will be refused.
Feature Request Example
Subject: Partially valid and invalid search query handling.
Description: The application’s search bar will be able to handle both valid and invalid search queries without
crashing the application and still provide the user with at least some search results in line with what was valid.
What the feature entails: modifying the tokenizer/parser that the application uses to handle valid and invalid
search queries without crashing and still providing a response.
Feature relevance: Tokenization and parsing.
Suggested Difficulty Level: medium.
***A kind reminder: A feature that does not work is not a feature, it is a bug.***
Surprise!
Building software can be an exciting activity. At some point in Week 10, requirements may change or
be added, and you may need to adapt your project to meet them. This is how it works in REAL LIFE,
and we will simulate it here.
Be prepared for changes! Build your software in a way that is easy to extend and change.
You may be asked to make small changes. This is to practice the software development/construction
process. If you successfully develop it, your final mark may be increased by up to 2 marks (your client
will "pay" more to have better software).
If a group does not participate in any of the checkpoints, they will not be eligible for this "surprise"
(missed opportunity).
Checkpoint
In week 7 and week 10, we will have checkpoints. You must participate in your lab session and show
your tutor what stage of development you are in (only ONE member has to present, make sure
someone in your group did it). For the first checkpoint, we expect you to have at least a schedule of
your development activities, the roles of each member described, and at least one meeting minute
besides an initial code structure. For the second checkpoint, we expect your app to be almost fully
implemented and tested. You also need to show your report and the completed sections. Your tutor
will review your schedule and will provide quick feedback. The checkpoints are mandatory.
*Note that every customer wants to know how the software is progressing. Here's the same, we are
your customer, you need to show that the app is being developed and that you will meet the deadline.
Every time you do not meet a checkpoint, your final mark for the group project will be reduced by 5
marks (you missed an important meeting!).
Note that besides those mandatory checkpoints, if you have any issues at all, please feel free to ask us
on the Wattle forum, lab or drop-in sessions.
Project Submission
We will use the school’s GitLab server for submitting the project. Your group should create a GitLab
repository and continuously update your work from week 6 to the submission deadline. We will
request you share the link to your repository during the group creation on Wattle (set the visibility of
your group project repo to private).
To get started, fork the course group assignment repository which provides some template files:
● Report.md (use it as a template for your report); Checklist.md (project minimum requirements);
statement-of-originality.yml; MeetingTemplate.md (a template for your minutes).
Code development
All of your work must be continuously and regularly updated to your group repository. You are
expected to manage tasks, including merging branches and consolidating your codes well ahead of
the deadline.
● You must include @author annotations for each java code file with the UID and name of the key
author. You must also include author annotations for methods and classes where significant
contribution were involved.
● Git commit: You must commit often and include meaningful commit messages. We expect to see
regular commits by each member during the full course of the project from the commit history.
Failing to do so will result in significant mark reductions and academic misconduct investigations.
● While you may use branches during the development process, only ONE branch (i.e., normally the
master branch of group Gitlab repository) will be assessed, in which you must place all the files,
including code files, report, meeting minutes, APK, etc.
● Remove unused code files and/or segments. Do NOT report a feature that was not actually
implemented in the final submission.
Use your own GitLab user account (UID) to commit your contributions. Add this information to your
report. (Failing to do this may result in zero marks and academic misconduct investigations).
Report (Important!!!)
The report is an essential part of the group assignment and should give us evidence and details of the
functioning of your group, project decisions and implementation. The technical outcome is a key
aspect of the evaluation of this project and your reasoning process and teamwork are just as important.
Therefore, you are required to produce a detailed report which presents the justification for your
design and team management of your project. A template for the report is available in our GitLab
Repo. It must be in the form of a markdown file titled ‘Report.md’ and include (but not limited to):
● Team structure and roles
● Summary of individual contributions
○ This section must contain each individual contribution to the project, including classes,
methods, lines of code, and link to the code files implemented by each team member.
○ Each team member is responsible for writing their own subsection.
○ A generic summary will not be acceptable and may result in team members losing a
significant amount of marks.
● An app summary with screenshots.
● A list of examples/use cases of your app.
● A UML diagram (e.g., class diagram).
● A design summary page (include justification for decisions made, diagrams, etc). The design
summary is an important item of your report and should include all decisions made and
information required to understand your decisions. This includes, for example,
○ Details about the parser (describe the formal grammar and language used)
○ Decisions made (e.g., explain why you chose one or another data structure, why you used a
specific data model, etc.)
○ Details about the design patterns used (where in the code, justification of the choice, etc)
○ If you implement the surprise item, explain how your solution addresses the task.
● A summary of the basic App and implemented features
○ List all items/features implemented in your project (Separate features into their categories).
● A summary of known errors/bugs (list of bugs).
○ A list of known errors and bugs demonstrates you tested your app. We may deduct some
marks based on the bugs listed in your report. However, if a bug is found by us but
reported, the part of the software containing the bug will not award you any marks.
○ How to write a bug report? Here is an example:
https://blog.instabug.com/how-to-write-a-bug-report-the-ideal-bug-report/
● A testing summary section (including e.g., number of test cases, description of tests,
coverage, etc.)
Be concise (just in case, according to the Oxford dictionary, concise means "giving a lot of information
clearly and in a few words; brief but comprehensive").
*If you are not familiar with YAML (for markdown files), you can refer to: https://commonmark.org/help/.
All attempted features MUST be documented
Note that if it is not in your report, we may not consider the feature, data structure, design pattern,
etc, as completed. It is your responsibility to report everything that was implemented in your project.
We are not playing treasure hunt and appeals will be rejected if what was implemented is not
explicitly described with reference to method names, line numbers, etc., in your report.
Please list all features you have attempted with the feature ID. Preferably, we would like you to
separate them by category and classify them for difficulty (this helps with marking).
For example (*Check assessment rubrics for more details):
Feature Category: Privacy
Implemented features:
1. [Privacy-Request]. Description of the feature and your implementation (easy)
○ Class X, methods Z, Y, Lines of code: 10-100
○ Class Y, methods K, L, M, Lines of code: 35-150
2. [Privacy-Block]. Description … … (medium)
Feature Category: Firebase Integration
Implemented features:
3. [FB-Auth]. Description of the feature and your implementation (easy)
○ Class A: methods A, B, C, lines of code: whole file
…
Other important items
You should place all non-android documents into one folder named Items at the root of your
repository. Make good use of links in your report to make reference to these documents in the
appropriate sections. These include:
● Team meeting minutes (at least 4 (this is the minimum!))
○ You should develop a clear plan of how the work will be divided and document the same in
the minutes of the first meeting.
○ Right after every meeting (max 2 days after, otherwise they will not be considered), upload
the minute to your project repo. Note that we will check the commit dates in your repo.
● Your conflict resolution protocol - Define this protocol in your first meeting (mandatory). This shall
include an agreed procedure for situations including (but not limited to):
○ e.g., if a member fails to meet the initial plan and/or deadlines
○ e.g., if your group has issues, how will your group reach consensus or solve the problem?
○ e.g., if a member gets sick, what is the solution? Alternatively, what is your plan to mitigate
the impact of unforeseen incidents for this 6-to-8-week project?
● A statement of originality (all members must be listed there and sign the document by adding your
own names to your group repository, using your own Gitlab account).
● You must bundle your app into a standalone APK that can be loaded and executed correctly on an
AVD (see video on Wattle in the Group Assignment Section).
● Create a short video titled `features.(mp4|mov|wmv)` that demonstrates each implemented feature.
The video should contain a visual representation of every feature showcased in the running app
with clear voiceover narration or written captions that explain the current feature being
demonstrated. Include both Basic and General features, in the same order as listed in the report.
● Your final submission at the default branch of your GitLab repository and the commit history will be
assessed. The project cannot be updated after the deadline (otherwise, you may get zero marks).
Individual Reflection and Peer- and self-evaluation
Each student much submit an individual reflection via Wattle, with the same due date as the group
report in Week 11. This includes:
● Individual reflection: write 100-120 words related to your experience during the group project (be
concise and direct). For example: how was your experience working in a team? Reflections on what
your team could have done better, what worked and what did not work? How was the work divided
and was that fair?
● Peer and self-evaluation: an evaluation of each member of your group:
○ Name - UID
■ Contribution: 25%
■ Justification: This member was responsible for the classes …, collaborated with
others, wrote sections X and Y in the report.
○ Name - UID
■ Contribution: 10%
■ Justification: This member was unavailable most of the time within week 7-9, did not
deliver some of the modules promised and recorded in the minutes (meetings 1 and
2). However, this member completed some modules (list …) and handled the minute
madness presentation.
○ …
*The "contribution" measures the percentage contribution of each member and must add to 100%.
For example, a group with 5 members who contributed equally to the project must have a
contribution of 20% for each member.
Group Project Demonstration
In week 12, there will be a hybrid group demonstration during our lecture time. This will be an
opportunity to showcase your project and also to get feedback and marks on what you have done.
This Project Demonstration will follow the Minute Madness format where each group will present a set
of timed slides within a predetermined time (slides will change automatically every x seconds). The
total number of groups will determine the duration of each presentation and the number of slides.
Your presentation must clearly present your topic and convince the audience that your app is
innovative and could be used in the real world. You must briefly talk about the structure of your
project, decisions made, and solutions for the problems faced during the project (use of a particular
data structure, design pattern, etc).
Your presentation must be clear, convey your ideas and give an overview of the software construction
process you and your team experienced.
I would recommend using some screenshots to show how your app looks (images can be better than
words sometimes).
More details related to the project demonstration will be released in Week 10. Slides must be
uploaded to the link to Microsoft PowerPoint in Week 11.
Best Practices for Using Generative AI Tools for Software Construction
Generative AI tools, such as ChatGPT and Co-pilot, offer immense value to software developers and
can significantly enhance their efficiency. These tools have shown the ability to generate code
snippets, suggest improvements, and