The current event dispatcher implies an internal sequence on the events sent out to a specific port. This can be quite nontransparent, as you need to know all previous port declaration to understand the output of a specific port.

An older bachelor thesis defines another kind of correspondence model, than the one currently used and extended ProtoComin a way that a valid correspondence model is automatically being built by ProtoCom.

The current and new correspondence models need to be merged in a way to keep the ProtoCom functionality of the new and the more intuitive way of accessing the model data of the current model.

Classification of User Behavior through Connectivity-Based
Clustering

Refactor the code to fit the proposed architecture.
Each phase of the MAPE loop should be represented by a single service.
Respectively Rest-APIs have to be negotiated and implemented.

An empty privacy warner already exists in /service.privacy.violation/src/main/java/org/iobserve/service/privacy/violation/filter/PrivacyWarner.java

Logging does nor work everywhere as expected. This might have to do with additional log configurations.

This is called ProbeController in the architecture.
https://github.com/research-iobserve/iobserve-documents/blob/master/jss-paper/jss-architecture.pdf

Comparison of user behaviour
classification methods

Limit the amount of allowed warnings, e.g. from Checkstyle oder PMD, to avoid neglected rules and low quality

We need a deployment event which includes geolocation information. Also revise architecture.

At the moment all features of iObserve are bundled in the same configuration.
This causes some issues if single features should be tested as unrelated ones also have to be provided.
For example, all visualizations and analysis steps are enabled as default.
This creates dependencies to other services that may not be used in all executions.

Therefore, it will be useful to create feature toggles, that also define the expected parameters or split the larger configuration into smaller and more specialized ones.

So far, AdaptationData records and a so called ModelGraph were used to pass data within iObserve's control loop. With the restructuring of the phases into separate gradle-projects the adaptationdata library was created to share these classes between the projects. However, it might make sense to restructure/split up this library in the future.

To cleanup the project the different config files, e.g., for Checkstyle, PMD, etc should be moved to a config folder and the build process should be adjusted.

Presently, we have two kind of model providers:

• File based model providers
• Database based model providers
• Generic database model provider

The file based providers could be used to initialize the NEO4J database. Beyond that they should be removed.

Currently, to avoid read/write conflicts/missing updates the ModelProvider contains non-locking readOnly-Methods and locking read/write Methods.
The class ModelProviderSynchronizer handles the locking.

The developer has to maintain the overview of the whole process to avoid deadlocks oder conflicts. In the future, this should be solely handled by the provider itself.

Implement a new RAC model (EMF) and integrate that with the model storage facilities from Lars (CAU).

Test Issue

An empty filter called AlarmAnalysis exists in /service.privacy.violation/src/main/java/org/iobserve/service/privacy/violation/filter/AlarmAnalysis.java

This has to be filled with the code necessary for the AlarmAnalysis. In advance it must be defined which information is necessary to detect data flow and classify it as an alarm.

You may document everything in the iobserve-documents project.

The test TestSessionAndTraceRegistrationPayloadFilter randomly fails. It is disabled at he moment but has to be repaired.

I have peeked into the Gradle build set up for the iObserve analysis, which I guess is a intended to be the replacement of the original Maven build. While I recently improved the Maven build to mitigate issues with Eclipse packages, the Gradle build does not support these features. However, it should. In research-iobserve/iobserve-analysis branch merged-observe, you may find all the necessary information in the README.md of the org.observe.releng directory.

Using the new TCP-Controller Interface from Kieker, we want to establish multiple TCP connections to different applications

We need an RAC mapper for events which are used to determine data flow. You have to clarify which events we can receive, e.g., EntryLevelEvents, to indicate data flow. Then these events must be transformed into their PCM equivalent.

the iObserve analysis is a rather complex piece of software utilizing a vast set of simple filters and composite stages. The configuration over command line parameters for all potential combinations is unsatisfying. Therefore, we should switch to a configuration file.

In general the analysis supports X distinct analyzes:

• Behavior analysis
• Deployment and Allocation
• Dataflow and Geolocation
• Separate Geolocation
• Call and Messages Traces

Not all these features are sufficiently implemented. However, they are intended features which should be activated separately. Also for some analyses, there are different strategies and dependencies. for example, the behavior analysis uses a set of different clustering and classification mechanisms.

