COMP0034 2022/23 Coursework 2

specification

20/2/23: Corrected the individual % for ML for testing.

Contents

  Introduction

  Data

  Coursework content

  Progress and support

  Submission

  Marking

  Referencing

Introduction

This document specifies coursework 2 which is worth 50% of the assessment marks available for the module.

In COMP0035 you designed a web app that does one of the following:

  provides a REST API that allows users (developers) to access one or more aspects of the

data set; or

  provides a feature that uses a simple machine learning model e.g. to make a prediction or

classify a submission.

For this coursework, you can choose either of the above. That is, you do not have to develop what you designed if you no longer wish to. If you designed a REST API you can choose to  develop a ML app; and vice versa.

Given your chosen option, for this coursework you are asked to provide evidence of:

1.  Application code

2.  Test code

3.  The use of relevant tools and techniques

These are detailed in the following sections.

Data

You must only use the data sets as approved for COMP0035.

Which data set to use depends on your circumstances. Please refer to the table below.

The same rules for ethics and data protection apply as for all other coursework in COMP0034

and COMP0035.

Coursework content

Getting started

Create a GitHub repository using the classroom. All aspects of the coursework must be included in a single source code controlled repository. This should be in GitHub unless you have a reason that requires you to use an alternative. Use the relevant link to create a copy of the starter repository:

  GitHub classroom link for individuals

  GitHub classroom link for groups

Technologies that must be used

You may also use any other Python package that is freely available, e.g. inPyPi; for example FlaskSQLAlchemy, Flask-Marshmallow, Requests, Flask-JWT-Extended, etc.

scikit-learn is suggested as the machine learning library though you may use any freely available python package.

JavaScript is not assessed in the marking scheme and therefore its use is discouraged. You are not permitted to use JavaScript to create the web app e.g. use of React or similar.

What you need to create

The following table summarises what is needed for each type of app and whether individual or group.

The coursework marking is split into:

  Application code

  Testing

  Use of tools and techniques

1.  Code a Flask app (A, B, C, or D as relevant) that runs a web app using the python Flask framework. It is suggested that you use the designs from COMP0034 coursework 2, though you are not assessed against these so you may change them to any extent you wish. Refer to the matrix for the elements that are expected to be in each app type.

C1. Create the structure and configuration for a Flask app. Consider config for environments, factory function create_app to create the app, blueprints.

C2. Create the routes in the Flask app.

C3. Create model classes to represent the data set. Individuals can read the data

from CSV or a SQLite database, groups must create an SQLite database. You may optionally need to create classes to model new data that your app requires but that is not in the dataset, e.g. to model users of the app.

C4. Create Jinja2 page templates that include CSS styling (e.g. using Bootstrap). Consider template inheritance.

C5. Create form classes. This would only be needed if you have a form such as

login, signup, create content for a blog etc.

  C6. Create the machine learning model. Use whichever Python library you are

familiar with e.g. scikit-learn or other. Since this is not explicitly taught in the course then you can use Jupyter if that is what you are familiar with using and submit an .ipyb file.

  C7. Demonstrate error handling e.g. custom HTTP error pages, try/except,

validation of user input, use of Flask flash messages for warnings/errors etc.

Groups are required to add an extra ‘feature’ to their app (C or D). If you have not already specified one in COMP0035 coursework 2, suggestions include (but are not limited to):

  Simple forum/blog

  Authentication/account management for the REST API. Consider use of JWT.

  A login and account management feature that allows users to create an account and

manage their account page details such as reset password, provide additional account    information or avatar etc. Investigate Flask-Login, Flask-WTF and Flask-SQLAlchemy.

  A feature that displays relevant information using the REST API, and/or allows the user

to search.

2.  Optionally, add any explanations that relate to this section toREADME.md. You do not have to write about your app. However, if you wish to provide an explanation of any aspect of your app that you think the markers should be aware of then note this. For example:

  to explain decisions that you made with respect to the application design or code   to indicate features of your app or code that might not be obvious

  to indicate aspects of the app that you didn’t manage to get working as you would

