ubuntuusers.de

Hallo zusammen,

zuerst einmal, ich bin neu hier im Forum nutze und entwickle unter Ubuntu privat wie auch beruflich schon seit etlichen Jahren. Vor knapp 2 Monaten hatte ich eine Idee für ein größeres Entwicklungsprojekt für welches ich auch schon zahlreiche Entwürfe erstellt und auch schon einen Prototypen einer der Komponenten entwickelt habe (Kommt hier alles noch).

Ich möchte dieses Projekt hier veröffentlichen, um zum einen dem Trend entgegenzuwirken, dass das Projekt in meinen Händen einschläft, und zum anderen, da es ein größeres Projekt ist, welches zahlreiche Aspekte beinhaltet, einen Aufruf an andere Entwickler zu machen, die sich in Teilbereichen dieses Projekts besser auskennen als ich.

Nun aber zu dem eigentlich Projekt:

Kurz zusammengefasst soll es ein auf offenen Standards und Schnittstellen basiertes Bestell-, Verwaltungs- und Analysesystem für den Gastronomiebereich werden. Ideen für digitale Speisekarten gab es ja schon mehrfach und wurden auch von einer Fastfoodkette meines Wissens umgesetzt, aber ich stelle mir das nur als ein Frontend in einer komplett integrierten Anwendungsumgebung für einen Gastronomiebetrieb vor.

Als kleine Impression: Stellen wir uns eine Reihe Restaurants vor, die das zu verwendende System nutzen. Dort sind die Speisekarten durch WebPads mit digitaler Speisekarte ersetzt. Gäste können über dieses direkt ihre Bestellung aufgeben und bekommen in der Wartezeit die Möglichkeit über die WebPads im Internet zu surfen oder aber sich an dem Restaurantsystem anonym (Also nur mit einem Loginnamen und Passwort. Keine Namen, Adressen, etc.) anzumelden. Hinter dieser Anmeldung verstecken sich nun zwei große Bereiche: Zum einen Zugang zum Community Bereich des Restaurants wo verschiedene Angebote und Aktivitäten warten (folgt noch). Zum anderen kann der Benutzer sich bei weiteren Besuchen in Restaurants mit diesem System direkt anmelden und das System kann alle Bestellungen seiner Benutzer-ID zuordnen. In regelmäßigen Batchläufen werden daraufhin alle angemeldeten Gäste anhand ihres Bestellverhaltens (nach diversen Indikatoren wie Preisklasse, Kategorien, Bewertungen der Speisen und Restaurants, etc.) miteinander verglichen und Korrelation zwischen den Kunden errechnet. Mit Hilfe dieser kann das System nun für alle im System gespeicherten Speisen Wahrscheinlichkeiten errechnen, mit denen ein angemeldeter Kunde dieses Gericht mögen wird (Sofern er schon ausreichend oft bestellt hat, um valide Daten vorliegen zu haben). Dies zeigt gerade dann deinen Charm wenn mehrere unterschiedliche Restaurants das System einsetzen würden. So könnte jemand der im System angemeldet ist durch das System Empfehlungen für andere Restaurants erhalten und dort dann, ob wohl er noch nie da war, persönliche Empfehlungen für die Speisen in dem Restaurant erhalten, alles basierend auf Korrelationen und Messdaten von der Summe aller anderen Kunden.

