mathrpg / ispd-plugin Goto Github PK

The help window is very primitive, and contains almost no content. It can be removed and, futurely, replaced with an online wiki.

Update schedule/allocation code to use factories (or perhaps even a Map of Suppliers) instead of reflection to instance classes.

Reflection makes the code harder to work with and potentially more brittle.

If reflection is ever re-introduced, it should be dynamically determined via annotations, not hardcoded strings.

Changes:

• Instantiation of scheduling and allocation policies should not use reflection
• UI options for such policies should not be hardcoded, but determined from this instantiation strategy
• Remove the @Policy annotation which is used to prevent 'unused class' warnings

Tests may be added on the way.

Reproduction:

• File > New
• Select IaaS Model
• Open User Configuration Window
• Remove default user
• Save model as any name
• Inspect resutling file

File contents will be:

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<!DOCTYPE system SYSTEM "iSPD.dtd">
<system version="2.2"/>

This is invalid XML and may produce undesirable behavior when used by the application.

Strangely, both gui and cli applications are fine when reading the model back up again. Surely, a warning should be emitted?

Code always creates a SimulacaoSequencial instance, which is unfit for cloud simulations.
It is unknown what kind of behavior is observed when simulating cloud models.

Models do seem to be parsed appropriately. However, a RedeDeFilas instance is always created.

This could be mitigated via the Grid-Cloud Unification milestone. With one RedeDeFilas and Simulacao class for all types of models, this wouldn't be a problem.

The code makes heavy use of System.out for debugging, specially in the motor.

It would be better to remove this hard-wired dependency, and use java's logging facility instead. Logging levels can be configured to process logs only when needed, and log processors can emit the log messages to whichever output is preferred.

For now, removing the System.out.print... statements will suffice. This will simplify the code and improve maintainability.

Both motor and policy packages will be impacted by this change.

This is a long-term issue.

The goal is to remove all static analysis warnings, and all warnings that happen during compilation.

As the time of writing (July 16th, 2023) there were over 100 compile-time warnings, and inummerable IDE warnings left in the project.

SuppressWarnings should only be used with a very good reason to do so. And even then, it probably shouldn't.

The application uses the project's home directory too much. Currently, it:

• Creates a Erros folder to save logs of critical errors
• Creates a policies folder for the source and bytecode of user-made scheduling and allocation policies
• Creates a configuration.xml file, if none is present on startup

This makes code maintenance untidy, can introduce unwanted race conditions while running multiple instances of the application, and it is unknown whether this behavior works when the application is packaged into a .jar file.

Where possible, such dependencies on the OS's file system should be removed. Where not, there needs to be a well planned-out space for such files.

A preferrable alternative would be to encapsulate all of these behaviors on a folder, .ispd, and place this folder within the OS's default location for application configuration (i.e., %appdata% on Windows and .config on Linux).

Perhaps the user should be allowed to determine where the application folder would be located, or where specific things should be (i.e., select a location for custom policies). If this is done, this choice would probably still need to be preserved in a known place.

The System Error window, which appears on uncaught runtime exceptions, can be improved in two ways:

• It could be made resizable, to help reading the full stack trace at once
• A 'copy error' button could be created, which copies the window text (or a substring of it) into the user's clipboard

This is very low priority.

When attempting to run a simulation with a user-defined policy, the user will instead come across a ClassNotFound exception.
Solving #21 may help progress this issue as well.

Reproduction:

• File > New
• Add a cluster icon (master by default)
• Configure a workload
• 'Simulate'

Error window shows up with the error 'One or more parameters have not been configured.', which is an error indicating that the parser has not identified any icon elements with the 'master' attribute.

• Tangentially related, this error message could be improved

Solution
WrappedDocument::hasNoMasters only considers 'machine' elements, need to consider 'cluster' as well.

Resources (such as images, dtd & html files) are gathered and used very liberally in the application, making it very difficult to determine which resources are actually used, and where.

It would be incalculably better to abstract away resource fetching and usage, and their paths as well.

This could also aid future testing, since this "ResourceManager" concept could be mocked.

