Gespräch mit Peter Coad, Chairman und Gründer von Togethersoft

Ich verwende Together für meine eigene Arbeit

Lofi Dewanto

Bekannt geworden ist Togetheroft mit seinem Produkt Together ControlCenter, das mittlerweile in der sechsten Version vorliegt und eine gefestigte Marktposition bei den UML-Modellierungswerkzeuge hat. Mittlerweile präsentiert sich Together als umfassendes Entwicklungswerkzeug, dessen Features über die reine Modellierung hinaus reichen. Auf der JAX2002 in Frankfurt hatten wir die Gelegenheit, mit Togetherofts Chairman und Gründer Peter Coad, der sich im objektorientierten Bereich einen Namen gemacht hat, zu unterhalten. Zwei Stunden hatten wir Zeit, um mit ihm über Ideen, die Zukunft und auch Persönliches zu diskutieren.

Java Magazin: Together ControlCenter hat sich von einem reinen Modellierungs- zu einem kompletten Entwicklungswerkzeug verwandelt. Borlands JBuilder entwickelt sich genau in die andere Richtung: Von einem reinen Implementierungs- hin zu einem durchgängigen Entwicklungswerkzeug. Beide Produkte treffen sich langsam aber stetig irgendwo in der Mitte. Was denken Sie über diese Entwicklung?

Peter Coad: Die aufgezeigte Entwicklung hat sehr viel mit Wettbewerbstrategien zu tun. Für uns ist die Kundenorientierung sehr wichtig. In meiner Theorie verwende ich hierfür den Begriff BUDS (Buyer Valued Unique Differentiations Sets). BUDS bedeutet einerseits den Mehrwert, den unsere Kunden durch unsere Produkte erreichen können. Andererseits kennzeichnet es die Einzigartigkeit unseres Produkts gegenüber konkurrierenden Produkten. Die BUDS-Entwicklung unserer Produkte verläuft stetig nach oben. Angefangen mit dem Release von Together C++ im Jahr 1994 bis hin zu TogetherJ für Java im Februar 1998. Jedes Mal fragen wir unsere Kunden, welche Features sie haben wollen. Schließlich – wie ich bereits gesagt habe – hat BUDS mit den Werten unserer Kunden zu tun. Viele von ihnen wollten innerhalb des gleichen Werkzeugs Modellieren und gleichzeitig Implementieren. So haben wir im Juni 2000 einen verbesserten Implementierungseditor in unser Werkzeug integriert. Anschließend veröffentlichten wir unser Prozessmotto Modellieren-Bauen-Weitergeben (Model-Build-Deploy). Es hat ungefähr zwei Jahre gedauert, bis die Leute merkten, wie nützlich dieser Prozess für die gesamte Softwareentwicklung ist. Ich weiß, dass jede Menge guter Implementierungseditoren auf dem Markt existieren, wie JBuilder oder Eclipse. Wir schauen jedes Mal nach, welche Features bereits existieren und welche Features das Implementierungserlebnis der Entwickler erhöhen können.

Es liegt in der Natur des Wettbewerbs, dass die Konkurrenz nicht stehen bleibt. Ich weiß, dass Borland in unsere Richtung geht und wir umgekehrt in ihre. Sehr interessant ist die Tatsache, dass früher unsere Hauptkonkurrenten Rational und WebGain waren. Rational ist dies heute immer noch. Danach kommt nun aber direkt Borland. Ein Jahr nach der Vorstellung von Together ControlCenter haben Enterprise-Entwickler gemerkt, dass hiermit genau so gut implementiert werden kann. Statt Rational Enterprise und JBuilder Enterprise zu verwenden, kann einfach Together ControlCenter über den gesamten Entwicklungsprozesses hinweg verwendet werden. Die Firmen Rational und Borland haben gute Produkte und machen entsprechend große Umsätze. Beide Firmen haben bewiesen, dass in diesem Bereich sehr große Chancen existieren. Was ich will, ist ein gesunder Wettbewerb.

JM: Eine einfache Frage, Herr Coad: Benutzen Sie Together ControlCenter selbst für Ihre Modellierungen?

