* Update Guice to a self-compile version that allows overriding
  @Provides methods.
* Create an "@PluginDecoder" annotation along with a MethodInterceptor
  that intercepts such annotated decode methods. It launches all decode
  methods that provide the same phenotype prior to executing itself
  (sub-decoding). These sub-decoders are providing updates to the
  phenotype before the actual decoding is executed.
  NOTE: Sub-decoder methods must be annotated with the "@Named("XYZ")"
  key where XYZ is the class name of the decoder. This is required to
  avoid @Provides methods that would return the same type.
* Re-create the DecoderModules by the Guice Injector before passing them
  to the GuiceDecoder such that Method Interceptors can be installed
  before the GuiceDecoder is instantiated.
* Correct the integration of the PlatformCommunicationGraphEncoding.
* Add more required @Provides Methods to the SystemModelAdapter.

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

* The IExplorationFeatureService allows to add extensions to the DSE
  process that consist of sub-modules, e.g., Variables, Evaluations,
  or additional operations on existing encodings.
* While the IExplorationFeatureService is used to manage all existing
  extensions, the activated ones (configuration) is passed to the DSE
  by the exploration backend. Currently, the activated features are hard
  coded, but shall be moved to the UI.
* Consequently, the IExplorationModuleService has bee removed. Its
  functionality has been moved to the ExplorationFeature abstract class
  that are single features registered with the
  IExplorationFeatureService.
* The activated features now govern the installation of the sub-modules
  (Creators, Decoders), instead of the previous
  IExplorationModuleService.
* When setting up the Opt4J exploration, the activated decoder
  configuration is now checked for consistency to avoid circular
  dependencies and duplicate responsibilities of decoders to create a
  phenotype.
* An IExplorationFeature type is added to the MOEA ecore model to allow
  referencing exploration features from EMF classes.

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

* Add a mechanism to analyze the Guice dependency graph to
  collect the set of genotypes that is required to obtain a
  requested Phenotype. The code is a modified version of
  the dependency graphs calculated within Guice's Grapher
  extension). The list of required Genotypes determines
  the list of creators to be launched.
* Use OperatorModules from Opt4J to inject them into the fw
  instead of using custom ones (conflicting inheritance
  hierarchy).
* Register Variables at the service level (Genotypes,
  Creators, Operators).

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

* Create a top-most injector (DSE injector) when the explorer is
  created. It hosts the Opt4J injector and allows accessing data from
  the DSE from within Opt4J Modules.
* Enable Multi-Operator bindings (multiple operators from which one is
  selected to be applied on the same Genotype-Type) by the Operator's
  type. This is required to allow injecting DSE-wide parameters, e.g.,
  system model data.
  * Use a OperatorKey to allow registering Operators Objects or their
    Classes in the selection map.
  * Operators registered by their type are initialized lazily when they
    are delivered by the OperatorSelector on request.
* Remove various dependencies on the SystemModelAdapter (Use DI where
  data is needed). This allows to break up very complex inheritance
  hierarchies.
* Extend the SystemModelAdapter to use @Provides annotations that are
  used in opt4j modules (e.g. decoders) to obtain system model data.
* Some of the old custom factories are now initialized with a null value
  for the SystemModelAdapter since they will be removed soon due to the
  use of DI.

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

* Self-build version that allows to embed the opt4j injector as a child
  injector.

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

* Refactoring: Remove unneeded Generics from several encodings and
  adapters. It is not possible in Guice to bind arbitrary Generics
  without additional concepts and a lot of implementation work. Thus,
  reduce the use of generics where possible.
* Modify the decoders to contain Provides methods that are resolved by
  the Guice injector to resolve the execution order.
* Reduce a lot of boilerplate code from the Decoders that was required
  by the old JGraphT-based Decoding.
* Only support FailSafeTaskMappingEntries for now: The genericification
  shall be discussed anyways.
* Register the guicified decoders in the Service registration class
  ExplorationAlg.
* Don't allow double registration of Guice Modules in the
  ExplorationModule service.
* Add a ThreadLocalScope that may be required for parallelization to
  ensure using the correct genotypes in the decoders.

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

* YELLOW: ExplorationExceptions.
* Add ExplorationServiceRuntimeExceptions for cases where no exceptions
  may be thrown (e.g., startup methods).
* Modify the ExplorationModule service such that instances of them must
  be registered instead of their types (no-arg constructors).
* Add the ExplorationModule service to the plugin startup class.
* Register the FailSilentTaskMappingDecoder.
* Adjust the FailSilent- and FaultTolerantTaskMappingDecoder such that
  they use the new Guice DI mechanism.
* Remove the creation methods of the above decoders from the DSE
  factories.

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

