ActionScript 2: Ein Lehr- und Übungsbuch

Von Arno Kohl

Wer hoch interaktive Applikationen, komplexe Spiele oder multimediale Websites auf professionellem Niveau erstellen möchte, kommt an ActionScript, der Programmiersprache von Flash, nicht vorbei.Der Autor führt nicht nur in die Sprache ein, sondern vermittelt anhand zahlreicher Praxisworkshops effiziente Lösungen zu verschiedenen Problemstellungen, die in vielen Flash-Projekten auftreten.
Der erste Teil des Buches behandelt ausführlich die theoretischen Grundlagen der Sprache. Dazu gehören zentrale Sprachelemente wie Schleifen, bedingte Anweisungen oder Funktionen, aber auch Klassen wie MovieClip, BitmapData oder diverse Filter. Zusätzlich wird gezeigt, wie man sprachunabhängig systematisch Programme entwickeln kann.
Der zweite Teil setzt das Gelernte mit Hilfe der Workshops in die Praxis um. Die behandelten Themen stammen unmittelbar aus dem Praxisalltag, z.B. Bildergalerie mit XML, Preloader, modulare Website, Puzzlespiel, geskriptete Animationen etc. Alle Workshops sind so aufgebaut, dass sie, Grundkenntnisse von ActionScript vorausgesetzt, auch unabhängig vom ersten Teil des Buches bearbeitet werden können.

• Sprache: Deutsch
• Herausgeber: Springer
• Erscheinungsdatum: 4. Jan. 2011
• ISBN: 9783540351825

Buchvorschau

Arno KohlX.media.pressActionScript 2Ein Lehr- und Übungsbuch10.1007/978-3-540-35182-5_1© Springer Berlin Heidelberg 2011

1. Einleitung

Arno Kohl¹  

(1)

MacromediaAkademie für Medien, Gollierstraße 4, 80339 München , Deutschland

Arno Kohl

Email: [e-mail]

Zusammenfassung

ActionScript (kurz: AS), die in Flash integrierte Script-Sprache, hat sich im Laufe der Zeit zu einem unverzichtbaren Tool im Arsenal des Webentwicklers gemausert. Interaktive Anwendungen aller Art bis hin zu sogenannten Rich Internet Applications lassen sich mittlerweile mit Hilfe dieser Sprache realisieren. Diese Mächtigkeit hat allerdings ihren Preis, steigt doch mit den Möglichkeiten zugleich auch die Lernkurve, um sich AS anzueignen, mit jeder Flash-Version weiter an. Darum möchte Sie das vorliegende Buch bei der Hand nehmen und behutsam durch den Script-Dschungel führen.

ActionScript (kurz: AS), die in Flash integrierte Script-Sprache, hat sich im Laufe der Zeit zu einem unverzichtbaren Tool im Arsenal des Webentwicklers gemausert. Interaktive Anwendungen aller Art bis hin zu sogenannten Rich Internet Applications lassen sich mittlerweile mit Hilfe dieser Sprache realisieren. Diese Mächtigkeit hat allerdings ihren Preis, steigt doch mit den Möglichkeiten zugleich auch die Lernkurve, um sich AS anzueignen, mit jeder Flash-Version weiter an. Darum möchte Sie das vorliegende Buch bei der Hand nehmen und behutsam durch den Script-Dschungel führen.

Einsteiger-Bücher gibt es viele, und wenn man eines kennt, kennt man die meisten anderen auch. Deren größtes Manko ist der Versuch, möglichst viele AS-Befehle abzudecken. Das sieht zwar im Inhaltsverzeichnis beeindruckend aus, doch spätestens dann, wenn man an einem konkreten Projekt sitzt, werden einem allzu schmerzhaft die Lücken bewusst, die man sich angeeignet hat. Denn derartige Bücher führen in die Themen anhand von Code-Schnipseln ein, die zwar leicht verdaulich sind, aber kaum in die Tiefe gehen. Außerdem stehen diese Schnipsel oft zusammenhanglos und mitunter etwas verlegen im Raum herum. Für den Anfänger fehlt daher nicht selten die Orientierung, wo man sie in einem konkreten, dem Produktionsalltag nahe stehenden Zusammenhang einsetzen kann. Das ist etwa so, als wollte man für eine Reise nach Frankreich Französisch lernen und würde dabei ein Lexikon verwenden anstelle eines Sprachführers.

Daher verfolgt das vorliegende Buch einen anderen Ansatz. Wir verzichten hier auf eine lexikalische Auflistung und Behandlung aller AS-Sprachelemente. Für diesen Zweck genügt zumindest prinzipiell die Flash-Hilfe. Statt dessen konzentrieren wir uns auf ausgesuchte Konzepte und Elemente sowie deren Bedeutung in der Praxis. Eine derartige Auswahl muss notgedrungen subjektiv ausfallen. Immerhin spiegeln sich in ihr zahlreiche Jahre Programmier- und Lehrerfahrung wieder, so dass sie nicht völlig willkürlich ist. Die Konzepte und Elemente werden zwar am konkreten Beispiel von ActionScript behandelt, besitzen jedoch zu einem beträchtlichen Teil sprachunabhängig Gültigkeit. Dazu gehören beispielsweise Variablen, Arrays oder Kontrollstrukturen, die von der Idee her auch in anderen Sprachen wie PHP und Javascript vorkommen. Ebenso ist die Beschreibung des Entwicklungsprozesses eines Programms nicht an Flash gebunden. Damit werden Sie in die Lage versetzt, sich im Fall der Fälle relativ einfach in andere Sprachen einzuarbeiten, falls Sie sich die vorgestellten Konzepte angeeignet haben. Denn es gehört zu den angenehmen Seiten der Programmierung, dass zahlreiche Sprachen mit vergleichbaren Konzepten arbeiten, so dass solide Kenntnisse in einer Sprache das Wechseln zu einer anderen durchaus erleichtern können. Man kann mitunter sogar Lösungen aus einer Sprache in eine andere übertragen, ohne diese Lösung selbst von Grund auf neu entwickeln zu müssen.

Der erste Teil des Buches beginnt mit einem Überblick über die Geschichte von ActionScript, gefolgt von drei Kapiteln, die über die Vorgehensweisen bei der Programmentwicklung u.a. anhand eines in Pseudo-Code formulierten Programms zum Kochen von Kaffee – Genuss für Geist und Körper gleichermaßen – informieren. Gerade die relative Zugänglichkeit von AS verleitet schnell dazu, einfach mal „drauf los zu programmieren" – und spätestens dann, wenn man den eigenen Code nach einigen Wochen erweitern oder ändern muss, türmt sich ein Berg an Problemen auf, weil man ihn aufgrund mangelhafter Planung und Strukturierung weder richtig versteht noch einfach modifizieren kann. Daher kann die Bedeutung sinnvoller Planung im voraus gar nicht oft genug betont werden.

Anschließend folgen kapitelweise Beschreibungen einzelner Sprachelemente und Strukturen wie Operatoren, Variablen, Kontrollstrukturen sowie der wichtigsten Klassen wie MovieClip, BitmapData, XML etc. Besonderen Raum nimmt die MovieClip-Klasse ein, da kaum eine Applikation ohne sie auskommen kann. Diese Kapitel stellen das jeweilige Element vor und geben einzelne Codebeispiele, um ihren Einsatz zu verdeutlichen.

Damit man auch tatsächlich erfährt, was es mit diesen Elementen in der freien Wildbahn da draußen auf sich hat, bietet der zweite Teil zahlreiche Workshops, in denen sie immer wieder in den verschiedensten Zusammenhängen auftauchen. Dadurch gewinnt das ansonsten recht abstrakte Erlernen von „Vokabeln" einen unmittelbaren Praxisbezug, denn die behandelten Themen kommen zu weiten Teilen so oder in einer abgewandelten Form auch tatsächlich im Produktionsalltag vor. Aus didaktischen Gründen musste zwar manches gekürzt oder geändert werden, da der Platz im vorliegenden Buch einfach nicht ausreichte, alles erschöpfend zu behandeln. So manches dort verwendete Skript lässt sich noch optimieren. Damit ginge jedoch die relativ leichte Zugänglichkeit und Verständlichkeit verloren. Dessen ungeachtet bieten die Workshops genügend Masse, um einerseits die Sprache am lebenden Objekt einzuüben und andererseits Einblick in die tägliche Praxis der programmierorientierten Flash-Entwicklung zu gewinnen.

An dieser Stelle bemerkt der Autor zugegebenermaßen mit einer gewissen inneren Freude, dass man Skripte aus einem Buch nicht durch schlichtes Kopieren in Flash einfügen kann, sprich: Das Lernen mit diesem Buch macht nur Sinn, wenn Sie den angesprochenen Code wirklich selbst eingeben. Wer Buchstabe für Buchstabe alles abtippt, wird eher darüber nachdenken, was er tut, als wenn man einfach nur kopiert. Kopieren und kapieren sind zwei verschiedene Dinge. Um das Schreiben zu erleichtern, befindet sich am Ende der meisten Workshops des zweiten Teils eine komplette Auflistung des aktuell behandelten Codes. Innerhalb der Workshops wird er abschnitt-, mitunter auch zeilenweise entwickelt und jeweils besprochen.

Einige Übungen im ersten und nahezu alle Beispiele im zweiten Teil arbeiten mit einer sogenannten Standarddatei. Damit ist lediglich eine simple Flash-Datei gemeint, die über folgende Eigenschaften verfügt:

Größe 800×600,

Bildwiederholrate 18 BpS,

Hintergrundgrafik mit vertikalem Farbverlauf helles zu dunklem Blau,

Hauptzeitleiste mit den Ebenen actions,objects, gegebenenfalls zusätzlich bgd,

Als Grundobjekt ein einfacher MovieClip in Form einer Kugel (Kreis mit radialem Farbverlauf).

Selbstverständlich sehen Ihre Flash-Dateien im Produktionsalltag anders aus: Mal muss ein Banner in der Größe 720×90, mal eine Site im Seitenverhältnis 16×9, mal eine interaktive Animation mit 25 BpS vor einem schwarzen Hintergrund erstellt werden – kurz, es gibt endlos viele verschiedene Möglichkeiten, mit welchen Einstellungen man im Einzelnen angemessen arbeitet. Da es im vorliegenden Buch um die Aneignung von Techniken, nicht jedoch um die optimale Realisierung spezifischer Applikationen geht, verwenden wir einfach eine Standardeinstellung, die Sie Ihren besonderen Bedürfnissen im Einzelfall anpassen müssen.

Obgleich das Buch aus zwei Teilen besteht, ist es nicht notwendig, erst Teil 1 und anschließend Teil 2 zu goutieren. Wer die theoretischen Grundlagen beherrscht, kann gerne direkt mit dem Workshop-Teil arbeiten. In dem Fall sollte man allerdings das Kapitel zu Framework und Code-Organisation kennen, da dort eine Vorgehensweise erläutert wird, die in den Workshops zur Anwendung kommt.