Mehr oder minder unabhängig zu entwickeln wäre also: ein Client für die digitale Speisekarte, von wo aus eine dynamisches Frontend die Speisekarte von einem Server ausliest und Bestellungen, Benutzeranmeldungen/-registrierungen, Bewertungen, etc. an diesen zurücksendet. Eine Verwaltungssoftware mit denen die Besitzer die Speisekarte anpassen können, Bilder hochladen, Statistiken auslesen, etc. Ein Auswertungsprogramm, welches im Batchbetrieb in festen Intervallen die neu gesammelten Daten einliest und die Korrelationen zwischen Gerichten, Kunden und deren Kaufverhalten, Kategorien, etc. errechnet und in den lokalen Datenbanken ablegt. Eine Client-Server-Architektur, welche die Kommunikation zwischen mobilen Clients (Den Speisekarten), lokalen Servern (Verwaltungsrechnern), lokalen Datenbanken (welche vermutlich direkt auf den lokalen Servern laufen) und dem zentralen Server und der zentralen Datenbank (Dort wo alle Daten akkumuliert, berechnet und wieder verteilt werden) sicherstellt. Ein Webplattform welche in die Architektur des Gesamtsystems integriert ist (Also auch an die Datenbank mit der Speisekarte und den Nutzerdaten angebunden ist) und neben Informationen zu dem Restaurant, diverse Social-Network-Funktionen bietet. Da dies in verschiedenen Gastronomiebetrieben eingesetzt werden soll, ist hier die Entwicklung eines Webtemplates sinnvoll.

Das Auswertungsprogramm bzw. den dafür notwendige mathematische Algorithmus habe ich bereits entwickelt und einen funktionsfähigen Prototypen, mit denen ich bereits einige Testläufe auf einer prototypischen Datenbank mit einigen Testdaten gemacht habe. An der Verwaltungssoftware arbeite ich bereits, geschätzt bin ich da bei 30 – 40%. Die Client-Server-Architektur existiert auf dem Papier, die konkrete Entwicklung der Schnittstellen ist jedoch noch offen. Für den Client existiert bisher nur ein grobes Konzept, da ich hierfür momentan noch einige Umfragen mache, was Gäste und Betreiber wirklich sinnvoll finden, bzw. sich wünschen. Die Entwicklung der Webplattform beschränkt sich bisher auch nur auf eine Auflistung der Use-Cases.

Zu den Entwicklungsparametern: Das Auswertungsprogramm sowie die Verwaltungssoftware ist in Java geschrieben. Entsprechend könnte ich mir für die Umsetzung der Webplattform eine Entwicklung mit JSP vorstellen. Für die lokalen Server ist ein entsprechender Applikations- Server auszuwählen (Gibt es ja genug, ich favorisiere momentan den Glassfish). Die Hardware für den Client habe ich noch nicht genauer eingeschränkt. Bei momentan verfügbaren Geräten ist irgendwas auf Android-Basis aus meiner Sicht am naheliegensten. Jedoch lasse ich mir da auch gerne anderes erzählen, da ich mich was Entwicklung mit mobilen Endgeräten angeht nicht so gut auskenne. Da der Client eigentlich nur übertragene Inhalte schön grafisch darstellen soll, präferiere ich momentan eine Umsetzung in Flash + Action Script.

Generell würde ich die Entwicklungsumgebung / -sprache auch wechseln, wenn etwas anderes wirklich sinnvoller wäre. Auch würde ich mich über jeden Hinweis freuen, der mir schon existente Applikationen, Tools, etc. zeigt, die Teile von dem, was ich hier plane bereits können, bzw. die man dafür in modifizierter Form verwenden könnte. Das ist auch der Grund warum ich das hier im Forum poste, da das ganze wie Anfang gesagt mit offenen Standards entwickelt werden soll, damit alle es nutzen und weiterentwickeln können (Ich weiß, da hab ich mich mit meinem Vorschlag Flash als Frontend zu nutzen schon selbst widersprochen) und natürlich auch die Möglichkeiten offener Software nutzen möchte, um das Rad nicht nochmal neu erfinden zu müssen.

Ich würde mich über Feedback freuen und stelle sofern Interesse besteht auch gerne noch detailliertere Informationen, Entwürfe, Prototypen und Programmcode bereit.

Also wie du dir das vorgestellt hast, sieht das schonmal sehr gut aus.

