UML: Funktion, Platform, Mapping

[Peter (Gast)]

Hi,

ich fange gerade mit UML an und eine der ersten Fragen die auftauchen 
ist, wie organisiere ich die Struktur. Speziell: wie trenne ich die 
Funktionalität von der Platform und bilde dann das eine auf das andere 
ab (Mapping)?

Ein einfaches Beispiel:
- Es gibt ein Mainboard mit Controller und LED
- Die LED wird am Mainboard-Pin A des Mainboard angeschlossen
- Der Controller schaltet die LED über Pin B1

Die Funktionen lauten also: LED_an() und LED_aus().
Die Abbildung der Pins lautet: Mainboard-Pin A <-> Controller Pin B1.
Soweit so gut.

Wie stelle ich diese Zusammenhänge mit UML dar? Welche Diagramme werden 
benötigt und wozu?

Gruß Peter

[Sven (Gast)]

Ich wieß nicht, ob du von UML gerade etwas zu viel erwartest. 
Grundsätzlich ist es eine fülle von Diagrammen, die etwas darstellen. 
Dabei gibt es unterschiedliche Sichtachsen (z.B. Sequenzdiagramm für 
Abläufe, Klassendiagramm für Klaennstrukturen oder Deployment Diagramme 
für die Verteilung der Software auf die Hardware, etc.).

Frage dich daher, für wen machst du das, aus welchem Grund und was 
möchtest du vermitteln. Dann kannst du entscheiden, welche Scihtachsen 
notwendig sind und daraufhin diese Mithilfe der Diagramme beschreiben. 
Aus meiner Erfahrung reicht die UML dafür alleinig aber nicht aus. Text 
als 2. Art der Vermittlung ist daher immer gut.

[Eric B. (beric)]

Peter schrieb:
> Hi,
>
> ich fange gerade mit UML an und eine der ersten Fragen die auftauchen
> ist, wie organisiere ich die Struktur. Speziell: wie trenne ich die
> Funktionalität von der Platform und bilde dann das eine auf das andere
> ab (Mapping)?
>
> Ein einfaches Beispiel:
> - Es gibt ein Mainboard mit Controller und LED
> - Die LED wird am Mainboard-Pin A des Mainboard angeschlossen
> - Der Controller schaltet die LED über Pin B1

Das ist alles hardware, hat mit UML erstmal nix zu tun.
UML beschreibt die Software.

> Die Funktionen lauten also: LED_an() und LED_aus().

Die LED wird dann zu eine (Instanz einer) Klasse, mit Methoden LED::an() 
und LED::aus(). Du brauchst dann noch eine Klasse
die diese Funktionen aufruft.

> Die Abbildung der Pins lautet: Mainboard-Pin A <-> Controller Pin B1.
> Soweit so gut.

Das ist Hardware, hat mit UML nix zu tun.

> Wie stelle ich diese Zusammenhänge mit UML dar? Welche Diagramme werden
> benötigt und wozu?

Das hängt davon ab was du alles modellieren möchtest.
Im einfachsten Fall hast du nur deine 2 Klassen wie oben beschrieben.
Dann könnte ein State Diagramm für die LED Klasse hilfreich sein und
vielleicht ein oder zwei Sequenzdiagramme um zu zeichen wie die Klassen 
kommunizieren um die LED ein oder auszuschalten.

[Johannes R. B. (Gast)]

schau dich mal unter den folgenden Seiten um ... da sollte einiges zum 
Thema UML und Mikrocontroller zu finden sein

http://www.avr-uml.de
http://www.avr-cpp.de
http://www.myxmc.de
http://mystm32.de

besonders spannend ist zum Thema Trennung Modell und Plattform bzw. 
Plattformapping wohl das hier:

http://www.avr-uml.de/tutorial/doku.php?id=uml-framework

leider kommt man in die details nur mit ner Lizenz von SiSy aber hier 
mal ein Bild im Anhang wie die das lösen...

Gruß

[Peter (Gast)]

Erstmal Danke für die Antworten.

Sven schrieb:
> Frage dich daher, für wen machst du das, aus welchem Grund und was
> möchtest du vermitteln.

Ich mache das für mich. Der Grund ist, dass ich ein systematische 
Vorgehen erlernen möchte, welches in der Software-Entwicklung üblich 
ist. Ich verspreche mir davon, schon vor dem Programmieren Fehler 
aufzudecken und meine Arbeit zu dokumentieren, so dass ich auch in einem 
Jahr noch weiss, was ich da gemacht habe.

Sven schrieb:
> Aus meiner Erfahrung reicht die UML dafür alleinig aber nicht aus.

Das kann ich leider nicht beurteilen, aber ich überlege, ob ich mich 
nicht gleich mit SysML beschäftigen soll.

Eric B. schrieb:
> Das ist alles hardware, hat mit UML erstmal nix zu tun.
> UML beschreibt die Software.

Da bin ich mir jetzt auch nicht sicher, ob es da nur um Software geht. 
Ist es nicht eine Modellierungssprache zum Beshreiben von Systemen?
Aber ein weiterer Grund sich mal SysML anzuschauen.

Eric B. schrieb:
> Die LED wird dann zu eine (Instanz einer) Klasse

Das mit der Instanz scheint mir eine gute Idee. Was in den Klassen noch 
abstrakt definiert ist, wird dann bezgl. Mikrocontroller A auf Pin B und 
bei Mikrocontroller B auf Pin CDE oder so abgebildet.

Johannes R. B. schrieb:
> schau dich mal unter den folgenden Seiten um ...

Dazu bin ich noch nicht gekommen. Aber Danke für die Hinweise. Hilft 
bestimmt weiter.

Gruß Peter

[Norbert (Gast)]

Eric B. schrieb:
> Das ist alles hardware, hat mit UML erstmal nix zu tun.
> UML beschreibt die Software.
UML beschreibt Systeme. Systeme, die eine bestimmte Funktion erfüllen 
(sollen). Ob die Funktion in Hardware oder in Software realisiert wird, 
ist dort erstmal unerheblich.

Wenn allerdings die Hardware in Form eines PC vorgegeben ist, hat man 
als Softwerker natürlich nur noch Blick für Software....

[Willi (Gast)]

Peter schrieb:
> [...] welches in der Software-Entwicklung üblich ist.

UML ist in der Software-Entwicklung definitiv nicht üblich!

[Johannes R. B. (Gast)]

also ich war bis gestern dort ( hat mir die Firma spendiert ;-) ) :

http://www.ese-kongress.de/

UML ist gefühlt jeder zweite Vortrag und jeder zweite Aussteller... und 
auch bei den anderen Kongressteilnehmern wirkte es nicht so als wenn die 
UML als unüblich angsehen... die UML Vorträge waren immer rappel voll

Gruß J.