Layer, Rekursion und Hierarchien ...

Wir nehmen gerne Ihre Ideen, Vorschläge, Meinungen entgegen. (Beiträge werden von uns gelesen, aber nicht beantwortet.)
Antworten
79616363
Beiträge: 1
Registriert: Sonntag 11. März 2012, 09:01
Wohnort: Leinfelden-Echterdingen

Layer, Rekursion und Hierarchien ...

Beitrag von 79616363 » Sonntag 18. März 2012, 23:00

Hallo,

kurz vorab, bevor das zu sehr nach einem Verriss aussieht:

Seit SPlan 6.x benutze ich sPlan begeistert um nicht zu heftige Schaltungen zu skizzieren.
Das ist der eigentliche Anspruch des Programms gewesen und dem wird es mehr als gerecht.

Hier ein großes Lob:

Einfacher geht's kaum!

Seit Kurzem benutze ich sPlan auch um Leitungsplanungen vorzunehmen. Für eine grafische Darstellung war auch sPlan 6.x dafür geeignet.
Die Auswertung der sPlan-Daten wird derzeit über ein VBA-Modul (Excel) vorgenommen.

Lästig war allerdings, dass die Exportmöglichkeiten der sPlan- Daten doch recht eingeschränkt sind.
Außer Bauteilbezeichnungen, Anzahl und Wert und so konnte ja nicht viel exportiert werden.

Da war es ja schon ein ziemliches (händisches und fehleranfälliges) Gefummel und Getrickse, dass man alle zu erfassenden Daten als *.CSV für eine weitere rechnerische Auswertung exportieren konnte.
Vieles musste sogar händisch in die exportierte Tabelle übertragen werden - Fehleranfällig und nicht gerade bequem! Die Kundensichtweise bzw. die Entwurfsansicht können nicht umgeschaltet werden!

