Software Design and Development

 

Southampton Solent University

Assessment Brief

Assessment Details

 

Unit Title:	Software Design and Development
Unit Code:	COM714
Unit Leader:	Prins Butt
Level:	7
Assessment Title:	Tourist Office
Assessment Number:	1
Assessment Type:	Software Artefact with Report
Restrictions on Time/Length :	2000 Words for Report + Software Artefact
Individual/Group:	Individual
Assessment Weighting:	100
Issue Date:	16th March 2020
Hand In Date:	8th June 2020
Planned Feedback Date:	6th July 2020
Mode of Submission:	Online
Mode of Marking:	Online
Mode of Feedback:	Online
Number of copies to be submitted:	1

 

 

 

 

Scenario

 

An internationally well-known city is developing an application, to be installed in tourist offices, to allow tourist information centre staff to look up and book hotels in the city on behalf of customers.

 

A tourist would visit the tourist office and ask the staff to look up hotels of a given star rating, where 1-star is the cheapest and 5-star the most expensive. The tourist office staff would then search for matching hotels using the application.

 

Having searched for a hotel, the tourist office staff should then be able to view the full details of a given hotel and book it for the tourist.

 

The application should also allow staff to add new hotels.

 

 

Task

 

Your task is to analyse this problem and design, build and test a prototype application in Java using a Swing GUI. (You do NOT need to worry about the implementation details of touchscreen applications.)

 

To do this, you should do the following:

 

a) Derive an initial domain model for this scenario.

b) Draw up a use case diagram for the following use cases:

 

* View full details of a given hotel by name (assume that no two hotels have the same name). Full details should include price, address and number of free rooms.

* Search for hotel by star rating

* Book a hotel. Payment does not need to be taken, this is done when the tourist visits the actual hotel.

* Add a new hotel

 

c) Create initial, analysis-level use-case texts for the use cases above.

d) Using the use-case texts and domain model, draw up robustness diagrams for the use cases above.

e) Use the robustness diagrams to refine the use-case texts and domain model, as appropriate.

f) Draw up sequence diagrams for the use cases above.

g) Use the sequence diagrams and domain model to derive a class diagram for the system.

h) Implement the system in Java using a Swing GUI.

 

Report

 

Your analysis, design and testing artefacts and code must be accompanied by a report. This should include discussion of the following (half a page to a page for each - I am not looking for reams and reams of text!):

 

* Decisions you made when drawing up your domain model and use-case texts.

* Any new objects discovered when drawing up your robustness diagrams.

* Detail on any changes made to the domain model or use-case text as a result of drawing up your robustness diagrams, and why.

* Any decisions made when drawing up your sequence diagrams

* Detail on places where your code did not match your design, and why.

* Critical evaluation of your code and/or design

 

Handing in

Please upload a ZIP file to SOL containing all your code, analysis and design artefacts and report by the deadline.

Marking Criteria

 

	A1-A4	B1-B3	C1-C3	D1-D3	F1-F3
Analysis and design (30%)	Work fully complete; additional considerations beyond the basics have been made in your design. Analysis and design artefacts all consistent with each other.	Work complete, analysis and design correct and artefacts all consistent with each other (a small number of inaccuracies or inconsistencies are permissible for a lower B).	Work complete, diagrams predominantly correct and consistent with each other, but with a number of inaccuracies.	Work mostly complete; significant inaccuracies and/or inconsistencies in your analysis and design.	(F1) Some parts of the analysis and design completed, but others incomplete. (Lower F) minimal effort.
Implementation (50%)	An implementation of all specified use cases which makes use of the more advanced implementation technologies covered in the unit. Robust error handling and a user-friendly interface. Implementation matches design, or if not, the reasons for this are explained clearly in the writeup.	All specified use cases implemented. There may be room for improvement in your error handling. Some evidence of use of the more advanced implementation technologies covered in the unit. Implementation matches design, or if not, the reasons for this are explained clearly in the writeup.	At least three out of four use cases implemented. Little error handling. Little evidence of use of the more advanced implementation technologies covered in the unit. Implementation matches design, or if not, the reasons for this are explained clearly in the writeup.	At least two use cases implemented, one of which should be something OTHER than the "search for hotel" or “view full details of hotel” use case. Implementation matches design, or if not, the reasons for this are explained clearly in the writeup.	A minimal effort; up to one use case (or the "search for hotel" and “view details of a hotel” use cases) successfully implemented.
Report (20%)	Clear justifications of decisions made when drawing up your analysis and design artefacts. including insightful comments. Considerations beyond the basics are made.	Clear justifications of decisions made when drawing up your analysis and design artefacts.	Largely clear justifications of decisions made when drawing up your analysis and design artefacts but unclear at times.	Writeup clear and accurate in some places but unclear and/or inaccurate in others. A significant number of omissions.	Predominantly unclear and/or inaccurate writeup. Little understanding demonstrated

 