have desired. For these please state:

  what the app should do

  what the app current does

  what steps you took to try and address the issue

1.  Write and run tests. Refer to thematrix for which of the following are expected for each app type.

T1. Flask app routes: Flask test client and create pytest tests for Flask routes.     T2. Helper functions:Pytest tests for Python helper functions e.g. utility functions

for routes. Only applicable of you have such helper functions.

  T3. Integration/functional tests: Selenium web driver with pytest and Flask test

client to create functional/integration tests e.g. carrying out sequences of steps in a web browser as if a user of the app

  T4. Coverage: Report on coverage and consider the extent to which your tests

do/don’t cover your code. It will be assessed by evidence that your tests test the      core functions and features of your app and any of the helper functions you create in your code.

2.  Add to the README.md:

  evidence (e.g. screenshot, saved test reports) of the results of the tests running

  evidence of coverage reports; and comment on the extent to which you decided to

test your app (100% is unlikely)

  evidence of CI reports related to tests (a URL to a GitHub Action in your repo is

sufficient)

Use of tools and techniques

1.  Provide evidence that demonstrates effective use of appropriate use of software engineering, and data science, tools and techniques. Refer to the matrix for what is expected for each app type. The type of evidence that is expected is:

  TT1. Source code control: Add URL to your repository to README.md.

Demonstrate use of source code control ( evidenced by commit history). This should be GitHub. If you can’t use GitHub then a suitable alternative must be agreed with the course tutor.

  TT2. Set-up instructions: Add instructions to set up and run your app to

README.md

  TT3. Dependency management: Provide a requirements.txt file in your zip file,

or if an alternative then appropriate files and instructions for using these

  TT4. Linting: Add to README.md. State what linter you used and a brief summary

of actions you took. Before and after screenshots are good (if using GitHub Actions then the workflows can be checked by markers instead of screenshots). You don’t   need to prove zero style warnings as you may have valid reasons for not implementing some linter suggestions (give your reasons if this is the case).

  TT5. Continuous Integration: Add URL to your continuous integration in

README.md. If you use something other than GitHub Actions, please provide access to [email protected] or provide screenshots in README.md.

  TT6. Anything else: If you use other tools/techniques please provide screenshots,

PDF, or other formats that can be downloaded and included in your zip (these must be able to be opened using freely available tools). URL links to external sites are      not accepted for marking purposes since they may be modified after the Moodle submission timestamp.

Matrix

The matrix below indicates what is expected for each of the three sections (Code, Testing, Tools and T echniques) for each of the app types:

A.  Individual: REST API

B.  Individual: ML app

C .  Group: REST API

D.  Group: ML app

Key: Y = Required, ? = Required in certain circumstances, Anything left blank is optional.

Progress and support

Scheduled lab sessions

Use the weekly scheduled lab sessions to work on your coursework. The coursework tutors and several PGTAs will be available in each session and able to give you support and guidance.

Moodle Q&A

Outside the scheduled lab sessions please post any requests for technical support to the Moodle

Q&A.  Do  not  send  emails  to  the  tutor  or  PGTAs  directly  as  you  won’t  receive  a  response.

When  posting  questions  about  your  code,  please  post  the  URL  to  your  repository.  This  enables the  tutor  and  TAs  to  see  your  code  which  is  usually  essential  for  solving  technical  problems! Other  students  won’t  be  able  to  access  your  repository  from  this  URL  so  long  as  your repository  is  private  and  is  within  the  ucl-comp0035  organisation.

Submission

Submit all the work as a single zip file on Moodle.

Do  not  include  the  venv  in  your  submission  please.

If your  dataset  exceeds  the  maximum  file  size  for  Moodle,  please  include  the  in  README.md an  explanation  of where  the  dataset  can  be  found.

Please  refer  to  Moodle  for  the  deadline  date  and  time.

