Es gibt verschiedene Möglichkeiten, UML zu verwenden. Martin Fowler nennt diese UML-Modi und identifiziert vier: UML als Notes , UML als Sketch , UML als Blueprint und UML als Programmiersprache .
UML als Programmiersprache hat sich nie wirklich durchgesetzt. In diesem Bereich wurde unter verschiedenen Namen gearbeitet, z. B. Model Driven Architecture oder Model Based Software Engineering. Bei diesem Ansatz erstellen Sie sehr detaillierte Modelle Ihres Softwaresystems und generieren den Code aus diesen Modellen. Es kann einige Anwendungsfälle geben, in denen dieser Ansatz nützlich ist, jedoch nicht für allgemeine Software und insbesondere nicht außerhalb großer Unternehmen, die sich die Tools leisten können, die diesen Ansatz unterstützen. Es ist auch ein zeitaufwändiger Prozess - ich kann den Code für eine Klasse schneller eingeben, als ich alle zur Implementierung erforderlichen grafischen Modelle erstellen kann.
UML als Blueprint ist oft ein Hinweis auf ein "Big Design Up Front" -Projekt. Das muss natürlich nicht sein. Das Modell kann auch für ein bestimmtes Inkrement vollständig beschrieben werden. Die Idee ist jedoch, dass die Zeit für die Erstellung eines Designs in Form von UML-Modellen aufgewendet wird, die dann an jemanden übergeben werden, der sie in Code umwandelt. Alle Details sind präzisiert und die Konvertierung in Code ist in der Regel mechanischer.
UML als Skizze und UML als Notizen haben ähnliche Eigenschaften, unterscheiden sich jedoch je nach Verwendungszweck. Die Verwendung von UML als Skizze bedeutet, dass Sie Entwürfe mit UML-Notationen skizzieren. Die Diagramme sind jedoch wahrscheinlich nicht vollständig, konzentrieren sich jedoch auf bestimmte Aspekte des Entwurfs, die Sie für die Kommunikation mit anderen benötigen. UML als Notes ist ähnlich, aber die Modelle werden nach dem Code erstellt, um das Verständnis der Codebasis zu erleichtern.
Wenn Sie darüber nachdenken, denke ich, dass alles, was oben steht, für jede Art von Modellnotation zutrifft. Sie können es auf Entity-Relationship-Diagramme, IDEF- Diagramme, Geschäftsprozessmodellierungsnotationen usw. anwenden . Unabhängig von der Modellierungsnotation können Sie auswählen, wann Sie sie anwenden (davor als Spezifikation, danach als alternative Darstellung) und wie viele Details (vollständige Details zu Schlüsselaspekten).
Die andere Seite davon ist Open-Source-Kultur.
Oft beginnen Open Source-Projekte damit, ein Problem zu lösen, das eine Person (oder heute ein Unternehmen) hat. Wenn es von einer Einzelperson gestartet wird, beträgt die Anzahl der Entwickler 1. In diesem Fall ist der Kommunikationsaufwand extrem gering und es besteht wenig Bedarf, über die Anforderungen und das Design zu kommunizieren. In einem Unternehmen wird es wahrscheinlich ein kleines Team geben. In diesem Fall müssen Sie wahrscheinlich die Entwurfsmöglichkeiten kommunizieren und die Kompromisse besprechen. Sobald Sie jedoch Ihre Entwurfsentscheidungen getroffen haben, müssen Sie Ihre Modelle entweder warten, da sich die Codebasis im Laufe der Zeit ändert, oder sie wegwerfen. In Agile Modeling- Begriffen sollten Sie "kontinuierlich dokumentieren" und eine "einzige Informationsquelle" verwalten .
Abgesehen davon gibt es die Idee, dass Code Design ist und dass Modelle nur alternative Ansichten des Designs sind. Jack Reeves hat drei Essays über Code als Design geschrieben , und es gibt auch Diskussionen im C2-Wiki, in denen die Ideen diskutiert werden, dass der Quellcode das Design ist , das Design der Quellcode und der Quellcode und die Modellierung . Wenn Sie sich dieser Überzeugung anschließen (was ich auch tue), dann ist der Quellcode die Realität und alle Diagramme sollten existieren, um das Verständnis des Codes und vor allem die Gründe dafür, warum der Code so ist, wie er ist, zu verbessern.
Ein erfolgreiches Open Source-Projekt, wie Sie es bereits erwähnt haben, hat Mitwirkende auf der ganzen Welt. Diese Mitwirkenden sind in der Regel technisch kompetent in den Technologien, die die Software antreiben, und sind wahrscheinlich auch Benutzer der Software. Mitwirkende sind Personen, die den Quellcode genauso einfach lesen können wie Modelle. Sie können Tools (IDEs und Reverse Engineering-Tools) verwenden, um den Code zu verstehen (einschließlich der Generierung von Modellen, wenn sie dies für erforderlich halten). Sie können auch selbst Skizzen des Flusses erstellen.
Von den vier Modi, die Fowler beschreibt, werden Sie meines Erachtens kein Open-Source-Projekt oder nur sehr viele Projekte finden, die Modellierungssprachen als Programmiersprachen oder Blaupausen verwenden. So bleiben Notizen und Skizzen als mögliche Verwendungszwecke für UML. Notizen werden vom Mitwirkenden für den Mitwirkenden erstellt, sodass Sie sie wahrscheinlich nirgendwo hochgeladen finden. Skizzen verlieren an Wert, wenn der Code vollständiger wird und wahrscheinlich nicht mehr gepflegt wird, da dies nur Anstrengungen der Autoren erfordert.
Bei vielen Open Source-Projekten werden keine Modelle zur Verfügung gestellt, da sie keinen Mehrwert bieten. Dies bedeutet jedoch nicht, dass Modelle nicht von jemandem zu Beginn des Projekts erstellt wurden oder dass Einzelpersonen keine eigenen Modelle des Systems erstellt haben. Es ist nur zeiteffektiver, eine Quelle von Designinformationen zu verwalten: den Quellcode.
Wenn Sie Leute finden möchten, die Designinformationen austauschen, sollten Sie sich Foren oder Mailinglisten ansehen, die von Mitwirkenden verwendet werden. Häufig dienen diese Foren und Mailinglisten als Designdokumentation für Projekte. Sie finden möglicherweise keine formale UML, aber möglicherweise eine grafische Darstellung von Konstruktionsinformationen und -modellen. Sie können auch Chatrooms oder andere Kommunikationskanäle für das Projekt aufrufen. Wenn Personen über Entwurfsentscheidungen sprechen, kommunizieren sie möglicherweise mit den grafischen Modellen. Aber sie werden wahrscheinlich nicht Teil eines Repositorys, da sie nicht mehr wertvoll sind, sobald sie ihren Zweck in der Kommunikation erfüllt haben.