Login
Newsletter
Werbung

Thema: UML-Programme im Test

31 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Fred Feuerstein am Do, 23. Februar 2012 um 15:27 #

..geht am Enterprise Architect quasi kein Weg vorbei. Läuft hier per Wine auch andstandslos unter Linux.

[
| Versenden | Drucken ]
  • 0
    Von safdsafsfa am Do, 23. Februar 2012 um 17:09 #

    warum?

    [
    | Versenden | Drucken ]
    • 0
      Von Fred Feuerstein am Do, 23. Februar 2012 um 18:32 #

      Code Generation für x Sprachen, Reverse Engineering, Unterstützung für Teamarbeit, mehr als nur UML, usw.

      [
      | Versenden | Drucken ]
      • 1
        Von IT-Consultant am Do, 23. Februar 2012 um 20:03 #

        Wir modellieren nur noch mit UML und lassen die Programme von ein paar billigen Programmierer in Indien coden. So spart man massiv an den Gehaltskosten und braucht sich nicht mit den abgehobenen Informatikern rumärgern.

        [
        | Versenden | Drucken ]
        • 0
          Von Oh Mann am Do, 23. Februar 2012 um 23:14 #

          LOL und die eigentliche Implementierungen der Klassen sind dann totaler Müll, weil der Code, bzw. genauer die Algorithmen ineffizient sind.


          Hauptsache die CPUs werden immer schneller, gell?

          [
          | Versenden | Drucken ]
          • 0
            Von IT-Consultant am Fr, 24. Februar 2012 um 00:15 #

            Hardware ist günstig. Die irrsinnigen Forderungen der HR hingegen müssen deutlich nach unten gesenkt werden.

            [
            | Versenden | Drucken ]
            • 0
              Von Oh Mann am Fr, 24. Februar 2012 um 03:59 #

              Es spricht doch nichts dagegen, bei den IT-Consultants Geld einzusparen und das ganze Geld in die Entwicklung zu stecken.

              [
              | Versenden | Drucken ]
              • 0
                Von IT-Consultant am Fr, 24. Februar 2012 um 10:31 #

                Nur wird ohne den Einsatz von Profis oftmals das Ziel der Software-Entwicklung vollkommen verfehlt. Warum werden denn in etlichen Fällen externe Berater für viel Geld eingekauft?

                Weil es die internen Mitarbeiter einfach nicht draufhaben und diese Qualität ohne externe Hilfe niemals leisten können.

                [
                | Versenden | Drucken ]
                • 0
                  Von erker am Sa, 25. Februar 2012 um 07:54 #

                  und warum fahren soviele IT-Projekte gegen die Wand obwohl oder gerade weil externe Berater fuer viel Geld eingekauft werden?

                  [
                  | Versenden | Drucken ]
                  0
                  Von hans wurst 500 am Sa, 25. Februar 2012 um 19:43 #

                  Du sagst es, weil es die internen Mitarbeiter einfach nicht draufhaben.

                  Und warum haben sie es nicht drauf? Vielleicht weil HR es nicht drauf hat?

                  Im Übrigen scheint es durchaus verbreitet sein, dass Firmen Technologien benutzen, die sich nicht beherrschen. (Das Warum sei mal beiseite gestellt.) Solche Firmen sind natürlich ein El Dorado für Berater.

                  Ich meine am Ende des Tages ist es ganz einfach: wenn eine Firma einen großen Softwarepark braucht, der nicht durch Software von der Stange bedient werden kann, dann macht es Sinn eigene Entwickler einzustellen. Ein externer Berater (genau wie ein externer Entwickler) muss sich jedes mal neu einarbeiten...

                  [
                  | Versenden | Drucken ]
              0
              Von Flux W. Wild am Fr, 24. Februar 2012 um 08:37 #

              Hat dich Mama wieder gezungen, dien Zimmer aufzuräumen?

              [
              | Versenden | Drucken ]
      0
      Von depp am Fr, 24. Februar 2012 um 09:57 #

      Ausschlaggebend war für mich vor allem die Geschwindigkeit und die intuitive Bedienung. Ich habe lange mit BOUML und Umbrello gearbeitet, die sind auch nicht schlecht aber eher umständlich in der Bedienung.

      [
      | Versenden | Drucken ]
0
Von block am Do, 23. Februar 2012 um 15:47 #

Und wo ist jetzt der in der Überschrift versprochene Test?

