Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
Letzte ÜberarbeitungBeide Seiten der Revision
grafische_programmierung_mit_der_uml [2019/07/22 18:19] – [Videozusammenfassung] huwigrafische_programmierung_mit_der_uml [2020/05/26 16:14] – [Eigenschaften und Verhalten] huwi
Zeile 27: Zeile 27:
 >{{uml:smd32pin.jpg?100|}} {{uml:klassecontroller.jpg|}} >{{uml:smd32pin.jpg?100|}} {{uml:klassecontroller.jpg|}}
  
-Jeder Controller kann eingeschaltet werden und soll dann arbeiten. Das sind Operationen, die der Controller ausführen soll. Diese können in der UML der Klasse zugeordnet werden. Operationen erscheinen als Liste im Klassenrahmen.+===== Eigenschaften und Verhalten ===== 
 + 
 +Jeder Controller kann eingeschaltet werden und soll dann arbeiten. Diese Verhaltensmerkmale werden als  Operationen abgebildet, die der Controller ausführen soll. Diese werden in der UML der betreffenden (verantwortlichen) Klasse zugeordnet. Operationen erscheinen als Liste im Klassenrahmen. Klassenbezogene Daten (Eigenschaften) werden als Liste von Attributen ebenfalls der Klasse zugeordnet
  
 > {{uml:controllerrun.jpg|}} > {{uml:controllerrun.jpg|}}
Zeile 111: Zeile 113:
 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:ledaggregation.jpg|}}+>{{uml:ledaggregation.jpg|}}
  
 In der gezeigten UML-Darstellung wurde Folgendes festgelegt: In der gezeigten UML-Darstellung wurde Folgendes festgelegt:
Zeile 125: Zeile 127:
     * **Die Klasse //DigitalOut// wird unter dem Namen //led// in der Klasse Controller als öffentliches Attribut aggregiert.**     * **Die Klasse //DigitalOut// wird unter dem Namen //led// in der Klasse Controller als öffentliches Attribut aggregiert.**
  
-<code cpp>+><code cpp>
 // SiSy UML C++ Codegenerator //////////////////////////////////////////////// // SiSy UML C++ Codegenerator ////////////////////////////////////////////////
 class Controller : public STM32F4 class Controller : public STM32F4
Zeile 152: Zeile 154:
 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:ledattribut.jpg?550|}}+>{{uml:ledattribut.jpg?550|}}
  
 ===== Erster UML Versuch mit SiSy ===== ===== Erster UML Versuch mit SiSy =====