Wollte jetzt eigentlich nicht auf das Projekt an sich eingehen, sondern vor allem auf den Client. Wenn du den mit Flash programmierst, werden die geräte reihenweise amok laufen. Weil die haben noch weniger Leistung als ein normaler PC und alles das was du mit Flash machen kannst (animationen, Oberflächen, die nicht neu laden müssen) kannst du auch mit HTML machen. Als toolkit für HTML und Javascript würde ich jQuery empfehlen. Das ist sehr einfach zu lernen und man muss für eine einfache Animation nicht viel Quellcode schreiben. Ob man Java oder etwas anderes einsetzt, darüber lässt sich wohl streiten. Aber das ist ja deine Sache.

Die Sache hört sich insgesamt sehr gut an, du gehst die Sache sehr organisiert an, wie ich finde. Also dafür schonmal ein großes Kompliment!

Meine Idee wäre möglichst alle Teile von einander zu trennen um das System möglichst modular zu machen. Wenn zum Beispiel jede Filiale einer Kette in Deutschland das selbe, zum selben Preis, anbietet, würde kein lokaler Server dringent benötigt werden, da alle Daten in der Zentrale/Hauptfiliale gespeichert werden können. Außerdem könnte man den Leuten mit Smartphones die Möglichkeit geben direkt von ihrem Handy zu bestellen. Dafür müsste man für die bekannten Platformen für mobile Geräte (iPhone OS, Android) ein Programm schreiben, das automatisch einfach die Speisekarten-Daten vom Server läd. Für die weniger verbreiteten Systeme könnte man zusätzlich eine Internetseite einrichten, die durch die Eingabe von einer Domain (z.B. 'speisekarte') aufgerufen wird.

Wow, gute Idee, wäre klasse wenn man das im großen Stil umsetzen kann!

fabiei schrieb:

Außerdem könnte man den Leuten mit Smartphones die Möglichkeit geben direkt von ihrem Handy zu bestellen.

...und im gleichen Zug vielleicht sogar noch Plätze im vorraus bestellen, so könnte man die Wartezeiten verkürzen.

Wenn zum Beispiel jede Filiale einer Kette in Deutschland das selbe, zum selben Preis, anbietet, würde kein lokaler Server dringent benötigt werden, da alle Daten in der Zentrale/Hauptfiliale gespeichert werden können.

Auf einen lokalen Server sollte imho nicht verzichtet werden, es könnte ja durchaus passieren, dass der zentrale Server oder die Internetverbindung des Restaurants kurzzeitig ausfällt.

In Sachen Flash schließe ich mich narrowtux an, bitte verwende es nicht. iPhone / iPad unterstützen Flash afaik sowieso nicht, bei Android weiß ich es nicht - und dazu kommt die unverhältnismäßige CPU Last. Wie narrowtux schon sagte, sind hübsche Effekte auch mit JavaScript realisierbar, sieh dir beispielsweise mal Chrissss's Blog an, der gibt optisch einiges her, auch ohne Flash.

Weiterhin könntest du darüber nachdenken, für das Projekt Bitbucket / Github / Launchpad... zu verwenden, dann ist es für die Entwickler einfacher, sich daran zu beteiligen.

Schöne Grüße und viel Erfolg!

Edit: WAS?! Seit wann hat sich Chrissss gelöscht?! 😢

Danke euch Dreien erstmal für eure konstruktive Kritik. Ich werd mich heute Abend und am WE mal hinsetzen und einiges nachdokumentieren, damit ich das hier zeigen kann. Denn momentan bin ich bei vielen Teilen mit der Implementierung weiter als mit den funktionalen Entwürfen. Aber nochmal zur euer Kritik:

@narrowtux: Hab nen bisschen zu JQuery recherchiert. Das ist ja unglaublich praktisch, warum hab ich davon noch nie was gehört? Vermutlich hab ich die letzten Jahre zu viel entweder mit Flash gemacht oder alles von der Pike an selbst in JavaScript geschrieben. Java habe ich deshalb gewählt, weil es plattformunabhängig ist und so auf den lokalen Servern genutzt werden könnte, egal was dort drauf ist. Schließlich kann es sein, dass einige Restaurants bereits einen Rechner haben, den sie dann als Server einsetzen wollen. Natürlich könnte man das Programm einfach für jede Plattform kompilieren, aber ich find's so einfach einfacher. Vor allem wenn ich langfristig an Support und Updates denke, die sonst für jede Plattformversion separat durchgeführt werden müsste. Im Nachhinein habe ich darüber nachgedacht aus Performancegründen (Java ist als Interpretersprache ja nicht allzu schnell) das Analyseprogramm in C++ umzuschreiben, aber das ist momentan noch ein "Kann-Kriterium".