Coad: 1988 hatte ich die Idee, Diagramme mit Quellcodes zu synchronisieren. Ich habe mich mit meinem Team dieser Aufgabe gewidmet. 1993 stellten wir ein Produkt vor, das ausschließlich für die Modellierung gedacht war. In dieser Zeit hat Dieter (Dietrich Charisius – Anm. d. Red.) aus Stuttgart, den ich bis dahin noch nicht getroffen hatte, mein erstes Buch gelesen. Er war begeistert von der Idee, Diagramme und Quellcodes stets zu synchronisieren. Kurz darauf haben wir uns getroffen und 1994 konnten wir das fertige Produkt auf den Markt bringen. Ja, von Anfang an verwende ich Together für meine Arbeit. Heutzutage macht das Modellieren natürlich viel mehr Spaß! Unser Entwicklungsteam verwendet ebenfalls Together für die Entwicklung unserer eigenen Produkte.

JM: Welche Features mögen Sie am liebsten bei Together ControlCenter 6?

Coad: Fragen Sie mich als Stratege oder persönlich ? Ich verwende primär die Klassendiagramme für meine Modellierungen. In der Version 6.0 kann – wenn mit zwei Monitoren gearbeitet wird – parallel ein Klassendiagramm editiert und ein Text bearbeitet werden. Es ist sehr schön, mit Together ControlCenter und mehreren Monitoren gleichzeitig zu arbeiten.

JM: Was denken Sie über die UML 2.0? Gibt es Verbesserungsvorschläge von Ihrer Seite?

Coad: In strategischer Hinsicht ist es manchmal gut, als Erster da zu sein, und manchmal ist es ratsam, es erst später zu erproben. Wir beobachten die UML 2.0 sehr genau und wir werden sie auch unterstützen. UML 2.0 ist eine Kombination von MDA (Model Driven Architecture) und Constraint-Sprachen. Eine sehr interessante Mischung und es könnte die Problemlösung der Softwareindustrie darstellen. Die Frage ist nach wie vor, ob wir Anwendungen mit Modellierungskonstrukten in einer einfacheren Art erstellen können. Dies bedeutet, dass wir eine Konstruktionsebene höher gehen müssen. Wenn wir UML-Diagramme, Klassendiagramme bzw. speziell Sequenzdiagramme anschauen, sehen wir, dass diese die graphische Repräsentation der Struktur in der Programmiersprachen darstellen. Meiner Meinung nach sind Diagramme für strukturelle Dinge sehr gut geeignet. Für detaillierte Beschreibungen sind Texte jedoch besser geeignet. Man kann nicht alles mit Diagrammen modellieren, da Modelle sonst unübersichtlich werden. Die Verwendung von UML für Diagramme und Constraint-Sprachen für Texte ist daher ein sehr vielversprechender Ansatz.

Zurück zu unserem Problem: Wie kann ein normaler Mensch – kein Entwickler – eine Anwendung mit UML selbst konstruieren? Dafür sind UML-Konstrukte (Klassen-, Sequenzdiagramme usw.) leider zu nah an Programmiersprachenkonstrukten entworfen worden. MDA könnte die Lösung dieses Problems darstellen, aber dies könnte eine andere Methode ebenso, und dieser Bereich ist mein Forschungsschwerpunkt. Meiner Meinung nach kann die Situation verbessert werden, wenn sich die Anwendungsentwicklung auf einer höheren Ebene abspielt.

JM: Kann diese mit der Abstraktionsebenen-Entwicklung in Programmiersprachen verglichen werden, von der Maschinensprache zu Assembler bis hin zu Java?

Coad: Ja, von reinen Funktionen zu Pascal-Funktionen und Pascal-Datenstrukturen. Und nun haben wir Klassen in der objektorientierten Programmiersprache. Diese Entwicklung hat jedoch sehr lang gedauert und sie spielt sich irgendwie in der gleichen Ebene ab. Die Anwendungen bleiben immer noch Anwendungen. Sicherlich könnten wir Anwendungen effektiver erstellen. Vielleicht gibt es eine Möglichkeit, Anwendungen visuell darzustellen? Web Services helfen sicherlich dabei, Leuten die gemeinsame Arbeit zu erleichtern. Geschäftsleute können die Web Services direkt verwenden, ohne dabei von Entwicklern abhängig zu sein. Man stelle sich vor, man befindet sich in einem Flughafenkontrollzentrum. Es ist jedem klar, dass dort Fluglotsen arbeiten müssen. Das langfristige Ziel wäre jedoch, eine höhere Ebene zu erreichen in dem Sinne, dass zukünftige Flugzeuge so intelligent sind, dass ein Flughafenkontrollzentrum nicht mehr nötig wäre. Entsprechendes gilt für professionelle Entwickler. Auf einem höheren Niveau könnten Geschäftsleute ihre Anwendungen selbst schreiben. Oder Entwickler arbeiten selbst beispielsweise visuell, d.h. auf einem höheren Niveau. MDA könnte dies möglich machen. Die Hauptfrage jedoch bleibt immer noch, wie können wir Leuten helfen, Anwendungen zu modellieren und zu entwickeln. Die Kombination von Diagrammen für Strukturen und Texte für Details wird bei der Anwendungsentwicklung immer bleiben.