Wer keinerlei Skriptkenntnisse besitzt, sollte dagegen systematisch alle Kapitel des ersten Teils durcharbeiten, wobei es sich empfiehlt, die vorliegende Reihenfolge einzuhalten, da sie aufeinander bezogen sind. Die Kapitel des zweiten Teils dagegen liegen unabhängig voneinander vor, so dass ein beliebiges Kapitel zum Lernen verwendet werden kann. Wer sich für Texteffekte interessiert, schlägt eben dort nach, ohne vorher etwa das Kapitel Grafikeffekte gelesen haben zu müssen.

Die Workshops fassen thematisch zusammenhängende Übungen in Kapiteln zusammen. So finden sich etwa im Kapitel Effekte (Maus) verschiedene Effekte, die in irgendeiner Form auf den Cursor bezogen sind. Die Kapitel werden mit einigen allgemeinen Hinweisen zur jeweiligen Bedeutung der konkreten Themen und Übungen eingeleitet. Danach folgt ein Überblick über das Ziel der Übung sowie eine sukzessive Auflistung der Arbeitsschritte in Form von Handlungsanweisungen. Die Schritte sind zumeist in einzelne Blöcke unterteilt, die anschließend erläutert werden. Besonderes Gewicht wird dabei auf die zugrunde liegende Logik gelegt. Sie ist letztlich wichtiger als die korrekte Syntax: Versteht man nicht, wie ein Problem gelöst wird, nützt eine fehlerfreie Syntax nichts, weil man nie in die Lage versetzt wird, eine eigene Problemlösung zu entwickeln. Eine Syntax zu erlernen ist letztlich ein reiner Gedächtnisvorgang, während die Logik einer weit darüber hinausgehenden Verstandesleistung bedarf.

An manchen Stellen wird eine konkrete Übung durch Hinweise auf Varianten ergänzt, deren Code mitunter vorgestellt wird und mitunter auch nur erwähnt wird. Solche Stellen sollten Sie als Aufforderung verstehen, um eigene Lösungen zu entwickeln.

Der in den meisten Praxisbeispielen vorgestellte Code lässt sich zwar mit einigen Änderungen direkt auf eigene Projekte übertragen, doch sollte man sich im Klaren sein, was er im Einzelnen bedeutet. Dieses Buch ist in erster Linie als Lehrbuch konzipiert und nicht als Kochbuch mit einfach zu kopierenden Rezepten bzw. Codeschnipsel.

Viele Probleme ermöglichen mehrere Lösungswege und so kann hier vorgestellter Code nur als ein möglicher, in der Praxis bewährter Weg, aber beileibe nicht als allein selig machender verstanden werden.

Gerne würde der Autor behaupten, er habe aus didaktischen Gründen bewusst einige Fehler eingebaut. Tatsächlich sind derartige Fehler bei dem vorliegenden Seitenumfang einfach unvermeidlich und der menschlichen Schwäche des Autors geschuldet. Dafür sei der Leser hier bereits um Entschuldigung gebeten.

Happy Coding!

Arno KohlX.media.pressActionScript 2Ein Lehr- und Übungsbuch10.1007/978-3-540-35182-5_2© Springer Berlin Heidelberg 2011

2. ActionScript: Geschichte, Versionen, Ausblick

Arno Kohl¹  

(1)

MacromediaAkademie für Medien, Gollierstraße 4, 80339 München , Deutschland

Arno Kohl

Email: [e-mail]

Zusammenfassung

Flash stellt eine vollständige Entwicklungsumgebung und ein Autorensystem für Online- und Offlineanwendungen nahezu jeder Art dar. Aufgrund seiner umfassenden Funktionalität hat es sich innerhalb relativ weniger Jahre von einem ursprünglich doch recht simpel gestrickten Animationsprogramm zum Standard insbesondere bei der Entwicklung von hoch interaktiven, multimedialen Anwendungen gemausert. Zu diesem enormen Erfolg trug ganz wesentlich die integrierte Skriptsprache ActionScript bei, die mittlerweile annähernd so mächtig geworden ist wie eine vollwertige Programmiersprache.

Flash stellt eine vollständige Entwicklungsumgebung und ein Autorensystem für Online- und Offlineanwendungen nahezu jeder Art dar. Aufgrund seiner umfassenden Funktionalität hat es sich innerhalb relativ weniger Jahre von einem ursprünglich doch recht simpel gestrickten Animationsprogramm zum Standard insbesondere bei der Entwicklung von hoch interaktiven, multimedialen Anwendungen gemausert. Zu diesem enormen Erfolg trug ganz wesentlich die integrierte Skriptsprache ActionScript bei, die mittlerweile annähernd so mächtig geworden ist wie eine vollwertige Programmiersprache.

Dabei wiesen die sehr bescheidenen Anfänge von ActionScript keinesfalls in die Richtung, die die Sprache nach einigen Jahren eingeschlagen hat. Denn Flash erblickte unter dem Namen FutureSplash-Animator als nettes kleines Animationsprogramm in Konkurrenz zu animierten gif-Dateien das Licht der Welt. 1996 wurde das Programm samt deren Entwickler von der im sonnigen Kalifornien ansässigen Firma Macromedia übernommen. Da der Schwerpunkt auf Animation lag, war die Scriptfähigkeit notwendigerweise bedeutungslos. In den ersten drei Flash-Versionen bestand sie lediglich aus sehr einfachen Befehlen, mit denen man Navigationen ähnlich einer Videosteuerung vornehmen konnte. So war es beispielsweise möglich, eine Zeitleiste anzuhalten und abzuspielen oder zu einem bestimmten Frame zu springen. Dabei handelte es sich um weitgehend vorgefertigte Verhaltensweisen, also fertigen Skripten, die man mit Hilfe von Eingabefeldern parametrisieren konnte. Ein direkter Zugriff auf den Code existierte nicht.

Erst mit Flash 4 schlug gewissermaßen die Geburtsstunde von ActionScript als einer eigenständigen Scriptsprache mit Elementen, wie man sie von anderen Sprachen her gewohnt ist. Dazu gehören Schleifen, Variablen und Ausdrücke, was erstmals das Erstellen umfangreicher, durchaus anspruchsvollerer Skripte ermöglichte. Offiziell firmierte die Sprache unter der Bezeichnung actions, intern verwendete man schon den heute geläufigen Namen ActionScript .

Ab dieser Version wurde die Sprache recht konsequent ausgebaut und immer näher an internationale Standards herangeführt. Bereits Flash 5 erlaubte den uneingeschränkten Zugriff auf den Code mit Hilfe eines integrierten Editors, ohne jedoch auf die von den Vorgängern her bekannte Möglichkeit eines simplen Zusammenklickens von Codeblöcken völlig zu verzichten. Dahinter stand die eigentlich bis Flash 9 bzw. CS 3 gültige Philosophie, zwei verschiedene Zielgruppen anzusprechen: Einerseits den Programmierer, der nicht davor zurückschreckt, komplexe Skripte zu entwickeln, und den Designer, der sich zwar mehr auf die Animationsfähigkeiten von Flash konzentriert, aber gleichzeitig auf eine einfache Art Interaktionen skripten möchte. Da die Sprache am ECMA 262- bzw. ECMAScript3-Standard ausgerichtet wurde, fanden sich Programmierer, die zuvor insbesondere mit Javascript gearbeitet hatten, recht schnell zurecht. Ein positiver Nebeneffekt war die relativ leichte Portierbarkeit von Code aus einer Sprache in eine andere.

Um die Entwicklung zu vereinfachen, konnte man zudem in sogenannte Smart-Clips Code und Objekte hineinpacken, so dass sie sich als fertige Elemente einsetzen ließen, ohne dass man auf den Code zugreifen musste. Ein bisschen erinnerte dieses Konzept an die Behaviors von Director, des damals noch großen Bruders von Flash, das ebenfalls von Macromedia entwickelt wurde.

Mit der Versionsnummer 5 wurde Flash, rückblickend betrachtet, tatsächlich erwachsen. Denn es gelang, das Image eines vornehmlich für zappelige Intros und Animationen geeigneten Entwicklungstools abzulegen (tatsächlich waren diese zappeligen Intros aber weniger dem Tool als vielmehr den betreffenden Entwicklern anzulasten). Nicht zuletzt eben ActionScript zeigte, was, wenn es voll ausgereizt wurde, möglich war – von kompletten, durchaus userfreundlichen, hoch interaktiven Websites über datenbankgestützte Anwendungen bis hin zu den auch heute noch allgegenwärtigen Spielen reichte die Anwendungspalette.

Beflügelt – oder muss man sagen: berauscht? – vom Erfolg schob Macromedia mit Flash MX, entstanden zu einer Zeit, als es plötzlich unmodern geworden war, Versionsnummern zu verwenden, eine stark erweiterte Version von ActionScript nach. Die wichtigste, die Sprache partiell bis heute prägende Neuerung war ein alternatives Ereignismodell, das es erlaubte, in einem einzigen Bildscript allen Objekten die benötigten Ereignisse und Aktionen zuzuweisen. Die Verwendung eigenständiger Objektscripte wurde damit prinzipiell obsolet. Dadurch gewann der Sourcecode an Übersichtlichkeit, denn die endlos verschachtelten Objekte (Movieclips und Buttons) machten es bisher ausgesprochen leicht, Code irgendwo regelrecht zu vergraben. Die Standardisierung von AS wurde vorangetrieben durch eine noch striktere Beachtung des ECMA-Standards.

Neben einer erweiterten, umfangreichen Funktionsbibliothek verfügte Flash MX über eine neue API, die es erlaubte, dynamische Vektorgrafiken zu programmieren. Aus den Smart-Clips entwickelten sich die komplexeren Komponenten, die mitunter schon den Charakter eigenständiger Anwendungen annehmen konnten. Als kleines Schmankerl bot man Programmieren die Möglichkeit prototypbasierter objektorientierter Programmierung, wenn auch in einer recht rudimentären Form.

Der starke Ausbau der Scriptmöglichkeiten verdeutlichte zugleich, in welche Richtung man sich die Weiterentwicklung des Programms dachte – letztlich eine Grundsatzentscheidung, die im Großen und Ganzen bis zur aktuellen Version 11 bzw. CS5 beibehalten wurde. Denn während jede neue Version immer ausgeklügeltere Features für den Programmierer bot, wurden die Designer hinsichtlich der Grafikwerkzeuge bis heute nur mit wenigen interessanten Neuerungen bedacht, nämlich die längst überfälligen Ebeneneffekte in Flash 8, die in der Tat beeindruckende Videounterstützung ab Flash MX 2004 und Bones-Animation sowie (leider nur halbausgegorenes) 3D in CS4. Mittlerweile scheint auch die Unterstützung der Designer in der Programmierung zu bröckeln, wird doch ActionScript mit jeder Version komplexer und für einen eher unbedarften Neuling undurchdringlicher. Dabei waren es gerade die Designer, die Flash einst entdeckt hatten!

Schon damals wurde als Parole die Entwicklung von RIA, Rich Internet Applications, ausgegeben, also komplette, nicht selten datenbankgestützte Online-Anwendungen. Dem war jedoch aller Euphorie zum Trotz Flash (noch) nicht gewachsen, wie der Online-Auftritt von Macromedia selbst bewies.

Der Nachfolger Flash MX 2004 machte einen weiteren großen Schritt nach vorn, indem neben die bestehende ActionScript -Version das neue AS 2.0 trat, das u.a. eine bessere Fehlerkontrolle durch eine strikte Typisierung, ein leistungsfähigeres, wenn auch gegenüber vorher umständlicheres Listener-Ereignismodell und vor allem eine an höhere Programmiersprachen angelehnte objektorientierte Programmierung ermöglichte. War Flash mit Version 5 erwachsen geworden, so geschah dasselbe bei ActionScript mit Version 7 (bzw. MX 2004).

Hier wie auch an anderer Stelle musste man als Entwickler jedoch der Entwicklungsgeschichte des Programms Tribut zollen: Um die Abwärtskompatibilität zu älteren Flash-Playern zu bewahren, erfolgte die Kontrolle der Typisierung ausschließlich in der Autorenumgebung, während sich der Player wie schon zuvor genügsam mit, um es böse zu formulieren, „Codesalat" zufrieden gab. Faktisch bedeutete dies, dass AS 2.0 Code durch die AVM (ActionScript Virtual Machine), die den erstellten Code interpretiert, in AS 1.0 umgewandelt wurde. All die schönen neuen Möglichkeiten, die eine an höhere Programmiersprachen angelehnte Struktur erlaubten, wurden damit partiell zunichte gemacht, und auch die Performance entsprach nicht dem, was man erwarten darf. Erst Flash 9 hat hier zu einer grundlegenden Änderung geführt.

Aus Entwicklersicht bot ActionScript damit immerhin eine stabilere Programmierung und eine größere Funktionalität. Andererseits allerdings stieg die Lernkurve für Scriptanfänger stark an. Gerade der leichte Zugang zum Scripting war ja bisher eine der wesentlichen Stärken von Flash gewesen. Dessen eingedenk entschied sich Macromedia zu einem Beibehalten von AS 1.0.

Konsequenter als der Vorgänger ermöglichte Flash 8, das sich wieder mit einer Versionsnummer schmücken durfte, objektorientiertes Programmieren. Die Entwickler spendierten dem Programm eine umfangreiche Klassenbibliothek insbesondere zur direkten Manipulation von Bitmapgrafiken auf Pixelebene sowie zum Up- und Download von Dateien. Der Zugriff auf Bitmaps erlaubte geskriptete Effekte, die zuvor gar nicht oder nur unter erheblichem Aufwand möglich waren. Man denke nur an Bumpmapping, eine Technik, die auf zweidimensionalen Objekten eine dreidimensionale Oberfläche durch Tiefeninformationen simuliert. Allerdings erwiesen sich insbesondere die neuen Filter-Klassen im Gebrauch als recht sperrig. So verlangen sie nach – salopp formuliert – einem Dutzend Pflicht- und einem weiteren Dutzend optionaler Parameter, deren Sinn nicht immer leicht zu erkennen ist. Eigentlich sollte in einem derartigen Fall die Programmhilfe erschöpfend Auskunft erteilen. Aber Flash 8 präsentiert sich als die erste Version, deren Dokumentation neuer Befehle und Elemente so unverständlich ist und deren Beispiele so unglücklich gewählt wurden, dass sie für Skript-Einsteiger faktisch fast schon wertlos ist. Man gewinnt den Eindruck, sie sei von Spezialisten für Spezialisten geschrieben – was aber gerade dem Sinn einer Hilfe widerspricht und angesichts der aufgrund der Sprachkomplexität steil angestiegenen Lernkurve schlicht eine Fehlentscheidung darstellt.

Flash 9, 2007 auf dem deutschen Markt erschienen, stellt vielleicht nicht nur einen neuen Meilenstein, sondern sogar einen Wendepunkt dar. Denn diese Version wartet mit einer stark überarbeiteten, neuen Version der Scriptsprache, nämlich AS 3.0 auf, die konsequent objektorientiert aufgebaut ist und sich eigentlich kaum mehr von einer Hochsprache unterscheidet. Ihr wurde im Flash-Player eine eigene Virtual Machine, AVM2, gewidmet, die unabhängig neben der aus Kompatibilitätsgründen beibehaltenen AVM1 enthalten ist. Sie zeichnet sich endlich durch die längst fällige höhere Performance aus, setzt aber eben auch das erheblich komplexere AS 3.0 voraus. Die Version 10 baut AS 3.0 aus, bietet die Möglichkeit, Objekte statt Frames zu tweenen, verfügt über einen modifizierten Editor für Tweens und beschenkt den Entwickler, wie erwähnt, mit inverser Kinematik und 3D. Dessen ungeachtet bleibt noch Raum für viele weitere Features, die zukünftige Versionen von Flash sicher bringen werden. Interessanterweise hat der deutsche Markt nach Angaben des Herstellers so an Bedeutung zugenommen, dass die lokalisierte Version von Flash diesmal früher erschienen ist als sonst üblich.

Im Rückblick zeigt sich eine permanente, durchaus viele Wünsche der Flash-Entwickler berücksichtigende Weiterentwicklung von AS, das sich im Laufe der Jahre zu einer mächtigen Skriptsprache mauserte. Sie steht zur Zeit noch konkurrenzlos da – auch wenn sich am Horizont in Form von Microsofts Silverlight sowie HTML5 dunkle Wolken andeuten.

Der enorme Erfolg von AS birgt gleichzeitig ein Risiko in sich, das in keiner Version so deutlich zum Vorschein trat wie bei Flash 9 bzw. AS 3.0. Denn diese Sprachversion ist derart umfangreich geworden, dass sich ein Einsteiger mit einer fast ähnlich steilen Lernkurve herumschlagen muss wie bei einer höheren Programmiersprache. Insofern steht Flash an einem Scheideweg: Sollen zukünftige Versionen die Funktionalität der Scriptsprache wie bisher weiter ausbauen? Wie wäre es beispielsweise mit einer echten 3D-Unterstützung, wie sie bereits seit Jahren der langsam in die Vergessenheit sinkende, einst große Bruder von Flash, nämlich Director, beherrscht? Das häufig gehörte Argument, damit wachse der Player notwendigerweise auf eine Größe von mehreren MB an, wird immer unbedeutender angesichts der Tatsache, dass DSL mittlerweile als Standard gelten darf. Das würde natürlich alle professionellen Entwickler und Programmierer freuen, geschähe aber zum Leidwesen der Designer und Gelegenheitsprogrammierer.

Oder soll man stärker die Designer berücksichtigen, die nach Jahren erst wieder mit den Ebeneneffekten in Flash 8 und der IK sowie einem überarbeiten Motion-Editor in Flash 10 ein Zückerchen geboten bekamen, während sich die meisten anderen neuen Features eher auf die Programmierung bezogen? So mancher Designer würde sich eine bessere Unterstützung bei Animationen wünschen. Schön wären beispielsweise verschiedene Kamera-Perspektiven, wie sie etwa in ToonBoom-Studio schon lange integriert sind. Sie würden die Erstellung von Animationen nicht unwesentlich erleichtern.

Unabhängig davon, wie zukünftige Flash-Versionen aussehen, sind heutige „Flasher" zunehmend gezwungen, mit ActionScript umzugehen. Denn eben weil es nicht mehr das simple Animationstool von einst ist, sondern eine mächtige Entwicklungsumgebung, deren Potential aber erst wirklich ausgeschöpft wird, wenn man sich der Scriptsprache bedient, werden selbst Designer mit Programmierung konfrontiert. Moderne Webseiten glänzen nicht alleine durch attraktives Design, sondern bieten ein hohes Maß an Funktionalität, das sich nur noch über Programmierung herstellen lässt. Das gilt erst recht für Applikationen, also vollständige Anwendungen, die, glaubt man den Auguren der Branche, dereinst Desktop-Applikationen weitgehend ersetzen werden (auch wenn das noch eher Zukunftsmusik darstellt). Aus dem Flash-Designer wird ein Flash-Entwickler, für den solide Grundkenntnisse in ActionScript unverzichtbar sind.

Damit stellt sich die Frage nach der AS-Version, mit der man arbeiten soll. Für den gestandenen Programmierer kann die Antwort nur lauten: AS 3.0. Denn so lassen sich endlich Konzepte umsetzen, die aus der professionellen Softwareentwicklung bekannt und jahrelang erfolgreich eingesetzt wurden. Gerade größere, komplexere Projekte profitieren von den Möglichkeiten dieser Version.

Die Mehrzahl der Flash-Entwickler gehört jedoch (immer noch) nicht zu dieser Kategorie, sondern stammt zumeist aus dem Bereich des Designs und der Web-Entwicklung. Ihnen fehlen daher oft die formalen Voraussetzungen, um problemlos mit einer derart komplexen, an eine Hochsprache angelehnten Scriptsprache zu arbeiten. Lohnt sich der Einstieg in AS 3.0?

In den meisten Fällen lautet die Antwort derzeit wohl: Nein. Das mag überraschen, zumal in einem Buch, das sich mit Programmierung befasst. Doch sollte man mit beiden Füssen auf dem Boden der Realität bleiben:

Für einen Nicht-Programmierer steigt die Lernkurve bei AS 3.0 so stark an, dass man sich genauso gut direkt auf eine Hochsprache wie Java stürzen kann. Wie viel Web-Entwickler, prozentual gesehen, brauchen Java wirklich? Für ein „normales" Web-Projekt lohnt sich der Aufwand nicht, eine Hochsprache zu erlernen, und AS 3.0 liegt, wie gesagt, aufgrund seiner Komplexität recht nahe an einer derartigen Hochsprache.

Der Erstellungsaufwand für eine Flash-Anwendung erhöht sich zunächst, da AS 3.0 einen recht konsequenten objektorientierten Ansatz verfolgt. So verlangt nun das früher so einfache Zuweisen eines Ereignisses, abgehandelt in einer einzigen Zeile, umständlich nach einem Listener sowie gegebenenfalls dem Import von Klassen.

Für AS 3.0 reicht es nicht aus, einfach nur neue Befehle zu erlernen. Vielmehr steckt eine konsequente Objektorientierung dahinter, die dazu zwingt, vor einem Projekt eine saubere objektorientierte Analyse zu erstellen. Sonst kann es schnell geschehen, dass man viele verschiedene Klassen anlegt, die mehrfach dasselbe tun – als Ergebnis erhält man mindestens eben so gefährlichen Codesalat, wie er gerne von gestandenen Programmierern den AS1-Skriptern vorgeworfen wird. Eine saubere Klassenstruktur erhält man nicht en passant, sondern bedeutet einen enormen Lernaufwand. Aus jahrelanger Dozententätigkeit weiß der Autor, dass gerade dieser Punkt vielen Webentwicklern enormes Kopfzerbrechen bereiten kann und dass viele sich gar nicht die Zeit nehmen (können), um hier richtig einzusteigen.

