COMP2100/6442 Group Project | A Smart Search-driven App
v.01 - Project Description released (2023-08-30)
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
Each group should consist of 4 students. Groups can contain a mix of undergraduate and master students and
students from different labs (although members being in the same lab could be beneficial).
** Your group must be created and registered before Week 7. Register your group on Wattle.
Do not start late, it may impact your project outcomes. **
The version of Android Studio is specified on the course website.
Please use API level 33 for your target and compile SDK. For Min. SDK, you may select the default or an API level
between 29 and 31.
As a future Software Engineer, you should read and understand the specifications of various information systems,
tools, and models. Follow this spec closely. If you fail to do so, you will get penalised in several aspects during the
marking period.
Table of Contents
Introduction
Key requirements for the App
Part 1: Basic App
Part 2: Custom features of the App
Search-related features
UI Design and Testing
Greater Data Usage, Handling and Sophistication
Firebase Integration
Peer to Peer Messaging
User Interactivity
Privacy
How many features should my group implement?
Voice your feature
Surprise!
Checkpoints
Project Submission
Report (Important!)
All attempted features MUST be documented
Other important items
Code development
Individual Reflection and Peer- and Self-evaluation
Group Presentation (Minute-Madness)
Appendices
Best Practices for Using Generative AI Tools for Software Construction
EXAMPLES OF THEME AND IMPLEMENTATION
Is there an example of a smart search engine-based app?
How should I develop the search mechanism?
What about the data?
What about the data structures (Red-Black, AVL, B-Trees)?
Why and how to simulate a data stream?
Frequently Asked Questions (FAQs)
What does `[stored in-memory]` mean?
What kind of app should we develop?
Why and how to implement these features?
Which design pattern should I use?
How complicated should my grammar be?
What should my app look like?
Can I use the lab code?
IMPORTANT
Assessment and General Policies
Late submission policy
Originality
Marking Criteria
Individual Contribution
Assessment Rubrics
Other relevant information
Introduction
The objective of this project is to gain some experience in the process of software construction. 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.
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: A smart Search-driven App
This group is tasked to develop a Smart Search-driven Mobile App in Android. Given the user's input based on
pre-defined grammar(s), a query processor "understands" and retrieves the information that meets the user's
query in an “intellij” manner.
You shall first come up with an objective and a specific theme for the App, then implement a range of features
(functionalities/capabilities) which is presented in the User’s Interface. Your software, of course, needs to be of
good quality, sufficiently tested, and utilise data structures taught in this course. You are encouraged to come
up with your own ideas related to this topic and features as a group. (Be creative!).
Talking about a search-driven app, the first things that come to your mind are likely large search engines like
Google, Bing, etc.; but the search has also become the core component for a variety of applications.
We use them to find a new home to live in, to get information about how to cook a recipe, to find a car to buy,
to find a date, etc. When shopping online (e.g., Coles), the search bar is probably the most used component that
drives users' decisions. In more advanced uses, predictive search is also helpful by doing preliminary filtering
based on the current input, offering suggestions, and incorporating auto-corrections. See more examples in the
Examples Section.
Although the content for your App is open, your implementation must meet a range of 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, Tokeniser/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 custom features.
List of Basic Features, each with a [featureId]:
1. [LogIn] 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.edu.au Password: comp2100
Username: comp6442@anu.edu.au Password: comp6442
2. [DataFiles] Create data file(s) with at least 2,500 valid data instances, which are then used to feed your app to
simulate different users’ interactions on with the App. A data item can be an action (e.g., a new product
added to the server, a user requested to view a profile; etc.). (easy)
Important: Include the link to the data file(s) on GitLab and firebase repository (add
comp21006442@gmail.com as a Developer) in your report.
3. [LoadShowData] When a user is logged in, load data (from the file(s) and/or Firebase) at regular time intervals,
and visualise the same in the App. (e.g., If the main page contains a list of featured products, the user may see
an increased number of products; as well as receive notifications from interactions simulated from the data
stream). (medium)
4. [Search] Users must be able to search for information on your app. (medium)
The application is dependent on your app theme. E.g., search for information of products, users, by certain
criteria (e.g. #apple $1-2).
a. must make use of a tokeniser and parser with a formal grammar of your own creation.
The underlying implementation must also:
I. Contain at least one fully implemented tree data structure taught in this course (Red-Black, AVL, 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, Bespoken, etc.) or Firebase.
And you must
IV. Include JUnit4 tests for the non-UI components.
Part 2: Custom 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. The features should be connected to the theme
of your app, and is used in the App in a meaningful way.
Note that we will assess your skills by reference to the core assessment criteria through these features, so it is not
just about fulfilling the hard-criteria of the features. 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).
List of Custom Features
Search-related features
1. [Search-Invalid] On top of giving search results from valid inputs, search functionality can process and
correctly handle partially invalid search queries and give meaningful results. (medium)
a. See the Feature Request Example for an explanation of this feature.
2. [Search-Filter] Sort and filter a list of items returned from searches, with the use of suitable UI components.
(easy)
UI Design and Testing
1. [UI-Layout] Incorporate suitable layout adjustments in the UI components for portrait and landscape layout
variants, as well as different screen sizes. (easy)
a. No marks awarded by only using Android studio's automated support for orientation and screen sizes
without proper adjustments.
2. [UI-Test] Complete UI tests using espresso (not covered in lectures/labs) of reasonable quality and coverage
of the App. (hard)
Greater Data Usage, Handling and Sophistication
1. [Data-Formats] Read data from local files in at least 2 different formats (JSON, XML, etc.). (easy)
2. [Data-Profile] Create a Profile Page for Users or any Entities, which contains a media file (image, animation
(e.g. gif), video). (easy)
3. [Data-GPS] Use GPS information based on location data in your App. (easy)
a. (Hint: see the demo presented by our tutors).
4. [Data-Graphical] Create a Graphical report viewer to see a report of some useful data from your app. No
marks will be awarded if the report is non-graphical. (medium)
5. [Data-Deletion] Implement Deletion for your chosen tree data structure, and the deletion must serve a
purpose within your application. (medium)
a. Must be for a Red-Black, AVL, B-tree, or any other approved tree data structure.
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)
a. Extension: Without restarting, the app should be updated synchronously as the remote database
(Firebase) is updated. This means that users will be able to see the instant updates from another
user/content provider. (hard)
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’ and prevent another user 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)
User Interactivity
1. [Interact-Micro] The ability to micro-interact with items/users (e.g. like, block, connect to another user, etc.)
[stored in-memory]. (easy)
2. [Interact-Follow] The ability to ‘follow’ items. There must be a section that presents all the items followed by
a user, grouped and ordered. [stored in-memory] (medium)
3. [Interact-Share] The ability to share an item to another user via private message or other channels within the
App. [stored in-memory]. (easy)
4. [Interact-Noti] The ability to send notifications for interactions (e.g., follow request, product viewed, etc.). A
notification must be sent only after a predetermined number of interactions are set [e.g., when ≥2 requests
have been received or 2 follow requests have been received). (medium)
5. [Interact-Scheduled] Scheduled actions. At least two different types of actions must be schedulable. E.g., take
down a product on Monday 3 pm). (medium)
Privacy
1. [Privacy-Request] Users may send requests to view certain contents, which are then accepted or denied by
the relevant user(s). (easy)
2. [Privacy-Visibility] Given there are at least two types of visibility (public, private, ...), users can only see some
profiles or contents that are set to Public or after request being accepted (easy).
3. [Privacy-Block] Provide content providers (or users) with the ability to ‘block’ users (or contents/profiles). The
user shall then not be able to view the relevant contents from search results. (medium)
How many features should my group implement?
The minimum for each group is to implement 4 Custom Features (on top of the 4 Basic features).
For groups that aim at achieving D and HD grades, you could tackle more features (and refer to the indicative level
of difficulty) to enrich the app. However, please make sure that you can manage the planned features and review
your plans periodically. Again, we expect quality over quantity.
*** A kind reminder: A feature that does not work is not a feature, it is a bug. ***
Quality over quantity for marking. For example, excellent implementation (great code documentation, excellent
use of data structures, appropriate incorporation of design patterns, etc.) of 4-6 features along with other general
parts of the app will net you greater marks than a fair attempt of e.g., 15 features.
Voice your feature
Is there a feature you would like to implement but is not listed here? No worries, you can post your idea on our
Wattle "voice your feature" forum with the information below. We will assess the proposed features and, if it is
approved, confirm the difficulty classification and featureId. 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 tokeniser, custom B-Tree, etc.)
- Why is this feature relevant to the 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 tokeniser/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.
Surprise!
Building software can be an exciting activity. At some point in Week 9-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 will be asked to create the new feature and adapt your software to it. This is to practice the software
development/construction process. If you successfully develop it, your final mark could increase by up to 5 marks
(out of 30) (your client will "pay" more to have better software). Note that naturally, that will not be a trivial
addition. The maximum marks for the group assignment will remain to be 30. Note that this is an optional item.
Checkpoints
In week 8 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 (You should try to attend the checkpoint as a full team, but for the second
checkpoint, at least ONE member has to be present).
Expectations
Checkpoint 1:
• Have a schedule of development activities.
• The roles of each member.
• At least one meeting minute.
• A planned structure of your code.
• Completed the majority of the basic features.
Checkpoint 2:
• Almost fully implemented and tested.
• A reasonable draft of the report.
• An APK of the App.
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
customers, and you need to show that the app is being developed and that you will meet the deadline. Missing
one checkpoint will result in a 5-mark reduction in your final grade (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 (Thursday, Week 11). 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).”
Report (Important!)
The report is an essential submission component that gives us evidence and details of your work and the
outcomes. The technical outcome is a key aspect of the evaluation of this project, but your reasoning process and
teamwork are just as important.
Therefore, you are required to produce a detailed report which justifies your design and your team management.
A template for the report is available in our GitLab Repo. It must be in the form of a markdown file titled
‘report.md’. The template is provided to you in our repo, which contains a detailed description and examples of
the item. This includes (but is not limited to):
● Team structure and roles.
● Summary of individual contributions.
● An app summary with screenshots.
● A list of examples/use cases of your app.
● A UML diagram (e.g., class diagram, use case).
● Application Design and Decisions (include justification for decisions made, diagrams, etc.).
○ 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 testing summary section (including e.g., number of test cases, description of tests, coverage, etc. with
screenshots and links to the test files).
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 links
to the relevant files in your report.
Please list all features you have attempted, separated by category and with the feature ID. You may refer to the
report.md template. Note that you must include links to the relevant codes, and provide a brief explanation of
your implementation for each feature.
Do NOT report a feature that was not actually implemented in the final submission.
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 refer to these documents in the appropriate sections. These include:
● Team meeting minutes (minimum! 4)
○ 1st meeting: develop a clear plan of work allocations and document this in the minutes.
○ Commit the minutes and push to your repo right after every meeting (max commit date is 2 days
after, otherwise they will not be considered).
● Your conflict resolution protocol - Define this protocol in your first meeting (mandatory).
● A statement of originality (all members must be listed there and each should sign the document with your
own Gitlab account by adding your own names to your group repository.
● You must bundle your app into a standalone APK that can be loaded and executed correctly on an AVD (see
video on GitLab or Wattle).
● Create a short video titled `features.(mp4|mov|wmv)` that demonstrates each implemented feature (both
Basic and Custom, in the same order as listed in the report), max 3 minutes and 120MB. 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 feature being demonstrated.
● Your final submission at the main 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).
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 file with the UID and name of the key author. If the
author has significant contributions down to the level of methods or inner classes, etc., you should then
provide annotations at the corresponding level (e.g., method docString).
● Git commits: 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.
● For the codes, only the final state of your main branch will be assessed, and you must place all the files,
including code files, report, meeting minutes, APK, etc. there.
● When merging branches, do NOT squash your commits (unless you are aware of its meaning and believe the
commits should be squashed for better quality).
● Remove unused code files and/or segments.
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).
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% or 99%.
Group Presentation (Minute-Madness)
There will be a group presentation during the lecture in Week 12. This is an opportunity to showcase your project
and get feedback from your peers. The presentation 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. The default
time is 1.5 minutes per group (3 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
then-announced link by the deadline (Friday, Week 11).
Appendices
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 provide contextual guidance, thereby simplifying the coding process and reducing the time
and effort required to complete some tasks. By leveraging these AI-based tools, we expect you to focus more on
designing and refining your software rather than spending valuable time on mechanical tasks automated by AI
tools.
It is important to note that you and your group are solely responsible for any output generated by AI tools that
you have used to complete your group assignment. It is also mandatory to explicitly acknowledge where and how
these generative AI tools were used to assist in completing the assignment. Failing to acknowledge the use of
these tools is a violation of academic integrity rules.
Important:
1. Any output generated by Gen AI tools in your assignment must be explicitly acknowledged and attributed to the
individuals or the whole group for using them. This includes any pieces of code, comments, text, or other content created
with the assistance of Gen AI tools. Gen AI tools cannot be listed as authors, as they are not accountable for their outputs.
2. The explicit acknowledgement must be given wherever these outputs are used in your assignment and also in the
statement of originality file. Explain how Gen AI tools were used, as well as the proportion of the work done by each member
and the AI tools.
3. Gen AI tools can be used in a variety of tasks, including debugging, documentation and commenting, and assisting with
other writing and coding tasks. These tools can help to streamline the coding process, improve code quality, and increase
overall efficiency. However, the output generated by these tools should be critically assessed as they are not always accurate.
It is part of your job to review, validate and refine the output generated by Gen AI tools.
4. You must have a complete and thorough understanding of all aspects of your submission, including any part of the code
and report contents generated by you, any member of your group or an AI tool. You must be able to explain and justify your
choices and decisions at any time if requested to do so.
5. You must ensure that any output meets the project requirements.
6. Do not use generative AI tools to bypass learning or understanding. Use them to improve efficiency in non-core tasks.
Over-reliance on external tools may compromise your grasp of code structure and relevant concepts, hampering your learning
and performance in more complex tasks.
7. The use of Gen AI tools is optional.
EXAMPLES OF THEME AND IMPLEMENTATION
Is there an example of a smart search engine-based app?
Yes, plenty of them! Think about things that we could define a grammar for:
• A Real Estate App where users can query the type of properties they are looking for (example query: bedroom = 1; rent
< 400;")
o Scenario: You are looking for a one-bedroom apartment that meets your budget.
• A Car Sales App (example query: km < 5,000; price > 40,000)
o Scenario: You are looking for a new car to buy with low mileage and a price to suit your budget.
• A Recipe App (example query: "eggs = 3, chocolate = 1, preparing time < 5")
o Scenario: You are at home and have only a few ingredients, what could you prepare with it?
• A Prescription App (example query: "500mg paracetamol; price < 50;").
o Scenario: A pharmacist needs to prescribe a medicine that contains a specific dosage of paracetamol and costs
less than $50. The pharmacist may not be aware of all possible commercial names of the medicines and the ones
s/he knows are out of stock.
Is there any running example? Let's say you want to create a "smart" Search Engine-based App for Real Estate.
This Real Estate app provides the users with an interface containing an input field where users can query the type
of properties they are looking for (see Figure 1).
Figure 1. Real Estate App Example
Query Examples (both examples should be correctly parsed):
• A possible query is: "bedroom = 3; rent < 700;" (you can read this query as "a user is looking for an apartment
with exactly 3 bedrooms AND rent less than $700")
• Another possible query is: "rent < 400; bedroom = 1;" (you can read this query as "a user is looking for an
apartment with rent less than $400 AND exactly 1 bedroom")
Your query processor is responsible for tokenising the query, parsing it, and evaluating it.
How should I develop the search mechanism?
Your search mechanism is responsible for tokenizing the query, parsing and evaluating it. You must define your
own grammar and document it. You can use the CFG Stanford tool to help you create your grammar.
Example for an educational app: Search: java and #advanced and @active
In this case (with a corresponding grammar and parser implementation), the user is looking for courses with
“java” in their name or description field, annotated with the tag “advanced”, and has an active status currently.
Hint: Which data structure would be most appropriate (or efficient) for this case? Your group must decide how
to implement it for efficiency, generalisability, extensibility, etc.
What about the data?
The data must be in a file and be structured in a way that is easy to be retrieved/processed.
Let's say the data for your app is stored in a local XML file structure as follows. Here is an example for representing
reviews for courses. Note that this may not necessarily be the best format, and you must decide the best format
for your app, which will be evaluated. For example, the following example records the information for a course. In
this example, each course is considered a single instance.
...
RENT
600
townhouse
3
…
…
*Note that you need to generate the data instances for your application as well the data format/structure. You
are free to choose any file format (JSON, XML, Bespoken, etc.). You can create a script to generate your data, a
script to scrape from the Web or manually create it. You can also get data provided by some API and platforms
(e.g. Khan Academy API, Kaggle). This and only this script can be written in any programming language (Java,
Python, etc). Please, make sure you are allowed to download the data from external sources and that the script is
included in your repository.
**As an option, you can use Firebase (and JSON) if you feel comfortable with it and if this is the best choice for
your app.
What about the data structures (Red-Black, AVL, B-Trees)?
You must know where, which, how and when to use it. It depends on how you design your app. Think about what
data structure you would use if you needed to search for something. For example, if you go for a tree, what would
be the key of your tree? Is this the most appropriate data structure for your app? Discuss with your group.
Let's go back to our example: A user is looking for properties that have 3 bedrooms and rent is less than $700.
Which data structure would be most appropriate (or efficient) for this case? What is/are the key(s) of my
tree(s)? Should I use one or multiple trees? Should I allow duplicate keys in a BST? Your group must decide
how to implement it.
Why and how to simulate a data stream?
To simplify the development of the app instead of using a client-server model, we allow you to create a file to
simulate users interacting with your app. You may want to create a method or module to read from a file every x
seconds and feed the new information into your application. Note that there is a Wiki article written by a former
student that may be helpful for this task. (You should also consider writing a good article to share your knowledge
with your colleagues. Wikis are also an example of learning platforms).
Frequently Asked Questions (FAQs)
What does `[stored in-memory]` mean?
It means that for the particular feature, storing data in the temporary memory (until the app is closed) would be
sufficient, but of course, storing data persistently on the device or remote databases is also acceptable.
What kind of app should we develop?
You could adopt a wide range of themes and features as long as you utilize Search as a core feature, including but
not limited to those example apps in the project introduction.
For any particular theme, you could think about what purposes could be fulfilled, or what issues could be resolved
with the help of a mobile platform. Alternatively, you could also select an existing application as your starting
point, and bring improvements and innovations with some changes in features. You can also think of certain target
users and sectors (e.g., industry training, military training) while deciding on the theme of your App.
We expect you to think outside the box and develop your own idea! Creativity and Novelty are part of the marking
criteria. It does not need to be complex, simple ideas are also good.
On the other hand, your application is only a prototype that showcases how your idea could be developed and
implemented in a real application. Please prioritise your effort on the core aspects of this project before
developing additional features. In particular, visual appeal is only one of the assessment criteria within “User
Interface”. We suggest you not overly focus on the artistic design of the App beyond simple alignment and the
use of basic UI components and toasts.
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.
Which design pattern should I use?
Again, you must know where, which, how and when to use it. It depends on how you design your app and the
features you implement. Several features (!!!) were proposed thinking about the most appropriate design pattern
to be used. You can use design patterns that were not covered in the course, but do not forget to explain/justify
them in your report.
How complicated should my grammar be?
It does not need to be complicated, but it must be unambiguous and easily extendable. Most importantly, you
have to demonstrate that you know how to implement it and be consistent with your app theme.
What should my app look like?
You are free to design your app. Be creative and check the rubrics.
Can I use the lab code?
Yes, you can, but you must reference it in the SOO and the code, 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 your completion of a feature.
Can I use pre-made solutions (e.g. 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).
IMPORTANT
We would like to ensure that you are reading the entire document carefully. Please go to the Wattle course site
and find the forum thread titled "Group Project Mystery". Without revealing anything, please leave a message in
the thread stating the following "Sergio, I've just solved the mystery". This will let us know that you have read
and understood the entire document. (Please do not just ask your friends to do this or tell them about this –
which would defeat the purpose of this. Thank you.)
Assessment and General Policies
Late submission policy
As the project will be done iteratively over the second half of the semester, every group should have something
that will gain a pass mark well before the due date. No late submissions shall happen. Whatever your group has
done up until the due date will be assessed. You are not allowed to submit/update any files after the deadline.
Originality
The project must be your own original work. If you make use of any code that is not your own, it must be clearly
referenced. This can be done by adding a simple comment next to the code stating where you obtained the code
from as well as in the statement of originality. This is very important, as any breach of this needs to be investigated
and reported. You are much better off not doing this project than copying a small part of code and risking academic
misconduct. Remember, we are assessing your code, not someone else’s code.
Every person in the group is responsible for the originality of every part of the project (regardless of who actually
wrote or contributed to it). Any violation of the academic honesty and plagiarism policy will result in the entire
group receiving the mark of zero for the group project.
*Any images or other assets that you copy from the Web must be attributed (e.g. from splash.com). This must be
added to your statement of originality. Ideally, you should only use assets that you have the right to copy, such as
ones you create yourself, are in the public domain, or under a Creative Commons License. With the statement of
originality, you are safe and will be assessed only based on work done by you and your group.
Marking Criteria
Marks will be based on several criteria (check rubrics and other requirements in the specification).
The indicative weight for each criterion in determining the final grade is displayed as follows.
Final Group Project (FGP) =
(3 + 4  +  1  +  3  +  2( + )  +  1/  +  1)
15
Note that despite the indicative formula presented above, violations of the rules for assignment submissions may
result in additional penalties, depending on the severity. Examples include:
● Poor GIT practices (e.g., pushing significant amount of codes to the repository at once);
● Late/missing submissions in any items (e.g., individual reflection);
● Misleading content in the submissions (e.g., reporting features that are not implemented, misrepresentation of
individual contributions).
● Note that for an incomplete submission may likely lead to more deductions in the relevant parts on top of the
1/15 weight for `Submission`.
Each criterion will be marked as indicated in the Assessment Rubrics. To score 'excellent', you must satisfy all the
'very good' criteria. To score 'very good', you must satisfy all 'satisfactory' criteria.
Individual Contribution
You will be assessed individually and as part of the group. You must make sure that the work is divided up so everyone
has the opportunity to undertake some coding and contribute to the overall project. Marks will be reduced for
members who contributed much less than others, and for the group for poor group management (remember, this is
a group project and you must work as a team and collaborate effectively).
Note that each group is expected to contribute approx. 80 hours for this project. The group marks DOES NOT default
to be the same for each member. Group members who contributed much less than others will receive an extra [5,80]%
penalty. Members who did not effectively contribute will receive zero marks.
Each member must implement and commit a non-trivial amount of code (will be checked!). Specifically, this entails
being the key author for at least TWO features (Basic and/or Custom), on top of having contributing to other tasks
such as report, meetings, presentation, testing, etc.
We also expect you to commit (reasonable amounts of code) frequently (e.g., twice every week from week 7!). Last-
minute commits and lines implemented are not expected in large projects and, therefore, marks will be deducted for
poor project and time management. We have assessed hundreds of projects before and we know that those who start
early, finish early and deliver a better product. This is our way to help you do better :)
The individual contributions must be in the report and reflected in the meeting minutes (tasks assigned and completed
by each member), as well as reflected in the Git commit history. Peer and self-evaluation must be submitted to Wattle
by each group member. This should be done independently (do not discuss with your groupmates – make your own
fair judgment and justify the same) and only examiners have access to the individual reflections.
Do you have any advice?
Read this document and do not leave it to the last minute. Choose your teammates carefully (run interviews,
align expectations, check their availability and commitment to this assignment). Be upfront about your
expectations and agree on that with your teammates. Define tasks for each member of the group. Regularly
check if your group is advancing with the tasks given to them. Read and discuss each item in the list (parts 1 and
2) with your group before implementing it. Be prepared for a plan B if something unexpected happens. Don't
leave it to the last minute (yes, I intentionally repeated it).
Assessment Rubrics
Remember teamwork is a key learning outcome for this project, so I would encourage you to prioritise working well
as a team over extending the project.
The basic and custom features will be assessed based on diverse aspects of software design as well as the actual
outcome in the App (the ADK). The following rubric lists the aspects of consideration based on the judgment of the
markers.
A full mark will only be granted if there are no bugs or design issues for each implemented feature. Partial marks
may be given depending on the quality and progress of implementation.
Criteria Excellent Very Good Satisfactory Unsatisfactory
Data Structures Chosen data structures well
suited to subsequent usage,
leading to efficient code in
terms of both programmer and
computing time.
The chosen data structure can
grow as the input grows
without concern for memory
(scalability).
Data structures are well suited
for subsequent usage with
minimal conversion or
transformation required.
Satisfactory choice of data
structures leading to inefficiency
or repeated need to convert data
structures or values to solve
tasks.
Unsuitable data structures were
chosen leading to significant
inefficiency or inability to solve
tasks.
Data structures loaded in each
task or different data structures
used for each task.
Code Quality
and Organization
Excellent documentation,
naming and style, following
conventions and making the
code easy to read. Code is well
commented and highly
understandable.
Code is very well organized,
using generics and inheritance
as appropriate.
Construction for reuse. Easy to
extend.
The overall program structure
makes the code easy to follow.
The program is modular and
easily expandable.
Good Documentation, naming
and style are complete,
consistent and appropriate. Code
is well commented and partially
understandable.
Good code organization with
appropriate use of inheritance.
(mostly) Construction for reuse.
Easy to extend.
The overall program structure
makes the code easy to follow.
The program is modular and
easily expandable.
A reasonable attempt at
documentation, naming and
consistent style, but it could be
improved in places. Code is
partially commented on and
partially understandable.
Alternatively, more significant
shortcomings in one aspect.
Inconsistent organization and/or
repeated code.
Construction mostly with Reuse.
Code can be partially extendable.
Missing or poor documentation,
poor naming, poor coding style.
Significant unnecessary code.
Lack of comments in code / code
is not understandable.
Poor code organization, or Code
is very difficult to follow.
Construction with low
reusability. Difficult to extend.
Missing APK.
Lacks @author annotations and
@feature in the code files.
Report Report is well organized, well
presented, clear and concise.
Project decisions are well
detailed with examples and
discussion.
It also presents code and
analysis. UML diagram(s) is/are
presented.
A clear and detailed testing
summary is provided.
References are provided.
Report is well organized and
presented.
Project decisions are detailed
with suitable examples and
discussion.
It partly presents code and
analysis. Some UML diagrams are
presented.
A clear testing summary is
provided.
References are provided.
Report includes necessary
required content, but lacks
organization and/or
presentation (e.g., template text
from the sample were left
uncleaned)
Project decisions are not clear
but present some examples and
discussion.
It does not present code and
analysis.
References are partially
provided.
Limited discussion or
understanding of issues. Poor
decisions made and choice of
examples. Poor organization, or
lack of clarity makes the report
hard to follow.
References are not provided.
Reported information
contradicts the submission (e.g.,
a reported feature was not truly
attempted).
Testing JUnit coverage test achieves at
least 70% of code (without UI).
Clear evidence of testing to
verify correctness and
robustness. Exceptions and
error cases are checked.
Clear evidence of Unit and
Integration tests.
JUnit coverage test achieves at
least 60% of code (without UI).
Some evidence of testing to
verify correctness and
robustness.
Clear evidence of boundary and
normal functioning tests.
Some evidence of Unit and
Integration tests.
Repeatable unit testing is
performed on the majority of the
project.
Appropriate use of Test Suites
and Parameterized tests.
Test are not well designed
(random tests).
Minimal or no test cases can be
found.
User Interface /
User Experience
(UI/UX)
User interface is intuitive and
can be easily used without
guidance.
Use of consistent theme and
style.
Feedback is provided to users
based on interactions.
UI is responsive (adapt to
different screen sizes and
orientations).
Stylish and friendly look and
feel.
User interface is mostly intuitive
and can be used with little
guidance.
Use of consistent theme and
style.
Some feedback is provided to
users based on interactions.
UI is mostly responsive
(reasonably adapt to different
screen sizes and orientations)
Friendly look and feel.
Standard user interface and not
very intuitive (needs some
guidance).
Use of theme and style are not
consistent. Navigation is not
clear.
Lack of feedback to users based
on interactions.
UI is responsive and provides
only screen orientation mode.
Standard user interface and
unintuitive (needs guidance).
Inconsistent use of theme and
styles. Navigation is not clear.
Lack of useful feedback to users
based on interactions. No
guidance to users.
UI is not responsive and provides
only one screen orientation
mode.
Creativity /
Uniqueness /
Specific Theme
App is innovative and can be
applied in a real-world
scenario.
Problem statement is clearly
defined and has the potential
App is innovative and can be
applied in a real-world scenario
to a limited number of
beneficiaries.
The developed app can be
applied in a real-world scenario
to a limited number of
beneficiaries.
Standard App created only for
demonstration purposes.
Lack of innovation, creativity and
special features.
to impact multiple
beneficiaries.
Unsolved problem with high
significance.
High degree of creativity in the
design and features.
Problem statement is clear and
has the potential to impact a
limited number of beneficiaries.
Problem with high significance.
Good combination of unique
design and features.
Problem statement is clear but
with low potential for impact.
Some special features are
incorporated.
Low or no potential for impact.
Teamwork A clear decision-making
procedure is formally
established by the group, a
document formalizes the roles
and contributions/ideas given
by each member of the group.
Goals are well established, and
priorities are well documented
and organized.
All members respect each
other, and conflicts are
resolved with open dialogue
and compromise (well
documented).
A conflict resolution approach
is documented and well
defined. Disputes are described
along with their outcomes.
Communication has worked well
within the group and you have
been able to adapt to a situation
that has arisen.
A procedure for making decisions
is informally established by the
group.
Goals are clear and achievable.
Priorities are clearly
documented.
All members respect each other,
and some conflicts are resolved
with open dialogue and
documented.
Interactions between group
members are documented.
A conflict resolution approach is
documented. Disputes are
described along with their
outcomes.
Tasks have been well divided,
with each member completing a
significant part of the project (Git
history and minutes).
A procedure for making decisions
exists, but it is not clear.
Goals are unclear, too general or
unachievable.
Some members did not feel free
to contribute, ask questions, or
share ideas. Interaction between
group members is limited and
not documented.
A superficial conflict resolution
approach is documented.
Disputes are described along
with their outcomes.
Cannot find (at least 3) meeting
minutes.
One-person team (by Git
history). Decisions are made by
individuals.
The group atmosphere is
competitive and individualistic.
Conflicts cannot be resolved
between group members. Low
interaction between group
members.
No conflict resolution approach
is documented.
*If you want to have your assignment remarked (appeal), you need to explain with reference to the rubrics why
your original mark was wrong.
Other relevant information
It is recommended that you develop your app on an Android Studio emulator so that you can demo your app via
a shared computer screen. The app must be developed using Java.
There will be no restrictions on external libraries, but make sure that the external libraries are clearly referenced
in your documentation and report and package it correctly. Only remember that we will evaluate what your
group implemented, this is very important to understand!
Last but not least, here is what Linus Torvalds said about his project in 1991:
It is time to code! Have fun!