JM: Was denken Sie über die Verwendung von Entwurfsmustern? Vereinfachen diese das Leben eines Entwicklers oder machen sie es schwerer?

Coad: Wir versuchen stets, das Leben der Entwickler einfacher zu machen. Mit unserem Werkzeug und unserem Motto Model-Build-Deploy bieten wir einen Prozess an, bei dem der Entwickler nicht abgelenkt wird. Mit Model-Build-Deploy können Entwickler einfach starten und sie können weiter gehen, bis sie das Ziel erreicht haben! Dies macht das Leben der Entwickler auf jeden Fall einfacher und schöner.

In kleineren Organisationen sind Entwurfsmuster nicht wichtig, für größere sind sie jedoch von enormer Bedeutung. Ein Kunde, dessen Firma Hunderte von Entwicklern beschäftigte, verdeutlichte dies sehr treffend. Sein gesamtes Entwicklerteam besteht aus einigen Leuten mit sehr guten Fähigkeiten und aus vielen Leuten mit eher durchschnittlichem Potential. Eine Mischung, die in Großfirmen die Regel darstellt. In so einer Umgebung ist es sehr wichtig, dass die Architekten und die überdurchschnittlichen Entwickler Entwurfsmuster erstellen, die von den anderen wiederverwendet werden können. Entwurfsmuster sind ein Weg, wie Expertise schnell an das gesamte Team weitergegeben werden kann. Entsprechende Bücher über die Entwurfsmuster sind ebenfalls sehr hilfreich, da durch sie mittels festgelegter Terminologien besser kommuniziert werden kann. Der Prozess bei der Softwareentwicklung hat also ebenfalls mit der Weitergabe von Expertise zu tun. In einer Entwicklung macht die Modellierung zu Beginn ca. 10% der Projektzeit aus. Anschließend wird die Entwicklung iterativ alle zwei Wochen für den Entwurf und die Implementierung weitergeführt. Das Team hat einen Chefarchitekten, der den Chefentwickler begleitet. Der Chefentwickler entwickelt die Sequenzdiagramme und schreibt Quellcodes. Alle zwei Wochen holt er neue Features ab und lädt die Klassenbesitzer, die die entsprechenden Features schreiben sollen, ein. Diese Verteilung der Verantwortung für jede einzelne Klasse ist insbesondere bei einem Großprojekt sehr wichtig. Der Chefentwickler kann einfachere Klassen an Anfänger und komplexere an Seniorentwickler verteilen.

JM: Wie sieht die Zukunft der Aspektorientierten Programmierung (AOP) aus? Ist diese der nächste große Schritt? Wird es demnächst eine Integration von AspectJ in Together ControlCenter geben?

Coad: AOP ist eine hilfreiche Ergänzung für die objektorientierte Programmierung. Durch AOP trennen wir die verschiedenen Interessen eines Objektes. Ein gutes Beispiel für AOP ist das Datenmanagement. Die Persistenz beim Datenmanagement kann mit verschiedenen Techniken gemacht werden, wie beispielsweise Datenbank oder Dateisystem. Ohne AOP werden diese beiden Persistenzmechanismen verstreut in verschiedenen Klassen implementiert. Mit AOP können wir diese Persistenzinteressen komplett getrennt programmieren, d.h. wir können Datenbank- und Dateisystemaspekt von der tatsächlichen Klasse trennen. Anschließend kann der benötigte Aspekt wieder eingefügt werden. Ich denke, dass AOP sich demnächst als integraler Bestandteil in der Programmierung durchsetzen wird. Aspektorientierung ist kein neues Paradigma in der Modellierung. In der Implementierung stellt diese jedoch eine Erneuerung dar. Mit AOP können die verschiedenen Aspekte einer Klasse dargestellt und ordentlich implementiert werden, ohne dass die tatsächliche Klasse von diesen Aspekten pollutiert wird. Die Integration von AspectJ in Together ControlCenter ist sicherlich bereits in der Aufgabenliste unseres Teams .

