Wenn es um gutes OO-Design geht, halten Sie es einfach

Ein ehemaliger Student von mir platzte einmal die absurde Aussage heraus: "Ich kann unmöglich objektorientiertes (OO) Design machen; ich habe nicht das Geld!" Bei weiteren Nachforschungen stellte sich heraus, dass für OO Design ein Produkt namens Rational Rose erforderlich war, das zu diesem Zeitpunkt etwa 500,00 pro Sitzplatz kostete. In seinen Augen war Design ohne Rational Rose nicht möglich. Leider ist diese Art von Balderdash weit verbreitet; Zu viele Leute denken, OO sei ein High-Tech-Prozess, der High-Tech-Tools erfordert. In der Praxis stehen Werkzeuge zu exorbitanten Preisen unbenutzt im Regal (oder werden stark unterbeansprucht).

In diesem Sinne diskutiere ich in diesem Artikel verschiedene OO-Designtools, wie sie funktionieren und warum sie meiner Meinung nach nicht nützlich sind. Ich erkläre auch, wie ich arbeite und was sich als nützlich erweist (zumindest für mich; Sie können gerne anderer Meinung sein).

Die Tools führen Sie nicht durch den Prozess

Jedes erfolgreiche OO-Design, das ich mir ausgedacht habe, ist ungefähr dem gleichen Prozess gefolgt:

  • Erfahren Sie mehr über die Problemdomäne (Buchhaltung, Unterrichtsplanung usw.)
  • Entwickeln Sie in enger Absprache mit einem Live-Benutzer eine Problemstellung , die das Problem des Benutzers ausführlich beschreibt, sowie Lösungen auf Domänenebene. Dieses Dokument beschreibt kein Computerprogramm.
  • Führen Sie eine formale Anwendungsfallanalyse durch, in der ich die Aufgaben ermittle, die zur Lösung des Benutzerproblems erforderlich sind, und arbeite dabei eng mit einem echten Endbenutzer zusammen. Normalerweise erstelle ich ein UML- Aktivitätsdiagramm (Unified Modeling Language) für jeden nicht trivialen Anwendungsfall. (UML ist eine symbolische Darstellung der Software als Bild.)
  • Erstellen Sie das dynamische Modell, das die Objekte im System und die Nachrichten zeigt, die diese Objekte aneinander senden, während ein bestimmter Anwendungsfall ausgeführt wird. Zu diesem Zweck verwende ich ein UML- Sequenzdiagramm .
  • Gleichzeitig erfasse ich nützliche Informationen im statischen Modelldiagramm. Hinweis: Ich mache nie zuerst das statische Modell (Klassendiagramm). Ich habe zu viele statische Modelle weggeworfen, die sich als nutzlos herausstellten, als ich anfing, das dynamische Modell zu erstellen. Ich bin nicht länger bereit, die Zeit zu verschwenden, die erforderlich ist, um das statische Modell im Vakuum zu erstellen.
  • Die oben genannten Schritte ergeben normalerweise zwei oder drei Anwendungsfälle. Danach beginne ich mit dem Codieren und repariere das Modell, falls erforderlich.
  • Zuletzt arbeite ich wie beschrieben an einem anderen Anwendungsfall und überarbeite das Design und den Code nach Bedarf, um den neuen Fall zu berücksichtigen.

Keines der heutigen Designtools führt Sie durch diesen Prozess. Zum größten Teil handelt es sich um überteuerte Zeichenprogramme, die selbst als Zeichenwerkzeuge nicht besonders gut funktionieren. (Rational Rose, die meiner Meinung nach eine der am wenigsten fähigen ist, unterstützt nicht einmal die gesamte UML.)

Round-Trip-Engineering ist ein grundlegend fehlerhafter Prozess

