Vorgehensweise Projektentwurf

[ds1337]

Hallo an alle,

ich studiere derzeit Informatik und beschäftige mich momentan intensiver mit der Sprache Java und der Modellierung von Projekten in UML.
Was mich allerdings etwas verwirrt ist die Vorgehensweise bei einem neuen Projekt.
Sagen wir ich möchte kleinere Programme zur Übung und Festigung des Java Wissens programmieren, wie ist hier die Vorgehensweise?

Programmiert ihr einfach drauf los und erweitert das Programm nach und nach oder macht ihr euch zuerst eine grobe Übersicht in UML und implementiert anschließend alles? Ich würde zum Beispiel gerne folgende Sachen programmieren (zur Übung):

Programm das A- und B-Woche anzeigt
Programm das Primzahlen findet
Umgekehrt polnische Notation
Einfacher Taschenrechner
...

Klar sind das alles kleine Programme für die eine Abstraktion in UML vielleicht Overkill wären aber ich bin jemand der Struktur braucht bei sowas daher würden mich mal die effektivsten Vorgehensweise beim "Projektentwurf" von erfahrenen Entwicklern interessieren.

Vielen Dank schonmal für eure Antworten!

 

[httpdigest]

Ich würde zum Beispiel gerne folgende Sachen programmieren (zur Übung):
Programm das Primzahlen findet

Hierfür ist ganz sicherlich kein UML notwendig. Du musst aber einfach nur einen Algorithmus kennen/lernen/finden.

 

[mrBrown]

Programmiert ihr einfach drauf los und erweitert das Programm nach und nach oder macht ihr euch zuerst eine grobe Übersicht in UML und implementiert anschließend alles?

Hängt ganz vom Problem ab, wenn es „zu klein“ ist, bringen Diagramme meist wenig.
Wenn es größer wird machen aber zumindest Domänenmodelle meist Sinn, grad auch um sich mit anderen darüber auszutauschen. Je nach Problem auch mal ein Aktivitätsdiagramm oder Sequenzdiagramm.


Ein genaues Klassendiagramm oder ähnlich „Code-nahes“ nutz ich allerdings kaum.

 

[White_Fox]

Ich habe einmal für ein (geplantes, bisher aber nie verwirklichtes) Programm mit einem Klassendiagramm angefanten. Und dabei festgestellt, daß das ganz schnell ins uferlose ausartet. Der Informationsgehalt geht rasch gegen null, und dann stellt sich die Frage wozu der Aufwand dann gut ist.

Klassendiagramme und UML mache ich gerne bei kleineren Teilproblemen, aber das ganze Projekt so zu planen...ich sehe nicht, wie das sinnvoll gehen soll. Aktuell schreibe ich ein kleines Programm (ich jedefalls halte es für klein), das allerdings schon >120 Klassen enthält (ohne Unittests).

Ich weiß nicht ob das die beste Strategie ist, allerdings bin ich wie folgt vorgegangen:

1. Anforderungen aufschreiben, was soll das Programm später leisten.
2. Ausdifferenzieren, wie das Programm benutzt werden soll.
3. Überlegen, wie das Programm grundsätzlich funktionieren soll (Algorithmen, usw.).
4. Alle Klassen schreiben (und testen), die für die Grundfunktion notwendig sind.
5. Dann das eigentliche Programm schreiben, nach MVC-Pattern, usw., und das macht den weitaus größten Teil der Arbeit.
6. Für eigenständige Teilprobleme (z.B. Datenhaltung und -speicherung) kommen dann aber öfter mal UML und Klassendiagramm zum Einsatz.

Ich muß dazu allerdings noch nachwerfen, daß ich kein Softwareentwickler oder Programmierer o.ä. bin, Programme schreibe ich ausschließlich in meiner Freizeit.

 

[Thallius]

Ich habe einmal für ein (geplantes, bisher aber nie verwirklichtes) Programm mit einem Klassendiagramm angefanten. Und dabei festgestellt, daß das ganz schnell ins uferlose ausartet. Der Informationsgehalt geht rasch gegen null, und dann stellt sich die Frage wozu der Aufwand dann gut ist.

Warte ab bis du dein erstes Programm nach GXP validieren must. Ich kotze gerade wieder im Strahl..... Noch nie soviel Arbeit in komplett sinnlose Dokumenation investiert von denen ich weiß das die niemals jemand lesen wird.