JM: Es gibt heutzutage de facto zwei konkurrierende Technologien im komponentenbasierten Software-Engineering: J2EE und Microsofts .NET. Was denken Sie, wie diese Situation in fünf Jahren aussehen wird? Wird es nur noch eine geben? Oder hilft die Web Services-Technologie weiter?

Coad: Ja, Mr. Gates . Web Services können selbstverständlich als Brücke für die beiden Komponententechnologien dienen. Es ist jedoch selbstverständlich, dass solche Interoperabilität vom jeweiligen Anbieter nicht gewollt ist. Die Vertreter des J2EE- und des .NET-Lagers wollen natürlich Kunden an sich binden und außerdem bekämpfen sie sich gegenseitig. In verschiedenen Unternehmen habe ich beobachtet, dass sie sich entweder komplett für J2EE oder .NET entscheiden. Unternehmen, die bereits mit Microsoft-Produkten gearbeitet haben, bleiben in der Regel bei .NET. Viele unserer Kunden, die im Finanzbereich arbeiten, sehen, dass Microsoft vielleicht in fünf Jahren ebenfalls in ihre Domäne eindringen wird, daher verwenden sie aber heute ausschließlich Java. Ein Unternehmen, das im sozial-humanitären Bereich agiert, hat J2EE ausgewählt, da diese Technologie skaliert und geprüft ist. Außerdem arbeiten im J2EE-Bereich mehrere verschiedene Anbieter wie IBM, Oracle, BEA, usw. Das Risiko mit .NET ist natürlich größer, da ausschließlich Microsoft in diesem Bereich tätig ist.

Ein wichtiger Punkt ist natürlich auch Microsofts Art, Geschäfte zu machen. Wenn ein Unternehmen irgendwelche Add-Ons für Microsoft Visual Studio erstellt, kann man davon ausgehen, dass diese von Microsoft in kurzer Zeit auch erstellt werden. Die grundsätzliche Frage ist dann immer, ob genug Geld in diesem Bereich verdient werden kann, bevor Microsoft alle anderen aus diesem Bereich herausdrängt. Schauen Sie doch mal die UML-Unterstützung von Visual Studio an. Microsoft sieht, dass UML sehr wichtig für die Kunden ist, daher besitzt Visual Studio nun einen Hauptmenüpunkt UML. Es ist interessant zu sehen, dass dieses Menü nicht Rational startete, sondern Visio! Visio kann bereits Reverse-, Forward-Engineering durchführen, es kann allerdings noch kein Roundtrip-Engineering. Die Frage ist nur, wann? Ich glaube, dass es nur eine Frage der Zeit ist, bis Rational von Microsoft Visio ersetzt wird. Für uns ist es wichtig, zu entscheiden, in welche Richtung wir gehen sollten. Wir haben uns noch nicht festgelegt. Tendenziell bewegen wir uns in Richtung Java und J2EE. Ich glaube, dass in fünf Jahren beide Technologien besser sein werden. .NET wird sicherlich skalierbarer als heute sein. Man sollte die Redmonder nicht unterschätzen. Ich hoffe im übrigen, dass es zu einem Gleichgewicht zwischen J2EE und .NET kommen wird.

JM: Was denken Sie über die Zukunft von Open Source-Werkzeugen wie beispielsweise ArgoUML?

Coad: Open Source-Werkzeuge werden immer bedeutsamer. Wir selbst betrachten OpenSource-Produkte immer sehr genau. Wir schauen jedes Mal nach, ob wir Open Source-Produkte in unsere Produktpalette integrieren können. Ich denke, dass Open Source-Produkte einen Platz in unserem Markt verdient haben. Es gibt für jedes Geschäftsmodell eine Chance auf unserem Marktplatz. Für einige Leute ist es wichtig, dass die Entwicklungsumgebung oder das UML-Werkzeug kostenlos ist. Dafür gibt es Open Source-Produkte. Für einige Unternehmen ist es wichtig, dass die Entwickler sehr produktiv arbeiten. Dafür gibt es gut entwickelte, kommerzielle Produkte. Ich glaube, dass Open Source-Produkte mehr Druck auf kommerzielle Produkte ausüben, so dass wir zwangsläufig schneller vorankommen müssen. Schließlich müssen wir unsere BUDS verbessern, um weiter zu kommen.

JM: Was denken Sie, was in den nächsten fünf Jahren mit unseren Technologien passieren wird? OOP, AOP, UML oder Together ControlCenter 20.0? Welche Visionen haben Sie?

