Lade Inhalt...

Optimierung eines Inventarisierungsprozesses mit Unterstützung einer App Inventor Android Anwendung

Projektarbeit 2012 24 Seiten

Informatik - Wirtschaftsinformatik

Leseprobe

Inhalt

ABKÜRZUNGSVERZEICHNIS

ABBILDUNGSVERZEICHNIS

1 EINLEITUNG
1.1 PROBLEMSTELLUNG
1.2 AUFBAU DER ARBEIT

2 ENTWICKLUNG VON PROGRAMMIERSPRACHEN
2.1 ERSTE GENERATION
2.2 ZWEITE GENERATION
2.3 DRITTE GENERATION
2.4 VIERTE GENERATION
2.5 FÜNFTE GENERATION
2.6 VISUELLE PROGRAMMIERSPRACHEN
2.6.1 Diagrammbasierte visuelle Programmiersprachen
2.6.2 Icon basierte visuelle Programmiersprachen
2.6.3 Formbasierte visuelle Programmiersprachen
2.6.4 Nachteile

3 APP INVENTOR
3.1 ENTSTEHUNG DES „APP INVENTORS“
3.2 HINTER DEN KULISSEN DES „APP INVENTORS“
3.3 KONZEPTDIAGRAMM
3.4 VERWENDUNG AN SCHULEN UND UNIVERSITÄTEN
3.5 AGILE SOFTWAREENTWICKLUNG
3.6 SYSTEMVORAUSSETZUNGEN

4 APP INVENTOR ENTWICKLUNGSUMGEBUNG
4.1 APP INVENTOR DESIGNER
4.2 APP INVENTOR BLOCK EDITOR

5 AUSGANGSSITUATION
5.1 PROBLEMBESCHREIBUNG
5.2 ABGRENZUNG

6 UMSETZUNG
6.1 LÖSUNGSANSATZ
6.2 DATENSPEICHERUNG MIT GOOGLE‘S „FUSION TABLES“
6.3 GESTALTEN DER BENUTZEROBERFLÄCHE
6.3.1 Suchen nach einem Artikel
6.3.2 Bearbeiten von Artikeln
6.3.3 Buchen von Artikeln
6.4 VISUELLE PROGRAMMIERUNG IM APP INVENTOR
6.4.1 Abrufen von Informationen aus Google Fusion Tables
6.4.2 Anzeigen von Informationen
6.4.3 Speichern von Informationen in Google ’ s Fusion Tables
6.4.4 Buchung eines Artikels

7 FAZIT

8 LITERATURVERZEICHNIS

ANHANG
DARSTELLUNG DER FUNKTION „EMPTYRESULT“
SPEICHERN EINES ARTIKELS
FUNKTIONSÜBERSICHT BEI ARTIKEL BUCHEN

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Inhaltliche Struktur der Arbeit (selbst erstellte Grafik)

Abbildung 2: Konzeptdiagramm der App Inventor Anwendung (Quelle: Open Source)

Abbildung 3: Agile Softwareentwicklung (selbst erstellte Grafik)

Abbildung 4: App Inventor Designer (selbst erstellte Grafik)

Abbildung 5: App Inventor Block Editor (selbst erstellte Grafik)

Abbildung 6 Beispielfunktion (selbsterstellte Grafik)

Abbildung 7: Schematische Darstellung des Datenbankmodells (selbst erstellte Grafik)

Abbildung 8: Artikelsuche (selbst erstellte Grafik)

Abbildung 9: Artikel bearbeiten-/-anlegen (selbst erstellte Grafik)

Abbildung 10: Artikel buchen (selbst erstellte Grafik)

Abbildung 11: Suche nach einem Artikel starten (selbst erstelle Grafik)

Abbildung 12: Suchergebnis nach einem Artikel anzeigen lassen (selbst erstellte Grafik)

Abbildung 13: Zuordnen eines Ortes zu einem Artikel (selbsterstellte Grafik)

