PCM Development/Palladio Concall/Minutes 20140908

Aus SDQ-Wiki

Palladio Concall

Mögliche Themen für Developermeeting

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