Flash hatte den enormen Vorteil, dem Designer die Möglichkeit zu bieten, relativ einfach Interaktionen und komplexere Anwendungen zu programmieren. Es konnte zumindest prinzipiell alles aus einer Hand entstehen. Wagner spricht zutreffend von der Ein-Mann-Show (Mobile Games mit Flash, p. 8). Das ist zweifelsohne eine der Gründe für die enorme Popularität von Flash als Autorensystem. Mit AS3 ändert sich das grundlegend: die Entwickler werden zu einem Spezialistentum gezwungen, bei dem eine deutliche Trennung zwischen Coder (Programmierer im eigentlichen Wortsinne) und Designer entsteht. AS3 ist schlicht zu komplex, um auf die Schnelle eine Applikation zu skripten und dabei wirklich zu wissen, was man tut. OOP ist eben nichts, was man mal en passent erledigt. Den Informatiker freut’s, den Designer graust’s.

Schon aus rein pragmatischen Gründen wird sich die Mehrzahl der Flash-Entwickler daher sinnvollerweise eher mit AS 2.0 anstatt 3.0 befassen müssen (wollen, sollen). Und dem trägt auch dieses Buch Rechnung, indem es sich weitgehend auf AS 2.0 beschränkt.

Bereits Version 2.0 bietet so viele Möglichkeiten, dass sie i.d.R. gar nicht ausgeschöpft werden. Auch vor diesem Hintergrund macht es wenig Sinn, sich eine neue, noch mehr (genau so wenig ausgereizte) Features bietende Version anzueignen. Es ist schon erstaunlich, wie groß beispielsweise die Kluft zwischen den Möglichkeiten, welche die in Flash 8 eingeführte BitmapData-Klasse bietet, und deren konkrete Verwendung ist. Anstelle der ColorTransform-Klasse findet nach wie vor die veraltete Color-Klasse Verwendung. Und die Rechnung mit einer Matrix, die uns in AS 2.0 an mehreren Stellen begegnet und Potential vor allem bei der Programmierung grafischer Effekte besitzt, wird so wenig eingesetzt, weil sie für viele Flash-Entwickler eher ein Mysterium Tremendum als ein sinnvolles Hilfsmittel darstellt.

Das Problem der richtigen Sprachversion hat wie kaum ein anderes die Gemüter der Flash-Entwickler erhitzt, und so manches Flash-Urgestein wie etwa Philipp Kerman entscheidet sich bei kleineren bis mittleren Projekten zugunsten von 2.0 anstatt von 3.0. Zudem wartet die neue Sprachversion, falls man nicht mit CS 4, sondern dem Vorgänger arbeitet, mit einigen Ungereimtheiten auf, die das Programmieren partiell erheblich erschweren. Dazu gehört insbesondere das gegenüber bisher ausgesprochen unglücklich gehandhabte Entfernen extern geladener swf-Dateien sowie eine deutlich optimierfähige Garbage Collection. Kein Geringerer als Colin Moock hat sich ausführlich mit derartigen Problemen beschäftigt, und einen Einblick in die Diskussion findet der geneigte Leser unter:

C. Moock: „The Charges Against ActionScript 3.0", www.insideria.com/2008/07/the-charges-against-actionscri.html.

Brendan Hall und Joshua Davis, beides profilierte Flash-Entwickler, die schon frühzeitig das Potential von Flash sowohl in programmiertechnischer wie designerischer Hinsicht ausreizten, wobei insbesondere Davis beide Bereiche zu verknüpfen suchte, urteilen über den heutigen Stand:

„Flash has matured incredibly in the past decade, but it has done so in a way that has blocked non-developers from even getting started. The simple fact of the matter is that with older versions of Flash you could learn the tool and how to program ActionScript almost entirely through creative play. With the latest iterations, unless you have a background in object-oriented programming, that method of learning by doing is simply not an option."

Als Konsequenz aus dieser Malaise entwickelten sie unter dem Stichwort „Hype" ein Framework, das jedem Interessierten den schnellen und einfachen Zugriff auf die Programmierfähigkeiten von Flash erlaubt, ohne sich in eine komplex gewordene Programmiersprache einarbeiten zu müssen.

Arno KohlX.media.pressActionScript 2Ein Lehr- und Übungsbuch10.1007/978-3-540-35182-5_3© Springer Berlin Heidelberg 2011

3. Programmentwicklung und Programmiersprachen

Arno Kohl¹  

(1)

MacromediaAkademie für Medien, Gollierstraße 4, 80339 München , Deutschland

Arno Kohl

Email: [e-mail]

Zusammenfassung

Programmieren ist eine Wissenschaft für sich – das mag banal klingen, aber gerade der Neuling, der sich naturgemäß kopfüber ins Programmieren stürzt, wird sehr schnell an Grenzen stoßen. Einerseits hat sich ActionScript zu einer recht komplexen, mächtigen Sprache entwickelt, andererseits erfordern heutige Flash-Projekte, die rasch auf viele Hundert oder Tausend Zeilen Quellcode anwachsen, sorgfältige Planung, will man nicht in einem Wust aus Spaghetti-Code und geskriptetem Nonsens untergehen. Angemessene Programmentwicklung setzt i. d. R. strukturiertes, überlegtes Vorgehen und systematische Planung voraus, um einerseits möglichst effizient und andererseits möglichst fehlerfrei arbeiten zu können. Insofern gleicht das Programmieren einer Anwendung dem Bau eines Hauses: Bevor man die Baugrube ausheben kann, muss man sich erst einmal einen Konstruktionsplan zurecht legen, an dem sich die einzelnen Bauphasen orientieren können.

Programmieren ist eine Wissenschaft für sich – das mag banal klingen, aber gerade der Neuling, der sich naturgemäß kopfüber ins Programmieren stürzt, wird sehr schnell an Grenzen stoßen. Einerseits hat sich ActionScript zu einer recht komplexen, mächtigen Sprache entwickelt, andererseits erfordern heutige Flash-Projekte, die rasch auf viele Hundert oder Tausend Zeilen Quellcode anwachsen, sorgfältige Planung, will man nicht in einem Wust aus Spaghetti-Code und geskriptetem Nonsens untergehen. Angemessene Programmentwicklung setzt i.d.R. strukturiertes, überlegtes Vorgehen und systematische Planung voraus, um einerseits möglichst effizient und andererseits möglichst fehlerfrei arbeiten zu können. Insofern gleicht das Programmieren einer Anwendung dem Bau eines Hauses: Bevor man die Baugrube ausheben kann, muss man sich erst einmal einen Konstruktionsplan zurecht legen, an dem sich die einzelnen Bauphasen orientieren können.

3.1 Ansätze (Top-Down, Bottom-Up)

Es gibt keinen Königsweg zum guten Programm, aber im Laufe der Zeit haben sich einige Vorgehensweisen herausgebildet, um einem die Arbeit zumindest zu erleichtern. Zu den erfolgversprechendsten Methoden gehören der Top-Down- und der Bottom-Up-Ansatz.

Der Top-Down-Ansatz versucht, unabhängig von konkreten Details einen Gesamtüberblick über ein Problem zu erhalten. Im nächsten Schritt wird es in möglichst wenige, z.B. drei oder vier, Teilprobleme zerlegt. Auch auf dieser Stufe geht es noch nicht vornehmlich um einzelne Details. In einem weiteren Schritt wird jedes Teilproblem seinerseits in einige wenige Teile zerlegt. Dies führt man solange durch, bis eine weitere Unterteilung nicht mehr möglich erscheint. Dann befindet man sich auf der untersten Stufe und damit zugleich bei kleinsten Details. Dieser Ansatz beschreibt ein Problem in einer Art Pyramide und arbeitet sich von allgemeinen Fragestellungen vor bis hin zur kleinsten Einzelheit. Insofern stellt dieser Ansatz eine große Kiste zur Verfügung, in die wir alle Elemente hineinpacken, die ein Problem oder eine Aufgabenstellung charakterisieren. Ein zeitlicher Ablauf oder eine logische Verknüpfung zwischen den einzelnen Elementen wird nicht definiert. Die Programmierung kann erst einsetzen, nachdem die Analyse vollständig abgeschlossen wurde.

Der Vorteil besteht darin, dass man zu jedem Zeitpunkt einen vollständigen Überblick besitzt, ohne von Detailfragen abgelenkt zu werden. Dem stehen allerdings einige Nachteile gegenüber wie insbesondere die zumeist geringe Flexibilität. Denn wenn sich im Laufe der Entwicklung die Problemstellung aus welchem Grund auch immer ändert, ist man gezwungen, die Top-Down-Analyse erneut durchzuführen, da sich die Beziehung der Elemente untereinander, u.U. auch die Elemente selbst nun geändert haben. Das Gesamtgefüge der ursprünglichen Analyse stimmt nicht mehr mit der aktuellen Situation überein.

Der Bottom-Up-Ansatz dreht den analytischen Prozess um und beginnt am Boden der Pyramide. Er greift sich ein Element (z.B. Objekt, Klasse, Methode etc.) heraus und analysiert alle notwendigen Details möglichst unabhängig von der Frage, wie sich dieses eine Element in den Gesamtzusammenhang fügt. Dann folgt die Analyse des nächsten Elements. Dies geschieht solange, bis sich aus den einzelnen Elementen der Gesamtzusammenhang erschließen lässt. Ist ein Element ausreichend definiert, kann man zumindest prinzipiell schon mit der Programmierung beginnen, obwohl die gesamte Analyse noch nicht abgeschlossen ist.

Zu den unbestreitbaren Vorteilen zählt die größere Flexibilität. Weil zunächst kein übergreifender Zusammenhang definiert wird, kann man auch zu einem späteren Zeitpunkt relativ problemlos weitere Elemente hinzufügen, falls es die Situation erforderlich macht. Zudem kann bereits zu einem frühen Zeitpunkt Programmcode geschrieben werden. Allerdings läuft man durch die im Anfangsstadium erfolgende Konzentration auf einzelne Details Gefahr, sich darin zu verlieren und nie den Gesamtüberblick zu erhalten, der aber notwendig ist, um alle Teile im Rahmen eines Programms zusammenfügen zu können. Zu frühes Programmieren birgt zudem das Risiko in sich, dass der aktuelle Code nicht optimal auf den später hinzukommenden Code abgestimmt ist.

