Designfrage: Motor _hat_ Motorkomponenten

KeineAhnung78

Vielen Dank!!!

Ich werde über eine Verbindungsklasse nachdenken und mir boost::signals ansehen.

Leider wird es je nach Motortyp unterschiedliche Algorithmen und auch unterschiedliche notwendige Verbindungen geben. Daher muss die Struktur sehr allgemein sein. Ich kann nicht sagen, dass immer der Rotor auf den Stator zugreifen muss. Evtl. braucht der Rotor bei einem anderen Motor nun Parameter des Motorgehäuses...

Werden hier auch Motorenkenntnisse benötigt?
Das sieht bisher nach einem E-Motor aus.

MfG f.-th.

SeppJ

KeineAhnung78 schrieb:

Leider wird es je nach Motortyp unterschiedliche Algorithmen und auch unterschiedliche notwendige Verbindungen geben. Daher muss die Struktur sehr allgemein sein. Ich kann nicht sagen, dass immer der Rotor auf den Stator zugreifen muss. Evtl. braucht der Rotor bei einem anderen Motor nun Parameter des Motorgehäuses...

Du könntest ein Strategy-Pattern zur Konstruktion des Motors benutzen. Das entspräche denn im wirklichen Leben dem Ingenieur der den Motor plant.

KeineAhnung78

f.-th. schrieb:

Werden hier auch Motorenkenntnisse benötigt?
Das sieht bisher nach einem E-Motor aus.

MfG f.-th.

Ja, es geht um E-Motoren. Dennoch verstehe ich die Frage nicht ganz!?

Werner Salomon

KeineAhnung78 schrieb:

Es gibt eine Klasse Motor (davon abeleitet verschiedene Arten von speziellen Motoren) und eine Klasse Motorkomponente (z. B. Stator, Rotor, Welle, ...).

Ein Motor habe nun eine Liste von Motorkomponenten. Jede Motorkomponente soll wissen, zu welchem Motor sie gehört.

wie SeppJ bin ich der Meinung, dass das ein Designfehler wäre, da Du zyklische Referenzen in Deinen Entwurf bekommst, die sich i.A. störend auswirken.

Welche Zweck soll Deine fertige Applikation am Ende haben? Es ist ein Riesenunterschied, ob Du an einer (Motor-)Steuerung oder an einer (Motor-)Simulation oder einem Artikelverwaltungsprogramm für Motorteile arbeitest. Die dazugehörigen Entwürfe sind dann ziemlich unterschiedlich.

Wie läuft das Programm ab? Was ist der Input und was soll am Ende ausgegeben werden?

Warum nicht einen Motor mit Stator, Rotor und Welle als Member? Und der Motor schaltet dann die notwendigen Verbindungen zwischen den einzelnen Objekte; wobei diese ja noch mit Interfaces versehen werden können, falls es verschiedenen Typen von Motorkomponenten gibt.

Eine Kernfrage ist noch: wozu dient Motorkomponente? Ist dies nur ein Griff zum Anfassen (und Wegwerfen) der Objekte, oder hat Motorkomponentenoch irgendeine 'Motoreigene' Methode?

Gruß
Werner

KeineAhnung78

Wernen, vielen Dank für deine konkreten Fragen.

Werner Salomon schrieb:

Welche Zweck soll Deine fertige Applikation am Ende haben? Es ist ein Riesenunterschied, ob Du an einer (Motor-)Steuerung oder an einer (Motor-)Simulation oder einem Artikelverwaltungsprogramm für Motorteile arbeitest. Die dazugehörigen Entwürfe sind dann ziemlich unterschiedlich.

Motorauslegung

Werner Salomon schrieb:

Wie läuft das Programm ab? Was ist der Input und was soll am Ende ausgegeben werden?

Input sind verschiedene Textdateien (ini-Stil), die aber je nach Motor einen abweichenden Aufbau haben. Ausgegeben werden (zunächst auf Kommandozeile) die elektrischen Daten verschiedener Betriebspunkte. Die Eigenschaften des Motors werden also durch charakteristische Größen beschrieben.

Werner Salomon schrieb:

Warum nicht einen Motor mit Stator, Rotor und Welle als Member? Und der Motor schaltet dann die notwendigen Verbindungen zwischen den einzelnen Objekte; wobei diese ja noch mit Interfaces versehen werden können, falls es verschiedenen Typen von Motorkomponenten gibt.

