Best Practices der toolgestützten Embedded-GUI-Entwicklung

Seite: 2/6

Firmen zum Thema

Folglich können bei der Entwicklung in den genannten fünf Themengebieten mannigfaltige Probleme auftauchen. Ein paar Beispiele:

Hardware

  • Die zunächst verwendete Hardware ist zu teuer, zu alt, zu langsam oder bietet nicht die benötigte Funktionalität.
  • Sollte dann ein Hardware-Wechsel anstehen (während des Projekts oder mit der nächsten Produktversion), kann es oft vorkommen, dass gerade die verwendeten Software-Komponenten, die eine zu große Abhängigkeit zur bislang eingesetzten Hardware haben, nicht wiederverwendet werden können. Folglich müsste ein großer Teil der Software neu entwickelt werden.
  • Auch kann es vorkommen, dass die finale Hardware zum Start der Software-Entwicklung noch nicht verfügbar ist, da jene selbst noch entwickelt werden muss. Allerdings ist es zwingend notwendig, den Entwicklungsprozess zu parallelisieren, um den gerne mal straffen Zeitplan einhalten zu können.
  • Eventuell sollen nicht nur eine Plattform, sondern zwei oder mehrere Plattformen mit der gleichen Software versorgt werden. Zum Beispiel möchte der Vertriebsaußendienst dem potentiellen Kunden nicht die tonnenschwere Maschine beim Besuch auf den Tisch legen - vielmehr sollte ein handliches Tablet oder Smartphone die Bedienbarkeit und Funktionalität der Maschine demonstrieren.

Durch plattformunabhängige Software Komponenten können die o.g. Probleme von vornherein vermieden werden. Doch wie kann Plattformunabhängigkeit erreicht werden? Beim toolbasierten Entwicklungsprozess sollte das Tool selbst die Möglichkeit bieten, GUIs unabhängig von der späteren Zielplattform zu entwickeln. Mit Hilfe einer abstrakten Zwischenschicht kann dies gelöst werden.

Funktionsumfang

  • Es liegt auf der Hand, dass der Softwarestand des realisierten Prototyps nur einen Ausschnitt der späteren Funktionalität des Endprodukts zeigt. Soll nun weitere Funktionalität eingearbeitet werden, die erst im späteren Verlauf des Projekts spezifiziert wird, kann es passieren, dass die eingangs gewählte Architektur zu einer schlecht erweiterbaren, nur schwer pflegbaren und zu komplexen Software führt.
  • Mangels Zeit könnte es auch passiert sein, dass der Prototyp nur als Mock-Up bzw. Click-Dummy implementiert wurde. Folglich wurde keine Anbindung an die Hardware und/ oder Middleware durchgeführt - doch wie genau soll dies nun umgesetzt werden?
  • Ein ähnliches Problem wird dem Entwickler früher oder später bewusst, wenn man den Ort der implementierten Logik ausfindig macht: Gibt es eine klare Trennung von GUI und Logik oder befindet sich ein Großteil der Logik innerhalb der graphischen Benutzeroberfläche?
  • Selbstverständlich können aber auch nicht-funktionale Anforderungen Hindernisse bei der GUI-Entwicklung darstellen. Für das Produkt soll zum Beispiel ein neuer Markt erschlossen werden und dieser erfordert eine zusätzliche Spracherweiterung. Doch wie lässt sich dies am einfachsten mit der bestehenden Software-Struktur realisieren?

Die oben genannten Hindernisse, die während oder nach der Entwicklung auf den Software-Entwickler zukommen, können gut eliminiert werden, sofern bereits zu Beginn eines Projekts ausreichend Zeit für die Konzeptarbeit eingeräumt wird. Die Architektur und Struktur der neu zu implementierenden Software sollte klar sein, bevor mit der eigentlichen Implementierung begonnen wird.

Dazu ist es notwendig, Dinge, die sich logisch voneinander trennen lassen, zu identifizieren und entsprechend zu separieren: Das Aussehen, die Geschäftslogik, die einzelnen UI Komponenten (Buttons, Listen, Menüs, Dialoge, ...), String-Literale (für die Unterstützung von mehreren Sprachen), etc.

(ID:44318559)