List view
Everything to do with standardization of the project, to make it more pleasant to work with: - Programming Conventions - Code Formatting - Static Code Analysis - Project Structure - Naming Conventions - Documentation
No due date•10/15 issues closedThis milestone refers to the addition of automated tests to the codebase. Characterization and Smoke tests will be added first, but unit eventually the application should count with Unit, Integration, and End-to-End tests. This is a high-priority item, since tests allow changes to be made more easily and safely in the entire application.
No due date•5/6 issues closedA milestone for the application of a **_Plugin Architecture_** to the program, to allow easy and dynamic expansion of its behavior. This architecture may even **solve** some issues iSPD faces currently, such as the need for easy addition of scheduling/allocation policies. A _sketch_ for the development of this architecture is as follows: - [ ] Discuss architecture viability - [ ] Determine _which_ components should be added or changed by Plugins - [ ] Design Plugin API - [ ] Study "rigid points" in the code that need to be refactored to become more malleable - [ ] Do such refactoring - [ ] Design Loading/Selection/Configuration of Plugins by the user - [ ] Introduce design Plugin API into the code - [ ] Extract "specialist" behavior into new plugins - [ ] Create Plugin development manual for users Things to do continuously: - [ ] Document the architecture - [ ] Create tests for validation
No due dateA milestone to keep track of progress in improving the application's UI/UX and migrating from swing into JavaFX. The migration will be gradual, and will involve interoperability between the two frameworks. A resource for the implementation of such interoperability can be found at: https://docs.oracle.com/javase/8/javafx/interoperability-tutorial/fx_swing.htm Swing GUI code may still be tidied up and refactored to aid in the transition by improving code understanding for re-implementations down the line.
No due date•2/2 issues closedThis milestone involves the merge of the missing functionalities from remote repositories. The merge will most likely happen by hand, by re-implementing the needed functionality into the current code structure. Currently, the following repositories whose functionalities are missing/incomplete are known: - DAG Task Modelling by Luis - PaaS Cloud Modelling by João - Edge Computing Simulation
No due date•5/6 issues closedThis milestone consists of all work towards improving and fixing the scheduling and allocation policies in the program. This includes generation, configuration, selection, usage in execution, and metrics collection of such policies. The milestone is called "Rework" since, as a long-term goal, we wish to move away from the legacy policy design into a more robust and modular one.
No due date•3/3 issues closedSince there is no fundamental distinction between both models, it makes sense to allow ""hybrid"" models which contain both grid and cloud components. This milestone will be used to umbrella all steps towards that goal; including, but not limited to: - Homogenization/Abstraction of grid and cloud machines and components - Generalization of simulation motor and policies to allow both grid and cloud components in the same simulations --- Some questions that still need to be answered about this unification: - How will masters choose between virtual machines and physical resources for the execution of tasks? - Will some machines be forbidden from being selected as a VM host?
No due date•0/1 issues closedTimeline: This milestone does not have a set timeline yet. Objectives: ### Simulation The simulation motor code will be optimized for time efficiency primarily, and secondly memory efficiency. A potential idea is to execute the simulation natively, outside of the JVM (on a compiled language); however, this change is outside of the scope of the project currently. Target simulation times need to be set, and benchmarking needs to be done to determine how far away the application currenlty is. ### User Interface The UI takes a while to load, and some computation-intensive operations leave it unresponsive. This needs to change. The most obvious solution is to make use of multithreading to keep the UI responsive during processing. The applicability of this technique will be investigated. ### Serialization XML Serialization has a lot of redundancy, and sending sending such type of data through the network will incur in high network costs. This is relevant since there is a possibility that the program will be re-structured to work independently as a 'server' to which people can send models to simulate. A custom bytecode format could reduce the amount of data needed to represent a model.
No due date•2/3 issues closed