Hallo Schmetterling,
vielen lieben Dank für die Zusammenfassung. Dieses Thema ist für mich nicht ganz einfach muss ich zugeben. Die Erklärung am Beispiel Auto finde ich sehr gut! So kann die verschiedenen Begrifflichkeiten besser auseinander halten.
Danke, es freut mich wenn es hilft
🙂.
Aber ich habe da mal eine allgemeine Frage: Wann wende ich so etwas wie UML-Notation in der Praxis an? Setzt sich in bestimmten Fällen ein Programmierer oder andere ITler hin und schreiben sich solch ein UML Diagramm? Schreibt man so etwas in Fachkonzepten rein, die gleichzeitig den Inhalt einem Kollegen aus der Fachabteilung darstellen-, aber genau so gut dem IT Kollegen als Basis dienen soll?
Oft ist es so, dass ein Kunde ziemlich unkonkrete Anforderungen und Wünsche hat. Da wünscht er sich z.B. ein System zur Abwicklung von Aufträgen und zur gleichzeitigen Verwaltung seiner Kundendaten. In vielen Gesprächen versucht man dann das was der Kunde will zu beschreiben, in Worten und ganz grob und später dann immer detaillierter. Man fragt ihn eben "Du Kunde, du willst deine Daten verwalten. Was willst du denn alles tun können? Möchtest du sie ansehen, ändern, neue Daten eingeben und bestehende Daten löschen können? Das sind so die Standard-Anforderungen. Daraus entwickeln sich dann wie in Kapitel 4.2 beschrieben erstmal ganz grobe Konzepte, die das beschreiben der Kunde will.
Das ist aber viel zu wenig Information für einen Programmierer, der konkrete Aufgaben und Vorgaben möchte, was zum Beispiel eine Funktion "erstelle neue Bestellung" tun soll. Es reicht ja nicht, einfach ein Objekt "neue Bestellung" anzulegen, oft werden noch Preise berechnet, der Bestellung werden Daten hinzugefügt, eine Rechnung wird gedruckt und noch einiges mehr. Diese konkretisierung erfolgt dann in weiteren Gesprächen (die werden oft mit Fachabteilungen geführt weil die genau wissen was sie wollen und brauchen) und das wird dann ab und zu mit Hilfe von den in der Kurseinheit beschriebenen UML-Diagrammen gemacht.
Die Fachabteilung sagt zum Beispiel "wir wollen eine neue Bestellung speichern". Das wäre dann der Anwendungsfall. Weiter geht es dann damit, zu hinterfragen was alles gemacht werden muss, bis so eine Bestellung fertig ist: Daten müssen eingegeben werden, andere Daten werden aufgrund der eingegebenen Daten aus dem System geholt (z.b. die Versandadresse), Preise werden berechnet und diese Mischung aus Neueingabe, Verbindung mit exisitierenden und berechneten Daten muss gespeichert werden und schön wäre es auch, wenn der Benutzer sieht, ob die Bestellung erfolgreich gespeichert wurde oder ob ein Fehler (Platte voll, nicht alle nötigen Daten vorhanden, ...) aufgetreten ist.
Das könnte man in einem Sequenzdiagramm festhalten, wobei der Anwender viele Sachen gar nicht weiß, der sitzt ja nur vor dem Computer, gibt Daten ein und drückt auf Speichern. Analog zu der Drei-Schichten-Architektur ist das das, was auf der GUI-Schicht passiert. Dann kommt die Fachkonzept-Schicht in der noch Daten dazugeholt und berechnet werden und erst wenn das fertig ist, geht das weiter an die Datenhaltungsschicht, an das Objekt das dann tatsächlich gespeichert wird, wie z.B. Seite 151 in KE2. Das alles lässt sich "relativ leicht" in einem Sequenzdiagramm festhalten und hilft der Klärung "was genau da passieren soll".
Ich hab bisher nur in einem Projekt so eine Hardcore-UML-Konzeptionierung mitgemacht, wo wirklich viele Diagramme gemalt worden sind. Vorteil von diesen Dingern ist, finde ich, dass sie relativ leicht lesbar sind, wenn man sich da mal 2,3 Tage intensiv mit beschäftigt weiß man wie die zu lesen sind. Sie sind relativ gut was die Interaktion zwischen Benutzer und Programm angeht, und man kann sie eben auf unterschiedlichen Ebenen modellieren.
Letztendlich erfolgt bei der Konzeptionierung folgendes: Man hat einen Auftrag, eine Idee und unterschiedlichste Anforderungen von unterschiedlichsten Benutzern und es geht darum, das ganze so zu formulieren, dass am Ende eine eindeutige Beschreibung daraus wird, auf der man sich verständigt ob das, was man formuliert hat, die Anforderungen trifft oder nicht. Je mehr es gelingt, die Anforderungen und Wünsche zu konkretisieren und je unmissverstädlicher das beschrieben ist, umso einfacher ist eine Abstimmung und umso einfacher ist es, das zu programmieren und die Kundenwünsche zu treffen.
Die Konzeptionierung, Entwurfsphase und Implementierung erfolgt oft nicht stingent nacheinander sondern nebeneinander oder vermischt - wenn bei der Implementierung noch Fragen auftauchen ist es oft nötig, doch nochmal die entsprechende Fachabteilung des Kunden zu fragen und so entsteht durch und oft macht es Sinn schon in der Konzept-Phase jemanden dazuzunehmen der sich Gedanken macht, wie das später umgesetzt wird und der weiß, worauf man schon am Anfang achten sollte wenn es später ans Eingemachte geht. Die Zuhilfenahme von UML ist nur ein Weg der Systementwicklung, ich finde das wird in der KE nicht so deutlich, oft ist es ein Mischmasch aus Diagrammen, Beschreibungen, Dokumentationen und auch verbalen Abstimmungen, die dann irgendwo schriftlich fixiert werden. Manchmal ist's halt leichter was in ein Diagramm zu malen als es zu formulieren im Text - wie das letztendlich abläuft ist aber von Projekt zu Projekt unterschiedlich, ich glaube es gibt kaum zwei Teams, die ganz gleich an die Sache rangehen.
Hoffe das beantwortet ungefähr deine Frage
🙂.
Jasmin
