Pilotprojekt für UML basierende Entwicklung gesucht.

Druckbare Version

20.12.2009, 11:07
astade

Pilotprojekt für UML basierende Entwicklung gesucht.

Hallo,

Wie bereits in diesem Beitrag beschrieben,

https://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?
20.12.2009, 12:38
kellerkind

Ich wäre dabei. Meld Dich einfach mal per PM...
20.12.2009, 13:00
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
20.12.2009, 13:44
astade

Liste der Anhänge anzeigen (Anzahl: 3)

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. :cheesy:

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.
20.12.2009, 14:20
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.
20.12.2009, 14:29
s.o.

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.
20.12.2009, 15:58
astade

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.
20.12.2009, 16:14
astade

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.
21.12.2009, 08:20
kellerkind

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.
21.12.2009, 14:18
astade

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
21.12.2009, 17:14
astade

Liste der Anhänge anzeigen (Anzahl: 1)

habe mal versucht, die Anforderungen an das Controller Board in Form eines use case Diagramms aufzustellen (siehe Bild). Habe ich noch was vergessen?
21.12.2009, 17:26
kellerkind

Die Motortemp. kannste weglassen, wir fahren ja kein Verbrenner ;-)
Dafür ist die Erfassung von Hindernissen wichtig. Temperatur ist eher unwichtig. Maximal für den Lipo beim Laden ;-)
Der "Hauptrechner" haste als Mensch dargestellt...dazwischen kommt noch das embedded Board, welches Quasi als Gehirn (Steuerzentrale und Schnittstelle zu anderen Kommunikationswegen -WLAN, LAN etc) für den Bot dient.
Bei der Position spielen zwei Positionen eine wichtig Rolle. Einmal die des Bots (Bewegt er sich überhaupt, oder rutschen die Räder druch) und zum anderen die Position/Bewegung des Motors/Getriebes.

Ansonsten glaub ich, wars das soweit erstmal, heisst für die Motoren bzw. Fortbewegung.
21.12.2009, 17:48
astade

Zitat:

Zitat von kellerkind

Die Motortemp. kannste weglassen, wir fahren ja kein Verbrenner ;-)

Ich dachte, auch Elektromotoren können überhitzen, wenn man es mit der Leistung übertreibt. Aber Du bist der Hardwerker O:)
Wenn Du das entscheidest, lassen wir die Motortemperatur weg.

Zitat:

Zitat von kellerkind

dazwischen kommt noch das embedded Board ..

Das ist die Anforderungsliste an das Controller Board! Das Usecase Diagramm soll zeigen, wer, welche Anforderungen an das Board hat.

Die "Männchen" heißen "Actor" und sind diejenigen, die die Anforderungen haben (meistens Menschen). In diesem Fall ist aber auch auch der Hauptrechner ein "Actor", weil er nicht Bestandteil des Systems (Controller Board) ist.

Als nächstes würde ich ein Blockschaltbild für die Software zeichnen (Komponenten Diagramm)
21.12.2009, 18:55
kellerkind

Dann kann ich als Softwarenapp ja echt noch was lernen, das freut mich voll!!!
Überhitzen sollte wirklicht nicht passieren. Da die Dinger locker bis 10A verkraften, da würde uns eher der Motor abrauchen und deswegen messen wir nur den Strom.

Haste das Diagramm noch geändert, hinsichtlich der Postionsbestimmung?
22.12.2009, 07:01
astade

Zitat:

Zitat von kellerkind

Haste das Diagramm noch geändert, hinsichtlich der Postionsbestimmung?

Das Diagramm beschreibt das Motor Board. Mit "Position" meine ich die gezählten Motor Umdrehungen, also die Odometrie. Klar braucht der Roboter möglicherweise noch andere Möglichkeiten sich zu orientieren, aber die kommen dann nicht vom Motor Board, oder?

Wenn Du das Gefühl hast, das Diagramm passt noch nicht 100% dann ändere es doch einfach mal so ab, wie Du die Sache siehst. Immer mit der Frage: "Was sind die Anforderungen an das Motor Board". Also was soll das Motor Board können. Wir brauchen ein solches "Bild" hinter dem wir beide stehen, damit wir auf das gleiche Ziel zuarbeiten.

Mit den Ovalen beschreibt man jede einzelne Anforderung (Use Case) und mit den kleinen "Männchen" (Den Aktoren) deutet man an, von wem die Anforderung kommt.

Das Diagramm findest Du im Astade Model, im Repository. Also Auschecken, ändern und wieder einchecken. Ich schau mir das dann an.

(könntest Du mir noch sagen, wie viele Schnittstellen (RS232, i2C u.ä) das Board hat. Ich möchte gerne das Komponenten Diagramm machen und dazu müsste ich wissen, wie viele Schnittstelle (und welche) wir zur Verfügung haben.)
22.12.2009, 08:13
astade

Liste der Anhänge anzeigen (Anzahl: 1)

Habe mal einen ersten Entwurf für die Softwarekomponenten des Motor Boards gemacht (Bild im Anhang)
06.01.2010, 16:10
astade

Wie machen wir weiter

Hallo Kellerkind,

mein Framework läuft inzwischen auf meinen Eval board (atmega128). Es wird Zeit, etwas "richtiges" zu machen. Wie sieht's bei Dir aus, wie machen wir weiter?