Abbildung 14 Funktion "emptyresult" (selbst erstellte Grafik)

Abbildung 15 Speichern eines Artikels (selbst erstellte Grafik)

Abbildung 16 Funktionsübersicht bei dem Bildschirm Artikel Buchen (selbst erstellte Grafik)

1 Einleitung

1.1 Problemstellung

In einer Firma wird der Inventarisierungsprozess einmal im Jahr durchgeführt, um die im Warenwirtschaftssystem hinterlegten Informationen mit dem tatsächlichen Bestand abzugleichen. Das Erfassen der Artikel erfolgt manuell auf Listen, die anschließend am Computer in das System übertragen werden. Dieses Verfahren bindet wertvolle betriebliche Ressourcen in Form von Arbeitsstunden und produziert eine nicht zu vernachlässigende Fehlerquote. Die Arbeit widmet sich der Frage, wie man dieses Problem mit neuartigen mobilen Endgeräten und einer Anwendung, die in einer visuellen Programmiersprache entwickelt wird, lösen kann.

1.2 Aufbau der Arbeit

Es wird zunächst auf die Entwicklung der verschiedenen Generationen von Programmiersprachen eingegangen. Dabei wird auch das Konzept der grafischen Programmierung erläutert, sowie Vor- und Nachteile genannt. Anschließend wird die Entwicklung von Google's App Inventor beschrieben sowie eine kurze Darstellung seiner Funktionsweise gegeben. Des Weiteren wird die wachsende Bedeutung von grafischen Programmierumgebungen anhand des „App Inventors“ für Schulen und Universitäten aufgezeigt. Das folgende Kapitel behandelt die Entwicklungsumgebung, bestehend aus dem Designer und Block Editor. In dem Praxisteil wird auf ein aktuelles Problem eingegangen, das mit den Möglichkeiten des App Inventors gelöst wird. Dabei werden die Umsetzung der Anwendung dargelegt und visuelle Programmierblöcke erläutert. (Siehe Abbildung 1)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Inhaltliche Struktur der Arbeit (selbst erstellte Grafik)

2 Entwicklung von Programmiersprachen

Die Entwicklung der Programmiersprachen wird in verschiedene Generationen eingeteilt.

2.1 Erste Generation

Zu der ersten Generation der Programmierung wird die direkte binäre Verarbeitung von Befehlen und Informationen gezählt. Es existieren nur zwei Zustände: „An“ und „Aus“ die entsprechend mit „0“ und „1“ dargestellt werden. Dieser Binärcode gilt als unmittelbare Maschinensprache (Sanda, 2001).

2.2 Zweite Generation

Da die Programmiersprache der ersten Generation aufgrund ihrer Abstraktheit für den Menschen schwer zu lesen und zu verstehen war, wurde an einer Lösung gearbeitet, die für den Benutzer besser lesbare Zeichenketten in Maschinencode umsetzt. Diese erste Abstrahierung zur Maschinensprache wurde mit der Assemblersprache umgesetzt. Diese Sprache enthält erste Zeichenketten, die für den Menschen lesbar waren (Sanda, 2001).

2.3 Dritte Generation

In der nächsten Generation fand eine weitere Abstrahierung statt. In diesen höher entwickelten Programmiersprachen wie FORTRAN, COBOL BASIC und C wurden Textbausteine der englischen Sprache eingebaut, so dass Entwickler die Programmiersprachen leichter erlernen und verwenden konnten (Sanda, 2001).

2.4 Vierte Generation

Die vierte Generation vereint eine höhere maschinensprachliche Abstraktion und die häufigere Verwendung englischsprachiger Begriffe. Auf dieser Ebene wird von der Sprache beschrieben, was die Anweisung erfüllen und nicht wie sie vom Computer umgesetzt werden soll. Zu einer Sprache der vierten Generation (4GPL) zählt zum Beispiel die Structured Query Language (SQL). Mit dieser können Datensätze aus einer Datenbank abgefragt werden, jedoch bildet SQL nicht ab, auf welche Art und Weise die Umsetzung erfolgen soll (Sanda, 2001).