Claus

 

[White_Fox]

Noch nie soviel Arbeit in komplett sinnlose Dokumenation investiert von denen ich weiß das die niemals jemand lesen wird.

Wenn das niemand liest, dann schummel einfach ein paar schöne Gedichte oder spannende Geschichten in die Mitte. Und verzichte auf den Rest. Da haben dann alle mehr davon, falls es doch mal jemand liest.



Für Netbeans gibt es ein Plugin, daß anhand des fertigen Codes ein Klassendiagramm erstellt. Das hab ich mit besagtem geplanten Programm mal getestet. Schon mit nur drei Klassen wurde das so riesig, daß nichts mehr lesbar war wenn man soweit rauszoomte daß das Diagramm ganz auf den Bildschirm passte.

 

[Thallius]

Wenn das niemand liest, dann schummel einfach ein paar schöne Gedichte oder spannende Geschichten in die Mitte. Und verzichte auf den Rest. Da haben dann alle mehr davon, falls es doch mal jemand liest.

Ich habe überlegt Krieg und Frieden reinzukopieren aber das war zu kurz

Claus

 

[Xyz1]

Klar sind das alles kleine Programme für die eine Abstraktion in UML vielleicht Overkill wären aber ich bin jemand der Struktur braucht bei sowas

Inwie fällt mir spontan nur das dazu ein

 

[Xyz1]

also nochmal schnell zum Thema zurück, es gibt eine Vorlesung dafür, im Prinzip setzt man für solche Übungen bestimmte Design Pattern an - das heißt aber nicht ,ein UML Klassendiagramm mit allen Einzelheiten zu fertigen, denn das übersteigt die Zeit um das zu programmieren um ein Vielfaches (und es wird auch nicht gelesen)...

Also du überlegst Dir etwas und schreibst in 10h ein Klassendiagramm auf, dann programmierst Du es in 1h ... ohne Klassendiagramm dauert es vielleicht etwas länger aber du wärst in 2h fertig.

 

[ds1337]

danke erstmal für eure Antworten! Was ich mich immer frage ist, wo ich bei einem Programm beginne dass vielleicht nicht nur aus 2-3 klassen besteht und vorallem wie viele Klassen / Interfaces oder sonst was benötige ich für die Umsetzung?

Ich bin jemand der gerne Struktur hat bei sowas.
Macht vermutlich Sinn vor dem Programmieren erstmal das zu schreibende Programm in alle möglichen Einzelteile zu zerlegen oder? Damit hat man eine bessere Übersicht über das große ganze denke ich.

 

[AndiE]

Ich halte es für entscheidend , dass UML einmal den statische nun einmal den dynamischen Aspekt abbildet. Wenn ich nun nich einen OOP-Ansatz hinzunehmen, dann will ich, dass sich Datenobjekte untereinander Nachrichten schicken. Dabei kann ich eine gegebene physische Gegebenheit logisch modellieren, und andererseits auch die Verarbeitungsfolge, wobei mir aber Kasperlung und Vererbung einige Dinge freimachen. Polymoorphie ist da schon was anderes.

ich denke, dass gerade beim Taschenrechner schon ein OOP-Ansatz und damit auch eine Modellierung mit UML was brigen.

 

[White_Fox]

Macht vermutlich Sinn vor dem Programmieren erstmal das zu schreibende Programm in alle möglichen Einzelteile zu zerlegen oder? Damit hat man eine bessere Übersicht über das große ganze denke ich.

Ich würde dir raten, bei der Kernfunktion deines Programms anzufangen. Das hilft, eine erste Vorstellung zu entwickeln. Alles möglichst schön feinkörnig in Klassen zerlegen, eine Klasse soll nur eine Aufgabe haben. Wenn ich mehr als eine Klasse in einem Vererbungsbaum habe, beginne ich diesen oft mit einer abstrakten Klasse, selbst wenn diese erstmal keine Methoden implementiert.

Es ist meiner Meinung nach unmöglich, sein komplettes Programm ausschließlich am Reißbrett zu planen und dann stur abzutippen. Dazu fallen einem für gewöhnlich unterwegs viel zu viele Dinge ein, die man noch implementieren könnte.

 

[Xyz1]

wo ich bei einem Programm beginne dass vielleicht nicht nur aus 2-3 klassen besteht und vorallem wie viele Klassen / Interfaces oder sonst was benötige ich für die Umsetzung?