Diese Tools funktionieren nicht nur nicht gut, der einzige Trick, den diese Tools ausführen - Code generieren - ist wertlos. Fast alle OO-Designtools folgen dem Begriff des Round-Trip-Engineerings, bei dem Sie in einem Designtool beginnen, indem Sie Ihr Design in UML angeben. Sie erstellen zwei wesentliche Sätze von Diagrammen: das statische Modell, das die Klassen im Entwurf, ihre Beziehungen zueinander und die darin enthaltenen Methoden zeigt; und das dynamische Modell, bei dem es sich um einen Stapel von Diagrammen handelt, die die Objekte im System zeigen, die zur Laufzeit verschiedene Aufgaben ausführen.

Sobald Sie das Modell fertiggestellt haben, drücken Sie einen magischen Knopf und das Tool generiert Code. Der vom Tool generierte Code ist jedoch aus zwei Gründen nicht besonders gut: Erstens werden in vielen Tools Skelette für die Klassendefinitionen erstellt, aber die Methoden sind einfach leere Stubs - das dynamische Modell wird ignoriert. Zweitens unterstützen keine Tools UML vollständig, vor allem, weil dies keiner kann. UML ist eine eigenständige Sprache, die zur Improvisation anregt, und ein Großteil des tatsächlichen Designinhalts wird in Kommentaren ausgedrückt, die vom Design-Tool normalerweise ignoriert werden.

Infolgedessen hacken Sie den generierten Code (die meisten Geschäfte hacken ihn wirklich). Innerhalb weniger Wochen hat der Code normalerweise wenig oder gar nichts mit dem ursprünglichen Design zu tun. Tatsächlich werfen Sie Ihr Design effektiv weg und fallen zurück in das WHISKY-Syndrom (Warum "kodiert" noch niemand?). Jahrelange fehlgeschlagene Programme beweisen mir, dass das Codieren ohne Design die Gesamtentwicklungszeit um mindestens den Faktor drei verlängert und zu einem viel fehlerhafteren Code führt.

Jetzt kommt der Roundtrip-Prozess: Sie öffnen Ihr Werkzeug, drücken den magischen Knopf und importieren den Code. Theoretisch wird das Design so neu erstellt, dass es den tatsächlichen Status des Codes widerspiegelt. Ein solches Reverse Engineering funktioniert jedoch nicht. Die Tools erstellen normalerweise neue Klassendiagramme, aktualisieren jedoch niemals das dynamische Modell. Da das dynamische Modell für den Prozess von zentraler Bedeutung ist, ist Ihr Design jetzt wertlos, es sei denn, Sie gehen zurück und aktualisieren es von Hand, was selten getan wird.

Auf die Gefahr hin, mich zu wiederholen, ermutigt der Round-Trip-Prozess Programmierer, das Design vollständig zu ignorieren und nur zu codieren und den Code dann von Zeit zu Zeit in Bilder umzuwandeln. In dieser Situation entwerfen die Programmierer jedoch nicht. Sie hacken Code und erstellen dann Bilder des daraus resultierenden Chaos. Hacking ist nicht gleich Design.

Während Design in der Tat ein iterativer Prozess ist (das Design ändert sich, wenn der Code entwickelt wird), sollten Sie eine Iteration starten, indem Sie zuerst das Design ändern und dann den Code umgestalten, um das neue Design widerzuspiegeln. Dazu müssten Sie in der Lage sein, das gesamte Softwareprodukt innerhalb des Tools anzugeben (wenn Sie den magischen Knopf drücken, wird ein voll funktionsfähiges Programm ausgegeben), und der Prozess wäre einseitig ohne Reverse Engineering Mechanismus.

Die CASE-Tools