Ganz klar, seit sPlan 7.0 ist einiges deutlich besser geworden.
  • Immerhin gibt es nun eine Parent/Child Beziehung, die einiges vereinfachen könnte - Leider ein nicht konsequent umgesetzter Ansatz.
    Warum zum Teufel kann kann ein Child nicht gleichzeitig als Parent agieren und weitere Childs haben? Wo ist hier die hierarchische Struktur?
  • Warum verliert ein Child wichtige Eigenschaften, wenn man den Parent löscht? Warum bleiben die Eigenschaften vom Grundsatz her nicht erhalten, bis das Child ein neues Mündel bekommt und dessen vererbte Eigenschaften erhält? Warum gibt es kein übergeordnetes universelles Objekt, das alle verwaisten Kinder kurzzeitig aufnehmen kann - Die ererbten Eigenschaften des verwaisten Child werden derzeit halt auf "N/A" oder so gesetzt.
  • Angenehm ist auch, dass sPlan 7.0 nun Maßstäbe kennt und sogar die tatsächliche Länge eines Linienzug angeben kann - Dumm halt, dass der Linienzug geschlossen sein muss und die Längenangabe nur rein informell und nicht intern verfügbar ist.

    Weiterhin ist es zwar möglich geschlossene Linienzüge zu trennen und auch die Möglichkeit Knoten hinzuzufügen oder zu trennen - Leider fehlt die Möglichkeit Linienzusammenhänge später wieder herzustellen :-(
  • Dass sPlan nicht rechnen kann, ist jetzt nicht so wild - Wobei das oft hilfreich wäre.

    Aber selbst mit der möglichen String-Konkatenation stößt man schnell an seine Grenzen, denn es können nur 1:1 Abbildungen dargestellt werden.
    D.h. [Name]=[Wert].
    Grundsätzlich gibt es auch nur einen globalen Namespace - Schlecht! - Damit lässt sich nichts übersichtlich darstellen.

    Allerdings ist es jetzt auch nicht sooo schwierig, hier nen kleinen Parser zu integrieren, der die Vorlage liefert um selbst rechnen zu können. Es wird ja wohl nicht sooo schwierig sein, um so etwas erst mal als Variant zu betrachten und dann zu entscheiden, ob eine Umrechnung in eine Zahl möglich ist - Das Rechnen selbst ist dann reine Formsache
  • Bei komplexeren Anwendungen und dem derzeitigen Handling ist man schnell mit einem Wust von globalen Variablen überschüttet, wo man sich schon ganz genaue Namenskonventionen überlegen muss, dass man keine Konflikte bekommt - Von Anwenderfreundlichkeit, Übersichtlichkeit, Fehleranfälligkeit u.Ä. sehen wir mal komplett ab ...
  • Mag sein, dass ich mit der folgenden Kritik einfach etwas zu blöd war das hinzukriegen, aber dennoch stellt sich mir die Frage.

    Weshalb ist es nicht möglich Pfade zu Bauteilebibliotheken relativ anzugeben?
    Wenn sich z.B. die Projektdatei im Pfad D:\e1\f1\g1 befindet, warum kann ich dann für dieses Projekt nicht angeben, dass sich die zugehörige Bibliothek im Pfad ..\..\mylib befindet?
    Warum muss hier der absolute Pfad D:\e1\mylib angegeben werden?
    Nicht gerade prickelnd, wenn man die Datei zur Zusammenarbeit an andere Mitarbeiter weitergeben will, die ne andere Dateistruktur haben.
    Zumindest im weitergegebenen Teilbaum sollte das konsistent bleiben um das Projekt als Teilbaum weitergeben zu können.
Ganz klar, in der angedachten Struktur können zyklische Beziehungen entstehen - Allerdings ist es nicht weiter schwer rechnerisch Zyklen in Graphen zu entdecken und sofort zu monieren.
  • Ich schließe mich dem bereits genannten Wunsch an, dass sPlan mehrere Layer beherrschen sollte. Bei reinen Schaltplänen ist das nicht so dramatisch, aber spätestens wenn man in ner Projektplanung auf die Machenschaften anderer Gewerke Rücksicht nehmen soll, dann ist es schon sinnvoll die ein- bzw. ausblenden zu können.
    Ja iss klar, das ist und war nie die Intention von sPlan ...
    • Genug geschimpft und schimpfen wollte ich eigentlich gar nicht - Im Gegenteil, den selbst gesetzten Anspruch (Schaltpläne malen[\b]) erfüllt sPlan 7.0 allemal.
      Allerdings schubst sPlan 7 mit seinen neuen Möglichkeiten schon etwas die Türe auf, um auch viel weiter gehende Aufgaben erledigen zu können.

      Hier sollte man fast schon überlegen, ob es sich dabei nicht schon um ein neues Produkt handelt. Z.B. "sPlan 8.0 professional" oder ePlan x.y.

      Kritik ist fast nichts wert, wenn sie nicht konstruktiv ist. Ganz offensichtlich fehlt es sPlan am objektorientiertem Aufbau - Man kann z.B. auch in reinem ANSI-C objektorientiert arbeiten! Dazu braucht man nur Structs!

      Grundsätze:

      • Alles ist ein Objekt bzw. eine Klasse - Auch ein Linienzug, ein Rechteck oder sonst was!

      • Jede Instanz einer Klasse (Objekt) hat Eigenschaften und Methoden, auf die ein Child innerhalb des Entwicklungsbaums zugreifen kann.
        Speziell darf sich die Entwicklungsfähigkeit einer Ausprägung nur eine Fortpflanzung erlauben und die Childs unfruchtbar in die Welt setzen - Wir sind nicht mal ansatzweise in "Jurassic Park"!
      .
      • Jedes Objekt hat grundsätzlich die Eigenschaft mögliche Childs zu haben.
        Dabei kann aber ein Elefant natürlich keinen Affen zeugen - Alles nach Möglichkeit der Tierart.

        Allerdings kann z.B. ein eine Verteilerdose (im weitesten Sinn) eine Zuleitung haben (Baumstruktur!).
        Verrückterweise geht es hier zu wie im wahren Leben eines Vaters. Zuerst sind versehentlich die Kinder da und die werden dann von Gerichtswegen dem Vorfahren zugeordnet ;-) - Und zwar über mehrere Ebenen. Wenn der Affe den Elefanten als Child zugeordnet bekommen soll, dann wird natürlich gemeckert! ;-)

        • Ob die Eigenschaften/Property eines Objekts als echte Eigenschaften oder Methoden vererbt werden, muss im Einzelfall entschieden werden (erwartete Zugriffshäufigkeit vs. Rechenaufwand der Methode).

        • Ein Objekt muss die Eigenschaft "visible/invisible" haben". Auf unsichtbar gemachte Objekte wird über eine Art Project-Explorer zugegriffen.

        • Wenn man's nicht anders machen will, dann kann man über unsichtbare Objekte jedem Parent-Objekt benutzerdefinierte Eigenschaften zuweisen ...