Ich bin jemand der gerne Struktur hat bei sowas.
Macht vermutlich Sinn vor dem Programmieren erstmal das zu schreibende Programm in alle möglichen Einzelteile zu zerlegen oder?

Das was Du da sehr abstrakt beschreibst riecht nach hoher Kohäsion und niedriger Kopplung.
Fang hier mal an zu lesen https://www.geeksforgeeks.org/coupling-in-java/

Es ist richtig, das Programm in viele Einzelteile zu zerlegen unter Beibehaltung der Austauschbarkeit. (Das kommt aber mit der Erfahrung.) Aber um Dir weitere Entwurfsmuster an die Hand zu geben, müsstest Du viel weiter ins Detail gehen.

Gleichzeitig würde man für ein "Hello world" im echten Leben aber nicht solche Berge versetzen wollen.

 

[ds1337]

Ich würde dir raten, bei der Kernfunktion deines Programms anzufangen. Das hilft, eine erste Vorstellung zu entwickeln. Alles möglichst schön feinkörnig in Klassen zerlegen, eine Klasse soll nur eine Aufgabe haben. Wenn ich mehr als eine Klasse in einem Vererbungsbaum habe, beginne ich diesen oft mit einer abstrakten Klasse, selbst wenn diese erstmal keine Methoden implementiert.

Es ist meiner Meinung nach unmöglich, sein komplettes Programm ausschließlich am Reißbrett zu planen und dann stur abzutippen. Dazu fallen einem für gewöhnlich unterwegs viel zu viele Dinge ein, die man noch implementieren könnte.

Die Aussage, dass eine Klasse immer nur eine Aufgabe erledigen soll ist interessant, habe das bisher immer nur im Kontext von Methoden gehört. Mir stellt sich jetzt nur die Frage was man unter "einer" Aufgabe versteht also wo setzt man quasi die Grenze zwischen, "das gehört noch zum großen und ganzen der Aufgabe" und "das muss separat über eine andere Klasse abgewickelt werden.

 

[White_Fox]

Noch eine Erfahrung:
Bei meinem Projekt, das ich aktuell baue, dachte ich anfänglich daß das in spätestens einem Jahr fertig wäre. Von der Grundfunktion her ist es wirklich einfach. Daher habe ich mich auch tief reingekniet und so gut es geht und ging mit meinen Kenntnissen das Programm so entwickelt, wie Software nach der reinen Lehre entwickelt werden sollte.

Das Ergebnis ist, daß ich jetzt seit fast zwei Jahren an dem Teil sitze. Für die Kernfunktion waren ursprünglich mal vielleicht sechs oder sieben Klassen vorgesehen, mittlerweile habe ich >120 Dateien in meinem src-Ordner. Es verging sehr viel Zeit auch mit Löschen und neu schreiben, weil ich mich in irgendeiner Sackgasse verrannt habe. Alleine ein brauchbares MVC-Muster auf die Beine zu stellen hat etwa ein dreiviertel Jahr gedauert.

Von daher würde ich dir raten, ruhig ein möglichst kleines Thema zu bearbeiten und einfach mal loszulegen. Du wirst sehen, das wächst ganz von alleine in den Himmel

 

[mrBrown]

Wenn ich nun nich einen OOP-Ansatz hinzunehmen, dann will ich, dass sich Datenobjekte untereinander Nachrichten schicken. Dabei kann ich eine gegebene physische Gegebenheit logisch modellieren, und andererseits auch die Verarbeitungsfolge, wobei mir aber Kasperlung und Vererbung einige Dinge freimachen. Polymoorphie ist da schon was anderes.

Das auch Objekte Nachrichten schicken, ist die Definition von OOP
Polymorphie ist davon auch nicht zu trennen, sowohl das Nachrichtenbasierte als auch Vererbung sind Polymorphie.
Vielleicht versteh ich aber auch völlig falsch was du sagen wolltest.

Die Aussage, dass eine Klasse immer nur eine Aufgabe erledigen soll ist interessant, habe das bisher immer nur im Kontext von Methoden gehört. Mir stellt sich jetzt nur die Frage was man unter "einer" Aufgabe versteht also wo setzt man quasi die Grenze zwischen, "das gehört noch zum großen und ganzen der Aufgabe" und "das muss separat über eine andere Klasse abgewickelt werden.

