objektorientierung, uml und solche späße
#16 Re: objektorientierung, uml und solche späße
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
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




-
- Beiträge: 40
- Registriert: 06.05.2012 11:25:41
#17 Re: objektorientierung, uml und solche späße
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 ...
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 ...
- the-fallen
- Beiträge: 1976
- Registriert: 07.03.2011 14:20:47
- Wohnort: zwischen Augsburg und Landsberg a.L.
#18 Re: objektorientierung, uml und solche späße
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"

- Prôtos FBL -stretched- a un motor 5+4D 1.13mm 14P de torro [V-Stabi]|[V-Gov] | [YGE90LV] | [UweG-Taumelscheibe] | [ZyclicMod]
- SuziJanis 700 UltraLight 3570g Abfluggewicht
- Besessen: T-Rex 250SE, T-Rex 450L, T-Rex600EFL, TDR, Blade mSRX
- nur Gebaut und eingeflogen: Blade700, Goblin500, TRex150 RKH, Blade 130X RKH, Vibe90
- Heizkoffersteuerung "HeatBox"
[" 99 little bugs in the code | 99 little bugs in the code | Take one down, patch it around | 117 little bugs in the code "] - Alex Shchepetilnikov
-
- Beiträge: 40
- Registriert: 06.05.2012 11:25:41
#19 Re: objektorientierung, uml und solche späße
ich dachte so : nick und roll sind "mandatory", gier und höhe "optional" (gps sowieso).
- the-fallen
- Beiträge: 1976
- Registriert: 07.03.2011 14:20:47
- Wohnort: zwischen Augsburg und Landsberg a.L.
#20 Re: objektorientierung, uml und solche späße
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:
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


Ich hät's so gezeichnet (und hoffentlich nicht selber Fehler reingebracht):
Falls du Violet-Dateien nutzen kannst und mein UML verwenden möchtest:
- Prôtos FBL -stretched- a un motor 5+4D 1.13mm 14P de torro [V-Stabi]|[V-Gov] | [YGE90LV] | [UweG-Taumelscheibe] | [ZyclicMod]
- SuziJanis 700 UltraLight 3570g Abfluggewicht
- Besessen: T-Rex 250SE, T-Rex 450L, T-Rex600EFL, TDR, Blade mSRX
- nur Gebaut und eingeflogen: Blade700, Goblin500, TRex150 RKH, Blade 130X RKH, Vibe90
- Heizkoffersteuerung "HeatBox"
[" 99 little bugs in the code | 99 little bugs in the code | Take one down, patch it around | 117 little bugs in the code "] - Alex Shchepetilnikov
-
- Beiträge: 40
- Registriert: 06.05.2012 11:25:41
#21 Re: objektorientierung, uml und solche späße
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
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
Zuletzt geändert von dollreiner am 20.06.2013 11:38:00, insgesamt 1-mal geändert.
- the-fallen
- Beiträge: 1976
- Registriert: 07.03.2011 14:20:47
- Wohnort: zwischen Augsburg und Landsberg a.L.
#22 Re: objektorientierung, uml und solche späße
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.
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.
- Prôtos FBL -stretched- a un motor 5+4D 1.13mm 14P de torro [V-Stabi]|[V-Gov] | [YGE90LV] | [UweG-Taumelscheibe] | [ZyclicMod]
- SuziJanis 700 UltraLight 3570g Abfluggewicht
- Besessen: T-Rex 250SE, T-Rex 450L, T-Rex600EFL, TDR, Blade mSRX
- nur Gebaut und eingeflogen: Blade700, Goblin500, TRex150 RKH, Blade 130X RKH, Vibe90
- Heizkoffersteuerung "HeatBox"
[" 99 little bugs in the code | 99 little bugs in the code | Take one down, patch it around | 117 little bugs in the code "] - Alex Shchepetilnikov
-
- Beiträge: 40
- Registriert: 06.05.2012 11:25:41
#23 Re: objektorientierung, uml und solche späße
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
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
- the-fallen
- Beiträge: 1976
- Registriert: 07.03.2011 14:20:47
- Wohnort: zwischen Augsburg und Landsberg a.L.
#24 Re: objektorientierung, uml und solche späße
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).
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).
- Prôtos FBL -stretched- a un motor 5+4D 1.13mm 14P de torro [V-Stabi]|[V-Gov] | [YGE90LV] | [UweG-Taumelscheibe] | [ZyclicMod]
- SuziJanis 700 UltraLight 3570g Abfluggewicht
- Besessen: T-Rex 250SE, T-Rex 450L, T-Rex600EFL, TDR, Blade mSRX
- nur Gebaut und eingeflogen: Blade700, Goblin500, TRex150 RKH, Blade 130X RKH, Vibe90
- Heizkoffersteuerung "HeatBox"
[" 99 little bugs in the code | 99 little bugs in the code | Take one down, patch it around | 117 little bugs in the code "] - Alex Shchepetilnikov
#25 Re: objektorientierung, uml und solche späße
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
Geht es bei euch nur um das optische Diagramm oben, ob die Pfeile richtig sind, oder tut ihr auch programmieren????????

Alf-1234
Gruss
Alf-1234
Alf-1234
-
- Beiträge: 40
- Registriert: 06.05.2012 11:25:41
#26 Re: objektorientierung, uml und solche späße
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.
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.
- the-fallen
- Beiträge: 1976
- Registriert: 07.03.2011 14:20:47
- Wohnort: zwischen Augsburg und Landsberg a.L.
#27 Re: objektorientierung, uml und solche späße
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.

Luna kenne ich nicht, aber vielleicht hab ich mal Langeweile und schau mir das an.
Hast auf jeden Fall noch viel vor.
- Prôtos FBL -stretched- a un motor 5+4D 1.13mm 14P de torro [V-Stabi]|[V-Gov] | [YGE90LV] | [UweG-Taumelscheibe] | [ZyclicMod]
- SuziJanis 700 UltraLight 3570g Abfluggewicht
- Besessen: T-Rex 250SE, T-Rex 450L, T-Rex600EFL, TDR, Blade mSRX
- nur Gebaut und eingeflogen: Blade700, Goblin500, TRex150 RKH, Blade 130X RKH, Vibe90
- Heizkoffersteuerung "HeatBox"
[" 99 little bugs in the code | 99 little bugs in the code | Take one down, patch it around | 117 little bugs in the code "] - Alex Shchepetilnikov
-
- Beiträge: 40
- Registriert: 06.05.2012 11:25:41
#28 Re: objektorientierung, uml und solche späße
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 ?
Code: Alles auswählen
//programm-hauptschleife
do
set nick als new pid
nick.kp = 3
nick.kd = 2
nick.istwert = messung_nick_gyro
nick.regelschritt()
sollwert_nick = nick.sollwert
loop
..
..
class pid
public kp,kd,ki as byte
public istwert,sollwert as integer
procedure regelschritt
...
endproc
endclass
- the-fallen
- Beiträge: 1976
- Registriert: 07.03.2011 14:20:47
- Wohnort: zwischen Augsburg und Landsberg a.L.
#29 Re: objektorientierung, uml und solche späße
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
(Hoffe man erkennt was)
Natürlich davon ausgehend, dass das alles einzelne Klassen sind - sonst wäre das Klassendiagramm unnötig

- Prôtos FBL -stretched- a un motor 5+4D 1.13mm 14P de torro [V-Stabi]|[V-Gov] | [YGE90LV] | [UweG-Taumelscheibe] | [ZyclicMod]
- SuziJanis 700 UltraLight 3570g Abfluggewicht
- Besessen: T-Rex 250SE, T-Rex 450L, T-Rex600EFL, TDR, Blade mSRX
- nur Gebaut und eingeflogen: Blade700, Goblin500, TRex150 RKH, Blade 130X RKH, Vibe90
- Heizkoffersteuerung "HeatBox"
[" 99 little bugs in the code | 99 little bugs in the code | Take one down, patch it around | 117 little bugs in the code "] - Alex Shchepetilnikov
- tracer
- Operator
- Beiträge: 63804
- Registriert: 18.08.2004 18:50:03
- Wohnort: Kollmar
- Has thanked: 2 times
- Been thanked: 2 times
- Kontaktdaten:
#30 Re: objektorientierung, uml und solche späße
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.
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.