PCM Development/Palladio Concall/Minutes 20140908
Palladio Concall
Mögliche Themen für Developermeeting
- Doku zu Palladio Simulation: https://svnserver.informatik.kit.edu/i43/svn/code/QualityAnalysisLab
Sirius vs. Graphitti
- wir haben spezielle Anforderungen z.B. soll es möglich sein Editoren zu erweitern
- Palladio Editoren
- Sirius Editoren:
- Sebastian hat SystemEditor mit Sirius nachbauen lassen. Der funktioniert auch schon recht gut. Das hat auch nur ca. eine Stunde gedauert
- Ziel: Vergleich von Sirius SystemEditor mit Graphitti SystemEditor
- Sirius kann mit OCL und Acceleo Query Sprache angefragt werden
- Sirius kann Properties-view automatisch erstellen
- Idee: auf den Palladio Days mal etwas ausprobieren
- Möglicher Vorteil Sirius: Generativer Ansatz, der auch funktioniert
- SHK: Max Schüttler: Sollte seinen Sirius Editor mal ins SVN einbuchen
Developermeeting Orga
- findet hochwahrscheinlich statt, da sich viele bei Sebastian Lehrig gemeldet haben
- Idee für Agenda: Agenda wird am Anfang des Developermeetings vor Ort festgelegt. Das hat bisher auch immer funktioniert
- Misha kann Graphitti vorstellen + Anforderungen an neue Editoren
- Misha kann auch noch Sachen zu Modularisierung vorstellen (falls es nicht für den Workshop genommen wird) und auch Sachen dazu wie PCM für System of Systems verwendet werden kann
- Sebastian stellt Analyseframework vor
EDP2 vs. Deprecated SensorFramework
- SensorFramework ist vorerst deprecated. Wenn jemand was neues codet dann sollte EDP2 verwendet werden
- Ziel: SensorFramework komplett los werden
- EDP2 kann z.B. Messpunkte, Einheiten usw.
- Bis zum Palladio Days sollte EDP2 weitestgehend fertig sein
Release Tasks & Responsibilities (See: https://sdqweb.ipd.kit.edu/wiki/PCM_Development/Palladio_Release_Process)
- 1. Testing --> can this be organised by Christian Stier
- Kann man auch noch mal auf dem Dev. Meeting besprechen
- Bisher waren Tests so, dass wir auf dem Dev. Meeting die Jira Tests durchgeführt
- Das könnte auch von SHKs/HiWis
- Im Optimalfall: in den JIRA Test-cases sollte alles ausfüllend
OCL Constraints (AtLeastOneInterfaceHasToBeProvidedOrRequiredByAUsefullCompleteComponentType; see mail by Max)=
- Eigentlich brauchen wir tatsächlich nur sowas wie AtLeastOneInterfaceHasToBeProvidedByAUsefullCompleteComponentType
Diskussion um RequiredRoles
- beim ProvidedType sind RequireRoles nicht bindet bzw. sie können erweiterte werden
- Idee: Architekt legt schon fest welche Rollen welche Roles wahrscheinlich required werden. Es können aber noch weitere hinzukommen
- Gegenargument: Die RequiredRoles haben bisher noch keine Auswirkung bzw. sie können später komplett anders interpretiert werden
- beim CompleteType sind die RequiredRoles bindet
- Kann auch noch mal auf den DeveloperMeeting auch noch mal diskutiert werden