Creating a software design for a COVID-19 shielding food box delivery system
Inf2-SEPP This coursework builds on Coursework 1 on requirements engineering, and needs to be attempted fully as a group. Please refer
The aim of this coursework is to create and document a design of the COVID-19 shielding food box delivery system, as well as reflect on some related Professional Issues concerns.
This coursework builds on Coursework 1 on requirements engineering, and needs to be attempted fully as a group. Please refer back to the Coursework 1 instructions for a system description. The follow-on Coursework 3 will deal with implementation and testing, and related professional issues.
This coursework is split into 2 practical parts:
- ASoftware Engineering part (Section 3), including tasks and self-assessment.
- AProfessional Issues part (Section 4) including tasks and self-assessment.
1.1 High level self-assessment instructions Inf2-SEPP
The self-assessment in each part will be part of your mark. For the self-assessment, you should consider to what extent your have met the assessment criteria for that part of the coursework. For each criterion, write one paragraph (a minimum of 2 sentences) discussing how well you think you have met that criterion and why (i.e., strengths and weaknesses of your solution).
Moreover, we encourage you to reflect on things like: your experience with the approaches used, progress and work within your team, difficulties you encountered and how you addressed them. Parts that you are particularly proud of and why, parts that you are not happy with and you could further improve. How you could improve them.
You should make a real effort to be reflective (especially for the criteria where you have more to say), as well as honest, here. Please note that only making statements about the criteria without justifications (e.g., “We identified stakeholders excellently well”) is not acceptable and will result in no credit for this part.
After the first deadline to this coursework, the markers will provide you with feedback on the same criteria to the one you have self-assessed on.
Moreover, we provide you with a set of ratings for each of the parts. Which give you an understanding of your progress with that part of this coursework. For the Software Engineering part, we keep these ratings informal. So that we can provide you with an initial idea of how well you did after the first (formative) deadline.
Please note that these ratings do not have a direct correspondence . With the grade intervals of the Extended Common Marking Scheme1 which we will use for your final mark. But they are still meant to be informative. For the Professional Issues part. As the first deadline is the only and final deadline. The ratings already correspond with the grade intervals of the Extended Common Marking Scheme which we will use to compute your mark for this part.
2 Updates to the system description Inf2-SEPP
The Scottish Government has been successful in establishing collaborations on the food box scheme with numerous catering companies spread across Scotland. A decision needed to be made as to which catering company would handle each pre-assembled food box order. Such that as many orders can be delivered to shielding individuals as possible, and resources are not wasted.
After discussions with the catering companies and the consideration of different options, a decision was reached that the catering com- pany which has headquarters closest to a shielding individual’s location (considering addresses, postcodes) will always be handling pre-assembled food box orders for that shielding individual.
As developers of the food order box system, you have raised the awareness of the Scottish Government about potential problems in allowing people to order from a su- permarket system directly. As they may not be shielding individuals and thus eligible to get such free food boxes. You recommended, and your customer and the supermarkets agreed. That the food box order system should issue each user with a personalised single- use link allowing them access to a supermarket’s dedicated food box order page. The supermarket system would check the link. As well as the request issuer’s IP, to decide whether to offer the user access to this page in order to make an order.
3 Your Software Engineering Tasks (worth 68.75% of the final mark for this coursework)
3.1 Design document
Ultimately, what you need to produce for this coursework is a design document that combines descriptive text with UML class, sequence and communication diagrams, de- scribing the food box system. The following subsections specify what should be included in this document.
There is no requirement for you to use a particular tool to draw your UML diagrams. The draw.io tool2 is one easy-to-use tool you might try. If you draw your diagrams by hand, be sure to include a high-quality scan in your report.
3.1.1 The system architecture
The food box system is intended to be used over the web, with shielding individuals potentially accessing it through different ways (we suggested SMS messages in CW1. But for the future the Scottish Government may also be considering web interfaces for it on computer, mobile and tablet).
Moreover, the Scottish Government is foreseeing that they may need to extend the system in the future so that it is also used for individuals from remote areas in Scotland. And for the delivery of other goods like first aid kits and medication. Or even the provision of emergency services. Therefore, the system may in the future need to interact with the systems of many other providers and organisations. It may also need to be used concurrently by a large number of users and systems.
Given your understanding of the system description, as well as your customer’s plans for its future from above, what would be your choice of type of architecture for this system, from the ones that you studied in the lectures and required reading? Please justify your reply, making reference to what you know about the system and about your chosen type of architecture.
Important! For the rest of this assignment, you should NOT make any assumptions that any architecture (your proposed one or others) are used.
Construct a UML class model for the system, also considering the updates to the system description mentioned in section 2. Include operations only when you consider them important for the execution of the following use cases:
- RegisterShielding Individual
- EditFood Boxes
4. Place Order
Do not include simple operations such as attribute getters and setters. The operation descriptions must include types of any parameters and the type of the return value. Some methods may take or return collections of objects of a given class T; represent these as of type Collection<T> rather than specifying a concrete collection type, unless you already have the exact type in your diagram as a separate class. Associations must include multiplicities at each end. Leave navigation arrowheads off associations, as at this abstract level of design, this information is not needed.
To create the class diagram, you are encouraged to experiment with the class iden- tification technique discussed in lectures, and/or the CRC card technique from the rec- ommended reading.
You might find it useful to express the class model using more than one UML class diagram. For example, one diagram might show just class names and the associations and other dependencies such as generalisation dependencies between classes. Other diagrams might omit the associations, but show for each class its attributes and operations.
For this task, it is important to consider things which could help you make a good object oriented design, like design principles and design patterns.
You may find the following reference for drawing class diagrams in draw.io useful3.
3.1.3 High-level description of the UML class model
The high-level description should expand upon the details of the design you chose. Focus on clarifying aspects which may be unclear from your class diagram and explaining where you have made design decisions. What alternatives did you consider and why did you make the choices you made?
You discussed ambiguities, subtleties, incompleteness in the system description dur- ing the first coursework. Be sure to indicate how these assumptions have impacted your design. A viewer of your class diagram should quickly form an impression of the structure of your design. But obviously the diagram leaves out many details. If you have attributes or operations of classes whose purpose is not clear from their names and associated types alone, add a few explanatory notes.
3.1.4 UML sequence diagram Inf2-SEPP
Construct a UML sequence diagram for the Edit Food Box use case, focusing on the part of its scenarios which is about editing the food box after it was ordered. Show message names, but there is no need to include a representation of any message arguments. As needed, use the UML syntax for showing optional, alternative and iterative behaviour.
3.1.5 UML communication diagrams
While sequence diagrams focus more on the sequential exchange of messages between objects, the alternative notation of UML communication diagrams (also sometimes called collaboration diagrams) can be used to focus on the organisation of the objects and their interaction. Communication diagrams were introduced in Lecture 10 and its associated resources. You may find this link useful for constructing communication diagrams in draw.io 4.
Produce UML communication diagrams for the main success scenarios of the Place Order and Cancel Order use cases. For Place Order, please assume that the shielding individual does not decide to edit the food box as part of the scenarios.
3.1.6 Conformance to requirements
Your static and dynamic models should both be consistent with the system requirements, as captured in coursework 1. Before you tackle any of the software engineering tasks in this coursework, we recommend that you check marker feedback on coursework 1 and update your requirements and use cases accordingly in your coursework 1 solutions. Moreover, if you discover any issues with your requirements documents while working on this coursework, then you should also update them in coursework 1. Please highlight any changes you make to coursework 1 in green , there, before re-submitting coursework
- In this section of coursework 2, you should comment on any apparent divergenceswith the requirements or issues you encountered with your requirements documents (particularly those which required changes).
3.2 The software development
Please provide short replies to each of the following questions:
- Of the two types of software development processes that we have studied in thiscourse. Which of them is handling design more like in this coursework? Why do you think this is the case?
- How does the other software development process handle design?How is this different to the first in terms of outcomes?
3.3 Software Engineering Task Self-assessment Inf2-SEPP
Please read the high-level instructions for self-assessment from Section 1.1.
The following are the criteria you need to self-assess on regarding the Software En- gineering tasks by writing one paragraph (at least two sentences) for each:
- Reflection on the suitability of different types of software architecture in the con-text of the given case study, based on the system description/updates and the customer’s plans for the future
- Application of the UML class diagram notation to represent the static design ofthe food box system, including operations for the 5 given use cases, based on the system description/updates to it
- Quality (from the point of view of good object oriented design) of the static designrepresented in the class model
- Quality (in terms of correctness, effort) of the explanations and the justificationsmade for design choices in the high-level description of the class model
- Application of the UML sequence diagram notation to represent the interactionsinvolved in the Edit food box use case (scenarios of editing the food box after it was ordered), based on the system description
- Quality (from the point of view of good object oriented design) of the interactionsrepresented in the sequence diagram
- Application of the UML communication diagram notation to represent the interac-tions involved in the main success scenarios of the Place Order and Cancel Order use cases, based on the system description/updates to it
- Quality (from the point of view of good object oriented design) of the interactionsrepresented in the communication diagrams
- Effort at ensuring consistency between cw1 and cw2 solutions (as also reflected byyour explanations in section 1.6).
- Consistency within the cw2 solution (level to which your solutions to differenttasks are aligned between them)
- Reflection on how different software development processes handle design, in thecontext of the given case study
- Effortat this self-assessment
For the formative assessment, you will receive a rating for the Software Engineering part among the ones provided below (this is only for your information, nothing to do here):
- Worrying:A solution where barely any or none of the SE concepts are correctly understood and applied to the case study. This feedback suggests that you should do a lot more work in studying the lectures, reading and practicing the tutorials, and then redo your solution to this
- A lot to do: A solution where only some of SE concepts are correctly understoodand applied to the case study, and the resulting design has a poor level of quality (from the point of view of good object oriented design). This feedback suggests that you need to do more work in studying the lectures, reading and practicing the tutorials, and then re-consider your
- Getting there:A solution where a good amount of SE concepts are correctly understood and applied to the case study, and the resulting design showcases a reasonable level of quality (from the point of view of good object oriented design). Additionally, the solution is mostly consistent within and with CW1, and the self-assessment is honest but only focuses on strengths and
- Looking good!: A solution where all SE concepts are correctly understood andapplied to the case study, and the resulting design showcases a good level of quality (from the point of view of good object oriented design). Moreover, the solution is consistent within and with CW1 and the self-assessment is thorough and reflective, going beyond the discussion of strengths and
3.4 Further information
3.4.1 Modelling using message bursts
Create a system design with a single thread of control. Do not try to make it concurrent. System activity consists of bursts of messages passed between objects, each triggered initially by some actor instance sending a message to some system object. Each burst corresponds to the execution of some fragment of a scenario of a use case. Assume that the only messages sent from system objects back to actor instances are the final reply messages of bursts. Such a message corresponds to the return of the method invoked by the trigger message sent by the actor. Imagine each burst completes relatively quickly,
in well under a second.
Because of the single-threaded nature, the system does not handle further input messages during a burst. This should not be too much of a restriction, because of the assumed short duration of each burst.
3.4.2 Abstract inputs
Consider input messages at an abstract level. Do not model the user interface or different sources of the input messages. Here are some examples: Here are some examples:
- To register, a shielding individual would send in a register shielding individualmessage, providing their CHI number, which is then checked against the Public Health Scotland records to verify that the individual is indeed
- Toget a food box, a registered shielding individual could send a get food box
message, opting for either catering company or supermarket.
- If going for the catering company, the user can optionally send an edit food boxmessage with the food box identifier and the information about the edited items and their quantities, and then a place order message, providing the delivery date and the edited food box or all of its contents, to place the The system then returns the placed order id.
3.4.3 Abstract data
Your design should create a Location class which is used to specify the details of a location (which consists of an address and a postcode). This will need to include a method for testing whether two locations are near to each other — do not worry about how this should be implemented yet.
Your design will also need to handle dates (useful for the delivery of the food box).
Dates should be represented using Java’s LocalDate class5.
3.4.4 Abstract outputs
Do not model the complexities of the user interface that might be displaying results. You should focus on designing the software system.
For example, a food box can be returned as an object with appropriate fields con- taining its details, and some of the messages can return a string (e.g., the status of the order or the verification of a command being successful).
3.4.5 Catering Company and Supermarket Systems Inf2-SEPP
Although the catering company system is very important in the processing of food box orders, it is an external system and so you must not concern yourselves with how it works. However, make sure that your design allows our system to interface with the catering company system for checking its stock levels, notifying it of food box orders being made, and getting status updates.
Supermarket food box orders are completely handled on the supermarket system, by providing users with a personalised link to them as explained in Section 2. However, our system must also provide a way for the supermarket to notify it of an order being placed, and subsequent order status updates. Add a way for the supermarket system to interface with our system in your design.
3.4.6 Delivery Service System
Delivery services may be employed by the catering companies to deliver food boxes to the locations of shielding individuals. You do not need to be concerned with the details of how this works. Delivery services only need to notify our system of the status of food box order delivery, and so you should make it possible for a delivery service system to interface with our system this way in your design.
4 Your Professional Issues Tasks (worth 31.25% of the final mark for this coursework)
As a team, write a short essay (we will refer to them as ‘blog posts’) on each of the topics below.
Each blog post should be a maximum of 500 words (this amounts to about one side of A4), and good submissions will not be far under this.
This article gives good advice on how to structure a short essay:
Remember that reading the first chapter of “A rulebook for arguments” should help here too.
Good essays will:
- Clearlychoose a main position
- Clarifyimportant details with reference to other sources
- Considerthe terms used and define them where necessary
- Justifyarguments with reference to course materials
- Anticipateand address counterarguments
How well you do these things will be the core criteria for marking in your blog posts.
Topic 1: “Discuss the extent to which the Volkswagen emissions testing scandal was a failure of Organisational Structure and Management.”
The case study is available here: https://www.bbc.co.uk/news/business-34324772
This topic is an opportunity to reflect on an event that has already happened, and so lends itself to exploring other sources, as well as reading and referencing others’ thoughts on the topic.
Topic 2: “How might legal considerations around Intellectual Property impact devel- opment of your food box delivery system?”
For the purposes of this question, you can assume that you are actually developing the system outside of a University course, as a company. It is also encouraged to imagine how the system might be expanded further, both technically and as a product (for example being bought by another company). This question less obviously invites use of external sources, but reference to other cases as examples is still a good way to strengthen an answer.
4.2 Professional Issues Self-assessment Inf2-SEPP
Please read the high-level instructions for self-assessment from Section 1.1.
The following are the criteria you need to self-assess on regarding the Professional Issues blogs by writing one paragraph (at least two sentences) for each (they are the same as for CW1):
- Answers the question
- Supportedby other sources
- Qualityof argument
- Recognitionof counterarguments / alternate views
- Knowledgeand understanding
- Styleand presentation
- Effortat this self-assessment
For the only assessment for these tasks (final one), you will receive a mark according to the following marking scheme and respecting the Extended Common Marking Scheme (this is the same as for CW1, and only for your information, nothing to do here):
- Pass (40+): Essay attempts to address the provided question but is hard to un-derstand and/or makes few clear
- Good (50+): Essay is understandable, clarifies key terms, and comes to one or moreobvious Some course materials and external sources are referenced.
- Very good (60+): Essay has a good structure, flowing between and building uponsubsequent points. It identifies possible counter arguments or alternative views and integrates a variety of external sources. The self-assessment is honest, but not very
- Excellent (70+):Essay reads well and contains well-made arguments which pull together a variety of views and sources. The self-assessment shows extra effort in
- Excellent(80+): Marks in this range are This essay draws the reader in and makes points beyond what would be expected of undergraduate students in Informatics.
5 Some advice (same as for CW1) Inf2-SEPP
5.1 Working online as a team
Teamwork is not easy, and this year it is made harder by the fact that we work remotely. However, you can turn this to your advantage if you use your experience as Informatics students, and make use of the wealth of software tools available to help you. Here are some that we would recommend:
- Microsoft Teams (free through our university) for setting up a team with yourcolleague, setting up meetings in the calendar, video calls, the chat, editable file sharing, its Tasks By Planner and To Do to organise and split your work.
- OneDrive or SharePoint under Office365 (free through our university) for storingdocuments, sharing and working collaboratively on
- 3.The GitHub (https://github.com/) online repository and version control sys-tem, which you will also use later in this course. Please be careful about access permissions (see subsection 3).
- Trello(https://trello.com/en) as an excellent (and also free) alternative for splitting up work and recording progress on tasks. We will also use it later in our
- Aww (https://awwapp.com/) as an online whiteboard where you can collabora-tively sketch your ideas like you would do on
You may want to mention what tools you used for your teamwork in your self- assessments.
5.2 Asking questions Inf2-SEPP
Please ask questions in labs, office hours or on the class discussion forum if you are unclear about any aspect of the system description or about what exactly you need to do. On the class discussion forum, tag your questions using the cw2 folder for this coursework. As questions and answers build up on the forum, remember to check over the existing questions first: maybe your question has already been answered!
5.3 Good Scholarly Practice
Please remember the University requirement as regards all assessed work. Details about this can be found at:
Please note that we will run a plagiarism checker on your solutions.
Furthermore, you are required to take reasonable measures to protect your assessed work from unauthorised access. For example, if you put any such work on an online repository like GitHub then you must set access permissions appropriately (permitting access only to yourself or your group).
6.1 For the Software Engineering Tasks in Section 3 Inf2-SEPP
Please submit a PDF (not a Word or OpenOffice document) of your design document. The document should be named design.pdf and should include a title page with names and UUNs of the team members who have worked on this coursework.
As a group, only one of you needs to make the submission. If you submit several times, only the last submission will be checked by the markers.
How to Submit
Ensure you are logged into MyEd. Access the Learn page for the Inf2-SEPP course and go to “Coursework” – “SE Coursework Submission” – “Coursework 2”.
Submission is a two-step process: upload the file, and then submit. This will submit the assignment and receipt will appear at the top of the screen meaning the submission has been successful. The unique id number which acts as proof of the submission will also be emailed to you. Please check your email to ensure you have received confirmation of your submission.
If you do have a problem submitting your assignment try these troubleshooting steps:
- Ifit will not upload, try logging out of Learn / MyEd completely and closing your If possible, try using a different browser.
- Ifyou do not receive the expected confirmation of submission, try submitting
- If you cannot resubmit, contact the course organiser at Alexandru@ed.ac.ukattaching your assignment, and if possible a screenshot of any error message which you may have.
- If you have a technical problem, contact the IS helpline (firstname.lastname@example.org).Note the course name, type of computer, browser and connection you are using, and where possible take a screenshot of any error message you
- Always allow yourself time to contact helpline / your tutors if you have a problemsubmitting your
6.2 For the Professional Issues Tasks in Section 4
Please submit your blog posts for the markers to view as a PDF in ‘Coursework” - “PI Coursework Submission” - ‘Group Blog for CW2”
7 Deadlines Inf2-SEPP
The deadlines for this coursework are as follows:
• Deadline 1 (compulsory with final marks for the Professional Issues part!, formative for the Software Engineering part): 16:00, Mon 1st March
Please submit the Professional Issues part of this coursework for final marks at this deadline. Please submit the Software Engineering part of this coursework for formative marking at this deadline, to get formative feedback back.
- Deadline2: (compulsory with final marks for the Software Engineering part!)