Ich hatte es nicht unter den Prinzipien genannt,
aber ein weiterer denkbarer Ansatz für die Zusammenfassung von solchen verschiedenen Werkzeugen,
ist, dass wir ein Werkzeug für alle unsere Zwecke nehmen.
Das heißt also, dass wir hier ein Werkzeug nehmen,
was sowohl das als auch das, als auch das unterstützt,
beziehungsweise was dann den gesamten Lebenszyklus abdeckt.
Sowas wäre durchaus ja als Lösung denkbar und in der
tatsächlich ist das das,
was die Hersteller gerne hätten
Jeder Hersteller würde gern sein Werkzeug als das allglückselige Werkzeug anbieten,
die Hochglanzprospekte, die Marketing-Aussagen tun das auch ganz viel.
Und wenn es für uns reicht, dann hätte das eine ganze Menge Vorteile.
Ich nenne hier mal zwei Beispiele. Enterprise Archie Architekt ist
ein Werkzeug, was eigentlich primär für den Softwareentwurf gedacht ist.
Aber es gibt eine ganze Menge Erweiterungen,
zum Beispiel für Requirements, Analyse, Test, Code-Generierung,
sodass wir ein komplettes Paket kaufen können
Ein weiterer Ansatz, der ganz anders funktioniert, ist Gira.
Gira hat eine Erweiterbarkeit durch Blug-in-Schnittstellen. Und Gira ist primär
fürs Projektmanagement, für Ticketmanagement gedacht gewesen.
Aber es gibt Erweiterungen, ganz, ganz viele Richtungen,
vor allen Dingen Richtung Antwortungsmanagement und Testmanagement.
Und diese Werkzeuge in der gesamten, die sind leicht von anderen Anbietern einzubringen.
Die zahlen natürlich irgendwie eine Lizenzgebühr an Gira,
dass sie da ein Anbieter sind, aber sie bieten Support.
Sie sind in dieser Welt von Gira eingebunden und das ist
für die Anwender sehr gut nutzbar,
weil alles miteinander unter der Haube von Gira unter dem Schirm
integriert ist
Das passiert häufig dadurch, dass Erweiterungen durch den Hersteller unterstützt wird,
weil kein Hersteller sich das leisten kann, alles zu unterstützen.
Dadurch wird ein breiterer Markt abgedeckt, ob man das durch
Add-ons macht oder durch eine Plug-in-Schnittstelle, ist erstmal egal.
Wichtig ist, dass es möglich ist für Trittanbieter hier mit
ihrer Leistung zu integrieren. Das ist natürlich auch eine Möglichkeit,
ihre eigenen Erweiterungen zu schreiben, wenn es diese Anwendung gibt.
Also verhindert sie denn für Schira oder für Enterprise Architect
die Ereignis Plug-in zu schreiben,
wenn ein entsprechendes Plug-in
noch nicht da ist
Aber da ist dann jemand die Frage,
wie sieht das mit dem Support und mit Updates aus?
Support, da verlassen sie sich da nicht auf Gira direkt,
sondern sie verlassen sich dann auf Anbieter des Plugins.
Oder wenn sie es selbst entwickelt haben, dann müssen sie
den Saupport auch selbst leisten. Also das sind,
das sind dann Aufgaben, die einen anderen,
für andere, wo sie andere noch einbinden müssen.
Der große Vorteil, wenn es diese einen, dieses einen Schirm,
dieses eine Dach gibt, wir haben viel, viel weniger Konsistenzprobleme.
Alles lässt sich viel besser integrieren,
zumal es auch jeder, der Hersteller versucht,
seine Sachen möglichst nahtlos,
reibungslos einzubinden
Und ich habe, aber ich muss natürlich sagen,
das ist dann insgesamt angepasst an das primäre Ziel.
Also bei Jera guckt immer irgendwo durch,
dass es eigentlich ja um Tickets geht. Oder bei Enterprise
Architekt guckt immer durch, dass es eigentlich um Softwareentwicklung geht,
auch wenn wir dort um Tests oder Parametrierung etwas haben.
Das heißt, spezialisierte Werkzeuge,
die für unsere Dämoäne separat gedacht sind, für die Produktionsplanung,
für die Parametrierung beim Rollout oder so etwas,
die sind in vielen Fällen
sehr viel besser mit ihrer Unterstützung
Und natürlich, wenn wir ein so komplexes Werkzeug haben,
was quasi alles kann, dann ist auch die Bedienung entsprechend komplex, also schmierig.
Das heißt, die Einarbeitung, auch die Fehlermöglichkeiten,
all sowas sind dort aufwendiger. Ja,
soweit zu den Punkten, die wir in den Fragen,
Frage 4 haben, diese verschiedenen Möglichkeiten der Werkzeugintegration,
jetzt möchte ich gern noch was zu Standards und zur Sicht der Hersteller sagen.
Standards brauche ich vor allen Dingen dann, wenn es beim Austausch geht.
Ja, also hier geht es eigentlich darum,
dass ich Standards haben möchte
Nämlich Standards sind etwas Werkzeugübergreifendes. Und tatsächlich geht es hier
auch um Standards der OMG zum Beispiel.
Ja, so wir haben XML zunächst als Standard.
XML ist ein Datenaustauschformat. Sie kennen das alles mit diesen Text. Ja,
und da ist XMI ein Format da von XMI,
heißt XML Meta Data Enterchange,
wurde auch von der OMG vorbereitgegeben und ist eigentlich primär gedacht dazu,
dass sich Modelle, die irgendwie auf der OML basieren,
damit austauschen kann
Soweit so gut, bloß wenn Sie mal versuchen,
die OML-Modelle von dem einen Werkzeughersteller mit den UML-Modellen eines anderen Werkstellers
oder in ein anderes Werkzeug zu importieren. So werden Sie feststellen,
da gibt es eine ganze Menge Sachen,
die da nicht so richtig funktionieren,
weil jeder Hersteller seine eigenen Spezialitäten da eingebaut hat und sei es
nur die Anordnung und das grafische Layout dieser Dinge oder gar noch,
dass sie andere Erweiterungen damit reingebaut haben,
die eigentlich in der OML selber nicht vorliegen und die deswegen
auch im Standard nicht vorgesehen sind
Ja, setzen wir fort mit weiteren Ansätzen,
die gemeinsamen Austausch zum Ziel haben. Sowas ähnliches wie ISMI
für OML-basierte oder OML-Verwandte-Diagramme gibt es noch mit Recive, Requirements Interchange-Format.
Da geht es darum, Anforderungen auszutauschen, insbesondere mit Entwurfswerkzeugen.
Das UML-Testing-Profile hatten wir im vergangenen Kapitel.
Da geht es darum, Testmodelle zu koppeln.
Das ist auch jedenfalls bis zur Version bis vor der Version 2.0
sehr stark an UML gekoppelt.
Wir können Testmodelle,
Testwerkzeuge damit koppeln
Weitere Dinge, die wir hier nicht besprechen können,
sind zum Beispiel FMI, Functional Mockup Interface.
Das ist für die Basis Madlab und vor allen Dingen für Simulationszwecke, Visualisierungszwecke gedacht.
Autos sah, es ist ein mächtiger Standard in der Automobilindustrie.
Die Automobilindustrie hat das starke Bestreben, nicht von einzelnen Herstellern abhängig zu sein,
hat deswegen ihr Datenformat herausgegeben, wie die Hersteller ihre Daten liefern müssen.
Und deswegen ist da ein Modellaustausch wirkungsvoll und arbeitet auch.
Obwohl wir natürlich nicht alle darstellen,
alle Daten des Herstellers bekommen, aber die Daten,
die in Audios sah auf der entsprechenden Ebene zum Beispiel ein Bremssystem,
ein Motor, ein Steuergerät, passend die haben wir.
Und dann möchte ich noch nennen, OSLC,
Open Service for Leipcycle Cooperation, das ist Collaboration.
Das ist auch ein Standard zum Werkzeugaustausch, der durch
die OMG unterstützt wird. Soweit klingt es erstmal toll.
Wir haben hier mehrere Standards zur Verfügung, aber das Problem ist,
die Hersteller von Werkzeugen unterstützen diese Standards nur ungern und schleppend.
Warum ist das so? Wir müssen uns klar werden,
dass das Geschäft der Werkzeughersteller sehr schwierig ist.
Es ist ein sehr hartes Geschäftsmodell. Viele der Werkzeuganbieter
leben mit notorischer Geldnot. Das hat damit zu tun,
dass es viele Anwender wenig bezahlen wollen. Ja, diese
kostenlose Mentalität ist sehr verbreitet. Und gleichzeitig solche Software,
die als Werkzeug geeignet ist, sehr, sehr komplex ist.
Stellen Sie sich mal die Testfälle vor, die Sie brauchen,
um ein Word, ein Textverarbeitungssystem wie Microsoft Wirt zu testen.
Und noch viel schlimmer ist es,
wenn wir noch etwas haben wie ein OML-Werkzeug,
was auch noch Code generieren kann,
Tests unterstützen kann
Viele Importfilter, Exportfilter halt, Werkzeuge hat.
All sowas. Das heißt, die Komplexität,
die Anforderungen an die Reife solches Werkzeugs sehr hoch,
die Kunden wollen wenig bezahlen und daraus resultiert,
dass immer Geld knapp ist.
So, Anbieter haben deswegen immer das Bestreben, höhere Einnahmen zu erzielen.
Aber wenn sie das zu hoch treiben, haben sie keine
Nutzer mehr. Das heißt, man muss irgendwo sehen,
wo die Grenze ist und was man damit erreichen kann.
Zum einen natürlich, dass man irgendwie Alleinstellungsmerkmale hat.
Und das ist das, wo ich vorhin sagte, proprietär.
Jeder Hersteller versucht, Kunden an sich zu binden,
indem er etwas anbietet,
was nur er hat
Und das macht natürlich die Kopplung schwer.
Und das ist dann eine Verletzung des Standards.
Also das wird dann durch XMI nicht mit ausgetauscht.
Das, was Rapsodie oder jemand anders da separat hat.
Und wenn wir eine verallgemeinerte Lösung bieten wollen, möglichst breiten Markt abdecken wollen,
dann müssen wir auch auf manche Werkzeuge, manche Feature verzichten.
Wir wollen einheitliche Feature und damit nicht mehr eine Lösung für
jeden, sondern eine Lösung für alle.
Nur dann wird es für uns
ökonomisch tragbar
Ja, also der Werkzeuganbieter mit der Suche eigentlich nach proprietären Lösungen.
Der Anbieter hat sie ziemlich gegensätzliche Interessen. Zum Beispiel,
was die Kosten betrifft. Natürlich möchte er nicht so furchtbar viel bezahlen,
aber das sollte man nicht nur den Erwerb einer Lizenz sehen,
sondern vor allen Dingen den Aufwand für die Nutzung.
Also wenn ich ein Werkzeug habe,
wo ich ständig ganz große Probleme habe,
weil irgendwas nicht funktioniert oder ich ständig,
das ist alles so kompliziert benutzbar, dass ich nur sehr wenig vorankomme,
dass ich viele Fehler mache,
dann ist das auch ein hoher Aufwand,
der zur Buche schlägt.
Das möchte ich als Einwinder nicht
Gleichzeitig möchte ich als Anwender nicht von einem Mann beterabhängig sein.
Dieser Anbieter könnte plötzlich die Preise hochschrauben.
Dieser Anbieter könnte plötzlich vom Markt verschwinden, weil er irgendwie
die Meinung der Meinung ist, es trägt sich nicht mehr.
Und dann stehe ich da mit meinen Werkzeugen und bekomme keinen Support mehr.
Gleichzeitig möchte ich, dass der Anwender guten Support leiste,
Anbieter guten Support leistet. Und ich möchte trotzdem wenig dafür bezahlen.
Das ist natürlich klar. Dieser gute Support soll mir helfen,
nicht nur das Qualitätsproblem schnell ausgehoben werden oder Sicherheitsprobleme,
die ich mit meinem Werkzeug habe, sondern auch,
dass mir vielleicht Möglichkeit geboten wird,
ein bestimmtes Besonderheit,
die ich unbedingt brauche,
da einzubauen
Und ich möchte natürlich viele Features haben. Während der Hersteller
einheitliche Features für alle möchte, möchte ich gerne die,
die für mich richtig sind. Und das Ganze macht das schwer,
also das macht es schwer für die Werkzeuganbieter,
gute Lösungen anzubieten und dabei auch noch das Geld zu erlösen, was sie dafür brauchen.
Und für die Anwänder, nicht von einem Anbieter abhängig zu sein.
Soweit zu den Schwierigkeiten, zu den Schwierigkeiten,
die wir hier haben, zu den Herausforderungen, ja,
Standards scheitern unter anderem daran,
dass die Werkzeughersteller sie nicht unterstützen und dass die Breite
der Einsatzbereiche auch über den Standard gerne mal hinausgeht