Hab ich sogar so gemacht, nur hier aus Schreibfaulheit die Liste eingefügt . Motor hat im Moment die Komponenten: Stator, Rotor, Gehäuse, Welle und Luftspalt. Wobei vielleicht besser Rotor und Welle durch ein _hat_ein_ verbunden werden könnten und ebenso Stator _hat_ein_ Gehäuse.

Werner Salomon schrieb:

Eine Kernfrage ist noch: wozu dient Motorkomponente? Ist dies nur ein Griff zum Anfassen (und Wegwerfen) der Objekte, oder hat Motorkomponentenoch irgendeine 'Motoreigene' Methode?

Im Konstruktor möchte ich alle erforderlichen Daten (Abmessungen etc.) aus den ini-Datei in Membervariablen abspeichern und daraus weitere Kenndaten in Memberfunktionen berechnen, die sich unmittelbar aus den Inputdaten ergeben. Beispiel: Die Abmessungen einer Nut stehen in der Inputdatei und die Fläche dazu wird ausgerechnet.

Shade Of Mine

Ich sehe in dem Zeiger jeder Komponente auf den Motor selbst absolut kein Problem.

Die reale Welt muss nicht immer 1:1 abgebildet werden, es geht viel mehr darum die Aufgabenstellung zu modellieren. Daher sollten wir uns nicht über eine Werkstatt und das Ausbauen von Motoren unterhalten sondern über die Aufgabenstellung.

Denn vielleicht sind die Parent-Pointer genau das was notwendig ist. uU ist hier eine Baumansicht sinnvoller als eine flache Liste? Das alles entscheidet die Aufgabenstellung...

dot

Ich würde hier mal den Builder Pattern vorschlagen. Und wenn du mich fragst hat wohl weder der Rotor einen Stator noch der Stator einen Rotor. Ich würde mal sagen ein Motor besteht aus einem Stator und einem Rotor...

KeineAhnung78

Shade Of Mine schrieb:

Denn vielleicht sind die Parent-Pointer genau das was notwendig ist. uU ist hier eine Baumansicht sinnvoller als eine flache Liste? Das alles entscheidet die Aufgabenstellung...

Ich könnte mir folgendes vorstellen:

Stator, Rotor und Luftspalt kennen ihren Motor.

Die Welle als Bestandteil des Rotors kennt zunächst nur den Rotor (und über diesen dann auch den Motor).

usw...entpsprechend für die vielen anderen Komponenten.

Werner Salomon

Ok - 'Motorauslegeung' und der Input für den Motor kommt aus einer Textdatei, die aber anscheinend schon den fertigen Motor und nicht die Anforderungen an den Motor beschreibt.

Ist es richtig, dass das Programm dann ausschließlich die Eigenschaften (elektr. Daten an Betriebspunkten etc.) berechnet, und die eigentliche Auslegung dann extern (ggf. durch den Bediener) geschieht?

Wenn es so ist, dann hast Du sicher einen (oder mehrere) Algorithmen, die Daten aus den verschieden Komponenten sammeln und daraus die gewünschten Ergebnisse bestimmen.

Mal angenommen, da sind mehrere Motortyen und zu jedem Typ gibt es genau einen Algorithmus. Dann erfordert dieser Algorithmus bestimmte Information von jeder einzelnen Motorkomponente.
Wäre dann folgender Ablauf sinnvoll? Motor wird aus ini-Datei geladen - in Abhängigkeit des Inhalts der ini-Datei können unterschiedliche Klassen instanziiert werden (egal ob Motor oder dessen Komponenten). Der Motor legt ggf. noch Verbindungen zw. den Komponenten. Jede Komponente hat ein Interface über das der Algo zugreift.

.. so ich brauche erstmal Dein 'so isses' - bevor ich weiter spinne

Gruß
Werner

Werner Salomon

KeineAhnung78 schrieb:

Ich könnte mir folgendes vorstellen:

Stator, Rotor und Luftspalt kennen ihren Motor.

Die Welle als Bestandteil des Rotors kennt zunächst nur den Rotor (und über diesen dann auch den Motor).

usw...entpsprechend für die vielen anderen Komponenten.