[
| Versenden | Drucken ]
0
Von Trajan am Do, 23. Februar 2012 um 19:47 #

Danke für die grobe Übersicht.

Allerdings verstehe ich nicht, warum die beiden Entwicklungsumgebungen Eclipse und Netbeans nicht getestet wurden. Beide bieten recht solide UML Umgebungen an, welche viele nützliche zusätzliche Funktionen bieten.

Ich würde es verstehen, wenn diese auch nur grob getestet würden aber wegen Komplexität komplett ausschließen?

[
| Versenden | Drucken ]
0
Von Lexi am Do, 23. Februar 2012 um 20:28 #

UML wurde entwickelt, um Softwarearchitektur eine formale Basis zu geben. Die exzessive Nutzung von UML führt aber weg von der Architektur hin zu programmiertechnischen Details. Man möchte das Programmieren (in einer Hochsprache) vermeiden, merkt aber nicht, dass man plötzlich mit einer grafischen Sprache programmiert. Das aber viel ineffizienter, weil Text bei einer gewissen Detailtiefe wieder mehr Übersicht bedeutet, besseres Verständnis und schnellere Änderung. Grady Booch sieht die Entwicklung von UML ähnlich negativ.

Und was die UML-Werkzeuge angeht. Ich habe schon viel benutzt und war meistens unzufrieden. Das taugt einfach nichts. Und was die Kollaboration angeht: Ein UML-Dokument ist eine Datei, das heißt, nur ein Mitarbeiter kann damit arbeiten. Bei Quelltexten hat man viele, kleine Dateien und jeder arbeitet auf einer Hand voll Dateien.


[
| Versenden | Drucken ]
  • 0
    Von foobar am Do, 23. Februar 2012 um 22:25 #

    +1

    [
    | Versenden | Drucken ]
    0
    Von hm am Do, 23. Februar 2012 um 23:05 #

    nicht ganz einverstanden - grafische Programmierung erleichtert in einer guten Umgebung die Übersicht enorm.. irgendwann wird's zu komplex, aber auch das kann man Schachteln.

    [
    | Versenden | Drucken ]
    0
    Von kjaskjas am Fr, 24. Februar 2012 um 14:37 #

    Grady Booch sieht die Entwicklung von UML ähnlich negativ.
    Wenigstens mal einer der Fehler zugibt.

    Früher war ich auch OOA/D-UML-begeistert. Mittlerweile verwende ich es nur noch wenn ich dazu gezwungen werden, ich finde das Ganze nur noch hinderlich und erinnert mehr an sinnlose Rituale anstatt an echter Arbeitserleichterung. Für Dokumentationszwecke oder Diskussionsgrundlagen ist es ok.

    [
    | Versenden | Drucken ]
    • 0
      Von Sam am Fr, 24. Februar 2012 um 15:32 #

      >Früher war ich auch OOA/D-UML-begeistert.

      Ging mir auch so, während der Ausbildung und kurze Zeit danach.

      Ich habe mich dann auf der Arbeit immer wieder über die "Gulasch-" Architekturen und "Gott-" Klassen Gewerke gewundert.

      Das Problem liegt darin, dass 90% der OO-Anwender den Algorithmus nicht von der Architektur trennen können, bzw. die Trennlinie dieser Klientiel unbekannt ist.

      Die OO-Anwender glauben, dass das "Kästchen-Malen/Klassen designen" schon irgend wann zur gewünschten Funktion führt. Tut es unter Umständen auch, wenn das Problem ein Objektorientiertes ist, wie z.B. die View/Control in Fensterbasierten Systemen. Tut es nicht wenn das Problem z.B. Sequentieller Natur ist, wie das finden von Kanten in einem Foto.

      OO kam halt historisch von den grafischen Oberflächen und vergleichbaren "Anwendungsfällen" und ist für mich ein Design-Pattern für eben diese Problemstellungen. Dieses Design-Pattern auf "alle" bereiche der Informatik auszudehnen ist aus meiner Sicht ein Holzweg, führt zu mehr komplexität, schlechterer Wartbarkeit, hohem Ressourcenverbrauch und höheren Kosten.

      [
      | Versenden | Drucken ]
      • 0
        Von sema am Fr, 24. Februar 2012 um 17:30 #

        @Sam
        Wow ... kein Wunder das du Probleme damit hast, wenn du Äpfel mit Birnen vergleichst. Ich glaube du hast gar keine Ahnung von was du da redest. :P

        [
        | Versenden | Drucken ]
0
Von TBO am Do, 23. Februar 2012 um 23:48 #

Ein Klassendiagramm um sich die Struktur des Codes zu vergegenwärtigen oder ein Statemachine-Diagramm, um eine State Machine zu verstehen ist ja ganz nützlich. Diese akademische Exzesse aber, wo alles in UML2 gemalt wird, und der Code dann idealerweise nur noch generiert werden soll (oder Programmierer mit einem VHS-Kurs Java die Kästchen ausmalen sollen) haben wenig mit der von mir beobachteten Realität zu tun. Weder in der Entwicklung von Anwendungen noch beim (meistens sorgfältigeren) Design von Bibliotheken. Da reicht dann doch meistens Dokumentation per doxygen/javadoc. Ich sehe auch nicht, warum ich malen soll, wenn ich schreiben kann. Eingeschränkte domänenspezifische Probleme mögen sich ja grafisch gut modellieren lassen (Eine bestimmte Klasse von Steuerungssoftware, z.B.). Aber generische Software-Entwicklung mit komplexer Logik? Ich frage mich, ob noch jemand außer praxiserfahrungsunbefleckten Studenten und Akademiker bzw. selbsternannten Architekten (die vormaligen Akademiker, jetzt mit Dr. in der Wirtschaft) das für praktikabel oder wünschenswert hält. Von mir wollten jedenfalls selbst die prozessverliebtesten Kunden noch kein UML.

[
| Versenden | Drucken ]
  • 1
    Von nobody am Fr, 24. Februar 2012 um 01:11 #

    Es fehlen die wichtigsten und besten Vertreter:

    a) JUDE (community edition)
    b) dbWrenchApp

    [
    | Versenden | Drucken ]
    • 0
      Von someoneelse am Fr, 24. Februar 2012 um 07:58 #

      1) Heisst astah http://astah.net/editions/community.
      2) Scheint ein Datenbank-Designer zu sein?

      [
      | Versenden | Drucken ]
      0
      Von Rones am Fr, 24. Februar 2012 um 13:31 #

      Ich muss Dir Recht geben, dass Jude (oder eben jetzt "Astah") eines der besten Programme in dem Sektor ist, die mir untergekommen sind. Es geht aber in dem Artikel anscheinend eher um freie (free speech) und nicht kostenlose (free beer) Software. Und da fällt Astah leider nicht darunter, oder hast Du Jude/Astah unter einer freien Lizenz erhalten?

      [
      | Versenden | Drucken ]
    0
    Von UML am Fr, 24. Februar 2012 um 04:02 #

    Von mir wollten jedenfalls selbst die prozessverliebtesten Kunden noch kein UML.


    Gerade mit UML kann man Kunden eine Softwarelösung doch einigermaßen vertraut machen.

    [
    | Versenden | Drucken ]
0
Von schmofarz am Fr, 24. Februar 2012 um 14:29 #

Ich persönlich finde den source-navigator, der unter den paket- und binary- namen snavigator und sourcenav bekannt ist.

Dieser ist auch in der Lage, Quellcode verschiedener Sprachen (Python, C, java, ASM, ...) zu analysieren und Diagramme darüber darzustellen.

Gruß

[
| Versenden | Drucken ]
0
Von anonymous am Mo, 27. Februar 2012 um 12:11 #

Mmh ... irgendwie konnte ich zumindest am vergangenen WE Dateien von http://www.bouml.fr/download.html herunterladen ...

Aber da es ja scheinbar keinen (veröffentlichten) Test gab, ist es auch nicht wirklich relevant.

[
| Versenden | Drucken ]
0
Von UML-Verächter am Mi, 29. Februar 2012 um 09:41 #

Was noch fehlt, ist "Fujaba": From UML to Java and Back. Ich habe das mal ausprobiert vor einigen Jahren, weil mein Professor aus Paderborn war und dafür die Werbetrommel rührte. Es hat einfach nicht funktioniert, die Dokumentation war nicht vorhanden und obwohl das Teil eine Gui hatte, wusste man nicht, wohin man klicken konnte. Menü, Schalter... alles ausgegraut. Paderborner Mist halt.

Wohltuend empfinde ich da geradezu UMLet, wo gar nicht erst der Fehlansatz der Code-Generierung angedacht ist.

@Lexi: Meinst du wirklich Booch und vielleicht doch Rumbaugh?

[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung