SDA SE Wiki

Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering

User Tools

Site Tools


AGOOP 17.05.04: \\ Offene Diskussion zum Thema Modellierungsalternativen.

  • In erster Linie koennen hier Fragen gestellt und von anderen Teilnehmern (hoffentlich) beantwortet werden.
  • (dsp) Mir wäre auch wichtig zu erfahren, wie Ihr vorgeht. Zieht Ihr Bücher heran? Kramt Ihr Skripten heraus? Stellt Ihr Prinzipien auf? Seid Ihr Euch der Qualitäten bewußt, nach denen Ihr die Alternativen bewertet? Listet Ihr überhaupt alle Alternativen auf oder habt Ihr die richtige Lösung schon im Gefühl? Sicher?
  • Rachid hat vorgeschlagen, dass jede/r ein vorbereitetes Statement abgeben muss.
  • Pascal schlägt vor, dass Ihr mal darueber nachdenkt, wann Ihr das letzte Mal mit einem nicht eindeutigen Fall zu tun hattet, und wie Ihr es letztenendes geloest habt. Welche Vorgehensweisen helfen in der Praxis Eurer Erfahrung nach?

Themenvorschläge:

[1] Wann ist Unterklassenbildung sinnvoll und wann parametrisiere ich eher Klassen?
[2] Wann ist die Verwendung von Delegation wichtig?
[3] Wie modelliere ich gesteuerte Geräte in meinem System?

Nachträge:

[4] Pascal zu Equal-Specializern in Lisp bzw. deren Nachbildung in Java


[#1]

Unterklassenbildung

Die Frage, ob man eher vorhande Klassen parametrisiert oder eine Unterklasse bildet scheint mir in vielen Gewändern zu erscheinen. Hier vier Beispiele:

1) In contract wird eine Klassenhierarchie der Bedingungen aufgebaut. Die konkreten Bedingungen könnten einerseits als Unterklassen oder aber auch als parametrisierte Objekte erstellt werden. Zunächst sind die Bedingungen aber nur Platzhalter, die als Elemente in einem Baum auftreten können, um so eine Struktur zu editieren. (Daran schließt sich an: Wann sollte ich auf der Ebene des Benutzerinterfaces solche Platzhalter verwenden und wann hänge ich meine schweren Objekte in diesen Baum?)

2) In der ersten Sprache des JTransformer-Prolog-ASTs stand der Fakt varDefT sowohl für Methoden Parameter, als auch für lokale Variablen als auch für Felder. (Für JTransformer-Neulinge: In einer Datenbanktabelle wurden drei leicht unterschiedliche aber nahe verwandte Objekte gespeichert.)

3) “Magic Objects”. Verwendung von speziellen “Benutzern” für bestimmte Aufgaben oder Rollen. Verwendung von “Pseudo-Stories” beim XP-Tracking.

4) “Magic Parameter” für Funktionen, Methoden. Also: Wenn ein Parameter einen bestimmten Wert hat, macht die Funktion etwas ganz anderes als sonst.

Ein paar Ideen:

  • Mit dem Unterschied von Klassen und Prototyp basierten Sprachen hat sich Günter ausgiebig beschäftigt. Hier lohnt es sich wohl in seiner Diss nachzulesen.
  • In Common Lisp kann man auch Methoden in Objekten (nicht nur in Klassen!) überschreiben. Hier kann man die Frage also nochmal komplizierter stellen. (siehe dazu: [4])
  • Man kann die Frage auch umgekehrt betrachten: Ich nehme eine Objektstuktur her und speichere in einem speziellen Objekt Meta-Informationen. (Beispiel: Ich hatte eine eine Datenbanktabelle mit Klartexten zu Konstanten verschiedener Kategorie. Ich habe dann den Klartext mit der Id -1 als Namen der Kategorie intepretiert.)


[#2]

Delegation

Gesteuerte Geräte

In Schlagworten: Spiegeln oder Hindurchsehen? Repräsentiere ich diese Objekte als Teil meiner Anwendungsdomäne? Hole ich mir den Zustand des realen Objekt von irgendwo und schreibe ihn dann in das Objekt, in dem es sich widerspiegelt? Oder manipuliere ich anderherum das reale Objekt durch das repräsentierende Objekt? Was ist, wenn der Zustand meines realen Objektes mit dem des repräsentierenden Objektes nicht übereinstimmt?


[#4]

Pascal zu Equal-Specializern in Lisp bzw. deren Nachbildung in Java

Hiho,

Daniel meinte neulich, dass bei Designfragen die eql specializer in Common Lisp die Antwortfindung nochmal komplizierter machen. Meine spontane Reaktion war, dass das (natuerlich nicht stimmt. Das reicht jedoch nicht als befriedigende Antwort, und daher habe ich ueberlegt, was das bedeutet.

Der Hintergrund ist, dass man aufgrund von Turing-Aequivalenz in allen Sprachen immer alles machen kann - der einzige Unterschied ist, dass in manchen Sprachen sich manche Dinge “nur'” komplizierter ausdruecken lassen. Daraus resultiert aber, dass man auch in Java eql specializer irgendwie nachbilden koennen muss. Auch das ist trivialerweise richtig, ist aber nur maessig spannend, wenn man dafuer im Prinzip einen Interpreter oder Compiler fuer eine andere Sprache implementieren muss.

Interessanterweise habe ich aber einen Weg in Java gefunden, die eql specializer nachzubilden, ohne dass man in Java einen Common Lisp Compiler schreiben muss. Sie lassen sich sogar relativ elegant in Java einbetten. (Damit faellt ein Vorteil von Common Lisp gegenueber Java also weg - andererseits sind deswegen Designfragen in dieser Hinsicht in beiden Sprachen genauso kompliziert zu beantworten. ;-P

Hier der Code - mein Lieblingsbeispiel fuer eql specializer ist die Fibonacci Funktion. Zunaechst die Common Lisp Variante:

(defmethod fibonacci ((i (eql 0))) 1)

(defmethod fibonacci ((i (eql 1))) 1)

(defmethod fibonacci (i)
  (+ (fibonacci (- i 1))
     (fibonacci (- i 2))))

? (fibonacci 6)
13
? (fibonacci 8)
34

Jetzt die Java Version:

public class FibInteger {

   protected int value;

   private FibInteger(int value) {
      this.value = value;
   }

   public static FibInteger make(int value) {
      if (value == 0) return ZERO;
      else if (value == 1) return ONE;
      else return new FibInteger(value);
   }

   public FibInteger fibonacci() {
      return make(make(value - 1).fibonacci().value +
                  make(value - 2).fibonacci().value);
   }

   public static final FibInteger ZERO = new FibInteger(0) {
      public FibInteger fibonacci() {
         return ONE;
      }
   };

   public static final FibInteger ONE = new FibInteger(1) {
      public FibInteger fibonacci() {
         return ONE;
      }
   };

   public static void main(String[] args) {
      System.out.println(make(Integer.parseInt(args[0])).fibonacci().value);
   }
}

java FibInteger 6
13
java FibInteger 8
34

Der einzige “technische” Unterschied ist, dass ich in Java eine Factory verwenden muss, um die Eindeutigkeit der Objekte ZERO und ONE (fuer 0 und 1) zu gewaehrleisten, waehrend in Common Lisp die Zahlen selbst bereits Objekte sind. Bei eql specializer fuer “echte” Objekte sollte das egal sein…

Pascal

research/jtransformer/trash/agoop170504.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2019