Furthermore, once this concept is introduced and used the application, moving resources to the standard folder will become trivially easy. (See #7)

• Write characterization tests to capture the output of the program when run via the CLI.
  • Refactor code as needed
  • Change System.exit behavior which complicates tests
• Study code coverage to guide future test writing.
• Use CLI args to maximize code coverage, within reason.

New icons appear in their configuration window to have a RoundRobin policy by default. However, if attempting to run a simulation, the user will encounter a Could not load policy '---'! error.

Two acceptable solutions:

• Display in the configuration window the 'no option' option again.
• Change the default state of newly created icons to use the RoundRobin policy (or whichever policy is default for their use case).

Will help test-drive critical logging behavior.

• Add dependency.
• Refactor existing log tests.

Reproduction:

• File > New, select PaaS model
• Add machine, with any attribute values
• Save model
• Resulting xml file does not contain an 'icon' element

For example:

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<!DOCTYPE system SYSTEM "iSPD.dtd">
<system version="2.3">
    <owner id="user1" powerlimit="100.0"/>
</system>

Resource files are scattered throughout the code, and are not (as one might intuit) located in their designated resources/ folder.

TODO:

• Understand .getClass().getResource() idiom, and potential alternatives
• Introduce class to abstract 'resource' management
• Move resources to their folders

Relevant resources:

• arquivo/xml/dtd
• gui/{html, imagens}
• idioma, potentially
• JavaFX and other forms, when introduced
• Text templates, if ever extracted

These two files deserve a cleanup.

• Deprecated constants
• Empty action methods do not need to be set on components
• Overcoupling
• Unclear responsibility separation
• Integers where enums would be more appropriate
• Inappropriate string literals as bundle keys, not following hierarchical format
• Mixed languages in code (pt + en)

Reproduction:

• File > New Model
• Create a machine icon, set to master
• Configure a workload, of any type and size
• Click 'Simulate'

Simulation attempts to run, with a runtime error occuring soon after due to the impossibility of creating an instance of the scheduler class.

Preferrably, the 'Simulate' button should show an early error and not allow the simulation to run.

A step toward command/query separation, 'Simulation' is reference inside service centers to schedule (and remove) events. It would be better for the methods to return all new events, or perhaps a 'command' object with addition and removal parameters.

It is debatable if events should be removed from the simulation queue at all, or if service centers should merely ignore invalid events. If the latter, removal does not need to be supported in the new interface.

This would also aid testability, since then service centers could be tested in isolation, without needing an entire 'simulation' object around them.

Run the TerminalApplication class, setting the argument -e with 0 or negative. As long as no -t option is set (number of threads), this value's range is not validated.

Specially since the iconic/simulable model interpreting removal (and #26), the documentation is extremely outdated.
The docs folder should be cleaned up, leaving only the example models and traces used to test application functionality.

Improve project's file structure to be more in line with the java ecosystem.
Doing this will also add the opportunity to use other JVM languages in the project.

User generated policies are, in theory, a great asset: the user can test various scheduling and allocation policies without needing to leave the application. It greatly reduces the iteration time and allows for 'playful discovery' of new techniques.

That being said, the system implemented currently is undesirable. It is best to remove it for now, and cogitate re-introducing it after the project architecture has been stablished.

Windows maintain an instance of ResourceBundle, which complicates UI code severely.

• It would be better to have a translation singleton.

The ability to switch languages in runtime complicates the MainWindow's code greatly (and some other windows' too).

• This should be removed, and re-implemented futurely.

There is no default language bundle for the application.

• en/US should be used as the default bundle.

The application is in no state to support multiple languages currently

• The pt/BR bundle should be deleted, and re-implemented futurely.

Lastly, the language bundle(s) have no purpose being within the source code.

• Move bundle(s) to resources folder.

This is another facet of the code that overcomplicates it and makes it harder to deal with.
Once the serialization system is re-worked, these features can be reintroduced via plugins.

TODO:

• Remove SimGrid import
• Remove SimGrid export
• Remove GridSim import
• Remove GridSim export

Standard workload format support will be reworked futurely as well. It won't be removed for now since it is overly coupled to the code.

A library with more options for fluent assertions. Can be used in combination with Hamcrest, and other testing libraries.

The application takes some exclusive code paths in case it is running from a JAR, like extracting scheduling policies' code.

This part of the application is neigh impossible to test, and very difficult to work with.

It will be better to re-engineer this part of the application to make it more testable.

Setup the necessary workflows for automated testing in Github.
Testing should be done on PRs; PRs should only be merged if all tests pass.