Das ist eine etwas falsche Deutung des „Single-Responsibility-Prinzips“, die sich hartnäckig hält

Richtiger wäre, dass es nur einen Grund geben sollte, eine Klasse zu ändern, oder, es sollte nur einen Verantwortlichen für die Klasse geben.

Um beim Taschenrechner zu bleiben: für den Interessieren sich ein Mathematiker und ein Designer. Wenn ersterer sagt, Addieren muss anders funktionieren, sollte das einen Teil der Klassen betreffen. Wenn der Designer sagt, Addieren muss über GUI statt über Konsole eingegeben werden, sollte das andere Klassen betreffen.

 

[mrBrown]

Vielleicht sollte man bei sowas aber auch erst noch mal klären, was jeweils mit UML-Diagrammen gemeint ist. Wenn man drei Leute fragt, sind sich mindestens zwei uneinig

 

[White_Fox]

Die Aussage, dass eine Klasse immer nur eine Aufgabe erledigen soll ist interessant, habe das bisher immer nur im Kontext von Methoden gehört. Mir stellt sich jetzt nur die Frage was man unter "einer" Aufgabe versteht also wo setzt man quasi die Grenze zwischen, "das gehört noch zum großen und ganzen der Aufgabe" und "das muss separat über eine andere Klasse abgewickelt werden.

Nimm als Beispiel das MVC-Muster.
Da hast du ein View-Objekt, die hat genau eine Aufgabe: Eine Benutzeroberfläche zur Verfügung zu stellen.
Wenn du jetzt eine GUI mit JavaFX oder Swing erstellst, greifst du auf viele andere Klassen zu und wirst ganz sicher nicht die gesamte GUI in einer monströs großen Klasse erledigen. Vielmehr werden umfangreiche Aufgaben in feiner abgestufte Teilaufgaben zerlegt und normalerweise ist es sinnvoll, dafür feiner spezialisiertere Klassen zu schreiben.

Das ist eine etwas falsche Deutung des „Single-Responsibility-Prinzips“, die sich hartnäckig hält

Richtiger wäre, dass es nur einen Grund geben sollte, eine Klasse zu ändern, oder, es sollte nur einen Verantwortlichen für die Klasse geben.

Ich hätte eher gesagt, daß eine Methode nur eine einzige Sache ändern sollte.

 

[mrBrown]

Ich hätte eher gesagt, daß eine Methode nur eine einzige Sache ändern sollte.

Das „ändern“ meint dabei, den Code der Klasse ändern, nicht den Wert irgendeiner Variable

Von Bob Martin zu SRP:

A module should be responsible to one, and only one, actor.

There should never be more than one reason for a class to change.

 

[White_Fox]

Das „ändern“ meint dabei, den Code der Klasse ändern, nicht den Wert irgendeiner Variable

Mir ist schon klar, wie du das gemeint hast.

Mir fallen allerdings einige Fälle ein die gegen Bob Martins Aussage verstoßen würden (so wie ich sie verstehe, nämlich wörtlich), andererseits sehe ich nicht, warum das ein Problem sein sollte. Beispielsweise, wenn Refaktur und eine allgemeine Umstrukturierung erfolgen.
Ich störe mich da etwas an der Gemeingültigkeit seiner Aussage, bzw. finde diese recht unscharf (oder ich verstehe sie einfach falsch, vermutlich wird es das sein).

Das Prinzip "Eine Aufgabe, eine Klasse" hat sich bisher jedenfalls gut bewährt, während ein Verstoß dagegen schnell zu Problemen geführt hat.

 

[TM69]

Hallo an alle,

ich studiere derzeit Informatik und beschäftige mich momentan intensiver mit der Sprache Java und der Modellierung von Projekten in UML.
Was mich allerdings etwas verwirrt ist die Vorgehensweise bei einem neuen Projekt.
Sagen wir ich möchte kleinere Programme zur Übung und Festigung des Java Wissens programmieren, wie ist hier die Vorgehensweise?

Programmiert ihr einfach drauf los und erweitert das Programm nach und nach oder macht ihr euch zuerst eine grobe Übersicht in UML und implementiert anschließend alles? Ich würde zum Beispiel gerne folgende Sachen programmieren (zur Übung):

Programm das A- und B-Woche anzeigt
Programm das Primzahlen findet
Umgekehrt polnische Notation
Einfacher Taschenrechner
...

