Flash Metamodel Basics

The metamodel presented here describes is platform-specific and describes applications to be devel- oped with Flash and ActionScript. It is independent from MML and and enables to model any kind of Flash application. Analogous to the MML metamodel it is defined according to the concepts of Model-Driven Engineering (sec. 3.4) and has been implemented using the Eclipse Modeling Frame- work (see sec. 6.7). The basic metamodel principles and conventions for presentation applied here are the same as described in section 5.1.5. The Flash metamodel presented here adheres to Flash version 8. An overview on Flash versions and MML support is provided in table 7.1.

Purpose The main purpose of the metamodel in this thesis is to build the base for an intermediate step in the transformation from MML to the final code skeletons, i.e. a first transformation from MML to Flash models and a second transformation from Flash models to code. This provides several benefits: First, it separates the conceptual mapping from MML to Flash from the concrete syntax for Flash applications and is thus easier to maintain and extend. Second, the Flash metamodel and the transformation into the concrete Flash syntax can be directly reused by other modeling approaches which want to use Flash as target platform.

It is not necessary for the MML approach to edit the generated Flash models as they can be transformed directly into the final code. Instead, the Flash authoring tool should be used to finalize the application. Thus, no concrete visual syntax and no visual modeling tool has been defined for the Flash models yet. However, an EMF-based tree editor analogous to that for MML (see figure 6.27) exists for the Flash models. It can be used to check, modify, or even create Flash models if desired. Of course, it is also possible in the future to add a concrete syntax to the Flash metamodel and create and edit Flash models directly in a visual modeling tool.

Deriving the Metamodel from the Flash JavaScript API It is not always trivial to figure out all possible elements in Flash Documents and the relationships between them as they are partially hidden by the authoring tool. Existing literature (see section7.2) and documentation [Adobec]2provide only step-by-step instruction for typical tasks in Flash but do not provide a precise systematic overview. Thus, this thesis proposes the solution to use the Flash JavaScript API to derive the metamodel in a systematic way. The following paragraph provides a brief excursus into the Flash JavaScript API and the associated scripting language JSFL. A basic understanding of them is also required later in section 7.3).

Excursus: JSFL and the Flash JavaScript API Since Flash MX 2004 it is possible to write custom extensions for the authoring tool. They have to be written in a scripting languageJSFL(Java Script for Flash, [Yard and Peters04, Ado05c]). This is a version of JavaScript to be used together with the

Flash JavaScript API. A JSFL file is a simple text file with the file extensionjsflwhich is interpreted and executed in the authoring tool. It can be created using the authoring tool or any text editor. It 1_{The term ‘Flash’ refers to the overall applications while ‘Flash Document’ refers to the Flash Documents only, i.e. FLA}

files without ActionScript classes).

2

[Adobec] refers to a complete online version of the Flash documentation. Each chapter is alternatively available for download as PDF manual. In the following we refer to the PDF manuals but the reader might also use [Adobec] instead.

is possbile to use it in combination with custom dialogue boxes defined in XMLUI as subset of the XML-based user interface description language XUL ([XUL], see also section 4.1.1).

The intended purpose of JSFL scripts is to extend the Flash authoring tool with custom function- ality. Therefore, JSFL files and XMLUI files (and other resources) can be packed in a Flash Extension file with the file extensionmxi. The mxi files can be distributed and installed as extension for the Flash authoring tool. Alternatively, it is possible to execute a JSFL file directly in the authoring tool. As third alternative, JSFL files can also be started directly from the command line which causes the Flash authoring tool to start and execute the file.

While JSFL itself is a simple JavaScript version without any specific features, the associated Flash JavaScript API provides full control over the Flash authoring tool. It provides access in terms of a

Document Object Model(DOM) similar to that implemented by web browsers for HTML. The Flash DOM provides full access on the content of a Flash Document. It enables to browse, manipulate, and create new elements within the document. Moreover, another part of the API (sometimes calledFlash file API) allows common file management functionality. Consequently, it is possible for instance to load a Flash Document into the authoring tool, manipulate it, and save it, or even to create an entirely new Flash Document via JSFL.

Listing 7.1 shows a simple example JSFL script. The variableflin line 1 is a predefined global variable which refers to theFlash Objectrepresenting the Flash authoring tool. Here an operation of the Flash Object is used which retrieves the current active Flash Document in the tool. Line 2 draws a simple rectangle shape within the document. Finally, line 3 saves the document with the filename “MyDocument.fla”.

var document = fl.getDocumentDOM();

document.addNewRectangle({left:0,top:0,right:100,bottom:100},0); fl.saveDocument(document, "MyDocument.fla");

Listing 7.1: Simple example JSFL script.

Rules for Metamodel Derivation The metamodel for Flash Documents is derived from the Flash JavaScript API as follows:

• An API class representing an entity in a Flash Document (i.e. a part of the document itself

instead of a functionality of the authoring tool) is mapped to a metaclass. Other API classes (like theToolsobject [Ado05c]) are omitted in the metamodel.

• A property in the API representing a structural property (like the name) or a basic visual prop- erty (like x- and y-coordinates on the screen) is mapped to a property in the corresponding metaclass. Properties representing the internal state of the authoring tool or visual details are omitted.

• A properties or operation representing an reference to other API classes is mapped to an asso- ciation in the metamodel.

• A generalization in the API is mapped to a generalization relationship in the metamodel. • The API often uses class properties to specify the type of a class more in detail (like the prop-

erty symbolTypefor the classSymbol). For each possible property value defined in the API a

subclass is created in the metamodel.

In this way, also the semantics for the Flash metamodel is defined indirectly by the operational semantics of its counterpart in the Flash JavaScript API.

Stage Library Compo- nents Timeline Tool- bar Property Window

Figure 7.1: The Flash Authoring Tool

The Flash JavaScript API defines only Flash Documents. The resulting metamodel part is in- troduced in the next section ( 7.1.2). Afterwards section 7.1.3 introduces the metamodel part for ActionScript which is similar to metamodels for other programming languages like Java.