Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
uml [2019/02/07 09:45]
127.0.0.1 Externe Bearbeitung
uml [2019/07/27 16:01] (aktuell)
huwi
Zeile 3: Zeile 3:
  
 ===== Klassendiagramm Kurzübersicht ===== ===== Klassendiagramm Kurzübersicht =====
->>{{uml:uml_kd_sq_editor.jpg?750|}}+>{{uml:uml_kd_sq_editor.jpg?750|}}
  
 Die folgende Abbildung zeigt Ihnen eine Kurzübersicht der Modellierungselemente des UML-Klassendiagramms. Die folgende Abbildung zeigt Ihnen eine Kurzübersicht der Modellierungselemente des UML-Klassendiagramms.
  
->>>{{:uml:kurzuebersichtkd.jpg|}}+>{{:uml:kurzuebersichtkd.jpg|}}
  
 **Darstellung von Attributen:** \\ **Darstellung von Attributen:** \\
Zeile 29: Zeile 29:
 Jedes Fenster muss erst einmal initialisiert werden bevor es angezeigt werden kann. Das ist eine Operation, die das Fenster selbst ausführen soll. Diese Operation wird in der UML der Klasse zugeordnet. Operationen erscheinen als Liste im Klassenrahmen. Jedes Fenster muss erst einmal initialisiert werden bevor es angezeigt werden kann. Das ist eine Operation, die das Fenster selbst ausführen soll. Diese Operation wird in der UML der Klasse zugeordnet. Operationen erscheinen als Liste im Klassenrahmen.
  
->>>{{:uml:initwindow.jpg|}}+>{{:uml:initwindow.jpg|}}
  
 ===== Objekte ===== ===== Objekte =====
 Objekte sind in der Programmierung Instanzen von Klassen. In der UML werden Objekte ebenfalls als Rechteck dargestellt. Die Kennzeichnung als Instanz erfolgt durch Unterstreichen des Namens. Zusätzlich kann der Typ der Instanz angezeigt werden. Die Instanzbeziehung zwischen einem Objekt und seiner Klasse wird als Abhängigkeit (gestrichelte Linie mit offenem Pfeil) und dem Stereotyp <<instanceOf>> dargestellt. Objekte sind in der Programmierung Instanzen von Klassen. In der UML werden Objekte ebenfalls als Rechteck dargestellt. Die Kennzeichnung als Instanz erfolgt durch Unterstreichen des Namens. Zusätzlich kann der Typ der Instanz angezeigt werden. Die Instanzbeziehung zwischen einem Objekt und seiner Klasse wird als Abhängigkeit (gestrichelte Linie mit offenem Pfeil) und dem Stereotyp <<instanceOf>> dargestellt.
  
->>>{{:uml:objectfenster.jpg?600|}}+>{{:uml:objectfenster.jpg?600|}}
  
 In der gezeigten UML-Darstellung wurde Folgendes festgelegt: In der gezeigten UML-Darstellung wurde Folgendes festgelegt:
Zeile 45: Zeile 45:
 Klassen können Eigenschaften (Attribute und Operationen) von anderen Klassen erben. Dies ermöglicht die elegante Wiederverwendung von einmal geschriebenem Code. Klassenbibliotheken und die darin enthaltenen Basisklassen beschleunigen die Entwicklungsarbeit enorm. Bei der Vererbung kann man auch je nach Lesart von einer //Generalisierung// (von unten nach oben gelesen) oder einer //Spezialisierung// (von oben nach unten gelesen) sprechen. Eine Generalisierung wird in der UML als Voll-Linie mit einem großen nicht ausgemalten Pfeil zur Basisklasse dargestellt. Die Eselsbrücke für die korrekte Richtung des Pfeils lautet //"ist ein"//. Klassen können Eigenschaften (Attribute und Operationen) von anderen Klassen erben. Dies ermöglicht die elegante Wiederverwendung von einmal geschriebenem Code. Klassenbibliotheken und die darin enthaltenen Basisklassen beschleunigen die Entwicklungsarbeit enorm. Bei der Vererbung kann man auch je nach Lesart von einer //Generalisierung// (von unten nach oben gelesen) oder einer //Spezialisierung// (von oben nach unten gelesen) sprechen. Eine Generalisierung wird in der UML als Voll-Linie mit einem großen nicht ausgemalten Pfeil zur Basisklasse dargestellt. Die Eselsbrücke für die korrekte Richtung des Pfeils lautet //"ist ein"//.
  
->>>{{:uml:greneralisierung.jpg?600|}}+>{{:uml:greneralisierung.jpg?600|}}
  
 In der gezeigten UML-Darstellung wurde Folgendes festgelegt: In der gezeigten UML-Darstellung wurde Folgendes festgelegt:
Zeile 58: Zeile 58:
 Die UML kennt ein zweites Ausdrucksmittel für den Sachverhalt //"ist ein"//. Es gibt zahlreiche Anwendungsfälle, bei denen Vorlagen, Muster verwendet oder Vorschriften eingehalten werden sollen. So etwas können Struktur- oder Verhaltensmuster, aber auch Schnittstellendefinitionen sein. Da es sich hierbei nicht um eine Vererbung im eigentlichen Sinne handelt, wird zwar derselbe Pfeiltyp verwendet, aber die Linie wird gestrichelt dargestellt. In der UML spricht man von einer Realisierung. Die UML kennt ein zweites Ausdrucksmittel für den Sachverhalt //"ist ein"//. Es gibt zahlreiche Anwendungsfälle, bei denen Vorlagen, Muster verwendet oder Vorschriften eingehalten werden sollen. So etwas können Struktur- oder Verhaltensmuster, aber auch Schnittstellendefinitionen sein. Da es sich hierbei nicht um eine Vererbung im eigentlichen Sinne handelt, wird zwar derselbe Pfeiltyp verwendet, aber die Linie wird gestrichelt dargestellt. In der UML spricht man von einer Realisierung.
  
->>>{{:uml:template.jpg|}}+>{{:uml:template.jpg|}}
  
 In der gezeigten UML-Darstellung wurde Folgendes festgelegt: In der gezeigten UML-Darstellung wurde Folgendes festgelegt:
Zeile 69: Zeile 69:
 Objektorientierte Programmiersprachen kennen verschiedene Konzepte, um die Stabilität von Anwendungen sicherzustellen. Eines der Konzepte ist die Kapselung. Dabei ist es möglich, Elementen, z. B. Attributen und Operationen von Klassen, sogenannte Sichtbarkeiten zuzuordnen. Damit kann verhindert werden, das geschützte Elemente unberechtigt benutzt werden. Die meisten Programmiersprachen unterstützen dies durch entsprechende Schlüsselworte wie //public//, //protected// und //privat//. Die UML bietet Symbole, welche zwischen den Sichtbarkeiten //+ public//, //~ package//, //# protected// und //- privat// unterscheiden. Die Sichtbarkeit wird bei Operationen und Attributen dem Namen vorangestellt. Objektorientierte Programmiersprachen kennen verschiedene Konzepte, um die Stabilität von Anwendungen sicherzustellen. Eines der Konzepte ist die Kapselung. Dabei ist es möglich, Elementen, z. B. Attributen und Operationen von Klassen, sogenannte Sichtbarkeiten zuzuordnen. Damit kann verhindert werden, das geschützte Elemente unberechtigt benutzt werden. Die meisten Programmiersprachen unterstützen dies durch entsprechende Schlüsselworte wie //public//, //protected// und //privat//. Die UML bietet Symbole, welche zwischen den Sichtbarkeiten //+ public//, //~ package//, //# protected// und //- privat// unterscheiden. Die Sichtbarkeit wird bei Operationen und Attributen dem Namen vorangestellt.
  
->>>{{:uml:sichtbarkeit.jpg?600|}}+>{{:uml:sichtbarkeit.jpg?600|}}
  
 In der gezeigten UML-Darstellung wurde Folgendes festgelegt: In der gezeigten UML-Darstellung wurde Folgendes festgelegt:
Zeile 82: Zeile 82:
 Zusätzlich sind in dieser Darstellung die Rückgabetypen der Operationen auf //void// bzw. //int// festgelegt worden. Dieses UML-Klassendiagramm kann jetzt in Quellcode überführt werden. Dieser kann, hier als vereinfachter Ausschnitt, so aussehen: Zusätzlich sind in dieser Darstellung die Rückgabetypen der Operationen auf //void// bzw. //int// festgelegt worden. Dieses UML-Klassendiagramm kann jetzt in Quellcode überführt werden. Dieser kann, hier als vereinfachter Ausschnitt, so aussehen:
  
->>><code cpp>+><code cpp>
 // SiSy UML C++ Codegenerator //////////////////////////////////////////////// // SiSy UML C++ Codegenerator ////////////////////////////////////////////////
 class Fenster : public SFrameWindow class Fenster : public SFrameWindow
Zeile 111: Zeile 111:
 Systeme bestehen aus Komponenten, die Komponenten aus Bausteinen, diese wiederum aus Einzelteilen usw. Diese Ganz-Teil-Struktur lässt sich in der UML als Aggregation bzw. Komposition abbilden. Dabei wird durch den oben angesprochenen Codegenerator solch eine Aggregation als Attribut im Code abgebildet.  Systeme bestehen aus Komponenten, die Komponenten aus Bausteinen, diese wiederum aus Einzelteilen usw. Diese Ganz-Teil-Struktur lässt sich in der UML als Aggregation bzw. Komposition abbilden. Dabei wird durch den oben angesprochenen Codegenerator solch eine Aggregation als Attribut im Code abgebildet. 
  
->>>{{:uml:aggregationpunkt.jpg?700|}}+>{{:uml:aggregationpunkt.jpg?700|}}
  
 In der gezeigten UML-Darstellung wurde Folgendes festgelegt: In der gezeigten UML-Darstellung wurde Folgendes festgelegt:
