Wie oft verwenden Sie formale UML?

Ich habe Ad-hoc-MUML (erfundene Modellierungssprache) verwendet, um das System ziemlich häufig zu entwerfen und zu erklären. Es sieht ähnlich aus wie UML und ist in der Regel ziemlich gut verstanden.

Ich hatte jedoch einen oder zwei Professoren, die sich für die Verwendung einer strengen, formalen UML aussprachen, die der Spezifikation so nahe wie möglich kam. Ich hatte immer den Verdacht, dass strenge UML nicht so häufig ist, wie sie behaupteten. Wie oft zeichnen Sie vollständige Diagramme, in denen alle richtigen Linienenden, Multiplikationen, Elementtypsymbole usw. verwendet werden?

Noch nie.

Heck, es ist Jahre her, seit ich das letzte Mal eine UML erstellt habe . Liniendiagramme auf Whiteboards und Papierfetzen zählen nicht.

Tatsächlich haben wir gerade die einzige UML-Frage aus dem Leitfaden entfernt, den wir während der Interviews verwenden, da sich keiner von uns wirklich um die Antworten gekümmert hat.

Ich verwende gerade genug UML (sowohl in Bezug auf die Diagrammtypen als auch auf den Inhalt der Informationen im Diagramm), um meinen Standpunkt zu verdeutlichen, damit ich oder jemand anderes das System oder das Subsystem implementieren kann. Und der einzige Grund, warum ich UML verwende, ist, dass es sich um eine weit verbreitete Gruppe von Symbolen handelt, die jeweils eine sehr spezifische Bedeutung haben. Es gibt also keine Unklarheiten. Jeder Softwareentwickler sollte in der Lage sein, sich das Diagramm anzusehen und zu verstehen, was ich über das zu sagen versuche System.

Ironischerweise soll UML flexibel sein.

In der realen Welt sollte es keine umständliche Übung sein, wenn man es auf eine richtige Weise macht. Es geht darum, ein System / einen Prozess / eine Idee effektiv zu kommunizieren und zu dokumentieren.

Um deine Frage zu beantworten, bin ich bei den anderen. Ich habe die formale UML noch nie vollständig ausgenutzt.

Ich habe UML ungefähr vier Jahre lang sehr regelmäßig für ein Produkt verwendet, das alle (die meisten) seiner Codeskelette aus Rational Rose generiert hat.

In den letzten fünf Jahren wurden mehr "Kisten und Pfeile" erfunden, die zumeist vor Ort erfunden wurden und in der Regel ausreichen, um die allgemeine Vorstellung zu vermitteln. Formell korrekte UML nur einige Male in dieser Zeit.

Ich hatte jedoch einen oder zwei Professoren, die sich für die Verwendung einer strengen, formalen UML aussprachen, die der Spezifikation so nahe wie möglich kam.

Fragen Sie Ihren Professor, wann er diesen Ansatz das letzte Mal auf einem realen System angewendet hat. Ernst.

Ich versuche so formal wie möglich zu sein, wenn es um UML geht, aber nur, wenn es Sinn macht. Zeloten auf beiden Seiten des Spektrums (von Cowboys bis hin zu straffen Formalisten) verstehen das nicht.

Es gibt Kontexte, in denen ein weniger strenger Ansatz (wie der, den Sie persönlich verwenden) am besten geeignet ist. Ein gutes Beispiel sind kleine Systeme oder Änderungen, bei denen die Anforderungen gering und nicht vollständig definiert sind. Die verantwortliche Gruppe ist effizient und effektiv. Es ist wichtiger, es herauszubekommen, als es perfekt zu machen. Es wird iterativ durchgeführt und einige Mängel sind akzeptabel.

Oder Sie befinden sich in einer Phase, in der Sie Gastimulation und Skizzieren ausführen, anstatt eine vollständige formale Modellierungsphase durchzuführen. Das sind Beispiele, die mir einfallen würden.

In anderen Fällen benötigen Sie einen starren formalen UML-Ansatz. Beispielsweise könnten Sie vertraglich gebunden sein; Sie haben eine sehr große Anzahl von Entwicklern in mehreren Teams (möglicherweise verteilt). Der Umfang des Projekts kann in Jahren liegen. Es ist ein sehr großes System (einschließlich Software- und Hardwarekomponenten). die Ausfallkosten sind hoch usw.

Zu anderen Zeiten müssen Sie stattdessen / zusätzlich zu UML (tatsächliche mathematische formale Modelle wie Petri-Netze, CSP oder zeitliche Logik) etwas anderes verwenden. Beispiele hierfür sind Echtzeitsysteme, Systeme, bei denen Ausfälle katastrophal sind (medizinische Geräte) oder wo Sie vertraglich gebunden sind (zB in Europa bei der Entwicklung von Transportsystemen)