Nach der Problemanalyse, die zu einer Beschreibung des Programms führt, folgt die Entwicklung der Programmlogik. Während die über die erwähnten Ansätze realisierte Programmbeschreibung festlegt, was das Programm tun soll, beschreibt die Logik, wie es das tun soll. Anders als zuvor spielt nun die Reihenfolge einzelner Arbeitsschritte eine entscheidende Rolle.

3.2 Algorithmus als Problemlösung

Aus der Problemanalyse muss sich in irgendeiner Form eine Lösung erarbeiten lassen. Sie wird als Algorithmus bezeichnet, worunter man eine endliche (begrenzte) Anzahl an Schritten zur Lösung eines exakt formulierten Problems versteht. Ein Algorithmus gibt also Handlungsanweisungen und legt so den Ablauf eines Prozesses fest. Formal gesehen verfügt eine derartige Lösung über bestimmte Eigenschaften, zu denen u.a. zählen:

Ausführbarkeit. Selbstverständlich müssen die Handlungsanweisungen ausführbar sein, also z.B. von einer Maschine befolgt werden können. Das ist dann der Fall, wenn sie möglichst kleinschrittig sind und in einer spezifischen, für die Maschine verständlichen Form wie z.B. einer Programmiersprache dargeboten werden. Dazu gehört auch das eindeutige Vorhandensein aller Informationen, um den entsprechenden Lösungsprozess ausführen zu können.

Endlichkeit. Die Lösung muss über eine feste Länge an Schritten verfügen. Ein Prozess, den wir mit unendlich vielen Schritten beschreiben müssten, ließe sich nie als Algorithmus umsetzen.

Terminierung. Der Lösungsprozess muss über eine Endebedingung verfügen, d.h. es muss festgelegt sein, wann die Ausführung zu Ende ist. Dieser Punkt bezieht sich auf die Ausführung, während der vorhergehende Punkt eine Aussage zur Beschreibung trifft.

Determinismus. Bei jedem beliebigen Schritt des Algorithmus muss eindeutig feststellbar sein, an welcher Stelle man sich gerade befindet. Zusätzlich muss bei gleichen Ausgangsbedingungen bzw. Eingaben auch immer das gleiche Ergebnis erzielt werden.

Das klingt alles recht abstrakt, beschreibt aber in allgemeiner Form jede Art von Handlungsanleitungen, egal ob ein Kochrezept, eine Wegbeschreibung oder eine Bedienungsanleitung für ein neues Handy. Ja, auch für ein Handy benötigen wir mittlerweile eine Anleitung. Früher konnte man damit einfach telefonieren, doch das moderne Handy ist längst zum multifunktionalen Äquivalent des Schweizer Taschenmessers im Kommunikationsbereich mutiert und widersetzt sich zunehmend einer einfachen Bedienbarkeit nach der klassischen Trial & Error-Methode.

Die Problemstellung „Handy bedienen resultiert daher in einem umfangreichen Algorithmus „Bedienungsanleitung, der recht komplex ausfallen kann. Diese Bedienungsanleitung muss in einer verständlichen Sprache abgefasst sein, damit die Einzelschritte befolgt werden können (Ausführbarkeit). Was so selbstverständlich klingt, gelingt leider nicht in jedem Fall, weder in der Programmierung noch bei Bedienungsanleitungen, oder ist Ihnen klar, wie folgende Anweisung zu deuten ist: „Wenn das Wetter kalt ist, wird die Puff Unterlage sich langsam puffen. Entrollen die Puff Unterlage und liegen auf ihr, dann wird sie von der Wärme sich Inflationen bekommen" (Jürgen Hahn: Jetzt zieh den Zipfel durch die Masche; Zürich 1994)?

Verständlicherweise sollten wir bei einem Handy mit zwei, drei Schritten, jedenfalls mit einer fest definierten und möglichst geringen Anzahl, in die Lage versetzt werden, einen Gesprächspartner anzurufen (Endlichkeit). Selbst ein Schweizer Taschenhandy, mit dem wir gleichzeitig im Internet surfen, unsere Umgebung filmen und dem Kühlschrank zu Hause die Anweisung geben, fehlende Lebensmittel automatisch per E-Mail zu ordern, erlaubt es, zu telefonieren.

Das Ergebnis der Arbeitsschritte ist entweder ein Telefongespräch oder eine Mitteilung über die (momentane) Unerreichbarkeit des gewünschten Gesprächspartners (Terminierung). In jedem Fall wird klar, wann der Prozess des Telefonierens endet.

Unabhängig davon, wann man sein Handy zückt und versucht, zu telefonieren, ist das Ergebnis immer dasselbe, nämlich so, wie im vorhergehenden Abschnitt angesprochen (Determinismus). Der Prozessablauf ist exakt festgelegt, bei jedem Einzelschritt ist dem Anwender erkennbar, wo er sich gerade befindet. Und das Ergebnis des Prozesses ist vorhersagbar. Wir müssen nicht damit rechnen, dass unser Handy bei Betätigen das Haus des Nachbarn sprengt oder unser Auto startet (nun ja, Letzteres ist sicher nur noch eine Frage der Zeit).

Prinzipiell funktioniert ein Algorithmus für ein Computerprogramm nicht anders. Wenn es uns dennoch leichter fällt, Handlungsanleitungen bezüglich des Telefonierens zu verstehen als Programmcode zu lesen, so liegt das lediglich an der Form, in der uns die Anweisungen für den Computer begegnen. Sie liegen in einer jeweils eigenen Sprache vor, die über eine spezifische Syntax (Struktur, Grammatik) und Semantik (Bedeutung) verfügt. Genau das aber gilt auch für die erwähnte Handlungsanleitung, die nur deshalb von uns so einfach verstanden werden kann, weil uns die Syntax und Semantik der verwendeten Sprache vertraut sind. Würde die Anleitung beispielsweise in Suaheli abgefasst, sähe sie genau so unverständlich aus wie Programmcode.

In einer grundlegenden Hinsicht unterscheiden sich allerdings Handlungsanleitung und Programmcode voneinander: Menschen sind in der Lage, mit unvollständigen Informationen umzugehen, Computer dagegen nicht (an dieser Stelle wollen wir den spannenden Bereich der Fuzzy Logic unbeachtet lassen). Wenn jemand die Anweisung erhält, für einen Besucher eine Tasse zu holen, damit dieser sich Kaffee hinein schütten kann, dürfen wir in den meisten Fällen davon ausgehen, eine saubere Tasse zu erhalten. Ist sie es nicht, wird sie gespült, oder es erfolgt solange eine Suche, bis eine saubere Tasse aufgetrieben werden konnte. In einem Computerprogramm dagegen müsste die Tasse spezifiziert werden: „Sauber" könnte man als Eigenschaft der Tasse bezeichnen, die true, also wahr sein müsste, bevor sie verwendet werden dürfte. Andernfalls wäre das Programm nicht in der Lage, zu entscheiden, welche Art von Tasse gewünscht wird. So wichtig dieser Punkt ist, so häufig machen gerade Anfänger den Fehler, Bedingungen vorauszusetzen, die einem Programm eigentlich explizit mitgeteilt werden müssten. Damit schleichen sich Fehler ein, die ausgesprochen schwer zu bereinigen sind, weil sie zwar der Logik, nicht jedoch der Syntax der verwendeten Programmiersprache widersprechen. Syntaxfehler lassen sich durch Tools i.d.R. recht einfach automatisiert finden, Logikfehler dagegen nicht. An dieser Stelle künden sich schon lange Nächte an.

3.3 Hilfsmittel zur Entwicklung von Algorithmen

Gerade am Anfang stellt sich die Frage, wie man denn für ein Problem eine angemessene Lösung entwickeln kann, bevor man den betreffenden Programmcode schreibt. Es existieren mehrere Vorgehensweisen, die mit wechselnden Abstraktionsleveln und partiell mit visuellen Hilfsmitteln arbeiten. Dazu gehören:

Flowchart. Der Ablauf eines Programms wird mit genormten Symbolen visualisiert. Wer beispielsweise aus dem Design-Bereich zur Programmierung findet, kennt eine ähnliche Vorgehensweise. Dort dienen Flowcharts dazu, um Strukturen wie etwa den hierarchischen Aufbau eine Site zu erfassen. In der Programmierung bildet ein Flowchart dagegen einen Prozess ab.

Natürliche Sprache. In dieser Form haben wir im vorhergehenden Absatz bereits das Telefonieren angesprochen. Gemeint ist, dass man eine Problemlösung in beredter Prosa formuliert, ohne sich an eine allzu strenge Form zu halten. Der Vorteil besteht in der Möglichkeit, schnell eine Handlungsanleitung zu erhalten, da die verwendete Sprache unserer Alltagssprache entspricht.

Pseudo-Code. Wer bereits über Programmierkenntnisse verfügt, kann mit einem Zwitter zwischen beredter Prosa und halbwegs formaler Syntax eine Problemlösung erarbeiten und beschreiben. Solcher Code soll möglichst unabhängig von der Syntax einer konkreten Programmiersprache formuliert werden.

Wir wollen uns die Verwendung von Flowcharts und Pseudo-Code etwas genauer anschauen. Dabei konzentrieren wir uns auf die klassische funktionale Programmierung, objektorientierte Programmierung dagegen wird nicht weiter berücksichtigt. Wir wählen diese Vorgehensweise, um die Lernkurve nicht allzu steil ansteigen zu lassen.

3.3.1 Flowcharts

Sucht man eine Vorgehensweise, die einerseits ohne allzu intensive Programmierkenntnisse funktioniert und andererseits trotzdem die gewünschte Programmfunktionalität verständlich abbildet, so empfiehlt sich ein Flowchart (Flussdiagramm). Es existieren zahlreiche spezialisierte Programme, die genormte Symbole zur Erstellung anbieten. Leistungsfähig ist beispielsweise SmartDraw, das sich neben leichter Bedienbarkeit durch eine ausgesprochen große Symbolbibliothek auszeichnet. Natürlich existieren wie immer im Freeware- und Open Source-Bereich ebenfalls Programme, die durchaus Vergleichbares leisten. Notfalls kann man sich auch mit Flash (bzw. einem beliebigen Vektor-Grafikprogramm) begnügen, denn die wichtigsten Symbole lassen sich schnell als MovieClip oder Grafik-Objekt erstellen.

Um die Entwicklung verständlicher Flowcharts zu ermöglichen, legt die Norm DIN 66001 fest, welche Art von Symbolen verwendet werden sollte. In den meisten Fällen reicht es aus, wenn Sie mit den in den Abbildungen 1 und 2 gezeigten Symbolen arbeiten.

A978-3-540-35182-5_3_Fig1_HTML.gif

Abbildung 1:

Standardsymbole zur Entwicklung eines Flowcharts

Ein Diagramm könnte beispielhaft so aussehen, wie in Abbildung 2 gezeigt.

A978-3-540-35182-5_3_Fig2_HTML.gif

Abbildung 2:

Beispielhaftes Flussdiagramm (Programmlogik)

