Was haltet ihr von IBM Rhapsody. Was ist Pro und was Contra? Wie sind eure Erfahrungen? Wo liegen die Herausforderungen? Welche Zukunft gebt ihr dem Tool?
Nun wie willst du Architektur und Design ohne UML darstellen? Dur ein gescheites Klassendesign vermittelt dir schnell, was deine Komponente so macht, meiner Meinung nach. C++ Code verstehst man besser mit einem Design. UML hat seine gute Berechtigung. Bei Rhapsody bin ich mir nicht so sicher ob man sich damit einen Gefallen tut.
Peter schrieb: > UML hat seine gute Berechtigung Klar. Wie ehedem ein schön gezeichnetes Flussdiagramm. Hast du dir schon das Flussdiagramm von (you name it, Microsoft Word for Windows, oder auch Microsoft Write für Windows) angeguckt ? Nein ? Gibt es nicht ? Diagramme gibt es nicht für ernsthafte Programme, weil viel zu gross, viel zu unübersichtlich, sie es unübersichtlicher machen als ohne. Diagramme gibt es nur im Lehrbetrieb, um einfache Beispiele noch deutlicher darzustellen.
Mal ehrlich, man bricht vom groben ins feine. Komplexe Systeme sind ohne Grobdesign (Architektur) und Feindesign undenkbar. Man definiert Komponenten und ihre Interfaces und realisiert das dann. Innerhalb der Komponente kannst treiben was willst. Deine Schnittstellen hast zu bedienen und zu nutzen. Es gibt den Job des Softwarearchitekten. Der beschäftigt sich eigentlich nur mit UML und implementiert nix. Softwareentwicklung ist Software Anforderungen, Software Architektur und Design, Software Implementierung, Softwsre Test. Alles andere ist Käse. Aber gut, jeder darf wie er meint. Zurück zu Rhapsody. Was haltet man hier davon?
Rhapsody ist was für Leitstandsentwickler. :-) Ich hab vor nen paar Jahren mal mit "Tau" von Telelogic experimentieren dürfen, also dem Vorgänger. Schrecklich. Alles auf english. Riesengroß. Bedenke, da war ich 15 Jahre alt. Da hat mir "easycase / easycode" damals besser gefallen. Man malt da Nassi-Shneidermann-Diagramme, die dann in C Quellcode umgewandelt werden. Easycode kann auch reversen. Also aus Code Diagramme machen. Und genau das find ich bei UML gut. Gute Programme können reversen. Man findet sich in fremden Quellen besser zurecht, das ist ja dann die Grundlage des Refaktorings, der Wiederverwendung und Umgestaltung von Software. Ob man da auch Programme in Pascal einlesen kann und in C++ wieder auslesen? Unsere Ernte ist jetzt vorbei, da ist dann mehr Zeit für Experimente. Dieses Experiment werd ich jetzt machen, aber mit Sparx Enterprise Ultimate, das Pascal und C++ kann. mfg
Wir haben damit auch große Produkte entwickelt. Clearcase als Versionsverwaltung im Hintergrund. Auf den Anaylusemodul war es ein kleiner μC das haben die Kollegen gemacht. Im Verarbeitungsmodul war ein Arm 946 unterwegs mit dem wir auch die 240x320 Pixel Bedienoberfläche angesteuert hatten. Als OS hatten wir VxWorks. War eine interessante Zeit. Der Code wurde in C++ entwickelt. Die Statemaschinen waren nicht fehlerfrei aber man konnte damit umgehen. Die 128 MB RAM waren für die Menge an Daten welche vorgehalten mussten zu knapp da haben wir mehr als eine Optimierungsrunde gedreht.
MaWin schrieb: > Diagramme gibt es nicht für ernsthafte Programme, weil viel zu gross, > viel zu unübersichtlich, sie es unübersichtlicher machen als ohne. > Diagramme gibt es nur im Lehrbetrieb, Da muss ich eindeutig widersprechen. Bei mir in der Automobilindustrie führt daran eigentlich kein Weg vorbei. Vor allem bei Sicherheitsrelevanten Steuergeräten...
bc schrieb: > Bei mir in der Automobilindustrie > führt daran eigentlich kein Weg vorbei. Aber nicht als Tool für Entwurf und Entwicklung, sondern nachträglich erzeugt als Lückenfüller in der erfoderlichen Dokumentation. Oliver
Wenn ich ein oder mehrere Module nicht verstehe, dann gucke ich mir den C Code an. UML Diagramme nur sehr sehr selten. Und das was ich da angucke, das hätte man auch in Visio malen können.
bc schrieb: > Da muss ich eindeutig widersprechen. Bei mir in der Automobilindustrie > führt daran eigentlich kein Weg vorbei. Vor allem bei > Sicherheitsrelevanten Steuergeräten... Jetzt ist mir auch klar, warum die Dinger (Autos) heute nix mehr taugen und die Displays oft wie ein Christbaum leuchten. UML ist so unnötig OOP. Dient eigentlich nur dazu, noch mehr Mitarbeiter zu beschäftigen denen konstruktives Denken fremd ist. Wer zum Verständnis von komplexen Zusammenhänge UML braucht, der ist fehl am Platz. Oder hat nichts wirklich zu tun. Ich war sehr viele Jahre in der RT OS Entwicklung tätig, UML hätte meinem Team nichts gebracht, ausser Zeitverschwendung und Frust.
Die frage bei UML ist immer was verwende ich und wie weit treibe ich es. UML Definiert viele Diagramme die sicher jeder mal für irgend etwas an Documentation verwendet hat. Sequenzdiagramme, Datenfluss diagramme, Statemashine, Class-Diagramme, ... usecases, ... Und viele teile der UML müssen nicht nur software beschreiben. da kann ggf auch etwas hardware mit dabei sein. Oder sie beschreiben geschäftsprozesse / abläufe. und grosse software projekte ohne documentation, ... kann man machen, macht man dann aber auch 3 oder 4 mal, ... jedes mal wenn die dafür verantwortlichen entwickler weg sind wird alles neu geschrieben. Wenn sich der neue entwickler an bestimmten code stellen die Frage stellt, wieso, weschalb warum ist das so und nicht anders, ... muss das so sein oder ist das ein fehler? Was hat er sich damals dabei gedacht? wie soll das Moduel / Interface verwendet werden?
123 schrieb: > Die frage bei UML ist immer was verwende ich und wie weit treibe ich es. Diese Frage stellt sich ausnahmslos bei jedem Werkzeug bei jedem Beruf. Der Profi unterscheidet sich vom Amateur, weil er diese Frage beantworten kann. Weil er die Werkzeuge seiner Zunft, optimal einsetzen kann.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.