Tests need to be (partly) restructured as it is hard r.n. to find a test to a given class. Also test coverage, as specified by clover, needs to be increased with meaningfull tests.

The current ModelProvider uses our own EMF to Neo4J mapping. It was developed as the Neo4EMF-project seemed to be dead and incomplete. However, they renamed their project in NeoEMF and did not remove the old github projects. Anyway, with continuous support for NeoEMF, we could try to use it instead of our own EMFtoNeo4J mapping. Therefore, we have to evaluate the fitness of NeoEMF with Neo4J and other DB-systems.

http://www.neoemf.com/

And in case it works out, port the ModelProvider to this new library.

In our current implementation f the model database, models that are referenced by the saved node (and are saved elsewhere) are as 'proxy nodes'.
These nodes contain only the reference to the represented model, but can't be automatically resolved.
For future work, it can be useful to enable Proxy Node Resolving and add further information like model version / variant.

We should publish parts of iObserve via sonatype. Therefore, we have to change settings.

Collect all configurations that are used for filtern in the properties file (for documentation) and ConfigurationKeys, to make sure they can be referenced. Also emigrate configurations out of filters, where the configuration is parsed internally (should happen externally).

Due to changes in the filter structure. Tests have to accommodate the new filter semantic. Some tests are also not very effective. This has to be fixed too.

We want to log user behavior during the the SE software project suitable for the iObserve behavior analysis. We already have a property SessionAndTraceRegistrationPayloadFilter which creates EntryLevelBeforeOperationEvents, AfterOperationFailedEvents, and AfterOperationEvents. However, there exists already another filter to log behavior, which is used by Henning. He has an analysis tailored for this needs. We need to port his analysis to iObserve or adapt his analysis to support the new record types.

When I try to build the analysis the following packages and all classes in them are missing. In detail they are:

• org.gag.* BTW the name is, well, misleading ;-) Is this a funny organization?
• protocom.extension.*
• giusa.parser.*

These packages should either be integrated or, in case they are general purpose and used in different projects, should be at least provided in their own repository with their own Maven or Gradle build.

Fix the geolocation updater for the PCM model.
The present implementation /analysis/src/main/java/org/iobserve/analysis/privacy/GeoLocation.java
Might not do what we want.

The model probe controller gets a set of warnings and computes which probes have to be deactivated and activated to accommodate these warnings. As it always gets a full set of warnings, it only needs to remember which probes it has activated in the past so that it can deactivate them if they are no longer needed for the incoming set of warnings.

We need to make xmeans and em available for the IBehaviorCompositeStage interface.

Currently iobserve relays on teetime stages for the trace reconstruction, but teetime stages is deprecated as it has been integrated with Kieker. However, in Kieker these stages have been named differently.

ModelComparisonStage has an odd structure in testing whether it has two inputs, which only works for exact two inputs and may fail later.

The model level probe activations and deactivations must be mapped to implementation level activations and deactivations. Therefore, we need access to the RAC with reverse mapping and the correct event model on both levels (CAU).

Planning and Execution of System Adaptations
in Cloud-Based Environments

Currently, all information are collected by the TBehaviorModelTableGeneration Filter
at the end of the information stream the collected and aggregated data is transfered to the remaining analysis.
In the future, we want o enable live clustering and updates for the monitored applications.

which rule set is suitable for iObserve?
Maybe the Kieker rules can be used

There are gradle and java warning present in the tooling which is not necessary. these must be removed prior to Ticket #122

Currently the analysis sub project contains all sorts of code which does not belong to the analysis service. Unfortunately, they are packed in the same org.iobserve.analysis. To fix this issue, I propose to move them to separate projects which would also allow to really create executables for planning and adaptation.

What to do:

• Create a new directory for planning, adaptation and execution
• Copy the build.gradle from analysis.cli to all these directories and adjust the parameters
• Add the directories to the settings.gradle file (after all the library components)
• Re-import the gradle main project in Eclipse this will automatically import the new directories as empty projects
• Create a src/main/java and src/test/java source folder in each project
• Move packages within Eclipse from analysis to the respective projects
• Fix the dependencies in the build.gradle file if necessary