From the class doc: 
* Service for adding Exploration Modules to the DSE. The define the
  concrete problems that shall be solved by the DSE process. Modules
  registered with this service are known to the DSE and can be selected
  by users to define a DSE process. The Modules registered here are not
  defining a concrete DSE process, just the concrete problems.
* Exploration modules can be categorized into three classes: Variable
  definitions, Problem statements and transformations, and Evaluators
  (solution metrics). The variable definitions consist of a Genotypes
  (variables), Operators (modify variables), and Creators (variable
  initialization). Problem statements transform Genotypes into
  evaluable solutions implemented by Decoders that produce Phenotypes.
  Evaluators rate Phenotypes such that the quality of a solution can be
  quantified.
* The complete DSE process is based on DI:Creators, Operators, Decoders,
  and Evaluators have to be implemented as Guice AbstractModules.
  Therefore, the package org.fortiss.af3.exploration.alg.dse.module
  contains base classes simplifying the definition of exploration
  modules.

* Also, provide a basic 


Signed-off-by: Alexander Diewald <diewald@fortiss.org>

* The generic parameter was intended to specify the extension types
  (modules) of an exploration services.
* This information is used nowhere, so remove it.

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

* The existing IExplorationModule is a marker interface for DSE
  extensions. It conflicts with the naming of "ExplorationModules" that
  are intended to declare sub-problem descriptions of a DSE process.

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

* Enables to build provisioning modules that do not implement empty
  configuration() methods.
* Additional bug fixes.
* Also update Guava to version 25.1 due to deps from guice.

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

* Remove the DseSpecification as a dependency from encoding, decoders,
  and creators in parts.
* DseSpecifications are used to extract constraints from the input
  constraint set. They will be replaced by a constraint extraction and
  propagation mechanism.

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

* Testwise implementation of a decoding mechanism that is intended to
  replace the current dependency declaration and resolution mechanism
  with the Guice framework. This step should allow to reduce a lot of
  boilerplate code and ease maintenance.
* The mechanism is is based on the "Providers" and "@Provide"
  annotation in combination with "@Inject" fields that declare the
  input dependencies.
* TODOs:
** Switch all decoders to the new mechanism.
** Reduce the mountain of abstraction code that is not really required
   to configure the DSE.
** Implement a service mechanism that binds the guice modules belonging
   to an exploration feature.

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

* Create a GuiceDecoder class that serves as a container at which
  Guice-based decoders can be registered. It calls the Decoder that
  provides the demanded output encoding (Provides annotation). The
  Guice injector will be responsible to resolve the dependencies between
  the decoders.
* Simplify the Phenotype classes such that there exists only a single
  phenotype that can host sub-phenotypes.
* Also remove the generic from the phenotype that declares it's primary
  input genotype: There is almost no gain in terms of safety/robustness
  versus a ton of code complications.

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

* Package and meta-model descriptions will be added later due to major
  restructuring in the coming weeks.

Issue-Ref: 3430
Issue-Url: https://af3-developer.fortiss.org/issues/3430


Signed-off-by: Alexander Diewald <diewald@fortiss.org>

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

Signed-off-by: Alexander Diewald <diewald@fortiss.org>

When using a non-z3 backend (here: the unofficial MOEA backend) that makes a more extensive use of the ExplorationSolution, invalid models can be produced. The reason for this behavior are faulty containment relations since the produced model fragments of the DSE were not contained in any other EObject. Here, it shall be noted that the SuperSets themselves are not intended as containers as of now since they are also used to pass around references to the relevant elements of a DSE.

Furthermore, one warning was produced due to an EAttribute not being set (noticeable on the console).

Technical details:

* getCastedType(...): Used to avoid ugly casting in client code. The DSE language is based on generic IModelElements, whereas the Sets/SuperSets are strict w.r.t. to the types to provide guarantess for the DSE I/O.
* The ExplorationSpecification now contains the the map of input parameters passed to the DSE (Tracing), but not its elements (!).
* ExplorationSolution: 
* * Contains the returned SuperSetMap.
* * Added a "pool" for SuperSets: They are accessible via the SuperSetMap.
* * Added a element "pool" for the generated elements referenced by the returned SuperSets.
* DSMLModelElementFactory: Creating Sets now requires a reference to the SuperSet (reduced code redundancy; can be used for robustness checking later).
* Adapt to the meta-model changes when using SuperSets/Sets (esp in the smt plugin).
refs 3353

refs 3257

* Using exponential functions for the penalty calculation of constraints is common practice and favored over pure potential functions.
refs 3257

* Adds a sub-method to the Partition Transformation Strategy that adds Ports and Channels to a PartitionAchitecture.
* The required Ports and Channels are derived from the Signals exchanged between Tasks.
* Ports and Channels are only added for InterPartitionCommunication (logically).
* The Sampling and Queuing characteristics of PartitionPorts is derived from their corresponding TaskPorts.
refs 3257