Klar sind das alles kleine Programme für die eine Abstraktion in UML vielleicht Overkill wären aber ich bin jemand der Struktur braucht bei sowas daher würden mich mal die effektivsten Vorgehensweise beim "Projektentwurf" von erfahrenen Entwicklern interessieren.

Vielen Dank schonmal für eure Antworten!

Großártige UML Diagramme werden heute nicht mehr erstellt.

Aber es kommt auf den Bereich darauf an, indem du arbeitest. Das heißt bei Automobilkonzernen wird gerne noch viel Wert auf Dokumentation gelegt. Die meisten Unternehmen arbeiten heute agile. Dieses hat den entscheidenden Vorteil, dass du schneller auf Veränderungen technischer, wirtschaftlicher oder sozialer Art, reagieren kannst.

Lies dir mal das agile Manifest durch: https://agilemanifesto.org/iso/de/manifesto.html

z.B. Scrum (ja, ja ich weiß eine reine Scrum Umgebung wirst du nirgends vorfinden, weil man das Beste aus verschiedenen agilen Modeln benutzt): Es beginnt mit einem Product Backlog, indem die Aufgaben nach ROI absteigend sich drin befinden. D.h. Das was am wichtigesten ist und am schnellsten Geld einbringt befindet sich an oberster Stelle. Durch das Sprint-Planning werden hieraus die Iterativ dich wichtigsten Punkten, die in einen Zeitraum von 2-4 Wochen passen abgearbeitet.,

Scrum bezieht sich allerdings auf Teams bis zu 9 Teammitgliedern (bei mehr als 9 Teammitglieder wird dieses anhand meistens SAFe aufgeteilt). Es bezieht sich nicht auf Projekte mit <3 Personen.

Und wenn du unbedingt UML Diagramm haben möchtest, so kann dir jedes UML Werkzeug heute hieraus Klassendiagramme erstellen. Erschrecke aber nicht, wenn diese schnell unübersichtlicht wird.

Vielleicht sollte man bei sowas aber auch erst noch mal klären, was jeweils mit UML-Diagrammen gemeint ist. Wenn man drei Leute fragt, sind sich mindestens zwei uneinig

Find ich nicht jeder der sich mit Software Engineering beschäftigt sollte die drei Diagrammarten Klassendiagramm, Aktivitätsdiagramm und Sequenzdiagramm kennen. Die anderen Diagrammarten, die noch zu UML gehören, sind meiner persönlichen Meinung nach, überflüssig.

Vielmehr werden umfangreiche Aufgaben in feiner abgestufte Teilaufgaben zerlegt und normalerweise ist es sinnvoll, dafür feiner spezialisiertere Klassen zu schreiben.

Insbesondere bei der Objektorientierung halte dich an SOLID. SOLID ist eine Abkürzung für fünf Entwurfsprinzipien, die Softwareentwürfe verständlicher, flexibler und wartbarer machen sollen. s. https://itnext.io/solid-principles-explanation-and-examples-715b975dcad4

 

[mihe7]

Programmiert ihr einfach drauf los und erweitert das Programm nach und nach oder macht ihr euch zuerst eine grobe Übersicht in UML und implementiert anschließend alles?

Das kommt darauf, worum es geht, wie weit die Erfahrungen im jeweiligen Bereich sind usw. UML-Diagramme in dem Sinn, wie Du Dir das vielleicht vorstellst, gibt es bei uns eigentlich selten. Für das eigene Verständnis kritzelt man sich ggf. mal die groben Zusammenhänge zusammen, wobei die Zeichnung dann lediglich einen "UML-Stil" hat. Das heißt aber nicht, dass man einfach darauf los programmiert.

 

[mihe7]

Find ich nicht jeder der sich mit Software Engineering beschäftigt sollte die drei Diagrammarten Klassendiagramm, Aktivitätsdiagramm und Sequenzdiagramm kennen.

Ich glaube, @mrBrown wollte darauf hinaus, dass jegliche Zeichnung, die eine gewisse Ähnlichkeit mit einem UML-Diagramm aufweist, als solches bezeichnet wird. Der eine nimmt es halt genauer als der andere. Analog: nahezu jeder HTTP-Service, bei dem JSON übertragen wird, wird heute salopp als REST-Service bezeichnet, auch wenn die Idee von REST in keinster Weise umgesetzt wird.

 

[AndiE]

Ich habe die Erfahrung gemacht, dass mir eine Zeichnung hilft, Technologien zu verstehen, wie Spring Boot. Dabei nutze ich die Elemente des Klassendiagramms, aber nicht unbedingt genau nach Vorschrift.

Es ist natürlich auch die Frage, inwieweit in der Praxis ein Programmierer ein Projekt alleine erstellt, wie im Hobbybereich oder in der Ausbildung. Ich denke, dass dies eher weniger der Fall sein wird.

Gehe ich aber vom Bereich der Ausbildung aus, und schaue auf einige Beiträge hier im Forum, dann wäre es doch schlau, das Programm im Vorfeld mit UML zu modellieren, sowohl auf Aufbau als auch von der Funktion her.

Für die gezeigten Programme würde ich insbesondere beim Taschenrechner überlegen, ob sich eine Trennung von Ansicht und Datenhaltung anbietet, und ob ich die Daten als Objekte, also Instanzen einer Klasse "Zahl", anlege.

Ich finde, die typische Menu-Steuerung in der obersten Zeile, wie sie früher gang und gäbe war, findet man heute bei kleinen Projekten und Apps fast gar nicht mehr, eher bei umfangreichen Anwendungen, wie Webbrowsern, Office-Lösungen u.ä..

Daher finde ich, dass man ein Programm schon "leer" (leere Funktionsrümpfe) planen und erstellen muss, aber nicht mehr (mit Menupunkten beim Programmieren) erweitern kann( wie man es früher gerne gemacht hat).

 

[TM69]

Ich habe die Erfahrung gemacht, dass mir eine Zeichnung hilft, Technologien zu verstehen, wie Spring Boot. Dabei nutze ich die Elemente des Klassendiagramms, aber nicht unbedingt genau nach Vorschrift.

Du redest von sogenannten Mockings? Dieses kann am Anfang hilfreich sein, wenn du auf einer grünen Wiese entwickelst und du dich mit deinem Kunden abstimmen must. Meistens bestehen aber bereits bestimmte System schon und müssen entsprechend angepasst werden.

Es ist natürlich auch die Frage, inwieweit in der Praxis ein Programmierer ein Projekt alleine erstellt, wie im Hobbybereich oder in der Ausbildung. Ich denke, dass dies eher weniger der Fall sein wird.

Es ist ein himmelweiter Unterschied, ein Projekt als Einzelperson oder mit max. 3 Leuten zu entwickeln, oder ob du in einem Projekt mit mehreren Teammitgliedern arbeitest. Letzters ist im Berufsalltag eher der Fall

Gehe ich aber vom Bereich der Ausbildung aus, und schaue auf einige Beiträge hier im Forum, dann wäre es doch schlau, das Programm im Vorfeld mit UML zu modellieren, sowohl auf Aufbau als auch von der Funktion her.

Find ich persönlich nicht. Es ist schon wichtig die wichtigsten Diagrammarten zu kennen, allerdings erstellt dir eigentlich jedes UML Tool dir aus deinem Quellcode die wichtigsten Diagrammarten. Ggf. sogar mit ERD und ORM, die allerdings nicht zum UML gehören. Mein Tip deshalb, fange mit der wichtigsten Funktion an und baue es immer weiter aus.

 

[TM69]

@AndiE darf ich dich fragen, was für eine Ausbildung du genau machst?

Ausbildung zum Fachinformatiker oder Studierst du Informatik?

 

[AndiE]

Ich habe ein Umschulung zum Fachinformatiker Anwendungsentwicklung gemacht. Vor 10 Jahren mit C#. Was ich von Java etc. weiß, ist Selbststudium oder Studium bei HPI.

 

[Xyz1]

Ich wollte eigentlich auch schon schreiben, warum er noch nie etwas von Mocks gehört hat, aber habe mich dann nochmal auf die Hände gesetzt und dachte das wäre unfreundlich....

 

[AndiE]

Es geht nicht um Mocks. Sondern darum, dass hier im Forum ( für mich) neueTechnologien wie Spring und SpringBoots angesprochen werden. Wenn man sich diese Frameworks runterlädt, hat man auf der Webseite dort einige Beispielprogramme, die zeigen, wie das funktioniert. Um zu verstehen, wie diese funktionieren, analysiere ich sie. Ein gutes Beispiel ist die "Petclinic", eine Anwendung, die eine Tierklinik darstellt. Man hat da ca. 20 Klassen. Um aber die Übersicht zu bekommen, habe ich sie grafisch dargestellt, eben mit Hilfe der Methoden der UML. natürlich gibt es da auch Grenzen, wie z.B., wenn man den Zusammenhang zwischen Webseite und Controlern darstellt, aber ansonsten finde ich das ein gutes Mittel, um sich da reinzudenken.

