-
        

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 17

Thema: Pilotprojekt für UML basierende Entwicklung gesucht.

  1. #1
    Neuer Benutzer Öfters hier
    Registriert seit
    11.12.2009
    Ort
    Darmstadt
    Alter
    55
    Beiträge
    22

    Pilotprojekt für UML basierende Entwicklung gesucht.

    Anzeige

    Hallo,

    Wie bereits in diesem Beitrag beschrieben,

    http://www.roboternetz.de/phpBB2/viewtopic.php?t=51541

    bin ich Entwickler in einem Projekt zur Model basierenden Software Entwicklung ( http://astade.de ).

    Software mit Hilfe von Zustandsautomaten zu entwerfen bringt viele Vorteile. Aber um das nicht nur zu behaupten, sondern auch zu beweisen, habe ich zunächst Astade um einen weiteren Zustandsautomaten Kodierer und ein Framework erweitert, dass speziell für kleinere Systeme ohne Betriebssystem gedacht ist.

    Jetzt Suche ich ein Projekt, bei dem man die Leistungsfähigkeit des ganzen zeigen kann. Es sollte schon komplizierter als ein "Blinklicht" sein, weil es schon ein bisschen kompliziert sein muss, sonst kann man den Nutzen nicht sehen.

    Es sollte aber nicht zu Umfangreich sein, weil ich die Entwicklung gerne auf einer Website dokumentieren möchte, um gewissermaßen eine Anleitung zur Benutzung von Astade für die Mikrocontroller Programmierung zu bekommen.

    Ich Suche jemanden (oder mehrere), die mit mir gemeinsam die Software entwickeln und die Erfahrungen aufschreiben. Dabei will ich gerne den größeren Teil der Dokumentation und auch der Softwareentwicklung übernehmen.

    Wozu ich aber jemanden Brauche ist:
    1. Wir müssen eine typische Programmieraufgabe definieren und auf einem echten System umsetzen. Da ich eigentlich ein Programmierwerkzeug machen möchte (Astade) und selbst keine Ambitionen einen "Staubsauger" oder "Rasenmäher" zu bauen, brauche ich jemanden, der das Problem definiert und auch an der Lösung interessiert ist. Jemand der aus diesem Grund auch bereits eine Hardware besitzt und die Qualität der Lösung beurteilen kann. (Die Software wird dann in "C" entwickelt)

    2. Jemanden der bereit ist, diese neue Technik auszuprobieren und ausgetretene Wege zu verlassen, auch wenn das Tool für diese Aufgabe noch nicht komplett fertig ist. Der Astade auch selbst auf seinem Rechner installiert und sich mit mir zusammen auf ein Experiment einlässt.

    Was ich bieten kann:
    1. Hilfe bei der Umsetzung des Projekts. Ich bin bereit wesentliche Teile der Software zu schreiben und zu testen.

    2. Die Aussicht, eine neue Programmiertechnik und ein neues Tool kennen zu lernen, zusammen mit dem Versprechen, dass Model basierende Software Entwicklung viele Vorteile bringt.

    Hat jemand Lust dieses Projekt mit mir zu machen?

  2. #2
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    28.09.2009
    Beiträge
    170
    Ich wäre dabei. Meld Dich einfach mal per PM...

  3. #3
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    33
    Beiträge
    2.380
    als aufgabe würde es doch quasi schon reichen einfache regelmechanismen aufzubauen, so ala linienfolger .... das ist ein seeeehr schönes beispiel für einen regelkreis und ist auch wunderschön in UML darstellbar ... man muss ja nciht gleich in die vollen gehen, man könnte ja auch versuchen den asuro zu programmieren

  4. #4
    Neuer Benutzer Öfters hier
    Registriert seit
    11.12.2009
    Ort
    Darmstadt
    Alter
    55
    Beiträge
    22
    Zitat Zitat von Ceos
    als aufgabe würde es doch quasi schon reichen einfache regelmechanismen aufzubauen, so ala linienfolger .... das ist ein seeeehr schönes beispiel für einen regelkreis und ist auch wunderschön in UML darstellbar ... man muss ja nciht gleich in die vollen gehen, man könnte ja auch versuchen den asuro zu programmieren
    Tut mir Leid, das verstehe ich nicht.
    Was genau meinst Du? Ein Regler lässt sich doch nicht als Zustandsmaschine darstellen, er hat doch keine Zustände !?!

    Den "asuro", klar könnte man. Du klingst aber nicht, als hättest Du das vor?
    Möglicherweise habe ich mein Anliegen noch nicht genau genug ausgedrückt:

    Ich habe: Ein Entwicklungstool.
    Ich suche: Jemanden der bereit ist, es auszuprobieren.

    Ich biete: Jegliche Unterstützung die Notwendig ist, dass der Test ein Erfolg wird.

    Warum: Weil ich daran glaube, dass das Tool hier gute Dienste leisten kann, ich aber nicht genug Mikrocontroller Erfahrung habe, um das wirklich beurteilen zu können.

    Ich bin hier wahrscheinlich deshalb so schwer zu verstehen, weil Roboter nicht mein Hobby sind, sondern Entwicklungswerkzeuge.

    Das Tool bietet Code Generatoren und die Möglichkeit, Zustandsmaschinen grafisch darzustellen. Außerdem ein komplettes Traceframework um die Funktion der laufenden Software ebenfalls grafisch darzustellen.

    Es ist ein Framework, also ein Ramen. Es hat selbst bereits einige 100 Zeilen Code und kann seine Stärke nur entfalten, wenn man ein komplexes Projekt so aufzieht. Wenn ich damit ein Blinklicht oder einen Regler implementiere, dann mache ich mich lächerlich.
    (Trotzdem: ein Blinklicht Teilverhältniss 1:2 im Anhang)

    Solche Tools setzt man eigentlich dann ein, wenn man wegen der Komplexität des Projekts Gefahr läuft, den Überblick zu verlieren. Oder um seinen Code so gut zu Dokumentieren, dass er ggf. auch von anderen verstanden wird.

    Im ersten Schritt, soll es ein Beispiel werden, also gerne was einfaches. Aber 3-4 nebenläufige Aufgaben und 4-10 Eingabe und Ausgabe Geräte sollten es schon sein, sonst versteht man den Nutzen nicht.
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken statechart.png  
    Angehängte Dateien Angehängte Dateien

  5. #5
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    28.09.2009
    Beiträge
    170
    Die nebenläufigen Aufgaben wären die Abfrage verschiedenster Sensoren für Odemetrie, Abstandssensoren, Liniensensoren, Wärmesensoren etc. Die Ein- bzw. Ausgaben wären dann die jeweiligen Richtungsänderungen bzw. die Bewegung als solches, evtl. Statuslichter (beispiel. Bremslichter, Frontlichter), und und und...

    Wenn man eine einfach grafische Oberfläche hätte um diese Aktoren, Sensoren etc. zu programmieren ohne von dem eigentlichen Prozessor eine Ahnung zu haben, wäre das wohl ein wesentliche Vereinfachung.

  6. #6
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    08.07.2006
    Ort
    Karlsruhe/München
    Alter
    27
    Beiträge
    587
    Achtung, der Miesepeter kommt:
    Ich habe gerade studiumsbedingt viel mit Moore and Mealy automaten zu tun. (Etechnik in München). Ich habe die Erfahrung gemacht, dass so kleinere Codes (aka Blinklicht, Ampelsteuerung) noch verdammt übersichtlich sind. Sobald es aber etwas komplizierter wird (aka Quicksort) oder komplexere Steuerungen ist es echt schwer den Überblick zu behalten.
    Vorallem problematisch sind die parralitäten, wenn man entscheiden muss was wichtiger wird und man entscheiden muss was als erstes Ausgeführt wird.

    Fazit: Moore and Mealy sind ganz schön für kleinere Sachen, aber für große Projekte aufgrund der Parallelität und der Unübersichtlichkeit meiner Meinung nach immer noch schlechter als es gleich in C zu schreiben. Denn da hat man diese Probleme nicht, da man sie unbewusst selbst abfängt. Das kann leider ein autogenerator nicht. Trotz allem bin ich gespannt wie sich dein Projekt entwickelt und werde auf jedenfall die Weiterentwicklung verfolgen.

  7. #7
    Neuer Benutzer Öfters hier
    Registriert seit
    11.12.2009
    Ort
    Darmstadt
    Alter
    55
    Beiträge
    22
    Zitat Zitat von kellerkind
    Die nebenläufigen Aufgaben wären die Abfrage verschiedenster Sensoren für Odemetrie, Abstandssensoren, Liniensensoren, Wärmesensoren etc. Die Ein- bzw. Ausgaben wären dann die jeweiligen Richtungsänderungen bzw. die Bewegung als solches, evtl. Statuslichter (beispiel. Bremslichter, Frontlichter), und und und...

    Wenn man eine einfach grafische Oberfläche hätte um diese Aktoren, Sensoren etc. zu programmieren ohne von dem eigentlichen Prozessor eine Ahnung zu haben, wäre das wohl ein wesentliche Vereinfachung.
    Danke!

    Genau meine Rede! Und so eine Beispielprojekt Suche ich.
    Ganz ohne "Ahnung" von der Eigentlichen Hardware wird's zwar nicht gehen, aber eine "Erleichterung" kann ich versprechen.

    @kellerkind: Du hattest ja bereits geschrieben, dass Du mitmachen willst. Gilt das noch? Wenn ja, dann lass uns ein Projekt Anfangen. Du gibst die Aufgabe vor. Kommunizieren tun wir hier im thread, dann können alle verfolgen, ob es was taugt.

  8. #8
    Neuer Benutzer Öfters hier
    Registriert seit
    11.12.2009
    Ort
    Darmstadt
    Alter
    55
    Beiträge
    22
    Zitat Zitat von s.o.
    Ich habe gerade studiumsbedingt viel mit Moore and Mealy automaten zu tun. (Etechnik in München). Ich habe die Erfahrung gemacht, dass so kleinere Codes (aka Blinklicht, Ampelsteuerung) noch verdammt übersichtlich sind. Sobald es aber etwas komplizierter wird (aka Quicksort) oder komplexere Steuerungen ist es echt schwer den Überblick zu behalten.
    Dazu zwei Anmerkungen: Bei Zustandsautomaten verlierst Du schnell den Überblick, wenn Du keine Zeichnung (Grafik) des Diagramms hast, die sicher mit dem tatsächlichen Code übereinstimmt. Das Tool stellt das aber sicher (und nur das!). Deshalb behältst Du den Überblick.

    Algorythmische Aufgaben, die nicht auf Ereignisse warten müssen, wie z.B. den Quicksort, solltest Du nicht versuchen, mit einem Zustandsdiagramm zu lösen. Nicht weil er zu kompliziert wäre, sondern weil er keine Zustände hat, in denen er auf Ereignisse warten muss.

    Einen TCP Protokollstack aber z.B. könnte man spielend so lösen, obwohl der sicherlich auch kompliziert ist.

    Zitat Zitat von s.o.
    meiner Meinung nach immer noch schlechter als es gleich in C zu schreiben.
    Wir schreiben in C! Der Code Generator generiert nur das Eigentliche Zustandsdiagramm (In C) und stellt damit sicher, dass Grafik und programmierter Code übereinstimmen.

    Das Message Passing Framework sorgt für die Nebenläufigkeiten. Es hat auserdem ein eingebautes Tracing framework. Wir haben hier 3 Dinge, die Hand in Hand arbeiten:

    1. Das message Passing Framework, das Nebenläufigkeiten, Timeouts und Tracing implementiert (In C).
    2. Den StadteChartCoder, der auf dieses Framework passgenau zugeschnittene Zustandsautomaten codiert (In C).
    3. Trace2UML ( http://trace2uml.tigris.org ) der die Trace Ausgaben des Framework versteht und die Zusammenarbeit der einzelnen Maschinen grafisch darstellen kann (zum debuggen)

    Außerdem hat Astade noch eine Build Oberfläche um den Compiler und den Editor komfortabel aufzurufen.

  9. #9
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    28.09.2009
    Beiträge
    170
    Zitat Zitat von astade
    @kellerkind: Du hattest ja bereits geschrieben, dass Du mitmachen willst. Gilt das noch? Wenn ja, dann lass uns ein Projekt Anfangen. Du gibst die Aufgabe vor. Kommunizieren tun wir hier im thread, dann können alle verfolgen, ob es was taugt.
    Jupp, bin dabei.

  10. #10
    Neuer Benutzer Öfters hier
    Registriert seit
    11.12.2009
    Ort
    Darmstadt
    Alter
    55
    Beiträge
    22
    Zitat Zitat von kellerkind
    Jupp, bin dabei.
    Prima. Ich habe ein SVN Repository für das Projekt eingerichtet.
    Lesezugriff hat jedermann, für Änderungen braucht man userID und Passwort (schicke ich Dir per eMail)

    Adresse des Web Interfaces: http://astade.homeip.net/websvn/list...&path=%2F&sc=0

    Zum auschecken folgende URL verwenden:

    http://astade.homeip.net/robotron/trunk

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •