Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende Überarbeitung | |||
grafische_programmierung_mit_der_uml [2019/01/29 17:32] – [Videozusammenfassung] huwi | grafische_programmierung_mit_der_uml [2019/07/27 17:01] (aktuell) – huwi | ||
---|---|---|---|
Zeile 7: | Zeile 7: | ||
===== UML In der Entwicklungsumgebung SiSy ===== | ===== UML In der Entwicklungsumgebung SiSy ===== | ||
- | >> | + | > |
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. | ||
- | >>> | + | > |
**Darstellung von Attributen: | **Darstellung von Attributen: | ||
Zeile 29: | Zeile 29: | ||
Eine Klasse ist in der Programmierung der Name und die Beschreibung der Attribute und Operationen eines bestimmten Typs von Systembausteinen. Die UML fordert, eine Klasse als Rechteck darzustellen. Der Name der Klasse soll mit einem Großbuchstaben beginnen. | Eine Klasse ist in der Programmierung der Name und die Beschreibung der Attribute und Operationen eines bestimmten Typs von Systembausteinen. Die UML fordert, eine Klasse als Rechteck darzustellen. Der Name der Klasse soll mit einem Großbuchstaben beginnen. | ||
- | >>> | + | > |
Jeder Controller kann eingeschaltet werden und soll dann arbeiten. Das sind Operationen, | Jeder Controller kann eingeschaltet werden und soll dann arbeiten. Das sind Operationen, | ||
- | >>> {{: | + | > |
===== 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 << | 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 << | ||
- | >>> | + | > |
In der gezeigten UML-Darstellung wurde Folgendes festgelegt: | In der gezeigten UML-Darstellung wurde Folgendes festgelegt: | ||
Zeile 48: | Zeile 48: | ||
Klassen können Eigenschaften von anderen Klassen erben. Die Verwendung von Klassenbibliotheken und der darin enthaltenen Klassen als Basisklassen der eigenen Anwendung 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 von anderen Klassen erben. Die Verwendung von Klassenbibliotheken und der darin enthaltenen Klassen als Basisklassen der eigenen Anwendung 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"// | ||
- | >>> | + | > |
Zeile 62: | Zeile 62: | ||
Die UML kennt ein zweites Ausdrucksmittel für den Sachverhalt //"ist ein"// | Die UML kennt ein zweites Ausdrucksmittel für den Sachverhalt //"ist ein"// | ||
- | >>> | + | > |
In der gezeigten UML-Darstellung wurde Folgendes festgelegt: | In der gezeigten UML-Darstellung wurde Folgendes festgelegt: | ||
Zeile 75: | Zeile 75: | ||
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, dass die so geschützten Elemente unberechtigt benutzt werden. Die meisten Programmiersprachen unterstützen dies durch entsprechende Schlüsselworte wie //public//, // | 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, dass die so geschützten Elemente unberechtigt benutzt werden. Die meisten Programmiersprachen unterstützen dies durch entsprechende Schlüsselworte wie //public//, // | ||
- | >>> {{: | + | > |
In der gezeigten UML-Darstellung wurde Folgendes festgelegt: | In der gezeigten UML-Darstellung wurde Folgendes festgelegt: | ||
Zeile 89: | Zeile 89: | ||
Zusätzlich sind in dieser Darstellung die Rückgabetypen der Operationen auf //void// 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// festgelegt worden. Dieses UML-Klassendiagramm kann jetzt in Quellcode überführt werden. Dieser kann, hier als vereinfachter Ausschnitt, so aussehen: | ||
- | >>>< | + | >< |
// SiSy UML C++ Codegenerator //////////////////////////////////////////////// | // SiSy UML C++ Codegenerator //////////////////////////////////////////////// | ||
class Controller : public ATmega328 | class Controller : public ATmega328 | ||
Zeile 116: | Zeile 116: | ||
Systeme bestehen aus Komponenten, | Systeme bestehen aus Komponenten, | ||
- | {{: | + | >{{: |
In der gezeigten UML-Darstellung wurde Folgendes festgelegt: | In der gezeigten UML-Darstellung wurde Folgendes festgelegt: | ||
Zeile 130: | Zeile 130: | ||
* **Die Klasse // | * **Die Klasse // | ||
- | <code cpp> | + | ><code cpp> |
// SiSy UML C++ Codegenerator //////////////////////////////////////////////// | // SiSy UML C++ Codegenerator //////////////////////////////////////////////// | ||
class Controller : public ATmega328 | class Controller : public ATmega328 | ||
Zeile 157: | Zeile 157: | ||
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. | ||
- | {{: | + | >{{: |
===== Erster UML Versuch mit SiSy ===== | ===== Erster UML Versuch mit SiSy ===== | ||
Zeile 166: | Zeile 166: | ||
Wählen Sie das **AVR-Vorgehensmodell**. Stellen Sie die korrekte Hardware ein. Dann laden Sie bitte die Vorlagen **AVR C++ Bibliotheken**. Legen Sie ein **Klassendiagramm** mit dem Namen "// | Wählen Sie das **AVR-Vorgehensmodell**. Stellen Sie die korrekte Hardware ein. Dann laden Sie bitte die Vorlagen **AVR C++ Bibliotheken**. Legen Sie ein **Klassendiagramm** mit dem Namen "// | ||
- | >>> | + | > |
Aus der Liste der angebotenen Diagrammvorlagen wählen Sie bitte **Grundgerüst für AppKernel-Applikation**. | Aus der Liste der angebotenen Diagrammvorlagen wählen Sie bitte **Grundgerüst für AppKernel-Applikation**. | ||
- | >>> | + | > |
Vergleichen wir die soeben geladene Vorlage mit unseren Vorüberlegungen, | Vergleichen wir die soeben geladene Vorlage mit unseren Vorüberlegungen, | ||
- | >>> | + | > |
Wenn wir das im oben begonnen Stil fortsetzen, können wir zu der geladenen Vorlage folgende Aussagen treffen: | Wenn wir das im oben begonnen Stil fortsetzen, können wir zu der geladenen Vorlage folgende Aussagen treffen: | ||
Zeile 200: | Zeile 200: | ||
Mit diesem UML-Grundgerüst wollen wir jetzt weiter arbeiten. Als nächstes schließen wir eine LED an den Controller an. Ziehen Sie eine Klasse aus der Objektbibliothek in das Diagramm und geben dieser den Namen //Led//. Verbinden Sie die //LED// ausgehend vom // | Mit diesem UML-Grundgerüst wollen wir jetzt weiter arbeiten. Als nächstes schließen wir eine LED an den Controller an. Ziehen Sie eine Klasse aus der Objektbibliothek in das Diagramm und geben dieser den Namen //Led//. Verbinden Sie die //LED// ausgehend vom // | ||
- | >>> | + | > |
===== Templates ===== | ===== Templates ===== | ||
Zeile 216: | Zeile 216: | ||
Wählen sie die Operation //onStart// in der Klasse // | Wählen sie die Operation //onStart// in der Klasse // | ||
- | >>>< | + | >< |
uint8 wert; | uint8 wert; | ||
wert=led.getBlinkCode(); | wert=led.getBlinkCode(); | ||
Zeile 225: | Zeile 225: | ||
Das entsprechende Sequenzdiagramm sieht dann so aus: | Das entsprechende Sequenzdiagramm sieht dann so aus: | ||
- | >>> | + | > |
===== Polymorphie ===== | ===== Polymorphie ===== | ||
Zeile 238: | Zeile 238: | ||
Ziehen Sie aus der Objektbibliothek eine Operation auf die Klasse //Taster//. Das Werkzeug SiSy erkennt jetzt, dass virtuelle Operationen vorhanden sind, welche sich überschreiben lassen und bietet diese im // | Ziehen Sie aus der Objektbibliothek eine Operation auf die Klasse //Taster//. Das Werkzeug SiSy erkennt jetzt, dass virtuelle Operationen vorhanden sind, welche sich überschreiben lassen und bietet diese im // | ||
- | >>>< | + | >< |
app.led.nextBlinkCode(); | app.led.nextBlinkCode(); | ||
</ | </ | ||
Zeile 245: | Zeile 245: | ||
Den Umstand, das der Taster sich direkt um die LED kümmert, können wir im Klassendiagramm mit einer // | Den Umstand, das der Taster sich direkt um die LED kümmert, können wir im Klassendiagramm mit einer // | ||
- | >>> | + | > |
===== Zustände ===== | ===== Zustände ===== | ||
Zeile 256: | Zeile 256: | ||
Bei dieser Gelegenheit schauen wir uns an wie die Entwickler dieses schon nicht mehr ganz triviale Verhalten des Tasters konstruiert haben. Selektieren Sie den Baustein // | Bei dieser Gelegenheit schauen wir uns an wie die Entwickler dieses schon nicht mehr ganz triviale Verhalten des Tasters konstruiert haben. Selektieren Sie den Baustein // | ||
- | >>> | + | > |
Dort finden Sie das Attribut //state//. Aus diesem können Sie im Kontextmenü //nach unten// wählen und gelangen zum Zustandsdiagramm für Button. | Dort finden Sie das Attribut //state//. Aus diesem können Sie im Kontextmenü //nach unten// wählen und gelangen zum Zustandsdiagramm für Button. | ||
- | >>> | + | > |
Die Modellierung von Zustandsdiagrammen wird im myAVR Lehrbuch {{http:// | Die Modellierung von Zustandsdiagrammen wird im myAVR Lehrbuch {{http:// | ||
Zeile 267: | Zeile 267: | ||
Mit dem soeben Erlernten sollten sich die im [[Framework|myAVR C++ Framework]] präsentierten UML Diagramme jetzt lesen und nachvollziehen lassen. Und hier diesen Abschnitt wiederum als Videozusammenfassung. | Mit dem soeben Erlernten sollten sich die im [[Framework|myAVR C++ Framework]] präsentierten UML Diagramme jetzt lesen und nachvollziehen lassen. Und hier diesen Abschnitt wiederum als Videozusammenfassung. | ||
- | >>>< | + | >< |
====== Zur Vertiefung ====== | ====== Zur Vertiefung ====== |