Beziehung zwischen OOAD, UML. Welches Wissen ist Voraussetzung?

Question

Ich versuche zu verstehen OOAD und UML. Bei dieser Quest bin ich auf einige Situationen gestoßen, in denen ich mich gefühlt habe, wenn eine von beiden Voraussetzung für den anderen Gegenstand ist. Das ist in einigen Situationen beim Lesen OOAD Ich fühlte, dass ich Vorkenntnisse von UML hätte und in einer Situation umgekehrt. Anstatt diese Verwirrung zu behalten, suche ich einige Eingaben:

1) Sollte man zuerst verstehen, was OOAD ist, bevor man die `UML erforscht?

2) Was ist die Beziehung zwischen OOAD und UML?

Jede Antwort in einfachen Worten wäre eine große Hilfe, um aus dieser verwirrenden Schleife herauszukommen.

Answer 1

Ich würde Ihnen empfehlen, über ordnungsgemäße OO vor UML zu lernen. Es ist wichtiger zu wissen, wie man Analyse und Design richtig macht, als zu wissen, wie man die UML-Syntax zum Ausdruck bringt. Eine Analogie ist, dass jeder einen Roman mit korrekter Syntax schreiben kann, aber es wird scheiße. Es ist schwer, gut zu schreiben.

UML ist eine von vielen Notationen, aber es wurde zufällig sowohl von der OMG als auch von ISO standardisiert. Ich habe zum ersten Mal von Rumbaughs Buch über OMT gelernt, das ich für eine bessere Notation hielt, aber es wurde jetzt wegen des UML-Standards aufgegeben.

Answer 2

Ich denke, Sie können es Hand in Hand tun - wenn Sie kleine Schritte machen. Ich stimme JimL zu. dass du zuerst das Grundkonzept von OO lernen solltest. Ich weiß, dass es schwierig ist, wenn du von einem reinen funktionalen Ansatz kommst. Aber selbst das Grundkonzept von OO ist leicht zu verstehen - wenn man erst einmal den richtigen Strohhalm gefunden hat. Nun, UML ist ein sehr komplexes Biest - wie OO wäre in seiner ganzen Länge und Breite. Aber wenn man es in kleinen Scheiben isst, serviert auf kleinen UML-Platten (Klassennotation), kann man den Status eines Kenners erreichen, ohne dick zu werden. OOAD ist schließlich nur ein nettes Abendessen, das aus dem Wissen von OO besteht und es richtig mit etwas UML anwendet.

N.B .: Ich selbst lernte OOAD den ICONIX-Weg (Sie können sie googeln). Das fand ich am praktischsten, was mir sehr geholfen hat. Später habe ich Bittner/Spence über Anwendungsfälle gelesen und festgestellt, dass dies eine noch wertvollere Ressource ist. Anforderungen (die eigentlich ein Fundament für jedes Design sind) erreichten mich erst sehr spät. Das war gar nicht so schlecht, da der Umgang mit ihnen extrem heikel ist!

Answer 3

Ich würde sagen, Sie sollten ein Verständnis für OO-Konzepte haben, bevor Sie versuchen, UML in den Griff zu bekommen. Am wichtigsten ist das Konzept einer Klasse, die Daten/Zustände und Operationen einkapselt.

OO ist eine Möglichkeit, Design und Implementierung zu strukturieren, während UML eine Möglichkeit ist, beides (und andere Dinge) zu dokumentieren.

Während es Aspekte von UML gibt, die in ihrem Ansatz nicht besonders objektorientiert sind (Anwendungsfall- und Aktivitätsdiagramme in den Sinn), werden Sie, wenn Sie auf die Implementierungsseite der Dinge kommen, beispielsweise kann nur im Kontext eines Elements existieren (normalerweise eine Klasse), und dass eine Datei kein grundlegendes Konzept ist, sondern eine Klasse.

So ist es schwierig, eine Sammlung von Quellcode in klassischem C mit gebrauchsfertiger UML zu dokumentieren. Wenn das, was Sie dokumentieren möchten, selbst objektorientiert ist, wird es Ihnen viel leichter fallen.

Answer 4

Nun, beide UML und OOAD dienen verschiedenen Zwecken.Wenn du mich nach der Priorität fragst, würde ich mehr zu OOAD als zu UML raten, nun zu deiner Frage, würde ich dir vorschlagen, eine hochrangige Idee für UML zu haben, wie zB deine Klasse darzustellen, wie man Assoziationen in UML darstellt Zusammensetzung usw. darstellen und dann OOAD Zeit geben.