@fabiei: Im Punkto Modularisierung stimme ich dir absolut zu. Alle genannten Komponenten möchte ich getrennt voneinander entwickeln und dann über ein Interface kommunizieren lassen. Eventuell werde ich die zentrale Komponente auch als Webservice anbieten. Was du bezüglich Ketten sagst kann sein, muss aber nicht. Ich gehe davon aus, dass das System in verschiedenen Restaurants eingesetzt wird, sie sich aber eine digitale Kundenbasis teilen. Das soll einer der Vorteile sein, dass sich unabhängige Restaurants in ihrer Datenbasis zusammenschließen (Folgt noch alles in den Use-Cases die ich spätestens am WE hier poste). In sofern werde ich definitiv lokale Server und Datenbanken behalten, unter anderem auch wegen dem Erreichbarkeits- und Performanceaspekt (z.B. sollen die Speisekarten in Echtzeit geladen werden, da unter anderem sehr viele Bilder geladen werden müssen). Wenn der zentrale Server z.B. mal nicht erreichbar ist muss das System trotzdem noch funktionieren.

@erd_baer: Meine Intention war es, dass man sein eigenes Smartphone alternativ zu den digitalen Speisekarten im Restaurant nutzen kann. Daher bietet es sich wie du sagst wirklich an, die Speisekarte und Bestellung dann über ne Website zu machen, die dann auf einem lokalen Webserver im Restaurant liegt und über das WLAN wie du sagst z.B. über die Domain "Speisekarte" erreichbar ist. Sofern sich hier Leute finden, die an diesem Projekt mitentwickeln wollen, bzw. auch gerne eine Komponente aus dem Konzept übernehmen wollen, werde ich dan darüber nachdenken ein entsprechendes CVS, ne Wiki und einen Bugtracker einzusetzen. Was man da genau einsetze würde ich dann zur Diskussion stellen. Ich präferiere dort Subversive, Drupal als Wikiersatz, Bugzilla und zum Kompilieren, Packen und Verteilen Maven.

Vielleicht nochmal zu den Leuten die ich suche: 1.) Jemand der sich mit Entwicklung auf WebPads und Smartphones auskennt. Denn das ist ein Bereich wo meine Kenntnisse noch sehr bescheiden sind. Also den Bereich Cliententwicklung würde ich auch gerne vollständig abgeben, wenn das jemand (Oder auch ein Team) übernehmen möchte. 2.) Ein Mathematikgenie mit dem ich im fortgeschrittenen Stadium nochmal über den bereits fertig entwickelten und implementierten Analyse- und Auswertungsalgorithmus gehen kann. Besonders wichtig ist hier neben der Validierung der Ergebnispräzision auch eine Aufwandsanalyse des Algorithmus (Nach meinen Hochrechnungen dauert die Auswertung schon bei ein paar hundert Kunden und Gerichten über ne Stunde). 3.) Jemanden, der gut im Webdesign ist, sich mit CMS auskennt (Wie gesagt präferiere ich dort Drupal) und da einige Module mitentwickeln möchte, die das CMS in die Systemlandschaft integrieren (z.B. das regelmäßig per Cronlauf die Benutzerdaten der CMS-Datenbank mit denen des Restaurantsystems aktualisert werden). 4.) Allgemein Menschen, die sich mit den Use-Cases beschäftigen und Anforderungen und Vorschläge für weitere Features und Funktionen entwerfen. 5.) Jeder der sonst irgendwie dazu beitragen will.

Use-Cases

1. Web-Client:

1.1 Digitale Speichekarte:

1.1.1 Gerichte nach Kategorien auswählbar

