Know-how für Kreative

Inhaltsverzeichnis
1 Erste Schritte
2 Versionen
3 Einführung in die Programmierung
4 Die Entwicklungsumgebung
5 Regeln
6 Anweisungen und Aktionen
7 Werte und Datentypen
8 Ausdrücke und Operatoren
9 Funktionen
10 Kontrollstrukturen
11 Dokumenten-Objektmodell und Gültigkeitsbereich (Scope)
12 Ereignisse
13 Objekterstellung
14 Vererbung
15 Movieclips
16 ActionScript 2.0
17 Komponenten
18 Codedesign und Konzeption
19 Flashdetection
20 Aussergewoehnliche Benutzerfuehrung
21 D mit Flash
22 Macromedia Central
23 HTML
24 JavaScript, ActiveX und Java
25 Flash undokumentiert
26 Vergangenheit, Gegenwart und Zukunft
27 Kurzreferenz
28 Buchtipps
29 Links
30 Die CD-ROM zum Buch
Index
Download: - ZIP, ca. 9,8 MB
Buch bestellen
Ihre Meinung?
<< zurück | Galileo Design / <openbook> / ActionScript | vor >>
ActionScript 1 und 2 von Sascha Wolter (http://www.saschawolter.de/) Objektorientierung und Codedesign mit Flash MX 2004
ActionScript 1 und 2 672 S., mit CD, Referenzkarte, 44,90 Euro Galileo Design ISBN 3-89842-221-6 |
| Kapitel 18 Codedesign und Konzeption
|  | 18.1 Analyse und Konzeption
|  |  | 18.1.1 Veränderliche Anforderungen und Konzepte
|  |  | 18.1.2 Mehr Vorstellungskraft durch Prototypen
|  | 18.2 Entwicklungsumgebung
|  |  | 18.2.1 Werkzeuge
|  |  | 18.2.2 Trennung von Ressourcen und Programmierung
|  |  | 18.2.3 Aufteilung in einzelne Module
|  |  | 18.2.4 Versionsmanagement
|  |  | 18.2.5 Strukturierung der Dateien
|  | 18.3 ActionScript
|  |  | 18.3.1 Bezeichner
|  |  | 18.3.2 Typisierung
|  |  | 18.3.3 Codehinweise
|  |  | 18.3.4 Kommentare und Dokumentation
|  | 18.4 Optimierung
|  |  | 18.4.1 Bytecode optimieren und extrahieren
|  |  | 18.4.2 Eigenständige Anwendungen und Bildschirmschoner
# Kapitel 18 Codedesign und Konzeption #### Vorschläge für eine bessere Entwickler-Welt Je größer ein Projekt wird und je mehr Personen daran beteiligt sind, desto mehr Regeln oder zumindest Empfehlungen sind notwendig. ##### 04_Fortgeschritten\Codedesign Die Organisation und Durchführung eines Projektes wird meist erst dann zu einem Problem, wenn entweder die Komplexität der geforderten Anwendung oder die Anzahl der beteiligten Personen eine größere Dimension erreichen. Dabei handelt es sich um eine fließende Grenze, die letztendlich auch von jedem Entwickler selbst gefunden werden muss: Dem einen geht die Arbeit gemeinsam mit vielen anderen Entwicklern leicht von der Hand, ein anderer wiederum kommt bereits ins Straucheln, sobald nur eine weitere Person ihm ins Handwerk zu pfuschen versucht. Regeln und Strategien auch bei scheinbar glatt laufenden Projekten helfen ungemein. Der Umfang von Regeln sollte aber nicht zu einer Belastung werden und dadurch den genau gegenteiligen Effekt erzielen als eigentlich gewünscht. Für die Entwicklung eines Flash-Banners sind umfangreiche Programmierrichtlinien sicher kontraproduktiv. Eine komplexe Anwendung lässt sich ohne solche Vorgaben jedoch kaum termingerecht nach den Wünschen des Kunden realisieren, geschweige denn später von anderen Entwicklern pflegen und erweitern. Die in diesem Kapitel aufgestellten Regeln sind jedoch nichts anders als Vorschläge und keine Gesetze! Bitte nehmen Sie diese als Anregung zur Kenntnis, und entwerfen Sie eigene Regeln, die Ihren Anforderungen gerecht werden. ## 18.1 Analyse und Konzeption Gerade im Bereich der Analyse und Konzeption eines Projektes erscheinen viele gut gemeinte Ratschläge eher als Binsenweisheiten. Schließlich ist jedem Entwickler klar, dass er erst dann mit der Umsetzung loslegen kann, wenn die Anforderungen analysiert und ein Konzept entworfen wurden. Und zu diesem Thema gibt es auch bereits viele Bücher, die sich über Hunderte von Seiten in beinahe epischer Breite damit beschäftigen. Doch alle guten Vorsätze helfen meist wenig, da sich viele Beteiligten nicht mehr daran erinnern können oder erinnern wollen – selbst wenn alles sprichwörtlich in Stein gemeißelt ist. Darum ist es häufig noch wichtiger, alle Eventualitäten zu bedenken, als ein Projekt bis in kleinste Detail analysieren und konzipieren zu wollen. Denn dass viele Personen sich an Absprachen und Vorgaben nicht mehr erinnern, liegt meist an deren mangelnder Vorstellungskraft (was kein Vorwurf ist, sondern in der Natur der Sache liegt) und an den sich ständig ändernden Anforderungen (was ebenfalls kein Vorwurf ist, sondern lange laufende Projekte auszeichnet). ### 18.1.1 Veränderliche Anforderungen und Konzepte Somit bleibt nichts anderes übrig, als die Analyse und Konzeption so gewissenhaft wie möglich und so umfangreich wie nötig zu machen. Dabei sollten wesentliche Eckpunkte wie z.B. die Zielplattform festgehalten und möglicher Änderungsaufwand bereits berücksichtigt werden. Beispielsweise kann eine Verschiebung des Projektes Einfluss auf die dann verfügbaren Flash Player und die Systemvoraussetzungen bei den Anwendern haben. In diesem Fall ist es für alle Beteiligten sehr hilfreich, wenn Änderungen während des Projektverlaufs in das Konzept eingearbeitet und allen inklusive der Konsequenzen mitgeteilt werden. ##### Beispiel Druckfunktion Ein Beispiel für die typische Dynamik einer Projektumsetzung ist die Druckfunktion von Flash. Denn Probleme entstehen meist erst bei der Umsetzung. Wer denkt denn schon im Konzept daran, dass beispielsweise der Ausdruck mehrseitiger Dokumente mit dynamischen Inhalten mit dem Flash Player 6 oder älter nicht funktioniert? Aber wegen solch eines Details darf wohl kaum das gesamte Projekt scheitern, und so muss eine pragmatische Lösung gefunden werden:
| Umbau der druckbaren Dokumente, so dass nur auf der ersten Seite dynamische Inhalte erscheinen
| Serverseitige Generierung der Druckmedien z.B. mit PHP-Ming (http://ming.sourceforge.net/) oder FlashPaper (http://www.macromedia.com/de/software/flashpaper/)
| Alternativer Einsatz von anderen Formaten wie PDF (http://www.adobe.de/products/acrobat/main.html)
Eine weitere Lösung dieses Problems ist der Einsatz des Flash Player 7. Dieser kann im Gegensatz zu Flash 6 mehrseitige Dokumente inklusive dynamischer Inhalte erzeugen und drucken. Und genau diese vierte Lösung war möglicherweise zu Beginn des Projektes noch gar nicht verfügbar, so dass sie auch nicht ins Konzept eingearbeitet werden konnte. Umgekehrt heißt dies auch: Selbst wenn im Konzept die Einschränkung des Druckens beschrieben ist, kann eine Veränderung der verfügbaren Technologien zu einer besseren Anwendung und somit zu einer nachträglichen Änderung des Konzeptes führen. Ein weiteres sehr wechselhaftes Thema sind die Schnittstellen zu Datenquellen. Hier kommt es nicht selten vor, dass sich diese nicht nur im Detail, sondern oft auch grundsaetzlich aendern. Mal soll es reines XML sein, dann wieder ein Webservice oder vielleicht doch Flash Remoting. Wer hier bereits im Vorfeld weitsichtig agiert und solche eventuellen Aenderungen im Programmcode vorsieht, der wird am Ende meist belohnt. ### 18.1.2 Mehr Vorstellungskraft durch Prototypen ##### Ein Crash-Kurs Flash für alle Beteiligten verbessert die Kommunikation untereinander sehr! Viele Probleme an einem Projekt liegen daran, dass die Beteiligten eine unvollständige oder zumindest voneinander abweichende Vorstellung über das Projekt und die verwendeten Technologien haben. Im ersten Schritt hilft es deshalb oft ungemein, wenn die Entwickler die Möglichkeiten, Probleme und Einschränkungen der jeweiligen Technologien vermitteln, um zumindest hier konkrete Vorstellung zu schaffen. Übrigens ist dieses Vorgehen insbesondere dann sinnvoll, wenn das Team sehr heterogen ist und sich aus unterschiedlichsten Spezialisten zusammensetzt: Einem Java-Entwickler ist z.B. der asynchrone Umgang mit Serveraufrufen in Flash völlig fremd, da Java normalerweise synchron arbeitet und eine neue Anfrage zu einem Server erst zulässt, sobald die vorherige abgeschlossen ist. ##### Ein Prototyp hilft, die technische Machbarkeit zu evaluieren und die Bedienbarkeit zu testen. Hier klicken, um das Bild zu Vergrößern Abbildung 18.1 Ein einfaches Zustandsdiagramm als Prototyp zur Illustration der Benutzerführung in einem Bestellwesen (UML-Zustandsdiagramm erstellt mit Microsoft Visio) Zur Verbesserung der Vorstellungskraft tragen auch kleine Prototypen bei. Hierbei handelt es sich oft um den Test der technischen Machbarkeit. Schließlich sind nicht immer alle Rahmenbedingungen im Detail bekannt, so dass einzelne Ideen erst einmal ausprobiert werden sollten. Oft ist es auch hilfreich, einen eher visuellen Prototypen ohne Funktionalität umzusetzen, um herauszufinden, wie sich eine Anwendung eigentlich anfühlt. Nicht wenige Entscheider und Entwickler haben völlig naive Vorstellungen über die Benutzerführung in einer Anwendung, und ein Prototyp hilft dabei, diese Vorstellung zu testen und zu korrigieren. Übrigens muss es sich bei einem Prototypen nicht immer um eine lauffähige Anwendung handeln. In vielen Fällen reichen bereits einfache Diagramme, die den Ablauf einer Anwendung anhand der verschiedenen Zustände und Übergänge visualisieren und gleichzeitig auch einen Eindruck der Komplexität vermitteln.
<< zurück | <top> | vor >>
Zum Katalog
ActionScript 1 und 2 bestellen
Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen? Ihre Meinung
Buchtipps
| Einstieg in ActionScript
| Einstieg in Flash 8
| Flash 8 und PHP
| Flash 8-Tutorials
| Dreamweaver 8
| Webseiten programmieren und gestalten
Shopping
Versandkostenfrei bestellen in Deutschland und Österreich Info

Copyright © Galileo Press GmbH 2005
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

[Galileo Design]
Galileo Press GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de