Rheinwerk Design < openbook > Rheinwerk Design - Know-how für Kreative.
Know-how für Kreative

 << zurück
ActionScript 1 und 2 von Sascha Wolter (http://www.saschawolter.de/)
Objektorientierung und Codedesign mit Flash MX 2004
Buch: ActionScript 1 und 2

ActionScript 1 und 2
672 S., mit CD, Referenzkarte, 44,90 Euro
Rheinwerk Design
ISBN 3-89842-221-6
gp Kapitel 18 Codedesign und Konzeption
  gp 18.1 Analyse und Konzeption
    gp 18.1.1 Veränderliche Anforderungen und Konzepte
    gp 18.1.2 Mehr Vorstellungskraft durch Prototypen
  gp 18.2 Entwicklungsumgebung
    gp 18.2.1 Werkzeuge
    gp 18.2.2 Trennung von Ressourcen und Programmierung
    gp 18.2.3 Aufteilung in einzelne Module
    gp 18.2.4 Versionsmanagement
    gp 18.2.5 Strukturierung der Dateien
  gp 18.3 ActionScript
    gp 18.3.1 Bezeichner
    gp 18.3.2 Typisierung
    gp 18.3.3 Codehinweise
    gp 18.3.4 Kommentare und Dokumentation
  gp 18.4 Optimierung
    gp 18.4.1 Bytecode optimieren und extrahieren
    gp 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.


Rheinwerk Design - Zum Seitenanfang

18.1 Analyse und Konzeptiodowntop

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).


Rheinwerk Design - Zum Seitenanfang

18.1.1 Veränderliche Anforderungen und Konzepte  downtop

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:

gp  Umbau der druckbaren Dokumente, so dass nur auf der ersten Seite dynamische Inhalte erscheinen
gp  Serverseitige Generierung der Druckmedien z.B. mit PHP-Ming (http://ming.sourceforge.net/) oder FlashPaper (http://www.macromedia.com/de/software/flashpaper/)
gp  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.


Rheinwerk Design - Zum Seitenanfang

18.1.2 Mehr Vorstellungskraft durch Prototypen  toptop

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.

Abbildung
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
  
  Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: ActionScript 1 und 2
ActionScript 1 und 2
bestellen
 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchtipps
Zum Rheinwerk-Shop: JavaScript






 JavaScript


Zum Rheinwerk-Shop: jQuery






 jQuery


Zum Rheinwerk-Shop: Responsive Webdesign






 Responsive Webdesign


Zum Rheinwerk-Shop: Suchmaschinen-Optimierung






 Suchmaschinen-
 Optimierung


Zum Rheinwerk-Shop: Schrödinger lernt HTML5, CSS3 und JavaScript






 Schrödinger lernt
 HTML5, CSS3
 und JavaScript


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo





Copyright © Rheinwerk Verlag 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.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern