Moin Rainer,

die Pfeile in deinem Schaubild stellen bestimmt die Ansprechrichtung der einzelnen Funktionen in Richtung der nächsten Function, die aufgerufen wird da, oder?
Was bedeuten geschlossene / offene Pfeilspitzen und die gefüllten / nicht gefüllten Rauten am Pfeilanfang?

Möchtest du keine Informationen vom Motor (z.B. Defekt / Ausfall) mittels Strom-Sensorik zurück in den Controller laden?

Viele Grüße
Mirko

nö, fliegt prima ohne motorregelkreis !
und wenn einer ausfällt : ist eh feierabend

pfeile und so sind (..hoffe ich : bin blutiger anfänger !) symbole aus dem klassendiagramm-baukasten (http://de.wikipedia.org/wiki/Klassendiagramm)
komposition, aggregation und vererbung. bloß wie man das jetzt zu fuß in code umsetzt : oh mann ...

Husi hat geschrieben:die Pfeile in deinem Schaubild stellen bestimmt die Ansprechrichtung der einzelnen Funktionen in Richtung der nächsten Function, die aufgerufen wird da, oder?
Was bedeuten geschlossene / offene Pfeilspitzen und die gefüllten / nicht gefüllten Rauten am Pfeilanfang?

Nunja,

nicht ausgemalte (aber geschlossene) Pfeile bedeuten eine Vererbung.
Entweder erbt eine Klasse aus einem Interface oder von einer generalisierten Klasse.
Dabei geht der Pfeil VOM Objekt das Erbt ZUR Quelle (man spricht also "Ich erbe von...").

Die nicht ausgemalten Vierecke an der "Pfeilspitze" sind Aggregationen.
Die ausgemalten Rauten an der "Pfeilspitze" nennen sich Kompositionen.

Bei Aggregationen kann das Benutzte Objekt auch weiterleben, wenn der "Nutzer" nicht mehr existiert.
Z.b. ein Objekt "Programmierfirma" nutzt mehrere Instanzen der Klasse "Programmierer". Wird die Firma von Microsoft aufgekauft und gleich geschlossen existiert das Objekt "Programmierfirma" nicht mehr, die einzelnen Programmierer jedoch schon und können woanders weiterverwendet werden.

Bei Kompositionen stirbt das benutzte Objekt mit dem Nutzer.
Als Beispiel könnten wir einen Menschen nehmen und nehmen an, er besteht aus einzel-Objekten (2xInstanz der Klasse Hand, 2x Fuss, etc).
Stirbt das Objekt "Mensch" sterben auch die Instantzen der Klasse "Hand", "Fuss", etc..., da sie nicht mehr benötigt werden oder nicht allein Lebensfähig sind.



Warum in dem Diagramm Nick- und Roll-Regler Kompositionen, und Höhen- und Gier-Regler Aggregationen weiß ich zwar nicht, aber entweder hat das einen bestimmten Grund oder ist einfach nur "Verklickt"

ich dachte so : nick und roll sind "mandatory", gier und höhe "optional" (gps sowieso).

Da kannst du dann aber eigentlich nicht die Symbole für Aggregation und Komposition nehmen.
Ich wüsste auch gar nicht ob "optional" ein eigenes Symbol in UML hat. Am Einfachsten würde ich das als "Bemerkung" an den Pfeil oder an das Klassenkästchen dran malen.

Aber jetzt diskutieren wir hier über Pfeile und Kringel Eigentlich wolltest du doch was programmieren, oder?


Ich hät's so gezeichnet (und hoffentlich nicht selber Fehler reingebracht):
Falls du Violet-Dateien nutzen kannst und mein UML verwenden möchtest:

nein, nein, das ist schon gut so. eine wasserdichte uml-modellierung wäre schon ein guter schritt.

in sisy steht bei aggregation : "die klasse enthält.." und bei komposition : " die klasse besteht existenziell aus.." .
das hab ich als optional/mandatory verstanden. mißverständniss ??

parallel dazu mein hauptproblem : wie drücke ich die unterschiedlichen zykluszeiten für die funktionen aus ?
primitivansatz (auch grafisch sehr unschön, i know..) :

http://www.reinerdoll.de/violet_takt.jpg

Jupp.

Wenn du das mit "meiner" Erklärung übereinander legst kommt das Selbe raus.
"Enthält" heisst, nutzt ein anderes Objekt.
"Besteht extentiell aus" bedeutet, kann nur leben wenn es das andere Objekt auch gibt.

Wenn du dir das bei Wikipedia anguckst steht da eigentlich auch das gleiche, und ebenso "weichgewaschen" dass man erst mal überlegen muss was die meinen.

Aber "Optional" bedeutet das in beiden Fällen nicht. Es sagt nur aus, ob Das eine ohne das andere Leben kann oder nicht.

jetzt hat sichs überschnitten :

parallel dazu mein hauptproblem : wie drücke ich die unterschiedlichen zykluszeiten für die funktionen aus ?
primitivansatz (auch grafisch sehr unschön, i know..) :

http://www.reinerdoll.de/violet_takt.jpg

Ich glaube das ist im UML gar nicht vorgesehen.
UML soll ja eher die Struktur und Abhängigkeiten aufzeigen, keine technischen Details.

Du kannst natürlich das Diagramm kreativ erweitern so lange man versteht was gemeint ist.
Irgendwann ist da natürlich Ende und du musst dir Gedanken machen wie du das anders Darstellst (zusätzliche Darstellungsform).

Sorry, wenn ich mal dumm frage:
Geht es bei euch nur um das optische Diagramm oben, ob die Pfeile richtig sind, oder tut ihr auch programmieren????????


Alf-1234

ich versuche, durch modellierung in uml, die objektorientierte programmiermethodik anzuwenden.
prozedural geschriebene coptersoftware ist ja für andere kaum lesbar, so unübersichtlich wird das.

ich werde dann in luna versuchen, das abzubilden. c++ wäre auch nen versuch wert, aber ich mag c nicht.

C/CPP auf einem AVR fetzt foch

Luna kenne ich nicht, aber vielleicht hab ich mal Langeweile und schau mir das an.

Hast auf jeden Fall noch viel vor.

ein paar schritte zurück, andersrum. ich hab code, der (symbolisch) etwa so ausieht : (schon klar, public ist übel usw., aber darum gehts nicht.) Frage : wie sieht das (..weitergedacht auf roll, gier usw.) in violet aus ?

Ich tät sagen, so:

(Hoffe man erkennt was)
Natürlich davon ausgehend, dass das alles einzelne Klassen sind - sonst wäre das Klassendiagramm unnötig

Das die Klasse Antrieb 4 Motoren fix hat, schränkt doch erheblich ein, oder?

Wäre es nicht sinnvoller, ein "Geometrie"-Objekt einzubauen?

Das als generische Klasse, die dann für Bi, Tri, Quadro, Heda, Okto oder was auch immer implementiert werden?

Also rufe ich ein Object davon auf und sage: Nick 10° nach vorne, und die Klasse muss halt selber wissen, wie sie was (Regler und/oder Servos) ansteuern muss?

Wenn ihr das in ner richtigen Sprache (also C/C++) macht, werde ich sicherlich versuchen zu helfen.