Fase 4: Reconocimiento de percepciones de roles de género que poseen los

Until now, the Abstract User Interface has been specified like in user interface modeling approaches. In conventional applications they would then be implemented by standard widgets. However, in mul- timedia applications the AIOs can also be realized by instances of the Media Components instead. MML enables to specify this byUI Realizationrelationships between AIOs and Media Instances.

Media Instance AMedia Instanceis an instance of a Media Component from the Structure Diagram (sec. 5.2). Analogous to AIOs and Domain Objects, the Media Instances are interpreted as properties of the Scene as well. Although in fact (during implementation) a Media Instance is always an instance of a concrete Media Artifact, the Media Instances in MML Presentation Diagrams are specified more abstractly as instances of Media Components. This is necessary as the concrete Media Artifact might be selected at runtime. However, it is optionally possible to specify a specific Media Artifact name for the Media Instance.

The Media Instances are denoted like Media Components but in addition with an instance name, separated by a colon, before the name of the Media Component. Thereby, the different alternatives to depict a Media Component are all allowed, e.g. collapsed or with a compartment showing its inner structure (see sec. 5.2.2).

UI Realization A UI Realization relationship specifies that an AIO is realized by a Media Instance. It means that the Media Instance fulfills the AIOs role on the user interface. Thus, during code generation such an AIO is not mapped to a standard widget but is implemented by an instance of a Media Component on the user interface. Other AIOs which are not realized by Media Components represent conventional user interface elements outside of the customer’s or designer’s multimedia- specific visions. They are mapped to conventional standard widgets during code generation.

A UI Realization is denoted as a dashed arrow from a Media Instance to an AIO.

Figure 6.15 extends the example from figure 6.14 with UI Realizations. For instance, the Edit Componentcaris realized by the Media Instancecarwhich instantiates the Media ComponentCarAn-

imationand by an instance ofEngineSound. The Output Componenttrackis realized by an instance

ofTrackAnimation.

UI Realizations: Media type vs. AIO type The most obvious case is that a Media Instance realizes an Output Component. But in interactive applications Media Instances can also be used for user interaction. For example, it can be possible to select a specific region in an image or to drag an animation with a pointing device. It depends on the media type whether and how a media instance may act as an interactive AIO, i.e. as an Input Component, Edit Component, Selection Component or Action Component. Audio can usually not act as an interactive AIO as it can not be manipulated. Of course it is possible to record and parse audio using a microphone as accomplished in speech recognition. However, this has no relationship at all to playing an auditive media object (see distinction between the terms “multimedia” and “multimodality” in sec. 2.1). The same holds for video, where a camera and gesture recognition are necessary for user inputs. However, all visual elements, including

<<PresentationUnit>>

<<Animation2D>>

trackAnim : TrackAnim ation

checkpoint : CheckpointGraphic [1..*] obstacle : ObstacleAnim ation [*]

help

{exitTo_Help_show GameHelp()}

engineSound : EngineSound

quit

{exitTo_Menu_show Menu()}

carAnim : CarAnim ation

obstcl : Obstacle checkpoint [1..*] cp : Checkpoint lapsCom pleted player : Player obstacle [0..*] track : Track playerNam e race : Race lapsTotal car : Car start track tim e car <<Scene>> Gam e start()

name elapsedTime totalLaps completedLaps

Figure 6.15: MML Presentation Diagram including UI Realizations for the SceneGame.

video, appear on the screen and can therefore receive user events, e.g. when selected by a pointing device. Thus, all visual objects can act as Action Components.

As animations can dynamically change their content dependent on the application logic, they can additionally act as Edit Components or Input Components. An example is a car animation which represents e.g. the current rotation of the car. The user might manipulate the animation with an input device to edit the car’s rotation value.

All visual objects can also act as Selection Component. As mentioned above Selection Compo- nents are more complex as they consist of multiple choices. A visual Media Instance can act either as the Selection Component as a whole or can represent a single choice. The former case requires that the Media Instance consists of several parts which act as choices, for instance an image of a map where different image regions can be selected. The latter case implies that there are multiple Media Instances – one for each choice. The distinguish between this two cases in the model and for code generation the latter case is specified by assigning the keywordchoices(denoted in curly braces) to the UI Realization.

UI Realizations of Inner Properties As defined above the UI Realization relationship is specified between a Media Instance and an AIO. However, it is also possible that a specific part of the Media Instance actually realizes the AIO. For example in a graphic representing a map, it might be useful that a click on a specific region in the map triggers an event. In the racing game example, it might for

instance be possible to select the kind of tires (rain tires or dry-weather tires) for a car by clicking on the wheels in the car animation.

In case of an Action Component, the part for instance triggers an event. In case of an Edit Com- ponent, the part can for instance be manipulated by drag and drop. In case of a Selection Component, the part can be selected.

In the Presentation Model this is specified by attaching a reference on the Inner Property (referring to a specific part of a Media Component, see sec. 5.2.8) to the UI Realization.

In the diagram, the UI Realization can be annotated with the name of one ore more Inner Proper- ties. Alternatively it is possible to draw the UI Realization directly as connection between the Inner Property and the AIO like in figure 6.15. Of course, the latter alternative requires that the Inner Prop- erty is visible in the diagram (i.e. the Media Instance must not be depicted in collapsed style) and that only one Inner Property is referenced by the UI Realization.

In the example in figure 6.15 the AIOcheckpointis realized by the Inner Propertycheckpointof

trackAnimand the AIOobstacleis realized by the Inner PropertyobstacleoftrackAnim.

Figure 6.16 shows the metamodel for the MML Presentation Model introduced so far. The middle part shows the basic metaclasses: aPresentationUnitis owned by aSceneand containtsAbstractIn-

teractionObjects. The subclasses ofAbstractInteractionObject have been shown in figure 6.13. The

upper part defines theUIRepresentationfrom an AIO to aDomainObject. Analogous toMediaRepre-

sentation(see fig. 6.7) aUIRepresentationcan refer to properties and operations. TheUIRealization

refers to aMediaInstance. AMediaInstanceinstantiates aMediaComponentand may in addition refer to a specificMediaArtifact. TheUIRealizationmay refer to a number ofInnerPropertyelements. The Domain Objects and the Media Instances are owned by the Scene and can be interpreted as properties of the Scene (see above).