Protokoll 2012-11-05 Review Misha Strittmatter

Aus SDQ-Wiki

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?