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.
Coad:
Coad: Fragen Sie mich als Stratege oder persönlich
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
Coad: Ja, Mr. Gates
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
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.