Es hängt alles von den Umständen ab und davon, was wir von jedem Ansatz erwarten. Ein Professor, der sich an die Formalität hält, ist einfach ein blinder Eiferer. Die Welt der Technik ist keine Schwarz-Weiß-Dichotomie zwischen Richtig und Falsch. Es ist eine Welt intelligenter Kompromisse.

Wenn Sie intelligent genug sind, um ein lockeres, informelles Modell in einer Weise zu verwenden, die effektiv und angemessen ist, um die Arbeit zu erledigen, dann soll es so sein. Ebenso wird von Ihnen erwartet, dass Sie erkennen, wann Sie NICHT informell vorgehen und / oder wann Sie NICHT formal vorgehen .

Trotzdem muss man es mit den Professoren nach Herzenslust spielen. Geben Sie ihnen einen Knochen, damit sie Ihnen eine Note geben, und wenn das bedeutet, sich endlich ihrem Mantra der Eiferer zu beugen, ist das in Ordnung. Sie wissen, was für Sie funktioniert, und Sie werden hoffentlich wissen, wann Sie was und wie in der realen Welt verwenden müssen.

Im Rahmen meiner Doktorarbeit habe ich untersucht, wie erfahrene Designer UML in Design-Kollaborationen einsetzen (obwohl in künstlichen Umgebungen).

Meine Erkenntnisse waren, dass UML-Metaphern und -Notationen entlehnt sind, aber die Strenge der Werkzeuge kaum eingehalten wird.

Später werden einige Modelle möglicherweise iterativ in eine strengere UML umgewandelt, häufig dann, wenn ein anspruchsvolles CASE-Tool zur Codegenerierung verwendet wird.

Die üblichen Einschränkungen der akademischen Forschung gelten natürlich :)

Ein Link zum Paper Abstract und zum Paper selbst (falls Sie keinen ACM-Zugang haben) .

Abgesehen davon empfehle ich Amblers "Agile Modeling".

Wir verwenden formale UML zur Codegenerierung eines Ruhezustands-ORM. Die meisten anderen Dinge sind informelle oder weiße Tafel. Es ist nur für uns bei der Codegenerierung wichtig, weil die mangelnde Formalität sie zerstören würde.

Dies hängt von der Branche ab, in der Sie tätig sind. Wenn Sie für Kunden arbeiten, die häufige technische Überprüfungen benötigen (z. B. PDR, CDR usw.), bevorzugen sie eine Art Standardisierung anstelle von Ad-hoc-Notationssystemen. Insbesondere Regierungsarbeit. Es verhindert Missverständnisse und die anfängliche 15-minütige Erklärung der von Ihnen erfundenen Notation.

Nur weil Sie UML verwenden, müssen Sie nicht jedes i punktieren und jedes t gemäß dem Standard kreuzen. Dies ist nur möglich, wenn Sie eine Art automatische Codegenerierung / -ausführung durchführen möchten. Ich kenne niemanden, der das für mehr als 1 Projekt getan hat.

Auf der anderen Seite, wenn Sie nur mit einem Team Ihrer eigenen Entwickler für Ihr Unternehmen arbeiten, wen interessiert es dann, welche Schreibweise Sie verwenden. Wenn Sie jedoch das richtige Werkzeug auswählen, können Sie Zeit sparen.

Nach alledem wird es Ihnen in einigen Branchen schwer fallen, mit UML zu entwerfen. In anderen Branchen werden Sie es nie sehen.

Ich denke, Sie werden auch eine Korrelation zwischen den Branchen finden, in denen das Design stimmen muss, da die Kosten für Korrekturen entsprechend hoch sind, da UML häufig verwendet wird. Im Gegensatz zu Branchen, in denen die Kosten für Konstruktionskorrekturen kaum mehr als Dokumentations- / Codeänderungen sind, wird UML wahrscheinlich nie verwendet.

In Bezug auf die ursprüngliche Frage. Die meisten Hochschulen tendieren dazu, die Ausbildung ihrer Studenten auf die Unternehmen abzustimmen, die ihre Studenten am häufigsten einstellen. Wenn Ihr Professor der Meinung ist, dass UML wichtig ist, würde es mich nicht überraschen, dass viele der Unternehmen, die an Ihrer Schule rekrutieren, UML verwenden. Sie sollten also lernen, es zu benutzen.

