Through this part we used the CommissionEmployee-BasePlusCommissionEmployee hierarchy that we explored throughout. Now we use an abstract method and polymorphism to perform payroll calculations based on the type of employee. We create an enhanced employee hierarchy to solve the following problem:
In the class diagrams below it makes each class’s association unknown and spaghetti-like. An arrow pointing from one box to another signifies a child class pointing to a parent. That should only happen for those classes using inheritance (Salaried and Hourly employee types should inherit from Classification, Commissioned can inherit from Salaried). You have a lot of extra attributes as well that are not needed. The name and id of the employee only needs to exist in the Employee class. The attributes in your employee class are good. Be sure to also include methods are part of each class. For example Employee should have the methods “issue_payment()”, “make_commissioned”, “make_hourly()”, and “make_salaried()”.
- Use Case diagrams show the various activities the users can perform on the system. The System is something that performs a function. They model the dynamic aspects of the system. It provides a user’s perspective of the system.
Actor:
An actor is a user of the system playing a particular role.
Use case:
Use case is a particular activity a user can do on the system.
Relationship:
Relationships are simply illustrated with a line connecting actors to use cases.
From the class diagram the payroll management system that we have developed will have an admin page as well as the login page through which it will be able to calculate the salaries for employees and also print the payslips.
- Implement the code for the diagram above.
The code is available in the zip file
Task 2: src/main/java/task2 [10 marks]
In this section design pattern refers to the catalogue of patterns by Gamma et al. that were presented in this course and the immutable data structure patterns.
For each of the three scenarios below state which one design pattern can best solves the problem and briefly explain (in the space provided) how the design pattern is applied to the specific case. Provide a class diagram as well.
- A GUI driven application is planned with a standard model view controller (MVC) design which has many views, many controllers and a single model. The model functionality is complex and so is the GUI and thus a single user action (such as a menu selection or a toolbar button press) will require the participation of many view and controller objects working together to be synchronised.
At the architecture and higher design level, the Model-View-Controller (with its variants) and the Presentation-Abstraction Control are two well-known patterns, which specify the structure of a GUI application. However, when applying these patterns in practice, problems arise, which are mostly addressed to an insufficient extent in the existing literature
This will require the use of JavaFx so as to design the Graphical User Interface that is driven in the model view controller.
The standard interaction cycle in the Model-View-Controller metaphor, then, is that the user takes some input action and the active controller notifies the model to change itself accordingly. The model carries out the prescribed operations, possibly changing its state, and broadcasts to its dependents (views and controllers) that it has changed, possibly telling them the nature of the change. Views can then inquire of the model about its new state, and update their display if necessary. Controllers may change their method of interaction depending on the new state of the model. This message-sending is shown diagrammatically in Figure one below
Figure 1: MVC Controller and Messaging
- A cross platform GUI toolkit has many widgets and components and is designed to run on multiple platforms such as Windows, Linux and macOS. New platforms should also be supported with minimal changes to client code.
Thirty years ago, all I/O was done on character displays. It wasn’t until the early ‘90s that graphical toolkits first appeared. Since then, Mac OS (and to a lesser extent, Linux) have since grown in importance compared to Windows, making it a better investment to create software that can run on all three platforms without requiring a rewrite. Without cross-platform toolkits, you would need to do a substantial rewrite for any other platform just to handle the I/O and user interaction. Meanwhile, graphics on each operating system are done in completely different ways. Cross-platform toolkits shield you (somewhat) from those variations and oddities.
- A diagramming application provides multi-level undo based on a history of operations that have been performed on the diagram.
The GUI in the application’s first impression. If you’re hoping to be successful, you can’t afford to make a bad first impression. You’re going to need a lot of different graphical elements, including buttons, checkboxes, toggles, dropdown lists, search fields, sliders, tooltips, and many more — everything your user needs to interact with the functionality provided by your application. Haphazard placement or unappealing widgets won’t help with first impressions
Task 3: src/main/java/task3 [10 marks]
- Draw a class diagram for your proposed solution incorporating at least two design patterns using the naming of the problem domain, i.e., do not just draw generic pattern diagrams that do not apply to the airline meal scenario. Your class diagram should include both of the concrete meal types described above (snack and full meal). For brevity you can specify a single concrete airline and a single meal item for each category for that airline but should clearly indicate where additional concrete classes sit in the class hierarchy. Use the
Answers.mdfile to add any additional explanation you may need. - Explain briefly how the design patterns facilitate extensibility based on points (1) and (2) above (one or two paragraphs each). Pay particular attention to how changes are isolated from client code.
- All actions begin in the view through events generated by the user. The controller provides listeners for the events. The controller also has the ability to manipulate the state of the view objects in a way which offers a response to the events generated by the user.
- The controller interacts with the model by either requesting information from the data source based on user-generated events, or by modifying the data based on these events.
- The model provides the programming interface which the controller must use to access the database, i.e., the controller does not interact directly with the database. In particular the notion of “connection” is never seen in the controller. Furthermore, the model also provides means to avoid, in most cases, direct SQL queries to the database.
- The view interacts with the model only to know about type information and other data abstractions held in the model. The relatively weak link indicates that the View/Model interaction should be “minimal” because the manipulation of data is to be done within the event handlers of the controller.