Diese Abbildung visualisiert in vereinfachter Form den eigentlich erstaunlich komplexen Vorgang des allmorgendlichen Aufbruchs zur Arbeitsstelle. Sobald wir über die Türschwelle treten, beginnen die Probleme, dargestellt an nur einem exemplarisch behandelten Beispiel. So müssen wir uns die Frage stellen, ob es regnet oder ob im Laufe des Tages Regen zu erwarten ist. Falls ja, nehmen wir einen Regenschirm und marschieren anschließend zur Bushaltestelle. Falls nein, gehen wir zu Fuß zum Ziel. In beiden Fällen endet der Prozess zumeist mit der Ankunft an der Arbeitsstelle.

Flussdiagramme sollten bestimmten Regeln folgen, die zwar nicht zwingend vorgeschrieben sind, deren Einhaltung aber das Lesen derartiger Grafiken erleichtert:

1.

Der Programmablauf (zumindest die allgemeine Logik) erfolgt von oben nach unten und von links nach rechts. Im Einzelfall mag es notwendig sein, mal einen Schritt von rechts nach links zu visualisieren, aber das sollte möglichst eine Ausnahme bleiben. Andernfalls fällt es schwer, den Ablauf korrekt zu erfassen. Die Ablaufrichtung entspricht damit unserer gewohnten Leserichtung.

2.

Es sollten nur Standardsymbole verwendet werden. Natürlich existieren mehr als die oben vorgestellten Symbole, aber schon mit diesen 8 können Sie sehr komplexe Programmabläufe visualisieren. Weitere Symbole lassen sich z.B. für SmartDraw auf der Webseite des Herstellers herunterladen (oder einsehen, falls Sie nur mit Flash arbeiten). Widerstehen Sie auf jeden Fall der Versuchung, eigene Symbole zu kreieren – denn diese können nur Sie selbst verstehen.

3.

Jedes Symbol hat entweder nur einen Eingang, nur einen Ausgang, nur einen Ein- und einen Ausgang oder einen Eingang und zwei Ausgänge.

4.

Ein Entscheidungssymbol enthält eine Frage, die nur mit Ja/Nein beantwortet werden kann. Für jemanden, der es nicht gewohnt ist, mit Flussdiagrammen zu arbeiten, stellt dies sicher die größte Herausforderung dar.

Flussdiagramme bieten den unschätzbaren Vorteil, dass sie einen zwingen, die gesamte Programmlogik in sehr kleine Schritte zu zerlegen. Mag einem vorher die Logik schon im Großen und Ganzen klar gewesen sein, so ist es dennoch nicht selten, dass man beim Programmieren feststellen muss, irgend etwas übersehen oder nicht tief genug durchdacht zu haben. Vor solchen Stolpersteinen schützt ein sauber ausgearbeitetes Flussdiagramm. Ist diese Arbeit geleistet, fällt das eigentliche Programmieren insgesamt leichter, da einem nun klar ist, was genau wann geschieht. Als nachteilig erweist sich jedoch der relativ hohe Zeitaufwand, der mit dem Erstellen von Flowcharts verknüpft ist, und die eher geringe Flexibilität, da nachträgliche Änderungen im Programmablauf dazu zwingen können, weite Strecken des Diagramms neu erstellen zu müssen.

3.3.2 Pseudo-Code

Eine in Pseudo-Code (auch: Schein-Code) formulierte Lösung orientiert sich strukturell allgemein an Programmiersprachen, formuliert aber die einzelnen Arbeitsschritte in einer relativ nahe an der Alltagssprache liegenden Form. Derartiger Code bedient sich bestimmter festgelegter Schlüsselwörter, um die Funktionsweise eines Algorithmus’ oder, allgemeiner, den Ablauf eines Programms sprachunabhängig abzubilden. Sprachunabhängig bedeutet natürlich, dass sich dieser Code nicht an eine spezifische Programmiersprache anlehnt (andernfalls würde man ja schon das konkrete Programm schreiben). Eine einfache if-else-Abfrage würde in Pseudocode beispielsweise folgendermaßen geschrieben:

wenn (Bedingung)

Anweisung(en)

sonst

Anweisung(en)

Das ActionScript -Äquivalent würde so aussehen:

if(Bedingung){

Anweisung(en)

}else{

Anweisung(en)

}

Da Pseudocode über das Einrücken und über einige Schlüsselbegriffe Programmiersprachen näherungsweise abbildet, ist es zumindest prinzipiell relativ einfach, daraus den benötigten korrekten Code zu erzeugen. Stärker als Flussdiagramme setzt Pseudocode jedoch eine gewisse Erfahrung im Programmieren voraus, um sinnvoll Logiken abbilden zu können.

Das obige Beispiel könnte man etwa so formulieren:

function zurArbeitGehen(){

gehe zur Tür hinaus

wenn(Wetter sieht regnerisch aus){

nehme Schirm;

gehe zur Bushaltestelle;

fahre zum Ziel;

}sonst{

gehe zum Ziel;

}

}

Die einzelnen Schritte bleiben gegenüber dem Flowchart notwendigerweise gleich. In beiden Fällen kontrollieren wir beispielsweise das Wetter. Nur sieht die Struktur, in der die Schritte wieder gegeben werden, durchaus ähnlich aus, wie sie auch in einem konkreten Programm zu finden wäre:

Anweisungen werden in der Reihenfolge der Ausführungen untereinander geschrieben. Ein horizontales Abweichen wie beim Flowchart (Ja, Nein) existiert hier nicht.

Logisch aufeinander bezogene Anweisungen werden in einem eigenen Block, einer Funktion, erfasst.

Bedingungen werden ebenfalls in einem eigenen Block, der if-Bedingung, erfasst.

In einem „richtigen" Code müsste abschließend noch der Aufruf der Funktion zurArbeitGehen() erfolgen, aber auch so ist der Ablauf unserer Lösung zu erkennen und nachzuvollziehen.

3.4 Beispiel-Algorithmus „Kaffee kochen"

Der Volksmund weiß, dass Programmierer dickbäuchig, männlich und exzessive Kaffeetrinker sind. Lediglich das letztgenannte Vorurteil stimmt, weswegen wir uns am konkreten Beispiel des Kaffeekochens anschauen wollen, wie sich ein komplexeres Programm in Pseudo-Code entwickeln lässt. Wir wählen eine Top-Down-Vorgehensweise.

Aufgabenstellung/Problemstellung:

Einen leckeren Kaffee kochen und ihn Gästen servieren.

Annahme:

Der Kaffee wird von einer Maschine gekocht, die exakte Anweisungen von uns benötigt. Wasser und Strom sowie Tassen und Kanne sind vorhanden, die durstigen Gäste natürlich auch. Außerdem verfügen wir über notwendiges Kleingeld, um gegebenenfalls in einem gut sortierten Laden um die Ecke Besorgungen durchzuführen.

In der allgemeinsten Form bzw. auf dem höchsten Abstraktionslevel besteht der fragliche Prozess aus zwei Teilen:

Kaffee kochen

Fertigen Kaffee servieren

Das reicht allerdings bei weitem nicht aus, um den betreffenden Prozess zielgerichtet in Gang zu setzen. Es fehlen nämlich konkrete Einzelschritte bzw. Handlungsanweisungen. Jeder dieser Teile umfasst eine Reihe von Schritten, die in manchen Fällen von spezifischen Bedingungen abhängen. Betrachten wir den ersten der genannten Teile, lässt er sich aufsplitten in die Phasen:

vorbereiten

aufbrühen

Ähnlich können wir den zweiten Teil untergliedern in:

vorbereiten

servieren

In beiden Fällen gehen dem Ergebnis der Teilprozesse – fertiger Kaffee, „vollendeter Genuß"TM – vorbereitende Schritte voraus. In Bezug auf das Aufbrühen handelt es sich um:

Kanne mit Wasser füllen

Wasser in Maschine füllen

Kanne in Maschine stellen

Filter in Maschine einsetzen

Pulver in Filter füllen

einschalten

Selbst an dieser Stelle haben wir noch nicht die kleinstmögliche Schrittfolge erreicht. Weitere Unterteilungen sind möglich. So besteht der erste Punkt, das Füllen der Kanne, aus folgenden Einzelhandlungen:

Kanne fassen

Zum Wasserhahn gehen

Unter Wasserhahn halten

Wasser fließen lassen

Wasser stoppen

Kanne zur Maschine bringen

Dieses Verfeinern wird solange durchgeführt, bis man ganz kleinschrittige Anweisungen findet, die sich nicht mehr unterteilen lassen. Für unsere Zwecke reicht der erzielte Detailgrad aus. Zu Übungszwecken können Sie jedoch gerne alle weiteren Schritte soweit ausarbeiten, bis sie sich nicht mehr in kleinere Häppchen unterteilen lassen.

Auf dieser Basis lässt sich ein Algorithmus angemessen formulieren. Er sieht zum aktuellen Zeitpunkt folgendermaßen aus:

Kaffee kochen

vorbereiten

Kanne mit Wasser füllen

Kanne fassen

Zum Wasserhahn gehen

Unter Wasserhahn halten

Wasser fließen lassen

Wasser stoppen

Kanne zur Maschine bringen

Wasser in Maschine füllen

Kanne in Maschine stellen

Filter in Maschine einsetzen

Pulver in Filter füllen

einschalten

aufbrühen

Fertigen Kaffee servieren

vorbereiten

Tassen nehmen

Zucker nehmen

Milch nehmen

servieren

Kaffee in Tasse füllen

Zucker geben

Milch geben

Wir könnten so fortfahren, bis wir eine zwar endliche, aber aufgrund der vielen Schritte endlos lang erscheinende Liste mit Instruktionen erhalten würden. Wirklich lesbar und damit verständlich ist eine solche Form allerdings nicht. Daher fügen wir eine formale Gliederung ein, die durch eingerückte Zeilen eine hierarchische Abhängigkeit anzeigt:

Kaffee kochen

vorbereiten

Kanne mit Wasser füllen

Kanne fassen

Zum Wasserhahn gehen

Unter Wasserhahn halten

Wasser fließen lassen

Wasser stoppen

Kanne zur Maschine bringen

Wasser in Maschine füllen

Kanne in Maschine stellen

Filter in Maschine einsetzen

Pulver in Filter füllen

einschalten

aufbrühen

Fertigen Kaffee servieren

vorbereiten

Tassen nehmen

Zucker nehmen

Milch nehmen

servieren

Kaffee in Tasse füllen

Zucker geben

Milch geben

Wir können nun auf einen Blick erkennen, dass die Schritte vorbereiten bis aufbrühen im ersten Teil zum Kochen des Kaffees gehören. Solche Anweisungs-Blöcke lassen sich in Programmiersprachen in sogenannten Funktionen erfassen. Dabei ist eine bestimmte Schreibweise bei der Wahl der Funktionsnamen zu berücksichtigen, die wir hier geflissentlich weitgehend ignorieren wollen, da es zunächst nur um das Prinzip geht. Wir kommen darauf in den nachfolgenden Kapiteln zu Variablen und Funktionen in ActionScript jedoch ausführlicher zu sprechen.

