5.2 Modeling Media Components
5.2.5 Artifacts and Instances
On a first look the Media Components seem to be relatively simple constructs – a media object encap- sulated by a player or renderer. However, considering all possible cases in multimedia development the situation becomes more complex: For example the racing game application might provide the user with different kinds of cars to choose from, sayPorscheandFerrari. In the early stage of application development it is sometimes not definitely decided how many cars or which kind of cars the appli- cation will provide – the developers just start with some example cars. Moreover, a common way of implementation is to keep the concrete cars modular and to load them dynamically into the application at runtime. Dynamic loading of Media Components is an important technique in larger multimedia applications and must be considered by the modeling approach. Moreover, sometimes the user even might create his own custom cars at runtime using a specific editor provided by the application. Other typical examples for dynamic loading of Media Components are levels in games, exhibits in a virtual museum or learning units in education software. In these examplesCar, Level, Exhibit, orLearning
x y Media Designer Media Component: Artifacts: Media Instances:
(a) Car Example
Porsche1 Porsche Car instanceOf instanceOf (b) Interpreted as in- stantiation Porsche1 Porsche Car instanceOf (c) Interpreted as generalization
Figure 5.9: Illustrating example of abstraction layers of Media Components
Unitare kind of abstractions of the (probably unknown) concrete media components.
Moreover, an application can contain multiple instances of the same concrete media component. For example, in the racing game application multiple Porsche cars might be visible on the screen.
EachPorschecan be represented by the same animation, i.e. the same media component, but has
a different location on the screen and is related to a different domain object (e.g. associated with a different player). It is also possible that some visual properties vary over the different instances, e.g. the differentPorschecars have different colors. This phenomenon is not restricted to a specific media type: There can be multiple instances of the same image at different locations on screen (e.g. in different scales) or multiple instances of the same video (having different states). Depending on the technology this is usually implemented either by multiple references to the same media object (e.g. to the same video) or by creating multiple copies (e.g. when placing a Flash MovieClip from the library on the screen). From the viewpoint of object-oriented programming the latter mechanism can be considered as similar to prototypes in “prototype-based” (or “object-based”, see e.g. [No-
ble et al.99]) programming languages. Anyway, the media components (e.g. Porsche andFerrari)
have to be designed only once by the media designer. Figure 5.9a illustrates the observed different abstractions.
Despite of the possible implementations in different platforms an abstract modeling language should support these different conceptual views on media components. There are different ways which might be used to model the observed abstractions. One can interpret them as kind of instantiation: the
Porscheis an instance ofCarand can itself be instantiated multiple times on the screen (fig. 5.9b).
Another possibility is using inheritance and interpretingCar as an (abstract) superclass ofPorsche (fig. 5.9c). However, both interpretations raise the problem that media components are basically no classes and concepts like inheritance and instantiation can not be directly applied to them without further definitions. For instance, it would be necessary to define the impact of inheritance as MML supports to define the inner structure of media components (see below).
A beneficial concept to model these relations can be taken from components in UML.2In UML,
a component can be manifested by one or more artifacts. “An artifact is the specification of a physical 2
Please note that although Media Components reuse some selected concepts of UML components they are still an independent concept. There are significant differences between components in UML and Media Components.
MediaArtifact fileName : String MediaComponent +manifestation 0..n +component 1 0..n 1
(a) MML metamodel for Media Artifacts.
<<Animation2D>>
Car
Porsche Ferrari
(b) Example for Media Artifacts.
Figure 5.10: Media Artifacts.
piece of information that is used or produced by a software development process, or by deployment and operation of a system. Examples of artifacts include model files, source files, scripts, and bi- nary executable files, a table in a database system, a development deliverable, or a word-processing document, a mail message. [. . . ] Artifacts can be instantiated to represent detailed copy semantics, where different instances of the same Artifact be deployed to various Node instances (and each may have separate property values, e.g., for a ‘time-stamp’ property).” [Obj07d]. Examples are an artifact
Order.jarmanifesting the componentOrderor an artifactOraclemanifesting the componentDatabase
Management System[Jeckle et al.04]. In the UML metamodel the Manifestation relationship is de-
fined as a kind of abstraction. This concept fits very well as archetype for media components: AMedia Component(e.g. Car) can bemanifestedby one or moreMedia Artifacts(e.g.
Porsche) which can be instantiated (probably by copy) multiple times where different
instances may differ in some properties (e.g. their location on the screen).
Specifying media artifacts provides an important information to the media designer about which and how many media artifacts must be designed. On the other hand it is not always possible to specify the complete set of media artifacts as it might be not decided yet or it should be extended at runtime. Thus, it is not expected that all media artifacts are defined in the MML model but it is recommended to state at least some example artifacts.
Figure 5.10a shows the metamodel for Media Artifacts. In MML, each Media Artifact can mani- fest only one Media Component. The manifestation relationship has no further properties and thus is not specified as a metaclass of its own.
Notation The media artifacts are denoted similarly to artifacts in UML. They are optionally marked by an icon and are connected to a media component by a manifestation relationship. Figure 5.10b shows an example from the racing game application.
Code Generation For each Media Artifact one placeholder is generated as described in section 5.2.2 for Media Components. Each placeholder is named like the artifact in the model. If no Media Artifacts are specified for a Media Component then a single placeholder is generated which is named like the Media Component itself.