Coad: Ich träume davon, irgendwo in der Karibik zu sitzen. Sonne, schönes Wetter . Das ist meine Vision. Ja, Together wird natürlich weiter entwickelt. Together sollte einen Mehrwert für die Geschäft bringen und das ist unser Ziel. Meine Vision ist es, dass wir demnächst Anwendungen visuell mit Hilfe von Komponenten und Adaptern zusammenstecken können. Dies würde einen neuen Weg der Programmierung darstellen. Die Geschäftsleute können die Anwendungen selbst zusammenstecken, und das befreit uns Entwickler von sich wiederholenden Tätigkeiten. Wir Entwickler können uns dann auf die Funktionalitäten der einzelnen Komponenten konzentrieren. Oder wenn ein Versicherungsvertreter seinen PDA einsieht, weiß er sofort, welches Konto momentan das Wichtigste ist, welches er verfolgen muss, da von diesem Konto das meiste Geld im letztem Monat gekommen ist. Dies ist viel interessanter als die derzeitige Programmierweise am Bildschirm. Wir haben diese Art der Programmierung doch schon über Dekaden gemacht. Es wird Zeit, auf ein höheres Niveau zu gehen! Der schwierige Punkt ist, dass wir zu wenig darüber wissen, wie Leute gemeinsam arbeiten können. Jemand erzählte mir, dass Boing für einen Flugzeugbau 25.000 Dokumentationen benötigt. Es gibt also Leute, die dafür da sind, andere Leute zu verwalten. Wenn wir darüber Bescheid wissen, wie diese Leute sich selbst verwalten können, dann haben wir die Möglichkeit, die Wirtschaftskapazität zu verbessern. In fünf Jahren können wir dieses Niveau vielleicht erreichen, zumindest in bestimmten Domänen.

JM: Erzählen sie uns noch etwas über den privaten Peter Coad!

Coad: Meine Familie ist sehr wichtig für mich. Meine Frau ist eine echte Partnerin und ich rede auch über Geschäftsstrategien mit ihr. Meine Eltern sind beide Lehrer und sie lieben es, zu lehren. Ich mag es ebenfalls, zu lehren. Wenn ich modelliere oder wenn ich Linien und Vierecke zeichne, sehe ich eigentlich drei-dimensionale Räume und Bewegungen. Ich kann Sachen hören. Ich erinnere mich daran, als ich zwischen drei Modellen auswählen musste, habe ich gesagt, dass sich das eine Modell gut anhöre. Ich bin ein visueller und auditiver Typ. Wenn ich einen Roman lese, muss ich schnell lesen, da ich ansonsten den Anfang vergessen habe. Ich kann mir jedoch Bilder und Farben detailliert über einen langen Zeitraum merken. Ich bin gerne draußen. Wir leben auf einem großen Grundstück, 4,5 Morgen mit vielen Bäumen und Vögeln – die Bäume sehen ähnlich wie hier in Deutschland aus. Ein sehr schöner und sehr ruhiger Platz. Er hilft mir, mein Gleichgewicht im Leben zu behalten.

JM: Vielen Dank für das Gespräch, Herr Coad!

Peter Coad, Jahrgang 1953, ist Chairman und Gründer der Togethersoft Corporation. Er widmete sich nach Abschluss seines Studiums (Electrical Engineering an der Oklahoma State University Stillwater) dem Studium der Informatik an der University of Southern California und beschäftigte sich schon früh intensiv mit der Idee der objektorientierten Softwareentwicklung. Im Jahre 1986 gründete er das Unternehmen Object International, das in erster Linie in den Bereichen Beratung und Schulung tätig war. Im Jahre 1994 initiierte Peter Coad eine enge Zusammenarbeit mit Dietrich Charisius, dem damaligen Geschäftsführer von Object International Software Germany. Ziel war es, eine Palette an Modellierungswerkzeugen für C++ und Java unter dem Produktnamen Together zu entwickeln. Diese Zusammenarbeit mündete fünf Jahre später in die Abspaltung des Produktbereichs Together und somit die Gründung der Togethersoft Corporation Inc.

Neben seiner Tätigkeit als Chairman ist Coad als Buchautor bekannt und auch im Bereich Weiterpictureung und Schulungen engagiert er sich. So hat er die Coad-Methode entwickelt, anhand derer Entwickler optimierte Objektmodellierung mittels UML vornehmen können.

Geschrieben von
Lofi Dewanto
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.