Als ich über UML las, versuchte ich dies bei allen Problemen, die ich in meinem C ++ - Kurs lösen sollte. Glücklicherweise war eines der ersten Beispiele, das ich versuchte, eine verknüpfte Liste zu beschreiben.
Hat nicht funktioniert
In Verbindung mit einem guten Modellierungsprozess ist UML jedoch nützlich. Nur weil es zum Guten oder Schlechten ein Standard ist.
Ich würde gerne eine Beschreibungssprache für die Metaprogrammierung von Vorlagen sehen. Ich denke, das würde viel dazu beitragen, zu verstehen, was im <<<>>> -Land vorgeht

UML ist schmerzhaft, wenn Sie auch die modellgetriebene Entwicklung ausprobieren. Ich meine, UML ist nur eine sehr nützliche grafische Notation und alles andere ist nutzlos. Ich verbringe keine Zeit mit Modellieren, sondern benutze UML jeden Tag, um die Struktur meiner Projekte zu erstellen. Was ich tue, ist, schnell ein grundlegendes Anwendungsdiagramm auf Anforderungsebenen zu zeichnen und dann sofort zu Klassendiagrammen zu wechseln. Ich füge die Rückverfolgbarkeit von Anforderungen zwischen Usecase- und Klassendiagrammen hinzu. Mein Klassendiagramm erstellt auch Code, weil es live synchronisiert ist. Es ist kein Tag im Code des gesamten Modells im UML-Modell gespeichert, das dem Java-Projekt zugeordnet ist.

Ich erstelle das Grundgerüst meiner Anwendung mit wenigen Klassendiagrammen und wechsle dann zum Code. Sobald ich den Code fertig habe, füge ich ihn mit dem Modell zusammen. Es ist eine Art Iteration zwischen Code und Modell, in der der Code das Modell ausführt. So geben mir meine Klassendiagramme eine höhere Abstraktionsebene und meinen Code, während mein Code mir meine Geschäftslogikimplementierung (z. B. Methoden) gibt.

Die UML-Modellierung dauert weniger als 10 Minuten pro Tag. Dies geschieht, wenn ich Zeit brauche, um zu überlegen, was und wie ich entwickeln muss.

UML ist großartig, fantastisch und wirklich nützlich, aber modellgetriebene Entwicklung ist nutzlos !!

Wenn ich ein System dokumentiere, das wir implementiert haben, versuche ich, es mit vollständiger formaler UML abzulegen. Aber den Rest der Zeit benutze ich nur so viel, wie nötig ist, um die Idee zu vermitteln. Außerdem verwende ich mehr DFDs als UML, da sie für die Systeme, die wir in letzter Zeit entwerfen, geeigneter zu sein scheinen.

Ich habe gerade mein angeblich erstklassiges College abgebrochen (zumindest vorübergehend), weil ich rigoros auf übermäßig zeitaufwendigen visuellen Modellierungsaktivitäten, Forumarbeiten und übermäßig redundanten Soft-Skill-Dingen bestanden habe, die jeder, der mit Computern aufgewachsen ist oder jemals nachdenklich gelacht hat in Richtung einer Benutzerschnittstelle würde es gut genug werden, dass der Gedanke, tief in Schulden zu geraten, einen dazu bringen würde, die Dinge in völliger Frustration brechen zu wollen.

Ich musste mich entscheiden, ob ich lernen wollte, was für Einsteiger- und Nachwuchsjobs anspruchsvoll war, oder welche Anforderungen CES an die ABET-Akkreditierung der Universität stellte, was Entscheidungsträger dazu veranlasste, sich dumm zu stellen, wenn es krasse Probleme mit zeitlichen Einschränkungen und unrealistischen Erwartungen gab eine PERT-Beurteilung würde ergeben. Die Universität übt nicht aus, was sie unterrichtet.

Meiner Meinung nach hat der Unified Process eine Menge Verdienste, aber die gesamte Praxis, visuelle Artefakte zu prägen, was auch immer die Modellierungssprache ist, ist ein bisschen lächerlich. Ein iterativ verfeinertes Dokument, das eine serielle Liste enthält, wie sie mit Word, Workflowy, Evernote, OpenOffice oder einem Textverarbeitungsprogramm erstellt werden kann, kann die Anforderungen des Unified Process perfekt dokumentieren. Etwas, an dem diese einfache Version leicht von mehreren Benutzern versioniert werden kann, und wenn man das richtige Tool dafür auswählt, kann ein Team sogar gleichzeitig daran arbeiten. Dies ist so viel einfacher, als wenn UML eine notwendige Methode zur Vereinigung der Horden zu sein schien.