Mir fällt garantiert noch mehr ein, aber dazu sag ich nur was auf Nachfrage. Die Idee von sPlan ist aber hervorragend und das Erscheinungsbild/Handling auch.
Allerdings sollte es innerlich aufgewertet werden.

Sicher ist ihr eigenes Entwicklungsteam mit der Weiterentwicklung bereits beauftragt, aber notfalls muss ich nebenher ne eigene und im Alleingang sehr zeitaufwendig zu erstellende Software basteln - Die wird dann aber als Beerware oder Shareware (not crippled) "verhökert".
Das soll keine Drohung sein, im Gegenteil - Ich wäre wirklich froh, wenn ihr Entwicklungsteam das übernehmen würde.

Ich weiß ja nicht, wie sPlan verwirklicht ist (in welcher Sprache?). Ich bin halt der C/C++/ADA - Freak. Macht aber nix, zumindest die Konzeption ist allen Sprachen gemein und da kann man zumindest Vorschläge machen - Auch wenn man nicht zuhause ist.

Gut, mit der Abwärtskompatibilität könnte es leichte Probleme geben, weil die neuen Dateien ja einige weitere Informationen tragen müssen.
So schlimm find ich das jetzt aber auch nicht, denn es ist ja kein Hexenwerk alte sPlan-Dateien zu lesen, zu verstehen und (natürlich ohne die neu hinzugekommenen Attribute) zu importieren.

Ich hab das Dateiformat jetzt bis jetzt noch nicht soweit analysiert, dass ich definitive Aussagen machen könnte - Das wäre derzeit einfach nicht problemorientiert.
Allerdings könnt ich mir vorstellen, dass man die Zusatzinfos so wrappen könnte, dass sie auch von obsoleten Versionen verstanden werden - Sofern sie Fragmente verstehen - Oder halt ganz anders - Mal gucken ...

Na ja, sPlan 6.x kapiert ja *.SPL7-Dateien auch nicht und wirft beim Versuch gelegentlich/meist nen suspekten "Floating-Point-Errror" - lustisch :lol:
Rechnen scheint eh nicht so das Ding von sPlan zu sein ...

Warum macht man das eigentlich nicht so, dass die Dateien im Klartext/XML-Style gespeichert werden? Warum werden da feste Feldgrößen von binären Daten abgespeichert?
Ja ja, es gibt auch reine Binärdaten - Aber gibt es nicht auch Base-64-Blocks?

Wenn ein Tag irgendeiner Version halt der ladenden Version unbekannt ist, dann wird das halt ignoriert.

Okay, kostet mehr Platz zum Speichern, aber das ist heutzutage (wo wir über TByte reden) nicht mehr das Problem!
Gut okay, wenn man Platz schon sparen will, dann haut man halt ein GZIP-Modul als Wrapper drüber - Ganz so klein (wie bei der binären Methode - (Entropie) wird's nicht, aber für heutige Verhältnisse klein genug.
Wir sind hier schließlich nicht in nem Satelliten, wo ein µC die Rechenleistung eines "Deep Thought" aufbringen muss!

Na ja, der Anspruch, dass das auch noch auf nem P1 laufen soll, kann ja wohl auch in die Tonne getreten werden - Und das sag ich als erklärter notorischer Extrem-Minimalist, Byte-Zähler, Komplexitäts- und µs-Jäger!

Außerdem würd eine Klartextausgabe eine Weiterverarbeitung der gesammelten Daten von externen Programmen wesentlich erleichtern!

Über z.B. einen *.CSV Reimport von externen Daten fang ich jetzt lieber nicht an.
Über echte Makrofähigkeit (in der Art von VBA) lieber auch nicht ...
Ist aber alles möglich!

Wie gesagt, es war alles nicht bös gemeint und soll nur als Vorschlag dienen.
sPlan erledigt alles zur Zufriedenheit, was es ursprünglich in der Urversion sollte - Allerdings steckt in der Idee das Potential für "mehr" - Und da sollte man dran bleiben - Selbst wenn daraus ein neues Produkt wird!

Tut mir leid, wenn das vielleicht etwas viel Kritik war ... Irgendwie haben wir hier mit mit gewachsenen Strukturen zu tun, die mal überdacht werden sollten ...
Muss ja nicht alles in die Tonne, aber der Kern braucht ne Runderneuerung ...

Viele Grüße,

Uli und das Rattenpack

Antworten

Zurück zu „Thema: Anregungen zu sPlan“