2.5 Fünfte Generation

Die neueste Generation befindet sich noch in einem experimentellen Stadium. Sie ist der englischen Sprache näher, als einer abstrakt textuell bestimmten Programmiersprache. Sie ermöglicht es, in der Interaktion zwischen Mensch und Maschine die gleiche Sprache zu verwenden, die auch bei der zwischenmenschlichen Kommunikation genutzt wird (Sanda, 2001).

2.6 Visuelle Programmiersprachen

Das Erlernen einer Programmiersprache ist eine langwierige und komplexe Aufgabe, die mit einem hohen Zeitaufwand verbunden ist. Visuelle Programmiersprachen stellen sich dieser Herausforderung und dienen als revolutionärer Ansatz, um Computerfunktionalität an Nicht- Programmierer zu vermitteln. Dieser Ansatz basiert hauptsächlich darauf, dass Bilder mehrere Bedeutungen in einer konzentrierten Form vermitteln. Dazu zählt auch, dass Grafiken besser genutzt werden können, um Verständnis zu vermitteln und es leichter ist, sich an Darstellungen zu erinnern. Durch das Verwenden von Bildern wird das Programmieren außerdem interessanter und Bilder können unabhängig von der Sprache des Benutzers verstanden werden (Shu, 1999). Beim Verwenden einer Grafischen Programmiersprache können Lexikalische, Syntaktische und Semantische Fehler nur schwer begangen werden (Leimbach & Trella, 2011). Wie von Shu schon Ende der 1990er Jahre festgestellt wurde, gibt es verschiedene Kategorisierungen visueller Programmierung. Nach seiner Festlegung bieten visuelle Programmiersprachen dem Benutzer die Programmierung mit grafischen Ausdrücken. Bei der Gestaltung wird keine Definition der Variablen als Text, Zahl, Datum oder Ähnliches getroffen. Des Weiteren sind die visuellen Programmiersprachen in drei Bereiche aufgeteilt. Es gibt diagrammbasierte, iconbasierte und formbasierte Umsetzungen (Shu, 1999).

2.6.1 Diagrammbasierte visuelle Programmiersprachen

Der Quellcode eines textbasierten Programmiersprache, wird meist in einem Diagramm basierend auf dem Modell von Nassi und Shneiderman Dokumentiert. Ein Ansatz von diagrammbasierten Programmiersprachen ist es, dieses Modell in ein ausführbares Programm umzusetzen. Dies würde zudem unterbinden, das Dokumentation und programmverhalten auseinanderwachsen.

2.6.2 Icon basierte visuelle Programmiersprachen

Icon basierte Systeme verwenden Piktogramme um Objekte und Aktionen darzustellen. Dies ist analog zu den alltäglichen Icons in Benutzerprogrammen zu sehen. (Shu, 1999)

2.6.3 Formbasierte visuelle Programmiersprachen

Formular basierte Programmiersprachen finden meistens in Datenbanken und Tabellen Verwendung. Die Eingabemasken können direkt zur Datenmanipulation verwendet werden und ermöglichen es somit, einfache Datenbankmodelle zu entwerfen (Shu, 1999).

2.6.4 Nachteile

Zwar sind visuelle Programmiersprachen schneller zu erfassen, jedoch steigt die Übersichtlichkeit mit der Komplexität der Programmierung (siehe Abbildung 16 im Anhang II) (Schaefer, 2011). Des Weiteren gab es über die Jahre eine vielzahl an von Ansätzen, von denen sich keiner im Allgemeinen durchsetzen konnte. Visuelle Programmiersprachen bleiben meist Insellösungen für einen spezifischen Anwendungsbereich (Schaefer, 2011).