Moodle  is  used  for  submission  as  it  records  submission  date/time  and  authenticates  students. Use  of  GitHub  is  not  considered  submission.

The  .zip  should  expand  to  the  correct  folder  structure  with  all  required  files.  GitHub  provides an  option  to  download  repository  contents  as  a  zip  which  can  then  be  uploaded  to  Moodle.        Ensure  that  all  files  are  included  in  the  zip ,  files  that  are  only  provided  as  URLs  will  be                 excluded  from  marking  consideration  (since  they  may  be  modified  after  the  coursework  is            submitted).

Include  in  your  submission:

Marking

Late submission

Late  submission  rules  apply.  Any  penalties  for  late  submission  are  applied  by  the  computer            science  teaching  and  learning  team  when  marks  are  entered  in  portico.  The  mark  you  see  in  the Moodle  gradebook ,  therefore,  is  the  mark  before  moderation  or  any  penalty  has  been  applied.

If you have an approved extension resulting from a SoRA or Extenuating Circumstances, these will be carefully checked by the teaching and learning team before marks are entered in portico. However, the due date in Moodle will not be modified, so it may appear on Moodle that your    submission is late even though you have an approved extension to cover the period.

An extension for any member of a group applies to the whole group since it is not possible to separate out the work of one person from the rest of the group.

Mark allocation and calculation

Marks will be allocated for the coursework as follows.

It is expected each person will spend 25 hours on the coursework. While not exact, an indication of the effort given the marking weighting is shown below.

An overhead for co-ordination is expected for groups. This has been assumed at 1 hour per   person per week for 6 weeks ( total 24 hours). This allows for a 30-minute weekly meeting as well as review of work items.

Additionally, groups will be required to complete an IPAC assessment that includes their own  and peers performance. The calculated IPAC rating will then be applied to the raw group mark i.e.

individual 's coursework mark = group mark * IPAC rating.

IPAC guidance is given in theassessment overview .

Grading criteria

The ‘UCL Computer Science: Marking Criteria and Grade Descriptors’ will be used to assess    the coursework (using only the criteria that are relevant to this coursework). In addition to the standard descriptors, further guidance is given for this coursework in the table below. Given     there can be a wide range of solutions it isn’t possible to cover everything you might do to       achieve a given level. The following should be used as guidance. Higher mark bands assume      that the criteria from lower bands have been achieved.

Some aspects below relate only to groups, individuals, or both. Check the coursework content

section  of this  specification  for  what  each  needs  to  include.

Flask app and associated code

Marking  considers:

extent  to  which  the  requirements  this  section  are  met

the  extent  to  which  the  solution  evidences  appropriate  use  of the  required  technologies      structure  of the  app  (basic  structure  or  more  complex  structure  with  config ,  factory  app , blueprints  etc)?

code  quality  such  as  adherence  to  relevant  standards  (PEP8 ,  PEP257);  documentation , structure,  use  of functions  or  classes  to  improve  structure  and  re-use,  etc

use    and  effectiveness    of error  handling

range  of skills/sophistication  of the  solution/complexity  of the  coding  techniques  involved etc.  demonstrated  in  the  resulting  application

Testing

Marking considers:

extent to which the requirements this section are met

the range, challenge and complexity of the test code.

the quality and structure of the test code. This includes code quality, test naming and structure, documentation, appropriate use of assertions, use of fixtures etc.

the extent to which your tests cover your code base. This is not assessed using coverage

statistics since a single selenium test can appear to provide 100% coverage. It will be assessed by evidence that your tests test the core functions and features of your        dashboard and any of the helper functions you create in your code.

Software engineering tools and techniques

Marking considers:

  extent to which the requirements this section are met. Not all tools/techniques are

required for individuals.

  demonstration of routine use of the tools at the appropriate times for the coursework

(e.g. source code control would be expected to be used through; CI may only be used when testing starts).

  evidence that the candidate understands the use of the tools and has used them to

improve the delivery of their coursework