.. nein tu's nicht. ich habe selber vor Jahren auch mal so angefangen. Das ist voll in die Hose gegangen. Ich habe es anschließend das 'Papa-Pattern' genannt - aufzunehmen in die Gruppe der Antipattern.

Das, was Du da vorschlägst, klappt nur, wenn der Motor seine Komponenten nicht kennt!

KeineAhnung78

Werner Salomon schrieb:

Mal angenommen, da sind mehrere Motortyen und zu jedem Typ gibt es genau einen Algorithmus. Dann erfordert dieser Algorithmus bestimmte Information von jeder einzelnen Motorkomponente.
Wäre dann folgender Ablauf sinnvoll? Motor wird aus ini-Datei geladen - in Abhängigkeit des Inhalts der ini-Datei können unterschiedliche Klassen instanziiert werden (egal ob Motor oder dessen Komponenten). Der Motor legt ggf. noch Verbindungen zw. den Komponenten. Jede Komponente hat ein Interface über das der Algo zugreift.

So isses :D.

Je nach Motortyp gibt es eine Instanz einer von Motor abgeleiteten Klasse. Diese Klasse konstruiert alle benötigten Komponenten.

Daneben gibt der Anwender (ebenfalls durch ini-Datei) vor, welche Berechnungen durchgeführt werden sollen.

Dazu gibt es dann eine Klasse Berechnung, die diese Informationen verwaltet.

Berechnung hält einen Zeiger auf den Motor. Soll bsp.weise ein Leerlauf berechnet werden, ruft Berechnung dann die entsprechende Leerlauffunktion der abgeleiteten Motorklasse auf (virtuelle Funktion).

Und die Leerlauffunktion greift auf alle Daten der Motorkomponenten zu.

volkard

KeineAhnung78 schrieb:

Dazu gibt es dann eine Klasse Berechnung, die diese Informationen verwaltet.

Nö. Berchnung ist eine Funktion.

Werner Salomon

KeineAhnung78 schrieb:

Je nach Motortyp gibt es eine Instanz einer von Motor abgeleiteten Klasse. Diese Klasse konstruiert alle benötigten Komponenten.

Daneben gibt der Anwender (ebenfalls durch ini-Datei) vor, welche Berechnungen durchgeführt werden sollen.

jetzt müßte man noch wissen, ob jede Berechnung auf jeden Motortyp angewendet werden kann? - wenn ja, wird es einfacher, weil man dann nur einen einzigen Satz von Interfaces benötigt, mit dem eine Berechnung auf Motor & Co zugreift.

dot

Nur mal so eine Frage: Für was sind in dem Szenario eigentlich die Komponenten gut!?

Shade Of Mine

KeineAhnung78 schrieb:

Shade Of Mine schrieb:

Denn vielleicht sind die Parent-Pointer genau das was notwendig ist. uU ist hier eine Baumansicht sinnvoller als eine flache Liste? Das alles entscheidet die Aufgabenstellung...

Ich könnte mir folgendes vorstellen:

Stator, Rotor und Luftspalt kennen ihren Motor.

Die Welle als Bestandteil des Rotors kennt zunächst nur den Rotor (und über diesen dann auch den Motor).

usw...entpsprechend für die vielen anderen Komponenten.

Das meine ich.
Das ist der komplett falsche Ansatz. Du sollst immer die Aufgabenstellung modellieren, nie die reale Welt.

Deshalb nochmal: WAS willst du machen. Nicht WIE oder WOMIT, sondern WAS.

Werner Salomon

KeineAhnung78 schrieb:

Berechnung hält einen Zeiger auf den Motor. Soll bsp.weise ein Leerlauf berechnet werden, ruft Berechnung dann die entsprechende Leerlauffunktion der abgeleiteten Motorklasse auf (virtuelle Funktion).

Und die Leerlauffunktion greift auf alle Daten der Motorkomponenten zu.

.. das würde bedeuten, dass sich zumindest Teile des Algorithmus innerhalb des Motors oder seiner Komponenten befinden. OO-technisch ist das ok .. es kann aber auch ok sein,in diesem Fall Algorithmus und Entität (Motor & Co) völlig zu trennen.

Schau Dir doch mal das Visitor-Pattern an. Tasuche in dem (Java)Beispiel im Wiki mal Car durch Motor und Visitor durch Algo_Basis aus. Trifft das dann Deine Anforderungen?

