Learning Outcomes

All the module learning objectives are covered by this assignment:

Knowledge & Understanding:

1.     Demonstrate asystematic understanding of the principles, knowledge and skills required to design, implement, test and document programs written in an object oriented language .

2.     Demonstrate a critical understanding of the essential principles and practices relating to object- oriented programming, including the need for standards, principles of quality, and appropriate  software support.

Intellectual/Professional Skills & Abilities:

3.     Critically evaluate the methods and conceptual tools used in developing solutions to programming problems.

4.     Analyse, specify, design, implement and test a high- level solution to a programming problem using object oriented and general imperative programming language constructs, using appropriate          documentation standards and software tools.

Personal Values Attributes (Global/ Cultural awareness, Ethics, Curiosity) (PVA):

5.     Effectively communicate development of a solution to a programming problem, including critical evaluation

The work is set in Week 08 of the module by which time you will have covered enough to make a start on the work.

Module Learning Outcomes

MSc Computer Science

If you are studying the MSc Computer Science, successful completion of this module will support you to evidence:

Knowledge & Understanding:

KU1. Demonstrate in-depth knowledge and critical understanding of the main areas of Computer Science, including the key areas of systems design, software development, security, databases and the web.            KU3. Apply knowledge and understanding of the software development life cycle .

Intellectual/Professional Skills & Abilities:

IPSA1. Appraise and judiciously apply a range of general computing principles, approaches, tools and methods. IPSA3. Design and deploy general secure, standalone and web- based software applications.

Personal Values Attributes (Global/ Cultural awareness, Ethics, Curiosity) (PVA):

PVA1. The ability to judiciously apply new skills and new knowledge as required.

PVA2. The ability to demonstrate creativity in problem solving and decision making.

PVA3. The ability to engage in critical self-appraisal of your own learning experience, personal strengths, limitations and performance .

Scope

The assignment is an individual assignment.

You will be provided with some initial program source code as described in the section below . You must extend the program to meet the specification below .

What follows is a detailed discussion of the program and how it is modelled and its functions, you will need to look very closely at the specification for the object-oriented (OO) program you are to create .

Assignment

Nonogram

This is a puzzle where you must colour in/fill in the grid according to the patterns of contiguous full cells given in the rows and columns. In the supplied text- based UI, full cells are shown as ‘@’, unknown cells as '.', and      cells you are sure are empty as 'X' (space) . If a row or column is invalid (doesn't match the pattern) this will be marked with a '?'; a solved row or column is marked with a '*', but it may still be wrong because of the other   columns or rows - keep trying!

To solve the puzzle, you need to use logic to slowly fill in the grid, with intersecting rows and columns, and the constraints of space giving you clues (see online websites for tutorials if you get stuck) .

The text UI includes help (some of the text here), an individual move, a row multi move, a column multi move, and quit. The remaining four choices are not yet implemented (undo, clear, save and load) .

Figure 1: Nonogram (file: tiny. non)

Further discussion of Nonogram can be found on Wikipedia (https://en.wikipedia.org/wiki/Nonogram) and the file format used by the supplied code ( . non) is described here: https://github.com/mikix/nonogram-                  db/blob/master/FORMAT.md.

You have been supplied with code that implements Nonogram and also a partially- implemented text- based   user interface . Three . non files are also included. The five model classes are Assign, Cell, Constraint, NGPattern, and Nonogram;the text UI is NonongramUI; plus, a problem-specific exception class,             NonogramException. The classes are illustrated in a UML class diagram (Figure 2) .

Figure 2: Class diagram for supplied code

The Tasks

The tasks you are to carry out are as follows:

To complete the implementation of the text- based user interface to include the (as yet unimplemented) clear  (i.e ., reset the Nonogram game), undo (a single user move, then a further move if called again, and so on), save (the state of the game to a file) and load (the state of the game from file) methods. You should only need to     make changes to the main user interface class (NonogramUI) and the helper class Assignto achieve this.

To design and implement a graphical user interface (GUI) for the Nonogram model code that allows the user to make moves, undo user moves, clear (reset) the game, save to, and load from file . The individual cells will        need to indicate if they are unknown, full or empty. The GUI should at least give feedback on when individual  rows/columns are invalid or solved, as well as when the overall puzzle is solved The appearance of the               interface is up to you, but an example is given in Figures 3 and 4. You should keep the user informed through  the use of e .g., a status box, and may also consider the use of dialogue boxes where appropriate (such as file    location selection) . You must use Observer-Observable to update the GUI as the model changes.

Develop a test plan and test the functionality of your classes.

Write a report including design, testing and reflection (see below) . The report should not exceed 3000 words (not including tables and figures) .

Figure 3: A possible GUI design (at start of a puzzle)

Figure 4: A possible GUI design (puzzle complete, and all unknown cells displayed as empty; the blue colour on

the row & column patterns indicates they are solved)

Deliverables

General Points

The development of your code is based on the object-oriented model, andyou must make use of classes in    developing your system. Each will have its own methods and properties though they could inherit from other classes.

All interactions must be made via just the text- based UI or just the GUI alone (do not try and mix text- based UI and GUI) . You may design the GUI as you see fit; see the example depicted above .

You might consider writing custom dialogue(s) to input the user’s preference and other information. This will require a little investigation on your part.

The GUI should consist of a number of classes each with well-defined functionality. There may be a driver class to set things going; multiple GUI classes to provide the user interface; there may be additional classes for e .g., file handling.

The code you produce must adhere to the published course coding standards. Marks are awarded for code   quality and appropriate defensive programming. Your code should be well commented and include Javadoc comments.

You will be expected to test parts of your program against a suitable set of situations. In your report you should describe your testing plan and results; also include your test results as screen s hots as evidence .

Design

You must produce design documentation. This will include class diagram(s) for the system, a short explanation as to the general purpose of each of the classes you have produced and a justification for any design decisions you have made (including options you discarded and why) .

Implementation

You must provide completeJava source code for your program. The code must adhere to the object-oriented style standards as defined for the module . Do not use a GUI editor to generate your code, but develop it by    hand using the Java Swing API .

Testing

You are expected to test your code using the strategies studied during the module . It is not necessary to test the supplied code, although you may choose to do so.

The testing section of your documentation should indicate the approachyou have taken to verifying and             validating your system. Just as you should not convey the design of your system by presenting the code or even listing the classes, you should not merely list the tests performed. Rather, discuss how tests were selected, why they are sufficient, why a reader should believe that no important tests were omitted, and why the reader         should believe that the system will really operate as desired when in use .

You may not be able to create JUnit tests for all aspects of your classes, particularly the graphical user interface classes. It is sufficient to carry out well planned and documented manual testing.

Strategy: An explanation of the overall strategy for testing: black box and/or white box, integration, kinds of test beds or test drivers used, sources of test data, test suites. You might want to use different techniques (or combinations of techniques) in different parts of the program. In each case, justify your decisions.

Test Data: A set of tables showing the test data you used for each class, etc. The format of the test documentation should be as follows: for each test case in the tables,

• a unique test ID

• a brief description of the purpose of the test

• the pre-conditions for running the test

• the test data

• the expected result

Reflection

You must provide a final critical evaluation of your work. The reflection section is where you can generalise  from specific failures or successes to rules that you or others can use in future software development. What surprised you most? What do you wish you knew when you started? How could you have avoided problems that you encountered during development?

Evaluation: What you regard as the successes and failures of the development: unresolved design problems, performance problems, etc. Identify which features of your design are the important ones. Point out design or implementation techniques that you are particularly proud of . Discuss what mistakes you made in your design, and the problems that they caused.

Lessons: What lessons you learned from the experience: how you might do it differently a second time round, and how the faults of the design and implementation may be corrected. Describe factors that caused problems such as missed milestones or the known bugs and limitations.

Known Bugs and Limitations: In what ways does your implementation fall short of the specification? Be       precise . Although you will lose points for bugs and missing features, you will receive partial credit for accurately identifying those errors, and the source of the problem.

This reflection should be one to two pages long.

Deliverables

Submit a zip archive containing a complete BlueJ project for your program including Java source code with comments (thisgoes in the ‘Code’ portal) .

A single document in pdf format (this goes in the ‘Report’ Turnitin portal) containing :

•            design documentation as specified above;

•            test documentation as specified above;

•            your reflection report as specified above .

Two portals will be provided on the eLP (BlackBoard) for you to upload your work .