3 App Inventor

3.1 Entstehung des „App Inventors“

Die Anwendung „App Inventor“ ist von Google-Mitarbeitern entwickelt worden. Es galt zunächst als experimentelles Lehr- und Lernwerkzeug und wurde im Juli 2009 an ausgewählten amerikanischen Hochschulen vorgestellt (Kloss, 2011). Ziel dabei war es, Studierenden den Einstieg in die allgemeine Programmierung zu erleichtern. Im Juli 2010 wurde das Projekt der Öffentlichkeit vorgestellt, jedoch wurde der Zugang als „Closed-Beta“ eingeschränkt (Kloss, 2011). Am 15. Dezember 2010 wurde die Zugangsbeschränkung aufgehoben und war damit für alle Benutzer verfügbar. „App Inventor“ wurde von „Google Labs“ betrieben. Bei „Google Labs“ handelte es sich um eine Sammlung von Diensten, die von Google betrieben und nach erfolgreichen Tests in die Produktlinie übernommen wurden. Die „Google Labs“ wurden am 17. Oktober 2011 geschlossen. Google beendete den Support von „App Inventor“ und stellte den Service zum 31.12.2011 ein. Um das Weiterbestehen der Anwendung zu sichern, wurde in Kooperation mit dem „Massachusetts Institute of Technology“ (MIT) ein „Center for Mobile Learning“ ins Leben gerufen. Dieses wird den Service weiter ausbauen und der Öffentlichkeit wieder zur Verfügung stellen.1 Des Weiteren wurde am 20. Januar 2012 der Quellcode des App Inventor als „Open Source“ der Öffentlichkeit zur Verfügung gestellt.2

3.2 Hinter den Kulissen des „App Inventors“

App Inventor ist das Ergebnis von Weiterentwicklungen im Bereich der grafischen Programmiersprachen. Weitere Beispiele dafür sind Scratch und StarLogoTNG, mit denen es möglich ist, Anwendungen anstelle von Textcode mit Hilfe von grafischen Bausteinen zu erstellen (Magnuson, 2010). Scratch ist eine weitere, blockbasierte visuelle Programmiersprache, die einfache Befehle unterstützt und Kinder motivieren soll, erste Anwendungen umzusetzen Eine Besonderheit des App Inventors liegt darin, dass es als Zielplattform auf mobile Endgeräte abgestimmt ist. Der Block Editor, der in der Anwendung zur Modellierung der Programmlogik verwendet wird, basiert auf einer Modifikation der OpenBLocks Bibliothek (Roque, 2007). Das OpenBlock Framework ist eine allgemeingültige grafische Block-Sprache, die nach eigenen Bedürfnissen angepasst werden kann.3 Beim Kompilieren wird das Programm zunächst in die Sprache YAIL übersetzt, die S-Expression verwendet und ein Scheme Programm definiert. Mit Hilfe des Kawa Frameworks wird anschließend Java VM byte code generiert. Somit wird, entgegen möglichen Erwartungen, kein Java Quellcode erzeugt (Magnuson, 2010).

3.3 Konzeptdiagramm

Der App Inventor ist ein Web Service der auf Google’s App Engine Plattform läuft. Von dort aus kann der Designer im Browser aufgerufen werden. Der Blocks Editor wird nach dem Laden der Block Datei lokal auf dem Computer mit Java ausgeführt. Vom Block Editor kann die Anwendung in einem Emulator gestartet oder auf ein angeschlossenes mobiels Endgerät gespielt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Konzeptdiagramm der App Inventor Anwendung (Quelle: Open Source)4

3.4 Verwendung an Schulen und Universitäten