1.1.2 Filter können auf die Speisekarte angewendet werden (Glutenfrei, Vegetarisch, Diabetiker, etc.)

1.1.3 Varianten zu den Gerichten auswählbar

1.2 Beim Anklicken einen Gerichts werden Detailinformation angezeigt

1.2.1 Anzeigen wie oft das Gericht im vergangenen Monat bestellt wurde (So sieht man, was wirklich zu den Spezialitäten dieses Restaurants gehört)

1.2.2 Durchschnittsbewertung des Gerichts und Kommentare von anderen Kunden

1.2.3 Bild des Gerichts

1.3 Nach dem Essen

1.3.1 Gericht bewerten

1.3.2 Restaurant bewerten

1.3.3 Empfehlung für andere passende Restaurants erhalten

1.4 Benutzerprofil

1.4.1 Registrierung und Login wenn schon am System angemeldet

1.4.2 Einstellungen im Benutzerprofil angeben

1.4.3 Standardfilter setzen

1.5 Im Internet surfen bzw. direkt eingeloggt auf die integrierte Restaurantwebsite

2. Lokaler Server:

2.1 Datenbank-Server

2.1.1 Enthält alle Benutzer- und Analysedaten aller am System angeschlossener Restaurants

2.1.2 Enthält nur vom lokalen Restaurant die Daten zur Speisekarte

2.2 Applikations-Server

2.2.1 Reagiert auf Anfragen der Clients

2.2.2 Reagiert auf Anfragen des zentralen Servers

2.3 Web-Server

2.3.1 Hostet Speisekarte für Clients

2.3.2 Hostet Speisekarten-Version für gängige Smartphone-Typen/-Betriebssysteme

2.4 Verwaltungstool

2.4.1 Speisekarte anpassen

2.4.2 Bestellanalysen

2.4.3 Bewertungen einsehen

3. Website/Communitysite des Restaurants:

3.1 Speisekarte im Internet

3.1.1 Gäste können eigene Speisekarten posten und darüber abstimmen

3.1.2 Gäste können sich ausgewählte Rezepte zu Gerichten auf der Speisekarte zum Nachkochen downloaden

3.2 Koch Wiki (???)

3.3 Köche des Restaurants bloggen (inkl. embedded Youtube-Kochvideos) (???)

3.4 Restaurant Scout (???)

3.5 Eventveranstaltungen (Kochveranstaltungen, Partys, Blind Dates, etc.) (???)

3.6 Payback Systeme für angemeldete Benutzer (???)

3.7 Entsprechende Moderator-Accounts für Restaurantpersonal

4. Zentraler Server

4.1 Regelmäßige Updates der lokalen Server (Einzelnd nacheinander)

4.1.1 Ziehen der Datenbank des lokalen Servers und Abgleich mit lokaler Datenbank

4.1.2 Analysieren der Daten (Siehe 4.2)

4.1.3 Updaten der lokalen Datenbank mit zentralen Datenbank und Analyseergebnissen

4.2 Analysen der Bestell- und Kundendaten

4.2.1 Kunden miteinander vergleichen und Korrelationen errechnen

4.2.2 Gerichtempfehlungen für Kunden errechnen

5. Client für Küchenpersonal

5.1 Anzeigen aktueller Bestellungen

5.2 Eingeben und tracken des Zubereitungsstauts der Bestellungen

Datenbankstruktur

Restaurant:

ID Integer(5)

Name Varchar(40)

BesitzerID Integer(8)

Ort Varchar(20)

PLZ Integer(5)

Adresse Varchar(30)

Kunde:

ID Integer(8)

Login Varchar(20)

Vorname Varchar(20)

Nachname Varchar(20)

Geschlecht Tinyint(1) // 0 = männlich, 1 = weiblich

Kundekrln:

Kunde1ID Integer(8)

Kunde2ID Integer(8)

Korrelation Float(8)

Kaufverhalten:

KundeID Integer(8)

KategorieID Smallint(4)

Anteil Float(6) // Getrennt nach Getränk und Speise

