Unclear what needs to be done / what the problem is (which one needs the predicate constructor?)
Where is the method created?
The classes are generic
The itnerface allows to pass containers, parent elements, etc.; based on these, the shown tree is reduced (for elements that can be selected). Instead of passing classes etc., we should pass a Predicate (function from EObject -> boolean)
SB: Should already be like this and only show the signatures/roles that are already declared (as it is described in the issue)
general discussion checks are still needed in the future
shall checks be split into code-gen related and meta-model related checks?
shall be identified meta-model related checks be integrated into meta-model as OCL constraints?
Predates OCL, checks things that cannot be easily checked with OCL (recursion?).
SB: Best would be to get rid of the checks (unclear how long check engine will exist/be maintained)
StS: We also do Java constraints (so if it is not possible in OCL it is no showstopper). Challenge is to find out which are valid meta model constraints and which ones are very specific for the code generation.
StS: Is the simulation working as it should?
Yes it is, but gives irritating errors / validation statements in the log.
verdict: For validations for which it is unclear whether we want them, discuss in next ConCall.
verdict: New ticket for metamodel to create necessary constraints, then set WFE-86 to Won't Fix, remove check file.
comment: Some of the checks could be migrated to the ProtoCom add-on because there is still code generation there. Should not be a problem, since the checks reside in the SimuCom project, ProtoCom still depends on it. Then deprecate/RIP the remaining file with SimuCom.
ProtoCom should be kept runnable but does not need active maintenance (and it should currently work).
Dependency graph very complex when graphically presented
How can this overview of the architectural dependencies of the Palladio modules be further prepared for our retrospective discussion?
Idea: Ranked dependency with color-grading?
Package-level is more confusing than current graphs.
Would be interesting to have something interactive (for example clicking on one node and then all related nodes/edges).
Remove some bundles/packages inside that are not really hard dependencies between projects but boiler code (e.g. dependency injection) which has high connectivity. -> filter criteria on the graph.
Dump the graphs, also on package level into Neo4j database and use the standard graph visualization there. Similar to JQAssistant?
Future: Representation is not as important as also making clear how to use the graph and which challenges become apparent from it.
JH: Would maybe make sense to use SotoArc/SotoGraph (virtual refactorings to find out how they would help with refactoring).
Would also be helpful to tag bundles (e.g., ui) to filter/arrange/check.
StS: Graph is complex because of transitive dependencies. Really hurts:
cyclic dependencies (barely in PCM codebase),
if low-level nodes depend on a lot of stuff and
UI dependencies.
Project-based representation is bad representation, because EMF-based project has many parts (meta model, UI, simulizar extension, ...). Different granularity of dependencies would make it better (e.g., bundle-level).
No prescribed architecture of Palladio, then evolution. We do not have a defined architecture to fit the current state into.
Verdict: Dump it in Neo4J. Sandro should have some knowledge about that.
Automated verification and evaluation of PCM models
Offered as practical course topic, but did not get a student for this