Da die Vorgaben des Programms recht übersichtlich sind und der Benutzer zu einem großen Teil bei der Entwicklung geführt wird, eignet es sich im Besonderen für den Einsatz an Schulen und Universitäten. Hauptsächlich geht es darum, Schülern sowie Studierenden erste Einblicke in die Programmierlogik zu ermöglichen und das Thema auf eine ansprechende Weise nahezubringen. Meistens richten sich die Kurse an Anfänger, die noch keine Programmiererfahrung besitzen. Wie von Reichelt und Boom dargestellt wird der App Inventor in der neunten Klasse eines Gymnasiums verwendet, um neben mobilen Anwendungen auch Lego Mindstorm Roboter zu programmieren (Leimbach & Trella, 2011). Durch die steigende Popularität von mobilen Endgeräten ist das Interesse von Schülern an der Programmierung für Anwendungen stark gestiegen. (Reichelt & Van de Boom, 2011). Mit Hilfe des App Inventors kann das computerbasierte Denken an Schüler gut weitergegeben werden (Morelli, Lanerolle, Lake, Limardo, Tamotsu, & Uche, 2011). Neben der Programmierung werden auch agile Programmiertechniken vermittelt. Eine weitere Stärke ist, dass mehr Fokus auf das Lösen von Problemen in Programmieraufgaben gelegt werden kann, anstelle der Beachtung der Sprachsyntax, wie es bei klassischen Programmiersprachen der Fall ist (Morelli, Lanerolle, Lake, Limardo, Tamotsu, & Uche, 2011). „Scratch“ ist eine weitere visuelle Programmiersprache, die an Programmieranfänger gerichtet ist. Mit dieser können recht einfache Programme entwickelt werden, die in einer künstlichen Umgebung angesiedelt sind (Introduction to Computer Science with Scratch and App Inventor, 2011).

3.5 Agile Softwareentwicklung

Durch die Verwendung des AppInventor kann agile Softwareentwicklung auf eine veranschaulichte Art und Weise vermittelt werden (siehe Abbildung 3). So wird zunächst das Problem erörtert, welches mit der Anwendung gelöst werden soll. Anschließend wird ein Design als Ablaufplan entworfen. Nun beginnt der Entwicklungsprozess. Zunächst wird das Interface mit dem App Designer entworfen. Daraufhin wird mit dem Block Editor das Coding vorgenommen. Im Folgenden wird die so entstandene Umsetzung getestet und debugged. Wenn nötig werden weitere Veränderungen und Verbesserungen durchgeführt und somit schließt sich der

Kreis. Werden beim Testen und Debuggen keine Fehler mehr festgestellt, so wird die Software freigegeben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Agile Softwareentwicklung (selbst erstellte Grafik)

3.6 Systemvoraussetzungen

Da der „App Inventor“ eine webbasierte Anwendung ist, ist es möglich, diese auf so gut wie jedem Computer zu verwenden. „App Inventor“ ist betriebssystem- und browserunabhängig. Um Zugriff auf die Anwendung zu erhalten, wird ein Google-Konto benötigt. Für das Ausführen wird zudem mindestens Java 6 benötigt.

Mindestvoraussetzungen:

Computer Plattformen:

- Windows : Windows XP, Windows Vista, Windows 7
- Apple : Mac OS X 10.5, 10.6, 10.7
- GNU/Linux : Ubuntu 8+, Debian 5+

Browser:

- Mozilla Firefox 3.6 oder höher
- Apple Safari 5.0 und höher
- Google Chrome 4.0 und höher
- Microsoft Internet Explorer 6 und höher

[...]


1 Siehe http://appinventoredu.mit.edu/ abgerufen am 20.Januar 2012

2 Siehe http://code.google.com/p/app-inventor-releases/ abgerufen am 20.Januar 2012

3 Siehe http://education.mit.edu/openblocks abgerufen am 14. Januar 2012

4 Siehe http://code.google.com/p/app-inventor-releases/ source Code abgerufen am 20.Januar 2012

Autor

Teilen

Zurück

Titel: Optimierung eines Inventarisierungsprozesses mit Unterstützung einer App Inventor Android Anwendung