CASE-Tools (Computer Aided Software Engineering) wie Rational Rose stellen in der Regel das Round-Trip-Engineering in den Mittelpunkt des Produkts. Da das Round-Trip-Engineering jedoch nichts Nützliches bewirkt, verwenden viele Entwickler die Tools als teure Zeichenprogramme. Von den verfügbaren Tools sind drei meiner Meinung nach eine Überlegung wert (obwohl ich keines davon verwende):

  • Das kostenlose Open-Source-Tool ArgoUML, das in Java geschrieben wurde, leistet einigermaßen gute Arbeit mit UML-Diagrammen. Die neueste Version versucht sogar, Sie durch den Prozess zu führen (bisher mit geringem Erfolg, aber es ist ein guter Anfang).
  • Embarcaderos GDPro, das früher von Advanced Software vertrieben wurde, bietet eine gute Unterstützung für eine Gruppe, die an einem einzigen Software-Design arbeitet, weist jedoch auch Mängel in dieser Abteilung auf. Ein Designer kann beispielsweise kein dynamisches Modelldiagramm auschecken, während die mit Objekten im dynamischen Modell verknüpften Klassen automatisch gesperrt werden.
  • Das Together ControlCenter von TogetherSoft umgeht das Problem der Rückfahrt, indem es dies nicht tut. Der Code und das Design werden gleichzeitig auf dem Bildschirm angezeigt. Wenn Sie einen Code ändern, ändert sich der andere automatisch. Zusammen unterstützt ControlCenter Gruppen von Programmierern jedoch nicht gut.
  • Ich sollte auch Microsoft Visio kurz erwähnen. Visio ist ein Zeichenprogramm, das UML auf eine Art und Weise unterstützt, aber seine Unterstützung ahmt die miserable Benutzeroberfläche von Rational Rose nach. Verschiedene Zeichnungsvorlagen für UML-Formen in Visio funktionieren besser als die integrierte UML-Unterstützung, einschließlich einer im Abschnitt "Goodies" meiner Website.

Was verwende ich, wenn ich diese Tools so schlecht finde? Die mit Abstand produktivsten OO-Design-Tools sind ein Whiteboard (ein Raum mit raumhohen Whiteboards von Wand zu Wand und vom Boden bis zur Decke ist ideal) und Post-It-Pads in Flipchart-Größe, von denen Sie Blätter abziehen und abziehen können klebe an der Wand. Ich habe diese verwendet, um bedeutende Projekte mit großem Erfolg zu entwerfen. Darüber hinaus nimmt die Arbeit an einem Whiteboard erheblich weniger Zeit in Anspruch als das Ringen mit einem OO CASE-Tool.

Die einzige Schwierigkeit beim Whiteboard-Ansatz besteht darin, die Informationen auf der Tafel zu erfassen. Es gibt zwar Whiteboards, die gedruckt werden, aber sie sind teuer, unansehnlich und zu klein. Ein hübsches Hardwareprodukt, das die Bewegung eines Stifts über ein Whiteboard verfolgt und die Stiftstriche im Computer erfasst. Andere Whiteboards funktionieren wie riesige Digitalisierertablets. Diese Lösungen erweisen sich jedoch als zu einschränkend; Das Design findet gleichzeitig auf Whiteboards in mehreren Büros, auf Servietten, auf Papierfetzen usw. statt. Sie können kein 300-Pfund-Whiteboard zum örtlichen Café tragen.

Also was funktioniert

Was kann eine Mutter tun? Wie erfassen Sie diese Artefakte, um sie im Computer zu archivieren, damit sie in ihrer jetzigen Form eine angemessene Dokumentation erstellen, ohne sie in ein Zeichenprogramm übertragen zu müssen?

Die Lösung:

  1. Eine Digitalkamera
  2. Ein wunderbares Softwareprodukt namens Whiteboard Photo von Pixid

Ein digitales Foto erzeugt leider häufig Bilder, die für die Dokumentation unbefriedigend sind. Zum Ausgleich verwandelt Whiteboard Photo digitale Bilder in etwas Nützliches. Bilder sagen hier wirklich mehr als tausend Worte. Abbildung 1 zeigt ein typisches digitales Foto eines Whiteboards.

Abbildung 2 zeigt ein weiteres Beispiel.

Abbildung 3 zeigt, wie Whiteboard Photo Abbildung 1 transformiert.

Und so sieht Abbildung 2 aus, nachdem Whiteboard Photo seine Magie entfaltet hat.

