PCM Development/Palladio Concall/Minutes 20170109

• Teilnehmer:
  • Steffen Becker (TUC)
  • Markus Frank (TUC)
  • Felix Willnecker (Fortiss)
  • Christian Stier (FZI)
  • Misha Strittmatter (KIT)
  • Philipp Merkle (KIT)
  • Michael Langhammer (KIT)

• Stateful/Statless in Palladio cont. (FW (Fortiss))
  • Patch fuel Memory Management: State für aktuelle belegten Speicher notwendig
  • State erlaubt Skalierung
  • Christian: Simulation selbst darf State haben
  • Felix: State in Simulation reicht eigentlich aus
  • Infrastructure muss nicht zwangsläufig in Repository: Christian schickt Doku dazu (wenn vorhanden) an Felix
  • Philipp: Befürchtung: momentan können die InfrastrukturInterfaces das aber wohl nicht
  • Felix packt Patch ins Jira und dann diskutieren wir auf Basis dessen
  • Philipp: So wie es bisher ist, ist es aber wohl ganz OK, weil es ähnlich wie die HDD Resource umgesetzt ist

• Updated QuAL report available: https://svnserver.informatik.kit.edu/i43/svn/code/QualityAnalysisLab/Documentation/trunk/org.palladiosimulator.qual.docs/ (Christian)
  • Current Status:
  • Documents MonitorRepository model and SimuLizar extension points for measurement (processing) extensions.
  • Any feedback and suggestions for feedback welcome, contact Christian with input.
  • Report format/branding: Currently single-author Paderborn-branded document from CloudScale context. Migrate to multi-author document?

• Release planning, current state
  • Memory Feature aus München wohl noch nicht in diesem Feature
  • grafische Editoren?
    • Signaturen in Repository sollten bis Februar/März fertig sein
    • d.h. die Editoren können eigentlich produktiv verwendet werden
    • Editoren müssen allerdings vorher gut getestet werden
  • Network und HDD von fortriss ist schon drin
  • Event Sim wird noch fertig
  • Feature Freeze: Anfang Februar
  • nächster Concall: gemeinsamer Test, danach jeder führt Tests durch
  • Tests: Jira hat Tests für Editoren. Sirius Hiwis könnten das übernehmen und den Test anpassen.
  • In Chemnitz gibt es auch ein-zwei Hiwis, die sich da schon eingearbeitet haben und dafür auch zur Verfügung stehen

• ResourceDemandingInternalBehaviors direkt in die BasicComponent zu hängen ist eigentlich falsch (Michael)
  • ResourceDemandingInternalBehaviors hat Performance Informationen und sollte deshalb nicht direkt in der BasicComponent sein
  • wird im nächsten Forschungstreffen in Karlsruhe noch einmal diskutiert

• Metallasse Parameter: statt parameterName selbst zu definieren sollte Parameter von NamedElement erben
  • eventuell nicht ganz trivial, da vorhandener Code bricht
  • Delegation funktioniert nicht so wie sich Michael das vorgestellt hat, d.h. größere Änderungen an vorhanden Code und vorhandenen Modellen sind notwendig

• nächster Concall
  • 06.02.