1 CSD2221 Block 2 Mini-Project (Covering Weeks 19 – 24) Please read the entire document before asking any questions or commencing the assignment. Initial notes  This is an individual assignment weighted as 25 per cent of the overall module assessment.  The work is to be assessed on two deliverables with the following relative weighting:-  80 % System analysis and design report  20 % Software prototype, developed in Java 8 Standard Edition within NetBeans 8. Description You are required to design a two-player version of the card game Get Stuck. This is an original game by David Parlett1 which uses the traditional 52 card pack. A detailed description of the game can be found at the following web page:- http://www.davpar.eu/oricards/getstuck.html The target development language is Java 8, Standard Edition operating in the NetBeans 8 IDE within a Microsoft Windows environment. To keep this relatively simple, the game should be designed to work for two players sitting side-by-side at a PC (or laptop) with a single keyboard, who take turns using the same keyboard. In other words, a two-player version of the game, but one that is not networked. Please note that the majority of the assessment is weighted to the software process in terms of requirements, analysis and design and the delivery of a design report. We are not expecting everyone to achieve perfect, working software and the assessment weighting has been apportioned accordingly. It is anticipated that, realistically, your software artefact may only be a prototype with a basic console (text-based) user interface, although those students who wish to do so are encouraged to explore graphical user interfaces in Java. Ideally, this will be a working prototype, but even if you do not manage this then you should aim to provide at least some completed Java classes that map to the core classes of your object-oriented design that is presented in the report. Note, this is an exercise in ‘forward engineering’, not ‘reverse engineering’. Designs and implementations will be scrutinised carefully by the course team. That is to say, implementation must follow design rather than coding a system and then retrospectively producing design diagrams afterwards. Any design reports that reflect a reverse engineered approach will be regarded as simply code documentation, not a design report, and you should expect significant mark penalties. Note (as always), any form of suspected plagiarism will be automatically referred to Academic Registry. Also, as part of the assessment procedure following the final submission, a cross-section of students will be required to attend a follow-up viva voce meeting with a panel of academic staff from the Computer Science department. 1 Author of the ‘Penguin book of card games’, published by Penguin books.2 Deliverables Report The system design report must be presented as a Microsoft Word document, and should follow the structure specified below. All chapters should begin on a new page. All sections and pages should be numbered appropriately. All diagrams and/or illustrations should have an appropriate caption, which is also numbered. Note that a nominal proportion of the marks will be for presentation of the report i.e., untidy, poorly structured documents will be penalised. Structure Title page Contents page including list of figures and/or tables Chapter 1: Requirements A full domain/product description, all functional requirements, all quality requirements, a comprehensive list of use cases, and any workflow illustration(s) using UML activity diagrams. Note: use case diagrams are not required and will gain no marks if included. All use cases should be represented as text-based, descriptive use cases which indicate a main success scenario, with inclusions and/or extensions as appropriate. Chapter 2: Initial conceptual model A full class diagram with a complete set of labelled associations, compositions and generalisation where appropriate. All associations should indicate correct multiplicities. Initial class descriptions should be included, and any invariants on the model described appropriately. Chapter 3: Dynamic designs An appropriate series of use case driven designs, dynamic UML (i.e., sequence diagrams), operation specifications, and possibly some UML object diagrams. This chapter should culminate in a significantly more detailed implementation model than the initial conceptual model, and include more detailed class descriptions with a commentary on how the class descriptions have evolved during dynamic design. Chapter 4: User interface interaction A commentary on user-system interaction flow using UML state diagram(s). Chapter 5: Testing A presentation of how the design and implementation was verified with respect to the functional requirements, and how the system was validated with respect to the use cases. Prototype If you achieve a software prototype, then it must be presented as a single NetBeans 8 Java project. To reiterate what was explicitly stated above, the prototype must demonstrate a clear mapping to the detailed implementation model that is presented at the end of Chapter 3 of the system design report. Submission Deadline for submission: 17:00 Friday 21st April, 2017 The two artefacts (report and NetBeans project) should be combined into a single ZIP (or 7zip) file for submission. A link for uploading the work is available in the CSD2221 Unihub course page, week 24 folder.