Wie die Bilder zeigen, ist der Unterschied erstaunlich. Um das Originalbild in die bereinigte Version umzuwandeln, drücke ich einfach Ctrl-L. Die Software fand automatisch die Grenzen des Whiteboards, korrigierte die Verzerrung, die durch die Aufnahme des Bildes aus einem Winkel verursacht wurde (erforderlich, um die Blendung durch den Blitz zu vermeiden), wählte die Linien des Designs aus und zeichnete sie. Alles, was das Produkt braucht, um Perfektion zu erreichen, ist die Handschrifterkennung, aber ich bin damit rosa gekitzelt. Ich kann jetzt Zeichnungen in Dokumentationsqualität direkt vom Original-Whiteboard erstellen, ohne Stunden damit zu verschwenden, die Zeichnung in eine lahme Entschuldigung für ein CASE-Tool einzugeben.

Halte es einfach

Nach meiner Erfahrung funktionieren Low-Tech-Tools am besten, wenn es um OO-Design geht. In der Tat sind sie schneller, einfacher zu verwenden und in kollaborativen Umgebungen leistungsfähig. Bisher habe ich festgestellt, dass die Kombination aus Whiteboard, Digitalkamera und Whiteboard Photo die beste Methode bietet, um Programmdesigns in eine Maschine zu integrieren.

Allen Holub bietet Beratungsdienste, Schulungen und Mentoring in den Bereichen OO-Design, OO-Prozess und Java-Programmierung. Er bietet regelmäßig einen intensiven OO-Design-Workshop für diejenigen an, die daran interessiert sind, ihre OO-Fähigkeiten schnell zu entwickeln. (Weitere Informationen finden Sie unter //www.holub.com.) Allen ist seit 1979 in der Computerbranche tätig, zuletzt als Chief Technology Officer bei NetReliance, Inc. Er ist in Magazinen weit verbreitet (Dr. Dobb's Journal, Programmers Journal, Byte und MSJ ua). Allen hat acht Bücher zu seiner Ehre, von denen das neueste - Taming Java Threads (APpress, 2000; ISBN: 1893115100) - die Fallen und Fallstricke des Java-Threading behandelt. Er unterrichtet OO Design und Java an der University of California in Berkeley Extension (seit 1982).

Erfahren Sie mehr über dieses Thema

  • Das kostenlose Open-Source-Designtool ArgoUML finden Sie unter

    //argouml.tigris.org/

  • Embarcaderos GDPro finden Sie unter

    //www.embarcadero.com

  • Weitere Informationen zum Together ControlCenter von TogetherSoft finden Sie unter

    //www.togethersoft.com

  • Die Microsoft Visio-Homepage

    //www.microsoft.com/office/visio/default.htm

  • Weitere Informationen zu diesem interessanten Tool finden Sie auf der Produktseite von Pixid Whiteboard Photo

    //www.pixid.com/home.html

  • Auf der Website von Allen Holub finden Sie seine Seite "Goodies", auf der Sie Tipps zum OO-Design, Faustregeln für die Programmierung und Notizen zu einigen Vorträgen von Allen finden

    //www.holub.com/goodies/goodies.html

  • Javaworld ‚s Objektorientiertes Design und Programmierung Index bietet zahlreiche Artikel Design Adressierung

    //www.javaworld.com/channel_content/jw-oop-index.shtml

  • Sie werden mehr tolle Bewertungen in finden Javaworld ‚s Product Reviews Index

    //www.javaworld.com/news-reviews/jw-nr-product-reviews.shtml

  • Lesen Sie mehr Kommentar in Javaworld ‚s Kommentar Index

    //www.javaworld.com/news-reviews/jw-nr-commentary.shtml

  • Für Tipps und Tutorials zu Entwurfsmustern, Entwicklungstools, Leistungsoptimierung, Sicherheit, Tests und vielem mehr abonnieren Sie unseren Applied Java- Newsletter

    //www.javaworld.com/subscribe

  • Sprechen Sie in unserer Diskussion über Programmiertheorie und -praxis

    //forums.idg.net/[email protected]@.ee6b806

  • Unter .net finden Sie eine Fülle von IT-Artikeln aus unseren Schwesterpublikationen

Diese Geschichte "Wenn es um gutes OO-Design geht, halte es einfach" wurde ursprünglich von JavaWorld veröffentlicht.