Preis Smallint(3)

Empfehlung:

KundeID Integer(8)

GerichtID Integer(8)

Rang Float(6)

Gericht:

ID Integer(8)

Titel Varchar(20)

RestaurantID Integer(5)

KategorieID Smallint(4)

Aktiv Tinyint(1)

Untertitel Varchar(80)

Beschreibung Varchar(300)

Typ Tinyint(1) // 0 = Getränk, 1 = Speise

Preis Smallint(3)

GekauftProMonat Smallint(5)

VariationID Integer(8) // 0 wenn ein Gericht des Hauses

KochID Integer(8) // Kunde der Gericht vorgeschlagen hat

BestellungsElement:

ID Long(11)

BestellungID Integer(10)

KundeID Integer(8) // 0 wenn nicht angemeldeter Gast

GerichtID Integer(8)

BewertungAnonym Tinyint(1)

Bewertung Tinyint(1) // 1 - 5; 0 = Keine Bewertung

Datum Integer(10)

Bestellung:

ID Integer(10)

KundeID Integer(8) // 0 wenn nicht angemeldeter Gast

RestaurantID Integer(5)

TischID Integer(6)

Gesamtpreis Smallint(4)

BewertungAnonym Tinyint(1)

Bewertung Tinyint(1) // 1 - 5; 0 = Keine Bewertung

Datum Integer(10)

Tisch:

ID Integer(6)

Bezeichnung Varchar(15)

Gruppentyp: (optional)

ID Tinyint(3)

Formel Varchar(100) // Regulärer Ausdruck für Gruppen

Gruppekrln: (optional)

GerichtID Integer(8)

GruppetypID Tinyint(3)

Korellation Float(6)

Kategorie:

ID Smallint(4)

Titel Varchar(20)

Typ Tinyint(1) // 0 = Getränk, 1 = Speise

Preis Smallint(3)

Kategoriekrln:

Kategorie1ID Smallint(4)

Kategorie2ID Smallint(4)

Korrelation Float(6)

Filter: (optional)

ID Tinyint(3)

Bezeichnung Varchar(40)

Kundenfilter: (optional)

KundeID Integer(8)

FilterID Tinyint(3)

Gerichtfilter: (optional)

GerichtID Integer(8)

FilterID Integer(8)

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Ein ERM folgt noch!

Ein DDL Datenbank-Dump auch!

Architektur

Hier die geplante Architektur erstmal nur aus Hardware-/Netzsicht.

Die Clients und mitgebrachten, WLAN-fähigen Geräte greifen per WLAN auf den lokalen Server zu, um mit diesem zu interagieren. Am Server direkt oder per Remote von jedem anderen Computer kann die lokale Administration durchgeführt werden. In regelmäßigen Intervallen wählt der zentrale Server einen der lokalen Server an, gleicht die Datenbanken ab und berechnet Korrelationen. Danach geht der zentrale Server zum nächsten lokalen Server über.

System Context Model

Nach dieser rein hardwareseitigen Sicht hier der abstrakteste Überblick über die logische Struktur des Gesamtsystems.

Component Relationsship Model

Dem abstrakten Überblick über die physische und logische Architektur, möchte ich nun ein Modell höherer Granularität vorstellen, dass alle aus meiner Sicht zu implementierenden Komponenten enthält, Angaben über Kommunikationswege und Plattform bzw. Sprache der Komponente macht.

Bedeutung der Farbgebung:

- Orange: Komponenten sind nur in einer Instanz vorhanden.

- Blau: Von der Komponente existieren n Instanzen (n = Anzahl der Restaurants)

- Grün: Die Komponente ist einer unbestimmten Anzahl Instanzen vertreten.

(Die unterschiedlichen Töne einer Farbe sind lediglich zur besseren Abgrenzung von lokalen Anwendungen, Webapplikationen und Datenbanken gedacht)

In runden Klammern habe ich die Abkürzung der Komponente für den Zukünftigen Gebrauch angegeben. Hier dazu die Aufschlüsselung der Akronyme:

- RCMS → Restaurant Content Management System

- CMSDB → Content Management System Database

- eBoF → Electronic Bill of Fare

- OMS → Order Management System

- LAS → Local Application Server

- LDB → Local Database

- RMI → Restaurant Management & Information System

- SMM → System Management & Monitoring

- TransDB → Transfer Database

- DTV → Data Transfer & Validation

- CDB → Central Database

- ARC → Analysis of Restaurant & Client Data

In eckigen Klammern ist die Plattform bzw. die Sprache angegeben, auf der die Komponente aufsetzen soll. Ist der Inhalt von Fragezeichen umgeben steht die Plattform bzw. Sprache noch nicht fest.

Quellcode für ARC & Teilen von RMI

Hier ein Auszug aus dem bisherigen Programmcode. Er beinhaltet den Auswertungsmechanismus, welcher soweit auch funktionsfähig und getestet ist. In diesem Programm ist der Auswertungsalgorithmus an die Verwaltungssoftware gekoppelt, was soweit aber nciht weiter schlimm ist, da die lokale und zentrale Datenbank identisch aufgebaut sind und sich nur in ihrem Inhalt unterscheiden (Die lokale Datenbank deckt nur eine Teilmenge der zentralen Datenbank ab). Die Datenbank, auf der das ganze läuft liegt lokal auf einer meiner DBs bei Strato. Die Schnittstelle zwischen dem Tool und der Datenbank stellt vorübergehend einfach eine handvoll PHP-Skripts dar. Dadurch kann ich hier funktionsfähigen Programmcode veröffentlichen, ohne dass ich hier mit dem Programmcode Zugangsdaten zu meiner Datenbank mitliefern müsste 😉

Quellcode

Achtung: Der hier zu findende Programmcode ist nicht kommentiert. Ich gehe mit dem Anspruch daran das der Programmcode an sich verständlich und die Variablen-, Klassen- und Methodennamen sprechend genug sind. Natürlich folgen Unit-Kommentare, sobald die Klassen komplett sind.

wow...

du bist aber sehr ehrgeizig...

und wie weit biste schon?

Wie gesagt: Das Auswertungssystem läuft (Also die ganzen Berechnungen der gesammelten Daten), sprich die Komponenten CDB und ARC. An der Verwaltungssoftware arbeite ich gerade, das bearbeiten der Speisekarte funktioniert aber soweit schon. Diese Elemente hab ich einen Post über dir ja schon als Quellcode hochgeladen. Als nächstes wäre dann eigentlich ein Entwurf für die digitale Speisekarte dran. Nach dem Vorschlag von narrowtux hab ich mich daraufhin mal mit mit jQuery beschäftigt.

Ansonsten... Kritik und Ideen sind weiterhin willkommen, genauso wie Angebote, falls jemand mit einsteigen bzw. einen Part übernehmen möchte.

Ich verstehe jetzt noch nicht so ganz, was davon in den Standard einfließen soll und was Implementationsdetail ist.

Ich empfinde es als gaaanz schlechte Idee, einen Standard auf Techniken wie Java, SQL, XML und so weiter aufzubauen – die Implementation eines solchen Standards ist unglaublich komplex, damit schränkst du die "Zielgruppe" ungemein ein: Nicht jeder kann (wirtschaftlich gesehen bzw. in Hinblick auf Fähigkeiten/Zeit/Motivation) sich mit einem solchen Standard auseinandersetzen oder gar noch danach programmieren.

Wie wäre es, wenn du als Standard einfach nur eine Kommunikationsschnittstelle festlegst? (NICHT über XML, sondern über etwas wie JSON oder von mir aus auch ein binäres Protokoll.) Wenn man als Frontend-Programmierer das Datenbanklayout kennen muss, ist etwas ziemlich schief gelaufen.

Und auf Java oder Flash zu setzen leuchtet mir auch nicht wirklich ein 😉

Ansonsten würde ich noch Permissions einbauen, also User- und Gruppenrechte.