Module Learning Outcomes Assessed:
1. Demonstrate principles of object-oriented programming analysis, design, and implementation.
Requires the implementation and execution of a program using GUIs, constructed from student defined and library classes in Java.
2. Apply UML use-case, activity, sequence, and class diagrams to the analysis of programming problems and the design of OO solutions.
Exercises methodical analysis and design using the specified UML diagrams applied to an object- oriented programming problem.
3. Determine the requirements and structure of programs running and communicating across a network.
This assignment requires a client-server application to be analysed, designed, and developed.
4. Design, develop and test OO client-server programs utilising common data structures.
Requires the use of data structures using the Java Collections library, typical examples are ArrayLists and HashMaps.
Task and Mark distribution:
See following pages for assignment task. See last page for mark distribution.
Individual Assignment Task
Java Client-Server System
Your coursework task is to build a Java client-server application around a predefined SQLite database.
Client-side Java application 1 with GUI interface.
(student to develop)
Server-side Java application 2 allows connection to clients.
(student to develop)
SQLite database resides on the server-side of the application.
(given as one of the options below)
Choose one of the available options for the application topic and database. Choose an option and/or data tables different to your friends’ choices.
Option 1 – Airline route manager (3 tables):
• Airlines
• Airports
• Routes (link table)
This system is responsible for manging global airline routes between airports. The air traffic controllers should be able to access and manage this information thorough a client GUI interface.
Option 2 – Football betting odds (3 tables):
• Football match data
• Bookies
• Odds (link table)
This system is to allow bettors and bookies to find and manage the odds across football match data.
Option 3 – Library book loans (3 tables):
• Books
• Person
• On loan (link table)
This system is to allow librarians to manage their collection of books and loan them out to people.
Option 4 – Wine reviews (3 tables):
• Wines
• Customers
• Customer reviews (link table)
This system is to allow customers to view expert sommelier reviews on wines and then make their own comments, reviews, and ratings as well.
Option 5 – Small-Business ERP System (Northwind Database) (14 tables – but only pick up to 3 tables from this, if this is your choice).
Figure 1 – Option 5 – Northwind.db database diagram showing the data tables and relationships.
A small business needs an Enterprise Resource Planning (ERP) system to help them manage their daily activities, business, and resources. The business managers need to be able to manage records of their products, suppliers, orders, employees, and customers.
Option 6 – Music Store (Chinook Database) (11 tables – but only pick up to 3 tables from this, if this is your choice):
A local music store is in the business of selling music albums to customers. The music store has a few employees who work in the sales and IT departments.
The sales team can get a range of questions from the customers, such as: ‘which tracks are on a particular music album?’, ‘what other albums does a music artist also have for sale?’ or ‘can you build me a playlist for the following tracks…?’. The sales team (including the Sales Support Agents and the Sales Manager) need a Java client-server solution to help them with answering these requests and updating the data they have on the system.
In addition to this, there is also a need for the General Manager to keep track of invoices, customers, and employee data.
The database which contains all the records has already been established as an SQLite database (called chinook.db). Figure 2 below illustrates the data tables and their relationships.
Figure 2 – Option 6 – Chinook.db database diagram showing the data tables and relationships.
Instructions
For each individual student attempting this coursework, you should choose to implement the coursework task for a maximum of 3 related data tables from the options above.
Make sure that you do not choose the same data tables as your friends have chosen. Similar source code submissions will be picked up by plagiarism detecting software and sent to academic conduct.
If you are not familiar with SQL relational databases, then I recommend you have a quick look at an online tutorial about ‘one-to-many’ relationships: https://code.tutsplus.com/articles/sql-for-beginners-part-3-database-relationships–net-8561
You do not need to be an expert in designing and building SQL databases for this module, just an appreciation of how one-to-many relationships work should be enough.
It will also help to get familiar with the basic Create, Read, Update, Delete (CRUD) commands in the SQL language – INSERT INTO, SELECT, UPDATE, DELETE. https://www.w3schools.com/sql/default.asp
(Note that databases and data-structures are two different concepts. You will have the opportunity to demonstrate the use of both in this coursework).
By ‘client-server’, it is meant that you should develop both the client application and server program and that they should communicate with each other over a TCP network connection. Java provides the ‘Socket’ and the ‘ServerSocket’ library classes as part of the ‘java.net’ package for this.
The database must sit on the server-side so that multiple clients can connect and access the data synchronously. A simple GUI should be developed for the client-side application so that multiple
users can operate the system with ease. You are expected to use one of the Java GUI frameworks for building your GUI; choose between AWT or Swing.
Basic requirements:
A user of the system should be able to:
• Open the client GUI and connect to the central server and database.
o Do not need to implement a login system, assume it is already handled by another part of the system.
o Do not need to build a multi-frame / window system, suggest putting all features into a single large JFrame window, perhaps using a JTabbedPane for more space as needed.
• View a list of all the data in your chosen data table(s).
• Send the list of data to the printer.
• Create a new data row for your chosen data table(s).
• Edit an existing data row for your chosen data table(s).
• Delete a row from your chosen data table(s).
More advanced requirements / features:
• Extra features could include (but not limited to):
o Viewing / displaying data gathered from across multiple related data tables, e.g.
when you click on an invoice it shows the customer information such as email address in another table nearby. Or by opening a row to get more details of the row in a different view – e.g. opening an invoice finds and displays the customer details for that invoice.
o Searching data based on data in related data tables – for example, ‘search and view a list of all the music tracks from a particular artist’, (SQL JOIN could be used for database queries across multiple tables).
o Sorting data by a column – numerical data sorting, alphabetical sorting, date field sorting.
o Filtering data by user input, e.g. ‘find all tracks which are greater-than <£1.00> in cost’ or ‘find all playlists which begin with an
o Random number generator or random similar search e.g. ‘suggest me a single random track’ or ‘suggest me a single random track which is of a similar genre to …’.
The features you choose to implement (for the data tables you choose to implement for), should be listed in an MS Word document and match up with your UML diagrams as well.
Before writing the program, a methodical analysis and design must be completed including UML: Analysis:
1. Console diagram for the GUI. Show how a user interacts through the GUI. Keep the GUI as simple as possible (all in the same frame – i.e. no menu system). Label components where necessary. (can produce this in MS Word).
2. UML use case diagram at high-level to show the actors and their main goals for the system.
3. Detailed use case description for one major use case (can produce this in MS Word).
4. High-level UML activity diagram to show interaction for one major use case, use swimlanes.
5. UML activity diagram at mid-level showing the event loop and possible events occurring in
your client application after the program is run and presented with your main GUI screen.
6. Perform textual analysis on your use case description and identify a list of potential classes.
(UML case tool or MS Word).
Design:
7. UML class diagram consistent with the application code (show the class design, attributes,
methods, and any class relationships).
8. UML sequence diagram for one major use case to show object-interaction. The diagram
must include a pseudocode narrative on the left-hand side.
All diagrams must be produced in their appropriate UML models as required. Include your name and SID in a note in the top left of each diagram. Store all UML models together in a single UMLStudio file similar as shown in figure 3.
Figure 3 – UMLStudio Models Folder
After writing your program, you must create a screencast video clip (approx. 3 minutes in length). In the clip, you must demonstrate your program running with test data and describe the stability, features, and functionality of your client-server application. Point out any shortcomings, bugs, logic errors or limitations in your solution.
For a pass your program and video should meet and demonstrate the following requirements to a suitable standard:
1. The client program builds and runs without errors.
2. The server program builds and runs without errors.
3. An operational client-side GUI has been implemented with suitable controls allowing for
transfer of data between user and client (use of Event Handling).
4. The program is in close correspondence to the UML diagrams.
5. The client program can successfully connect to, and exchange data with, the server.
6. The server program can successfully store and retrieve data from the database.
7. The basic program functionality is achieved.
8. Use of data structures (such as ArrayLists) for temporary storage and manipulation of data. 9. Neatly written program code with consideration to the use of tabbing, suitable naming
conventions, structured appropriately.
10. Access to IntelliJ project and source code is provided through CU GitHub repository.
For a first your program and video demonstration should additionally meet the following requirements to a high standard:
1. Excellent functionality is achieved. No bugs or logic errors. May cover some of the more advanced requirements.
2. The GUI is refined in its layout and design.
3. The client program is protected from entering invalid data, it will not crash the program.
4. The server is protected from clients sending bad data, it will not crash the server or corrupt
the database.
5. Exception handling is implemented.
6. Use of custom defined classes to reduce the system complexity and promote an object- oriented design (demonstrates Abstraction, Encapsulation, Information Hiding, etc.).
7. Good code reuse, avoids code duplication with good design practices and principles used.
8. The server program is multi-threaded.
9. The server can accept connections and exchange data with multiple clients at the same time.
10. Excellent use of classes, class design and relationships, e.g. composition, inheritance,
interfaces, abstract types and methods, overloading and overriding. Makes use of standard
library features.
11. Excellent use of data structures. Use of Java collections e.g. ArrayList<> or HashMap<>, use
of generics, iterators etc.
12. Evidence of regular commits, consistent, detailed, and meaningful commit messages.
13. No linting errors.
14. Javadoc documentation for your code.
15. Unit testing with JUnit.
All Java code files must contain your name and SID as part of the comments at the top.
Starting Point
To help you get started with the coursework there is the SQLite databases in the CW-STARTING- POINT repository on our GitHub.
Assessment Marking Grid (Guidelines)
Criteria:
0% – Fail
20% – Fail
40% – Passable
60% – Strong
80% and above – Excellent
UML Diagrams.
UML poor or missing.
Lacking UML diagrams and/or major errors.
Most UML diagrams completed. Possible minor errors.
Strong UML diagrams. No errors.
Excellent UML diagrams. Neat and fully correct in all respects. Covers high- and low-level details.
Version Control.
No access to repository. Source repository is not on our Coventry GitHub organisation.
Repository has very limited commits ~1-4. Commits maybe an entire project or multiple files all in a single commit. No evidence of incremental progress.
Evidence of semi-regular commits over a short time frame ~5-9 commits. Limited evidence of incremental progress between commits. Commits are usually showing large blocks of code additions all in one go, such as entire files.
Evidence of regular commits over a longer time frame ~10-19 commits. Clear evidence of incremental progress between commits. Commits are usually showing gradual additions, changes, and edits to individual lines or blocks of source code.
Evidence of regular, daily, commits over a longer time frame ~20+ commits. Demonstrates clear incremental progress with logical commit messages for features etc.
Stability, Features and Functionality.
No access to source or video. Source repository is not on our Coventry GitHub organisation.
Program does not run, has major bugs or compiler errors.
Does not achieve the basic functionality.
Program builds and runs.
The basic functionality is achieved. Could have minor bugs under normal use.
Strong functionality.
No bugs under normal use.
Excellent functionality.
Covers all requirements with possible extra / advanced features added. No bugs or logic errors under testing.
Connection client- server.
No access to source.
Connection code poor or missing. No client-server.
Connection established between client and server. Successful exchange of data between client- server.
Strong connection code. Exchange of data as objects with a clear protocol for messages established between client-server and/or possible attempt at Threaded Server.
Excellent connection code. Multi-threaded server allows multiple client connections at the same time and exchange of data. Synchronized methods. No logic errors with testing. Possible advanced thread pooling or broadcasting.
Database access on the server-side.
No access to source.
No database code, or basic data storage on client-side only.
Database on the server-side. Successful exchange of data between server-database. SQL SELECT and INSERT work with no errors.
Database with strong read and write code. SQL such as: ORDER BY, WHERE, INSERT, DELETE used correctly. Prepared Statements used to avoid SQL injection.
Excellent database code with full create, read, update, delete (CRUD) functionality, perhaps more advanced SQL used e.g. INNER JOIN.
Use of Classes, Standard Libraries and Data Structures.
No access to source.
No class design ~2 classes. No data structures used.
Good use of classes. Some basic class design e.g. nouns for class names and verbs for method names. ~3-4 classes used. Basic use of data structures e.g. arrays or lists with primitive or wrapper types.
Strong use of classes. ~4-6 classes used with a clear responsibility for each class. Using fields and methods correctly. Well organised code architecture. Strong use of data structures and core Java library types. Use of Java collections e.g. ArrayList of own custom types with for each loop. Perhaps demonstrates use of class relationships Composition and Inheritance.
Excellent class design. ~7-10 classes with single responsibility principle. Delegates work to classes instead of excessive moving of data between classes.
Uses advanced design concepts correctly, e.g. composition, inheritance, interfaces, abstract types and methods, overloading and overriding. Makes extensive use of core Java, exceptions, AbstractTableModel, data structures, use of generics, iterators, etc.
Code Standards, Neatness, Documentation, Unit Testing.
No access to source.
Untidy code. Poor structure and difficult to read. Poor naming, tabbing, and bad practices.
Passable, mostly tidy code, readable. Naming conventions okay e.g. UpperCamelCase used on class names and correct tabbing i.e. Codeà Reformat File…
Neat code. lowerCamelCase used on variable identifiers.
Meaningful identifiers used, i.e. nouns for class names, verbs for method names, variables are thoughtfully named.
Excellent tidy code. Good practices being used, follows naming conventions, private attributes, meaningful identifiers, code contains no linting errors under Analyse àInspect Code….
Good examples of Javadoc documentation and Unit Testing.