Ich beziehe meine meinung auf den Post eines Benutzers, der einen Rover über ein Feld steuern wollte, aber die Situation nicht modellieren konnte. Erst recht nicht eine Dokumentenverteilung. In der beruflichen Praxis, die mir leider versagt wurde, wird es sicher einen SW-architekten geben, der die Prgrammstruktur entwirft, und dem einzelnen die Programmierung einzelner Funktionen aufdrückt.

Das ist eben der Unterschied, den ich zu privaten Projekten sehe, wo ich auch die Architektur selbst ersinnen muss.

Ob ich da mit Mocks, TDD oder DDD oder sonstwie arbeite, sei mal dahingestellt.

 

[mrBrown]

Großártige UML Diagramme werden heute nicht mehr erstellt.
[...]
Die meisten Unternehmen arbeiten heute agile. Dieses hat den entscheidenden Vorteil, dass du schneller auf Veränderungen technischer, wirtschaftlicher oder sozialer Art, reagieren kannst.

Wobei sich agile und Diagramme keineswegs widersprechen, das passt durchaus gut zusammen.

Nur halt nicht im Sinne von Klassendiagrammen, die in jedem Fall 100% ausformuliert sein müssen, bevor man anfängt zu programmieren.

Find ich nicht jeder der sich mit Software Engineering beschäftigt sollte die drei Diagrammarten Klassendiagramm, Aktivitätsdiagramm und Sequenzdiagramm kennen. Die anderen Diagrammarten, die noch zu UML gehören, sind meiner persönlichen Meinung nach, überflüssig.

Einmal das was @mihe7 schon sagte, und zusätzlich würd ich drauf wetten, dass es hier im Trend ein paar gibt, die pauschal UML-Diagramm und Klassendiagramm gleichsetzen (und wenn nicht hier, dann wenn man sich 10 beliebige Leute hier im Forum raussucht)

Überflüssig würde ich als keins davon pauschal bezeichnen, auch wenn ich selber manche vermutlich niemals nutzen werde. Mindestens die Idee hinter den meisten ist sinnvoll, unabhängig davon wie formal korrekt man die dann nutzt.

 

[mrBrown]

Du redest von sogenannten Mockings? Dieses kann am Anfang hilfreich sein, wenn du auf einer grünen Wiese entwickelst und du dich mit deinem Kunden abstimmen must. Meistens bestehen aber bereits bestimmte System schon und müssen entsprechend angepasst werden.

Wenn man ein System übernimmt sind Diagramme nicht minder sinnvoll. Ein vernünftiges Diagramm zeigt Übersicht und Zusammenhänge meist deutlich schneller und verständlicher, als es Code oder Erklärungen ohne Diagramme je könnten.

Gehe ich aber vom Bereich der Ausbildung aus, und schaue auf einige Beiträge hier im Forum, dann wäre es doch schlau, das Programm im Vorfeld mit UML zu modellieren, sowohl auf Aufbau als auch von der Funktion her.

Find ich persönlich nicht. Es ist schon wichtig die wichtigsten Diagrammarten zu kennen, allerdings erstellt dir eigentlich jedes UML Tool dir aus deinem Quellcode die wichtigsten Diagrammarten. Ggf. sogar mit ERD und ORM, die allerdings nicht zum UML gehören. Mein Tip deshalb, fange mit der wichtigsten Funktion an und baue es immer weiter aus.

Aus dem Quellcode UML generieren, und vorher per UML modellieren, sind allerdings zwei völlig gegensätzliche Dinge.

