@uuqjz Please review, I would like to have some feedback from you. Documentation is also starting to get added. See the readme.md on the branch. I would delegate the technical details (e.g. the Conversion Details section) to you, as I have only been active with the PCM Converter (which I will describe in the documentation myself)

The idea behind the abstraction of the input and output models for the converts is threefold:

1. Single Responsibility (Principle)

The converter should only be responsible for converting a loaded model to another loaded model.
It should not be the responsibility of the converter to load the model.
Additionally and aside from the principle, this also causes the converters to only have one method that is exposed to the outside.
This reduces the amount of required constructors of the converters

2. Better Maintainability

The older methods for handling different methods for loading the same model had lots of duplicate code. (e.g. the actual conversion). Some parts (like the high level calls to do the conversion) were not always extracted into a single method, instead spreading the code to all constructors

3. Enabling a common CLI interface

As the CLI works best when the converters have a common interface for the conversion, a common constructor would have been needed either way. Therefore, an interface like this would have been needed anyway, as the models require different elements, like Strings containing paths or the models themselves. Additionally, some converters need only one file, while some others require multiple.

@uuqjz @sebinside @Nicolas-Boltz Ready for review. Conflicts resolved/rebased

Here are couple of quick comments, besides the required rebase.

Additionally, I ran the standalone converter in interactive mode to convert JSON to DFD (which worked perfectly) and DFD to JSON which produced the following exception. Maybe I misused it, in that case, more hints / enhanced exception handling would be welcome ;)

Exception in thread "main" java.lang.RuntimeException: Cannot create a resource for 'file:/C:/[...]/OnlineShopDFDsimple/onlineshop.dataflowdiagram'; a registered resource factory is needed
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:403)
	at org.dataflowanalysis.analysis.resource.ResourceProvider.loadModelContent(ResourceProvider.java:122)
	at org.dataflowanalysis.analysis.dfd.resource.DFDURIResourceProvider.loadRequiredResources(DFDURIResourceProvider.java:36)
	at org.dataflowanalysis.converter.dfd2web.DataFlowDiagramAndDictionary.<init>(DataFlowDiagramAndDictionary.java:112)
	at org.dataflowanalysis.converter.interactive.ConvertTask.getConverterModelInteractive(ConvertTask.java:144)
	at org.dataflowanalysis.converter.interactive.ConvertTask.runConversion(ConvertTask.java:122)
	at org.dataflowanalysis.converter.interactive.ConvertTask.handleInteractive(ConvertTask.java:84)
	at org.dataflowanalysis.converter.interactive.ConvertTask.main(ConvertTask.java:42)

This issue should be fixed by 0a69912

@sebinside Issues should be resolved now

When I run it in normal mode and select PCM the options for output model are:
Please enter the desired destination model:
[1] WebEditor Diagram
[2] Data Flow Diagram Model

When I run it in debug mode the options are
Please enter the desired destination model:
[1] Data Flow Diagram Model
[2] WebEditor Diagram

While not too big of an issue this could cause a lot of confusion when you try to debug and quickly enter the numbers.

When converting PCM to DFD, assignments without input or output pin are created. They can cause issues with the analysis. As far as I can tell this did not happen before.

Edit: This is the Audi Model

When converting PCM to DFD, assignments without input or output pin are created. They can cause issues with the analysis. As far as I can tell this did not happen before.

Edit: This is the Audi Model

Test implemented in 6abaad0. It does not seem to be an issue anymore

@sebinside @01Parzival10 This PR is ready for a re-review and can be merged