Implementation must match the design!

 

Please note that it is not possible to achieve higher than a grade D at best for an implementation which significantly differs from your design, unless you clearly and satisfactorily describe the reasons for the difference in your writeup. Grades for the implementation criterion will be reduced as follows if your code is significantly different from the design, and you do not provide a satisfactory reason why (a partial mismatch will result in a partial reduction):

 

Original grade	Reduced grade
A1 to A4	D1 to D3
B1 to B3	F1
C1 to D3	F2
F1 to F3	F3

 

Other information

Copyright

Please note that using images or text from other websites is infringing copyright and is therefore illegal and not to be done! The only exceptions are if the source website has given you permission, or the material is available in the public domain or under a liberal licence (e.g. Creative Commons). By all means use creativity in the design of your app (though note that you will not be given credit for visual design), but use your own material or material you are legally allowed to make use of.

Learning Outcomes

 

This assessment will enable students to demonstrate in full or in part the learning outcomes identified in the unit descriptors.

Extenuating Circumstances

The University’s Extenuating Circumstances procedures are in place if there are genuine circumstances that may have affected your academic performance. Remember however you need to be ‘fit to study’, this means that you can either submit your assessed work or declare extenuating circumstances, but you cannot do both.

A summary of guidance notes for students is given below:

http://docman.solent.ac.uk/DocMan8/OCSFile?RNS=1234570925

 

Academic Misconduct

Any submissions must be your own work and, where facts or ideas have been used from other sources, these sources must be appropriately referenced. The University’s Academic Handbook, includes the definitions of all practices that will be deemed to constitute academic misconduct. You should check this link before submitting your work.

Procedures relating to student academic misconduct are given below:

http://docman.solent.ac.uk/DocMan8/OCSFile?RNS=1234570157

 

Ethics Policy

The work being carried out by the student must be in compliance with the Ethics Policy. Where there is an ethical issue, as specified within the Ethics Policy, then the student will need an ethics release or an ethical approval prior to the start of the project.

The Ethics Policy is contained within Section 2S of the Academic Handbook:

http://docman.solent.ac.uk/DocMan8/OCSFile?RNS=1234569791

 

 

Anonymous Marking

A copy of the University’s Policy on Anonymous Marking, process details and student guidance on submission sheet completion can be found on the following links, which are also uploaded on the Student Portal.  The guidance ‘fact sheet’ will be available at Faculty Reception Points.

Policy:  http://docman.solent.ac.uk/DocMan8/OCSFile?RNS=1234574213

Process:  http://docman.solent.ac.uk/DocMan8/OCSFile?RNS=1234574215

Fact Sheet:  http://docman.solent.ac.uk/DocMan8/OCSFile?RN=1234574214

 

Grade marking

The University uses a letter grade scale for the marking of assessments. Unless you have been specifically informed otherwise your marked assignment will be awarded a letter grade. More detailed information on grade marking and the grade scale can be found on myCourse. The guidance ‘fact sheet’ is available at the Faculty Reception Points.

Policy: http://docman.solent.ac.uk/DocMan8/OCSFile?RNS=1234569864

Fact sheet:  http://docman.solent.ac.uk/DocMan8/OCSFile?RNS=1234576014