Per UML (oder "an UML abgelehnt, aber weniger formal) modellieren finde ich fast immer sinnvoll, grad auch wenn man im Team arbeitet. Zumindest hab ich bisher noch nie erlebt, dass der Aufwand für ein Diagramm nutzlos war.

Aus fertigem Code automatisiert erstellte Diagramme hab ich aber bisher nie als wirklich sinnvoll empfunden. Die zeigen meist nicht vernünftig das, was relevant ist, und brauchen eine Menge an händischer Nacharbeit.

 

[TM69]

Wenn man ein System übernimmt sind Diagramme nicht minder sinnvoll. Ein vernünftiges Diagramm zeigt Übersicht und Zusammenhänge meist deutlich schneller und verständlicher, als es Code oder Erklärungen ohne Diagramme je könnten.

Diesem muss ich bedingt widersprechen. Hast dir mal ein großes Projekt in UML generieren lassen? Dieses wird ganz ganz schnell unübersichtlich. Allein die ganzen Interaktionen und Beziehungen untereinander.

Aus dem Quellcode UML generieren, und vorher per UML modellieren, sind allerdings zwei völlig gegensätzliche Dinge.

Per UML (oder "an UML abgelehnt, aber weniger formal) modellieren finde ich fast immer sinnvoll, grad auch wenn man im Team arbeitet. Zumindest hab ich bisher noch nie erlebt, dass der Aufwand für ein Diagramm nutzlos war.

Ja und nein. Aus verschiedenen Gründen. Hier nur ein paar:

+ Standardisiert: UML ist eine anerkannte und verständliche Plattform für Software-Design. Es ist eine Standardnotation unter Softwareentwicklern.
+ Kommunikation: UML dient als Blaupause für ein zu entwickelndes/bestehenden System dienen. Dieses ist allerdings nur dann effektiv, wenn dieses allen Benutzern und Entwicklern richtig vermittelt werden kann. (s. u.)
+ Unvollständiges Wissen: Wie bereits oben erwähnt muss man nicht alle (>10) Diagrammarten kennen, sondern es langt vollkommen die 3 wichtigsten Diagrammarten zu kennen.
+ Allgemeingültig: UML Modelle können auf verschiedene Domänen und Technologien angewendet werden.
+ Vielzahl von Tools: Es gibt hunderte von unterschiedlichen UML - Tools. Von Open-Source (z.B. MyGen) über Freeware (z.B. Visual Paradigm CE) bis hin zu kommerziellen (z.B. Visual Paradigm (mein persönlicher Favorit))

- Steigende Komplexität: Seit Bestehen von UML hat sich dieses kontinuierlich Vergrößert. Insbesondere Anfänger werden von den zig Diagrammen förmlich erschlagen.
- Keine formale Notation: Es wird UML nicht unbedingt benötigt, um Entwurfdesigns zu vermitteln. Mit Verbindungslinien-Programmen z.B. Visio oder Whiteboard können den gleichen Erfolg haben.
- Indiffirentes Design: Im Kern bezieht sich die Darstellung auf die zugrundeliegende Softwarearchitektur, die einfach und grundlegend ist. Es wird aber keine komplexen Diagramme benötigt, um das Design darzustellen oder zu erläutern.

Es bleibt somit festzuhalten, dass UML eine Hass-Liebe ist.

 

[LimDul]

Wobei sich agile und Diagramme keineswegs widersprechen, das passt durchaus gut zusammen.

Nur halt nicht im Sinne von Klassendiagrammen, die in jedem Fall 100% ausformuliert sein müssen, bevor man anfängt zu programmieren.

Jepp, da stimme ich zu. Wir entwickeln agil. Für unsere gesamte Software gibt es kein Klassendiagramm - das würde aber auch eine Tapete nicht ausreichen (dürften mittlerweile weit über 1000 Klassen sein). Aber es gibt für viele kleine Aspekte abgespeckte Klassendiagramme zur Visualisierung der Konzepte. Die haben alle in der Regel maximal 10 Klassen. Nicht für alle Konzepte, aber für viele der fachlichen Klassen.

Und in der Regel ist es auch so, dass am Anfang, wenn wir eine neue fachliche Komponente anfangen ein oder mehrere Diagramme in Umlet malen. Wenn dann die Umsetzung der fachlichen Komponente fertig ist, werden diese Diagramme dann an die Realität wie es umgesetzt ist, angepasst. Das ist meines Erachtens hier der wichtige Teil - man kann agil entwickeln, aber man muss dafür sorgen dass hinterher alles konsistent ist. Mit der Methodik erreichen wir mehre Dinge:

- Wir haben vorher ein grobes Konzept wie es aussehen soll und entwickeln nicht blind los
- Man kann anhand des Diagramms einfacher über das Für und Wider bestimmter Varianten diskutieren
- Wir haben am Ende eine korrekte Dokumentation des Konzepts.