Protokoll 2012-11-05 Review Misha Strittmatter

Teilnehmer

• Nikola Veber
• Florian Klein
• Michael Langhammer
• Andreas Rentschler
• Nikolaus Huber
• Per Sterner
• Max Kramer
• Philipp Merkle

Protokoll

• Generelle Kommentare
  • Niko: Terminologie: orientieren an Begriffen aus der Domain des Experimentdesigns, z.B. Experiment Set/Series, Experiment, Experiment Run
  • Typo: ResourceModel -> ResultModel

• Global Component Diagram
  • Niko: besser "sortieren", evtl. in Schichten auftrennen; insbesondere andere Darstellung für Ausarbeitung
  • Max: idealerweise auch Kreuzungen von Konnektoren vermeiden
  • Philipp: Ausführen des ModelExtractor besser je Run? Weil die Struktur des PCM Modells sich zwischen Runs ändern könnte
  • Michael: Analysemodi, der dritte Fall ist Spezialfall des zweiten?
  • Max: Quelle von "Check Utilization", wer ruft Analysis Controller auf?
  • Andreas: Datenfluss besser nicht in Komponentendiagramm modellieren
  • Niko: Möglichkeit zur Komplexitätsreduktion? Controller hate z.B. viele Interfaces...
  • Andreas: Semantik des gebogenen Rückpfeils?
  • Niko: Warum eigenes ResultModel? Warum liest man nicht aus FileDataSource direkt aus?
  • Philipp: Warum nicht Adapter für SensorFramework API statt ResultModelStorage?
  • Niko: Wo steckt Logik "95% Quantil für ExternalCall?" -> steckt im Storage
  • Philipp: Vorschlag: schönere API für Zugriff auf SensorFramework bieten (bisherige API kapseln); zusätzliche Komponente liefert Statistiken (Max, Mean, Quantil, ...);
  • Max: Drei Aspekte: Rohdaten, Aggregierte Daten, Arbeiten auf Daten -- diese 3 Aspekte sollten auch getrennt i.S.v. Komponenten sein

• Global Activity Diagram
  • Niko: Auftrennung konzeptioneller Teil und Implementierungsspezifisch ("Notify GUI"), insbesondere für Ausarbeitung
  • "Check Utilisation" evtl generischer formulieren: wäre starker Anstieg Response Time nicht auch Indikator für Bottleneck; linear Anstieg = OK, überlinear = Bottleneck
  • Niko: man sollte zusätzlich auch Response Time für BN Analyse betrachten, da vermutl. nur hier eine überlinare Fkt. beobachtet werden kann
  • Niko: Ressourcen skalieren üblicherweise linear, kann man für das zu Grunde liegende Modell annehmen

• Global Class Diagram
  • Niko: Warum WL-Intensity keine ConfigData?
  • Andreas: an UML Notation halten, z.B. bei Dependencies die Rolle bezeichnen; in der Ausarbeitung wichtig, keine "eigenen" Diagrammelemente zu verwenden
  • Michael: Bedeutung der "reads"?
  • Niko: AnalysisContext von vielen verwendet => Blackboard? -> aber nur lesender Zugriff
  • Michael: AnalysisContext, Gefahr dass diese zur Gottklasse wird
  • Niko: Viele Pfeile zwischen Interfaces/Klassen -> hohe Komplexität?
  • Per: GUI registriert sich als als Listener beim Storage, dadurch Entkopplung
  • Max: SimpleEcoreTransformer, Transformationssprache vorgesehen? => SimpleJavaTransformer?

• ResultModel Class Diagram
  • modfication nicht double sondern generischer
  • falls Aggregation nicht wegfällt könnte man sich die Notiz am ResultIdentifier sparen indem man einen abstrakten und zwei konkrete ResultIdentifier schafft, jeweils für aggregierte und nicht-aggregierte Ergebnisse
  • Assoziation PCMResult -> ResultIdentifier als Komposition ("Containment")
  • Max: "Associations may be reverse navigable..." - welche? Besser einen solchen Hinweis weglassen; wo reverse navigable, sollte man das explizit kenntlich machen
  • Philipp: member "wli", "aggregation" verschieben nach PCMResult, da diese eher Metadaten darstellen
  • Andreas: Vererbung von PCMEntity nicht im Diagramm darstellen
  • Max: "Component" -> "Assembly Context"
  • Niko: "DemandingModelEntity" -> "ResourceDemanding..."
  • Niko: "SEFF" -> "RD-SEFF"
  • Niko: DemandingModelEntity: getDemand muss parametrisiert sein mit RessourceType
  • Andreas: Interface-Implementierung sollte mit gestricheltem Vererbungspfeil dargestellt werden
  • Niko: ResultDecorator vemrutlich eher ungeeignet im Rahmen der DA

• Analysis Result Class Diagram
  • Max: Aggregation statt Polymorphie zwischen Table und MetricMatix, d.h. Table bekommt Matrix als Argument
  • Philipp: Trennung zwischen Datenspreicherung und den Operationen, die auf diesen Daten operieren (am besten zwei Komponenten)
  • Michael: Typo "oneLandBridge"
  • Michael: "TRow", sollte auch Schlechtesten liefern
  • Niko: verschiedene Abstraktionsniveaus (MetricMatrix, HotPath sind unterschiedliche Sachen, aber auf der gleichen Ebene)

• ConfigData Class Diagramm
  • Michael: warum static fromConfig(...)?
  • Max: Statt statischer fromConfig-Methode eine Factory?