* Correctly implement a constraint that enforces partitions to host only Tasks of ONE safety level.
refs 3257

* The SuperSet transformation methods are now implemented in a TransformationStrategy (Sub-package modeltransformation). Remove the leftover stubs.
refs 3254

refs 3257

refs 3261

* Simplify the Transformation Service interface.
* Clean and simplify the base implementation of the Transformation Framework.
* Introduce a container element that makes the Transformation almost agnostic to the fact if the inputs stem form DSE-internals or SuperSets.
* Add a SuperSetMap transformation strategy.

* Add SuperSets to the transformation interface: The dependency handling is still missing.
* Transformation for generated partitions.
* Transformation for Partition to ExecutionUnit allocations.
* transformation for Task to Partition Allocations.
refs 3257

* Change the MM accordingly.
* Introduce static helper methods to implement the getters/setters of the affected maps: Runtime exceptions are thrown on mismatching types.
* Add a migrator to set the DSESuperSet types of old models.
* Adjust the factory methods.
refs 3289

=================
| Exploration

exploration.ecore
=================
- ExplorationSpecification
  - targets: non-contained (Migrator!)
  - Add superSet reference to pass required SuperSets to the DSE backend.
- Remove ExplorationSolution interface: No Migration needed.
- Rename ExplorationSolutionSet --> ExplorationSolution
  - Deprecated inputModelAdapter: No migration needed, only used in MOEA.
  - Renaming: targetSpecification --> explorationSpec
    - targetSpecification marked @deprecated
    - No mirgator needed: Class was not used in previous stable releases.
- Add EClass SuperSetMap: Relates types of elements to SuperSets
  - solution: EJavaClassToSuperSetMap (containment!)
- Add EClass EJavaClassToSuperSetMap: internal map of "SuperSetMap"
  - key: Class
  - Value: SuperSet (NO containment!)
- ExplorationSolution
  - Renamed solutionModelMap -> solutionSets
    (Type EJavaClassToEJavaObjectMap -> EJavaClassToSuperSetMap)
  - Adjust EOperations to modifications in backend map.
- SingleExplorationSolution
  - Add the solution state for single solutions.
  - Adjust EOperations to modifications in backend map.
- Removed EJavaClassToEJavaObjectMap

dseproject.ecore
================
- DSE:
  - Add EReference target: ExplorationTarget (containment)
  - Remove explorationSpecification (Migrator!)
- Add an ExplorationTargetPool that contains all ExplorationTargets of a DSE
  project.
- DSERun:
  - Add EReference explorationSolution (containment)
  - Remove EReference visualization (Migrator!)
  
dsl_v2.ecore
============
- Overwrite the accept method for the Sum expression: Do not return null if the
  associated set is empty, evaluate to Zero, instead.

New Migrators
=============
- DSEExplorationTargetContainmentMigrator
  Migrates the set of explorationTargets to the DSE project
- VisualizationToExpSolutionMigrator:
  Migrates the Visualization data to the ExplorationSolution representation that
  allows a better traceability.
  
Other Business
==============
- Adjust plugin.xml to account for recently removed Objective- and
  ConstraintExpression classes. Now, ExplorationObjective and
  ExplorationConstraint is used.
  
=================
| Exploration.alg

- Adjust the Opt4JBackend to be comply to the new DSE Backend Specification
- The output type detection in the base decoder is more robust.
- The ITaskAdapter temporally references its corresponding component to ease
  the refactoring of the DSE backend interface. This shall not be needed when
  the transformation framework is integrated again.
- Temporally transform the internal solutions to a superset of
  ComponentToExecutionUnitAllocations to create s solution model. Workaround
  until the transformation framework is integrated again.
- Misc adjustment for backend changes.

=================
| Exploration.smt

- Adjust the Z3Backend to be comply to the new DSE Backend Specification
- Base the results of the DeploymentRun2 and SolverRun2 on the
  ExplorationSolution (see above).

================
| Exploration.ui

- Adjust the GUI logic to account for the changed containment relations.
- Update the DSE project import wizard for the Meta-Model changes.
- Move the ExplorationSolutionVisualizationUtils class to the UI plugin (here).
  It is used to transform ExplorationSolutions to a Visualization representation
  (i.e., DataSetCollection).
- Use doubles instead of ints in the SpiderChartUtils. Although not a proper
  solution, this covers more cases... Instead the generic should be reflected.
refs 3273

* No migration needed due to the eClasses' abstract/interface nature.
* Removed ObectiveExpression
* Removed ConstraintExpression
* Removed ExplorationTargetExpression
* Removed GenericObjective
* Removed GenericConstraint
refs 3273

refs 3279