volkard schrieb:

KeineAhnung78 schrieb:

Dazu gibt es dann eine Klasse Berechnung, die diese Informationen verwaltet.

Nö. Berchnung ist eine Funktion.

Stimmt - wenn man hier eine Berechnungs-Hierachie einsetzt, braucht man wieder die Klassen und würde diese dann als Funktoren bezeichnen

KeineAhnung78

Werner Salomon schrieb:

jetzt müßte man noch wissen, ob jede Berechnung auf jeden Motortyp angewendet werden kann? - wenn ja, wird es einfacher, weil man dann nur einen einzigen Satz von Interfaces benötigt, mit dem eine Berechnung auf Motor & Co zugreift.

volkard schrieb:

Nö. Berchnung ist eine Funktion.

OK, also gerne noch mehr Details

Die Klasse Berechnung enthält eine Liste von Einzelberechnungen. Dies ist erforderlich, da jede Einzelberechnung unterschiedliche Szenarien verwirklicht: z. B. unterschiedliche Speisespannung. Jede Einzelberechnung wiederum hat eine Liste von Betriebspunkten, denn die Anzahl und Art der Betriebspunkte ist leider auch motorabhängig (Eine Synchronmaschine hat keinen Schlupf, eine Gleichstrommaschine keinen Kipppunkt,...). Zu jeder Einzelrechnung gehört auch noch eine Instanz der Klasse Umgebung, in der Temperaturen usw. abgelegt sind.

Nehmen wir an, ich habe eine Asynchronmaschine und der Anwender will Leerläufe bei verschiedenen Spannungen:

Berechnung* b= new Berechnung();

//Parameter der Einzelrechnungen weggelassen
b->fuege_einzelrechnung_hinzu(new Einzelrechnung()); 
b->fuege_einzelrechnung_hinzu(new Einzelrechnung());
b->fuege_einzelrechnung_hinzu(new Einzelrechnung());

Die Berechnung wird aus der main angestoßen. Eine Schleife über alle Einzelrechnungen ruft jeweils die Methode leerlauf auf, wobei der Algorithmus des Leerlauf in der Motorklasse steckt, da dort dann auf alle Komponenten zugegriffen werden kann.

dot

Warum nicht einfach so:

void SynchronousMotor(Config& configuration)
{
  ...
  BreakoverPoint(stuff);
  ...
}

KeineAhnung78

Shade Of Mine schrieb:

KeineAhnung78 schrieb:

Ich könnte mir folgendes vorstellen:

Stator, Rotor und Luftspalt kennen ihren Motor.

Die Welle als Bestandteil des Rotors kennt zunächst nur den Rotor (und über diesen dann auch den Motor).

usw...entpsprechend für die vielen anderen Komponenten.

Das meine ich.
Das ist der komplett falsche Ansatz. Du sollst immer die Aufgabenstellung modellieren, nie die reale Welt.

Es mag ineffizient oder was auch immer sein, aber wieso es jetzt falsch wäre, erschließt sich mir nicht . Ich find´s stimmiger als pauschal jeder Komponente einen Zeiger auf den Motor mitzugeben.

Shade Of Mine schrieb:

Deshalb nochmal: WAS willst du machen. Nicht WIE oder WOMIT, sondern WAS.

* Programm zur Motorauslegung
* Anwender gibt Art des Motors und Betriebsbedingungen (Temperatur, Kühlbedingungen,...) vor
* Programm berechnet Motorcharakteristik und Anwender kann prüfen, ob Motor für die Anwendung geeignet ist.
* IO über ini-Dateien, Kommandozeilenprogramm
* Motor besteht aus vielen Einzelkomponenten, die durch geometrische, elektrische, mechanische Daten beschrieben werden. Aus den Daten werden weitere Eigenschaften unabhängig von der späteren Rechnung abgeleitet (Bsp. Kreisradius wird eingegeben, Kreisfläche wird berechnet ist als Eigenschaft des Objekts abrufbar
* Es gibt nicht _die_ _eine_ Berechnung. Die Vielfalt ist sehr groß: verschiedene Umgebungsbedingungen, verschiedene Spannungen, verschiedene Betriebspunkte, Leistungsreduzierungen des Motors,...