Ändern Sie den Pseudo-Code so, wie es die fettgedruckten Zeilen anzeigen (aus Gründen der Übersichtlichkeit wollen wir ab dieser Stelle derartige Änderungen fett auszeichnen):

function kaffeeKochen(){

vorbereiten

Kanne mit Wasser füllen

Kanne fassen

Zum Wasserhahn gehen

Unter Wasserhahn halten

Wasser fließen lassen

Wasser stoppen

Kanne zur Maschine bringen

Wasser in Maschine füllen

Kanne in Maschine stellen

Filter in Maschine einsetzen

Pulver in Filter füllen

einschalten

aufbrühen

}

function fertigenKaffeeServieren(){

vorbereiten

Tassen nehmen

Zucker nehmen

Milch nehmen

servieren

Kaffee in Tasse füllen

Zucker geben

Milch geben

}

kaffeeKochen();

fertigenKaffeeServieren();

Formal gesehen umfasst unser Code nun zwei Funktionsdefinitionen, in denen teilweise ganz konkrete Anweisungen und Befehle enthalten sind, sowie danach in den beiden letzten Zeilen folgend zwei Funktionsaufrufe. Diese Aufrufe sorgen dafür, dass die vorher definierten Anweisungen auch wirklich ausgeführt werden. Sie sind vergleichbar mit einer Aufforderung an eine andere Person, jetzt Kaffee aufzubrühen und zu servieren.

Durch die Verwendung des Schlüsselworts function sowie der runden Klammern () machen wir deutlich, dass es sich hier um die Definition einer Befehlsfolge handelt. Mit den geschweiften Klammern {} kennzeichnen wir deren Anfang und Abschluss.

Die Übersichtlichkeit erhöht sich weiter, wenn wir die sehr detaillierten Schritte, die zu einer übergeordneten Handlungsanweisung wie beispielsweise Kanne mit Wasser füllen gehören, ebenfalls in eine Funktion auslagern.

Ändern Sie den Pseudo-Code:

function kaffeeKochen(){

vorbereiten()

aufbrühen

}

function fertigenKaffeeServieren(){

vorbereiten

Tassen nehmen

Zucker nehmen

Milch nehmen

servieren

Kaffee in Tasse füllen

Zucker geben

Milch geben

}

function vorbereiten(){

Kanne mit Wasser füllen

Kanne fassen

Zum Wasserhahn gehen

Unter Wasserhahn halten

Wasser fließen lassen

Wasser stoppen

Kanne zur Maschine bringen

Wasser in Maschine füllen

Kanne in Maschine stellen

Filter in Maschine einsetzen

Pulver in Filter füllen

einschalten

}

kaffeeKochen();

fertigenKaffeeServieren();

Alle Schritte, die zum Vorgang vorbereiten gehören, haben wir in eine entsprechende Funktion verlagert. Jedes Mal, wenn wir Kaffee aufbrühen wollen, rufen wir diese Funktion auf, um alles Notwendige bereitzustellen.

Schauen wir uns den bisherigen Code an, erkennen wir, dass es noch eine zweite Stelle gibt, an der die Anweisung vorbereiten zu finden ist, nämlich unmittelbar vor dem Servieren des fertigen Kaffees. In einem früheren Abschnitt wurde darauf verwiesen, dass wir mit zweideutigen Informationen i.d.R. umgehen können. Im aktuellen Beispiel würden Menschen aus dem jeweiligen Kontext darauf schließen, dass Vorbereiten einmal die Verwendung eines Filters, ein anderes mal die Suche nach sauberen Tassen umfasst. Eine Maschine bzw. ein Computer dagegen wäre zu einer derartigen Interpretation nicht in der Lage und würde statt dessen bei jeder Handlungsanweisung vorbereiten genau das tun, was in der gleichnamigen Funktionsdefinition bzw. Handlungsdefinition steht. Was für korrekten Programmcode gilt, sollte man sich daher auch für einen Pseudo-Code merken: Wenn möglich, sind verschiedene Handlungsanweisungen auch mit verschiedenen Begriffen zu formulieren, was es in formaler Hinsicht erleichtert, das spätere Skript fehlerfrei in der richtigen Syntax zu entwickeln. Wir könnten hier die verschiedenen Anweisungen des vorbereiten durch ein Suffix genauer kennzeichnen, z.B. vorbereitenKaffee und vorbereitenServieren. Dann sähe unser Code so aus:

function kaffeeKochen(){

vorbereitenKaffee()

aufbrühen

}

function fertigenKaffeeServieren(){

vorbereitenServieren()

servieren

}

function vorbereitenKaffee (){

Kanne mit Wasser füllen

…

}

function vorbereitenServieren(){

Tassen nehmen

Zucker nehmen

Milch nehmen

}

…

Die drei Punkte (…) deuten Auslassungen an, um nicht permanent den gesamten Code wiederholen zu müssen. Sie fügen an dieser Stelle gedanklich die bereits oben dargestellten Zeilen ein.

Damit können wir nun eigentlich genüsslich Kaffee schlürfen. Allerdings bleiben in unserem Algorithmus noch einige Fragen offen. Ein typisches Problem stellen die Vorannahmen dar. Dort haben wir vorausgesetzt, dass Wasser, Kaffeepulver und Strom vorhanden sind. Doch was ist mit den für unseren Prozess ebenso unverzichtbaren Filtern? Wir verwenden sie einfach in unserem Programm, ohne zu prüfen, ob überhaupt welche vorhanden sind. Wir müssen daher unsere Funktion vorbereitenKaffee erweitern:

function vorbereitenKaffee(){

…

Kanne in Maschine stellen

wenn(keine Filter vorhanden){

Filter kaufen gehen

}

Filter in Maschine einsetzen

Pulver in Filter füllen

einschalten

}

Auch an anderen Stellen greifen wir einfach auf Objekte zu, ohne uns zu vergewissern, ob sie vorhanden sind. Dasselbe gilt z.B. für Milch und Zucker. Dementsprechend sollte die Funktion vorbereitenServieren lauten:

function vorbereitenServieren(){

wenn (Tassen unsauber){

dann spülen

}

Tassen nehmen

wenn (kein Zucker){

Zucker kaufen

}

Zucker nehmen

wenn (keine Milch){

kaufen (bei den derzeitigen Preisen besser: Nachbarn fragen)

}

Milch nehmen

}

Damit erweitert sich unser Algorithmus um ein wichtiges Konzept, nämlich die Bedingung. Anweisungen wie das Kaufen von Zucker oder das Verwenden eines Filters werden von Voraussetzungen abhängig gemacht, die explizit im Programm als Bedingung formuliert werden.

Es gibt noch weitere Stellen, an denen Bedingungen erfüllt sein müssen, ehe der nächste Arbeitsschritt ausgeführt werden kann. Dabei können diese Bedingungen beliebiger Art sein. Oft kommt es vor, dass zuerst ein bestimmter Arbeitsschritt beendet werden muss, bevor der nächste Schritt folgen kann. Das gilt in unserem Beispiel hinsichtlich des Servierens, denn selbstverständlich muss man erst einmal abwarten, bis der Kaffee schon fertig aufgebrüht ist, ehe man sich daran laben kann. Den aktuellen Status kann man an der Maschine ablesen, die uns beispielsweise durch ein Lämpchen mitteilt, wann der Kaffee fertig ist. Momentan ist es allerdings noch so, dass wir zunächst den Anweisungs-Block kaffeeKochen und dann unmittelbar danach den Block fertigenKaffeeServieren ausführen. Tatsächlich muss jedoch die zweite Anweisung von dem erfolgreichen Abschluss der ersten abhängig gemacht werden.

Daher korrigieren wir unseren Code:

function kaffeeKochen(){

vorbereitenKaffee()

aufbrühen

wenn (Lämpchen brennt noch){

warten

}sonst{

fertigenKaffeeServieren()

}

}

Zum Schluss nach allen Funktionsdefinitionen lautet der Aufruf nur noch:

kaffeeKochen()

Nun bleibt noch der Vorgang des Servierens, der ebenfalls von Bedingungen abhängt und in eine Funktion ausgelagert werden kann. Ändern Sie daher den bestehenden Pseudo-Code in:

function fertigenKaffeeServieren(){

vorbereitenServieren()

servieren();

}

function servieren(){

Kaffee in Tasse füllen

wenn (Gast will Zucker){

Zucker geben

}

wenn (Gast will Milch){

Milch geben

}

}

In beredter Prosa ergibt sich damit derzeit folgender Ablauf:

Zuerst werden einzelne Arbeitsschritte, soweit sie von der Logik her zusammengehören, in Funktionen zusammengefasst. Wir verfügen jetzt über folgende Definitionen dieser Art:

kaffeeKochen. Das ist die wichtigste Funktion, die den gesamten Prozess in Gang setzt. Sie ruft in dieser Reihenfolge die Funktionen vorbereitenKaffee und aufbrühen auf. Anschließend kontrolliert sie das Lämpchen an der Maschine. Brennt es noch, müssen wir warten, da der Kaffee noch nicht fertig ist. Andernfalls wird die Funktion fertigenKaffeeServieren aufgerufen.

vorbereitenKaffee. Hier werden alle Schritte ausgeführt, die notwendig sind, bevor wir die Maschine einschalten können. Dazu gehört etwa das Einstecken eines Filters, das Einfüllen von Pulver etc.

aufbrühen. Hier haben wir nicht etwa gemogelt, schließlich fehlt doch eigentlich eine entsprechende Definition. Das Aufbrühen ist ein maschineninterner Vorgang, der ausgelöst wird, sobald wir den betreffenden Befehl geben. Es ist nicht notwendig, kleinschrittigere Anweisungen zu geben. Jede Script- und Programmiersprache verfügt über derartige vorgefertigte Funktionen (natürlich nicht zum Aufbrühen, sondern um anderweitige Aktionen auszuführen). Sie stellen die Grundbausteine dar, aus denen der Programmierer seine eigenen, komplexeren Funktionen aufbaut.

fertigenKaffeeServieren. Diese Funktion legt fest, was geschehen soll, nachdem der Kaffee fertig aufgebrüht wurde. Sie besteht aus den zwei Anweisungsblöcken vorbereitenServieren und servieren.

vorbereitenServieren. Wie bei aufbrühen bedarf servieren (s.u.) einiger vorbereitender Schritte, die hier definiert werden.

servieren. Diese Funktion umfasst alle Handgriffe, die ausgeführt werden müssen, bis die schon jetzt halb verdurstete Gästeschar endlich trinken darf.

Abschließend geben wir den Befehl KaffeeKochen(), der die gesamte in den Funktionen beschriebene Kette an Aktionen auslöst. Bis zu diesem Zeitpunkt hat einer der Gäste den Raum unter Protest in unverständlichem Pseudo-Code verlassen, weil er immer noch nichts zu trinken bekommen hat.

Jeder passionierte Kaffeetrinker weiß, dass die Menge des verwendeten Pulvers ebenso entscheidenden Einfluss auf den späteren Genuss ausübt wie die Menge der Milch und gegebenenfalls des Zuckers. Ein noch so geringes Abweichen von der Idealmenge vermag den Genießer in tiefste Depression zu stürzen. Um ein solches Problem zu umgehen, empfiehlt es sich, die Idealmenge irgendwo festzuhalten. In der Programmierung geschieht das mit Hilfe von Variablen.

Ganz am Anfang des Codes fügen wir ein:

mengeKaffee =8 Löffel

Diese Information muss beim Einfüllen des Pulvers in den Filter berücksichtigt werden:

function vorbereitenKaffee(){

…

Filter in Maschine einsetzen

mengeKaffee Pulver in Filter füllen

einschalten

}

Durch die Variable mengeKaffee haben wir exakt festgelegt, wie viele Löffel wir zu verwenden wünschen. Über die Funktion vorbereitenKaffee wird nun nicht mehr eine beliebige Menge Pulver in den Filter geschüttet, sondern genau so viel, wie in besagter Variable festgehalten, in unserem konkreten Fall also 8 Löffel. Auf die gleiche Art und Weise müssten alle anderen Mengenangaben präzisiert werden, also z.B. Milch und Zucker.

Für den Fall, dass Sie unterwegs verloren gegangen sind, hier der aktuelle Stand:

mengeKaffee =8 Löffel

function kaffeeKochen(){

vorbereitenKaffee()

aufbrühen

wenn (Lämpchen brennt noch){

warten

}sonst{

fertigenKaffeeServieren()

}

}

function vorbereitenKaffee (){

Kanne mit Wasser füllen

Kanne fassen

Zum Wasserhahn gehen

Unter Wasserhahn halten

Wasser fließen lassen

Wasser stoppen

Kanne zur Maschine bringen

Wasser in Maschine füllen

Kanne in Maschine stellen

wenn (keine Filter vorhanden){

Filter kaufen gehen

}

Filter in Maschine einsetzen

mengeKaffee Pulver in Filter füllen

einschalten

}

function fertigenKaffeeServieren(){

vorbereitenServieren()

servieren();

}

function servieren(){

Kaffee in Tasse füllen

wenn (Gast will Zucker){

Zucker geben

}

wenn (Gast will Milch){

Milch geben

}

}

function vorbereitenServieren(){

wenn (Tassen unsauber){

dann spülen

}

Tassen nehmen

wenn (kein Zucker){

Zucker kaufen

}

Zucker nehmen

wenn (keine Milch){

kaufen (bei den derzeitigen Preisen besser: Nachbarn fragen)

}

Milch nehmen

}

kaffeeKochen();

Wäre nun nicht die richtige Zeit, um einen Schluck zu nehmen? Leider immer noch nicht – an dieser Stelle mag der eine oder andere Leser unzufrieden brummeln, denn jedermann dürfte klar sein, dass die richtige Kaffeesorte von elementarer Bedeutung für den „vollendeten Kaffeegenuß"TM ist. Was geschieht jedoch, wenn jemand die verwendete Sorte keinesfalls goutieren möchte? In dem Fall bliebe zwar der gesamte Prozess vom Ablauf her der gleiche, aber eine Variable müsste mit einem anderen Inhalt belegt werden. In der Programmierung lässt sich das Problem z.B. mit Hilfe einer sogenannten parametrisierten Funktion lösen, also einer Funktion, der wir beim Aufruf eine Variable mit einem bestimmten Inhalt mitgeben. Dazu muss zunächst in der Funktionsdefinition festgelegt werden, dass wir eine derartige besondere Variable benötigen:

function vorbereitenKaffee( welcheSorte ){

…

mengeKaffee Pulver welcheSorte in Filter füllen

…

}

Und der Befehl beim Aufruf dieser Funktion lautet:

function kaffeeKochen(){

vorbereitenKaffee(„Segafredo Intermezzo")

…

}

Wenn wir den Befehl zum Kaffee kochen an die Maschine ausgeben, teilen wir ihr gleichzeitig mit, welche Sorte denn gewünscht sei. In unserem konkreten Fall übergeben wir leckeren „Segafredo Intermezzo". Wenn wir beim nächsten Mal anderen Kaffee wünschen, brauchen wir nur dementsprechend den Aufruf zu ändern:

function kaffeeKochen(){

vorbereitenKaffee(„Pangalaktischer Donnergurgler Espresso")

…

}

Obwohl uns bereits ein Gast verlassen hat, sind immer noch mehrere vorhanden. Daher reicht es nicht aus, abschließend die Funktion servieren in der momentanen Form aufzurufen. Denn die dort beschriebenen Arbeitsschritte müssen wir nicht nur einmal, sondern so oft ausführen, wie durstige Gäste anzutreffen sind, schließlich soll ja jeder einen Kaffee erhalten. Wiederholt auszuführende Anweisungen werden in der Programmierung mit Hilfe von Schleifen definiert. Ergänzen Sie dementsprechend die Definition von servieren:

function servieren(){

für jeden Gast{

Kaffee in Tasse füllen

wenn (Gast will Zucker){

Zucker geben

}

wenn (Gast will Milch){

Milch geben

}

}

}

Auf diese Weise wiederholen wir für jeden einzelnen Gast das gesamte Prozedere des Verteilens unseres hoffentlich köstlichen Kaffees. Halten sich noch 5 Gäste bei uns auf, führen wir die fraglichen Anweisungen fünfmal aus, sind 2 da, eben nur zweimal.

Wenn man Code auf diese Weise entwickelt, kommt es vor, dass manche Information redundant und damit überflüssig ist, und dass der Programmablauf noch optimiert werden kann. So verfügen wir mit fertigenKaffeeServieren über eine Funktion, die nichts anderes tut, als ihrerseits weitere Funktionen, nämlich vorbereitenServieren und servieren aufzurufen. Wir können also auf fertigenKaffeeServieren verzichten und an deren Stelle direkt die beiden genannten Funktionen verwenden.

function kaffeeKochen(){

vorbereitenKaffee(„Segafredo Intermezzo")

aufbrühen

wenn (Lämpchen brennt noch){

warten

} sonst {

vorbereitenServieren()

servieren();

}

}

Anschließend kann die Funktionsdefinition von fertigenKaffeeServieren gelöscht werden.

Die bis hierher entwickelte Form des benötigten Algorithmus beschreibt bereits recht genau den Prozess, den wir programmiertechnisch abbilden wollen. Er enthält zahlreiche grundlegende Elemente, die in jedem Programm anzutreffen sind: Variable, Parameter, Aufruf bzw. Anweisung, Anweisungs-Block, Schleife und Bedingung. Die Abbildungen 3 bis 6 visualisieren sie in Kurzform, jeweils konkreten Elementen unseres Pseudo-Codes zugeordnet.

A978-3-540-35182-5_3_Fig3_HTML.gif

Abbildung 3:

Variablen- und Funktionsdefinition

A978-3-540-35182-5_3_Fig4_HTML.gif

Abbildung 4:

Anweisungsblock

A978-3-540-35182-5_3_Fig5_HTML.gif

Abbildung 5:

Argument, Parameter, Schleife

A978-3-540-35182-5_3_Fig6_HTML.gif

Abbildung 6:

Anweisung, Bedingung, Funktionsaufruf

Welche Bedeutung die jeweiligen Elemente im Einzelnen besitzen, werden wir uns in den nachfolgenden Kapiteln noch genauer anschauen.

Unser gesamter Pseudo-Code sieht jetzt so aus:

mengeKaffee =8 Löffel

function kaffeeKochen(){

vorbereitenKaffee(„Segafredo Intermezzo")

aufbrühen

wenn (Lämpchen brennt noch){

warten

}sonst{

vorbereitenServieren()

servieren();

}

}

function vorbereitenKaffee(welcheSorte){

Kanne mit Wasser füllen

Kanne fassen

Zum Wasserhahn gehen

Unter Wasserhahn halten

Wasser fließen lassen

Wasser stoppen

Kanne zur Maschine bringen

Wasser in Maschine füllen

Kanne in Maschine stellen

wenn(keine Filter vorhanden){

Filter kaufen gehen

}

Filter in Maschine einsetzen

mengeKaffee Pulver welcheSorte in Filter füllen

einschalten

}

function vorbereitenServieren(){

wenn (Tassen unsauber){

dann spülen

}

Tassen nehmen

wenn (kein Zucker){

Zucker kaufen

}

Zucker nehmen

wenn (keine Milch){

kaufen (bei den derzeitigen Preisen besser: Nachbarn fragen)

}

Milch nehmen

}

function servieren(){

für jeden Gast{

Kaffee in Tasse füllen

wenn (Gast will Zucker){

Zucker geben

}

wenn (Gast will Milch){

Milch geben

}

}

}

kaffeeKochen();

Hätten Sie jemals gedacht, dass Kaffeekochen so kompliziert und Programmieren so einfach sein könnte?

Arno KohlX.media.pressActionScript 2Ein Lehr- und Übungsbuch10.1007/978-3-540-35182-5_4© Springer Berlin Heidelberg 2011

4. Programmierung und ActionScript

Arno Kohl¹  

(1)

MacromediaAkademie für Medien, Gollierstraße 4, 80339 München , Deutschland

Arno Kohl

Email: [e-mail]

Zusammenfassung

Mittlerweile haben Sie Ihren Kaffee aus dem vorhergehenden Kapitel genossen und stellen sich die Frage, ob man denn tatsächlich jedes Mal, wenn es einen nach Kaffee gelüstet, programmieren muss. Sicher nicht, dennoch sprechen zahlreiche Gründe für die Programmierung (zumindest in der Flash-Entwicklung).

Mittlerweile haben Sie Ihren Kaffee aus dem vorhergehenden Kapitel genossen und stellen sich die Frage, ob man denn tatsächlich jedes Mal, wenn es einen nach Kaffee gelüstet, programmieren muss. Sicher nicht, dennoch sprechen zahlreiche Gründe für die Programmierung (zumindest in der Flash-Entwicklung):

Eine programmierte Lösung reduziert die Dateigröße gegenüber einer rein grafischen Lösung zum Teil erheblich.

Interaktionen, also der Eingriff des Anwenders in den Ablauf Ihrer Applikation und die Zweiweg-Kommunikation mit ihm, ist nur per Programmierung möglich. Das beginnt schon bei der simplen Steuerung einer Animation, die ohne (allerdings ausgesprochen einfachen) Code nicht realisierbar ist.

Die Programmierung bietet erheblich mehr Flexibilität. Wenn wir beispielsweise eine Animation programmieren, können wir sie zeitleistenunabhängig sehr schnell über Variablen ändern und verschiedene Versionen austesten. Wir müssen