Zeile 124: Zeile 124:
     * **Die Klasse //SPointList// wird unter dem Namen //punkt// in der Klasse //Fenster// als öffentliches Attribut aggregiert.**     * **Die Klasse //SPointList// wird unter dem Namen //punkt// in der Klasse //Fenster// als öffentliches Attribut aggregiert.**
  
->>><code cpp>+><code cpp>
 // SiSy UML C++ Codegenerator //////////////////////////////////////////////// // SiSy UML C++ Codegenerator ////////////////////////////////////////////////
 class Fenster : public SFrameWindow class Fenster : public SFrameWindow
Zeile 152: Zeile 152:
 Die Aggregation entspricht also einem Attribut der Klasse. Somit ist die folgende UML-Darstellung letztlich genau dasselbe. Die Attributdarstellung spart Platz, ist aber weniger übersichtlich was die Systemarchitektur betrifft.  Die Aggregation entspricht also einem Attribut der Klasse. Somit ist die folgende UML-Darstellung letztlich genau dasselbe. Die Attributdarstellung spart Platz, ist aber weniger übersichtlich was die Systemarchitektur betrifft. 
  
->>>{{:uml:attributdarstellung.jpg?500|}}+>{{:uml:attributdarstellung.jpg?500|}}
  
 ===== Sequenzen ===== ===== Sequenzen =====
 Sequenzdiagramme dokumentieren ausgewählte Verhaltensweisen eines Systems. In SiSy werden Sequenzdiagramme für jede Operation automatisch generiert, wenn diese ausgewählt ist. Der Entwickler kann anhand des dynamisch erzeugten Sequenzdiagrammes visuell überprüfen, ob die gewünschte Steuerstruktur von ihm erstellt wurde. Dieser Perspektivwechsel zwischen Quellcodezeilen und grafischer Darstellung der Codesequenz kann enorm dazu beitragen, die Qualität des Codes zu verbessern. Sequenzdiagramme dokumentieren ausgewählte Verhaltensweisen eines Systems. In SiSy werden Sequenzdiagramme für jede Operation automatisch generiert, wenn diese ausgewählt ist. Der Entwickler kann anhand des dynamisch erzeugten Sequenzdiagrammes visuell überprüfen, ob die gewünschte Steuerstruktur von ihm erstellt wurde. Dieser Perspektivwechsel zwischen Quellcodezeilen und grafischer Darstellung der Codesequenz kann enorm dazu beitragen, die Qualität des Codes zu verbessern.
  
->>><code cpp>+><code cpp>
 void MainWnd::onInitWindow() void MainWnd::onInitWindow()
 { {
Zeile 170: Zeile 170:
 Das von SiSy automatisch erstellte Sequenzdiagramm zu diesem Code sieht dann so aus: Das von SiSy automatisch erstellte Sequenzdiagramm zu diesem Code sieht dann so aus:
  
->>>{{:uml:seqinitwnd.png?340|}}+>{{:uml:seqinitwnd.png?340|}}
  
  
Zeile 177: Zeile 177:
 Die folgende vereinfachte Darstellung der Klassen aus dem Paket //SVL_CONTROLS// zeigt, dass die einzelnen Bausteine (Controls) einer grafischen Benutzeroberfläche (GUI) in einer Vererbungshierachie angeordnet sind. Die Basisklasse //SWindow// verfügt über eine virtuelle Operation //onPaint// (kursiv).  Die folgende vereinfachte Darstellung der Klassen aus dem Paket //SVL_CONTROLS// zeigt, dass die einzelnen Bausteine (Controls) einer grafischen Benutzeroberfläche (GUI) in einer Vererbungshierachie angeordnet sind. Die Basisklasse //SWindow// verfügt über eine virtuelle Operation //onPaint// (kursiv). 
  
->>>{{:uml:polymorphie.png?600|}}+>{{:uml:polymorphie.png?600|}}
  
  
Zeile 189: Zeile 189:
 Den Umstand, das die Klasse //SRadioGroup// sich direkt um eine Menge von //SRadioButton// kümmert,  wird im Klassendiagramm mit einer //Assoziation// dokumentiert. Diese drückt aus, dass die Klasse //SRadioGroup// die von ihr kontrollierten //SRadioButton// kennt.  Den Umstand, das die Klasse //SRadioGroup// sich direkt um eine Menge von //SRadioButton// kümmert,  wird im Klassendiagramm mit einer //Assoziation// dokumentiert. Diese drückt aus, dass die Klasse //SRadioGroup// die von ihr kontrollierten //SRadioButton// kennt. 
  
->>>{{:uml:assoziation.png?600|BILD}}+>{{:uml:assoziation.png?600|BILD}}
  
 Das Besondere an der Assoziation ist, dass dabei die Instanz der assoziierten Klasse nicht Bestandteil (by value) der Klasse ist, sondern nur auf den "Standort" der Klasse verwiesen wird (by reference). In C++ wird das als Zeiger abgebildet.  Das Besondere an der Assoziation ist, dass dabei die Instanz der assoziierten Klasse nicht Bestandteil (by value) der Klasse ist, sondern nur auf den "Standort" der Klasse verwiesen wird (by reference). In C++ wird das als Zeiger abgebildet.