Wam Metaphern
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

WAM steht für Werkzeug, Automat, Material. Dahinter versteckt sich eine komplette Entwicklungsmethodik. Der Fokus liegt aber auf den o.g. Metaphern, die sehr gut mit der XP SystemMetapher harmoniert. Nach WAM sucht man nach geeigneten Materialien, Werkzeugen und Automaten, um das System für Entwickler und Anwender verständlich zu beschreiben.

Ein Material ist demnach ein fachlicher Gegenstand oder ein fachliches Konzept. Beispiele: Konto, Vertrag, Bestellung, Notiz. In der softwaretechnischen Umsetzung haben Materialien kein Wissen über Technologien, wie z.B. Benutzungsoberflächen, Transaktionsmonitore oder Middleware. Dadurch sind sie sehr flexibel einsetzbar und wiederverwendbar.

Materialien werden durch Werkzeuge bearbeitet. Werkzeuge haben immer eine Repräsentation gegenüber dem Anwender. Im Gegensatz zu den Materialien werden die Werkzeuge nicht einfach aus dem Anwendungsbereich übernommen. Zum einen ist es so gut wie unmöglich, die Flexibilität eines Bleistiftes in Software zu realisieren. Auf der anderen Seite bekäme man dann nur eine Simulation des Anwendungsbereiches. Irgendein Fortschritt wird in der Regel von einem Softwareprojekt schon erwartet. Also wird nur das generelle Konzept "Werkzeug" in Software übertragen. Die konkreten Software-Werkzeuge richten sich jedoch nach den technischen Möglichkeiten sowie den fachlichen Aufgaben. Passend zu den o.g. Materialien könntes es einen Überweiser, einen Vertragseditor oder auch einen Besteller geben.

Werkzeuge sollen möglichst flexibel handhabbar und miteinander kombinierbar sein.

Es gibt jedoch immer einen Teil an lästiger Routinetätigkeit, der nur unzureichend mit Werkzeugen unterstützt werden kann. Für diesen Zweck werden Automaten eingesetzt. Diese sind nicht so flexibel einsetzbar wie Werkzeuge, nehmen dem Anwender aber mehr Arbeit ab.

Wir haben in unseren XP-Projekten sehr gute Erfahrungen mit den WAM-Metaphern gemacht. Wir haben erstmal mit diesem generellen Konzept gearbeitet und dann über die Projektlaufzeit die Metaphern immer weiter verfeinert.

-- StefanRoock


Ein Beispiel aus dem Versicherungsbereich könnte so aussehen: Fachliche Kernkonzepte wie Versicherungsprodukt, Vertrag, Partner, Beitragskonto lassen sich leicht identifizieren. Diese werden als Softwarematerialien modelliert. Da ist jetzt noch nichts geheimnisvolles dran, außer vielleicht, dass man hier auf GUI, EJB, Persistenz und sonstige Technologien komplett verzichtet. Martin Fowler nennt diese Objekte POJO (Plain Old Java Object) und empfiehlt diese technologiefreie Modellierung für das Fachmodell.

Nun analysiert man, welche Aufgaben die Anwender mit diesen Materialien erfüllen müssen und konstruiert passende Werkzeuge und Automaten. Aufgaben könnten in unserem Beispiel sein:

Jetzt konstruiert man die Werkzeuge so, dass man mit wenigen flexibel nutzbaren Werkzeugen alle Aufgaben erledigen kann. So könnte man mit dem Produktdefinierer die ersten beiden Aufgaben erledigen, mit dem Vertragseditor die Aufgaben drei und vier. Die fünfte Aufgabe könnte man auch durch ein Werkzeug unterstützen. Allerdings kann diese vollständig automatisch ablaufen. Dafür wird ein entsprechender Automat entwickelt, der alle Verträge automatisch fortschreibt, die ihre Hauptfälligkeit erreicht haben (in diesem Fall verhält sich der Automat als ähnlich wie ein klassisches Batch-Programm).

-- StefanRoock


Eine Sache ist mir noch nicht ganz klar: Wie entscheidet man bei dieser Metapher, ob Verhalten zu einem Material oder einem darauf operierenden Werkzeug/Automaten gehört? Besteht nicht die Gefahr, dass die Materialen zu reinen Datenobjekten degenerieren? -- IljaPreuß


Dieses Zuordnungsproblem hat man ja eigentlich immer, wenn man einen Oberflächenteil und ein fachliches Modell hat. Das Problem ist also nicht WAM-spezifisch. Im ersten Ansatz kann man versuchen alles fachliche in das Material zu tun, was kein Technologiewissen braucht. Und wenn man dann noch die Methoden an den Materialien daran orientiert, was man auch in der physikalischen Welt mit den Materialien machen kann, ist das eigentlich auch ganz einfach. Und es bleibt deutlich mehr für das Material übrig als ein reiner Datensack.

Dann finden sich z.B. Materialschnittstellen wie:

  public class Kunde
  {
    public Adresse gibAdresse();
    public void fuegeAuftragHinzu(int auftragsnummer, Betrag auftragswert);
    public int[] gibAuftragsliste();
    public Betrag gibGesamtengagement();
    ...
  }

Hier sieht man schon, dass man Materialschnittstellen auch unter Berücksichtigung technologischer Randbedingungen entwerfen muss. Rein fachlich würde man dem Kunden direkt die Aufträge hinzufügen. Dann bekommt man in einem großen System aber beliebige Performance-Probleme. Daher werden hier mit der Auftragsnummer nur fachliche Verweise verwaltet. Adresse ist auch ein Material. Betrag ein sogenannter Fachwert (=Value Object).

-- StefanRoock


KategorieXp KategorieMetapher
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 30. April 2002 16:39 (diff))
Suchbegriff: gesucht wird
im Titel
im Text