Re-Engineering Graphical User Interfaces based on ...

Re-Engineering Graphical User Interfaces based on their Resource Files with UsiResourcer Jean Vanderdonckt1, Óscar Sánchez Ramón1,2, Jesús García Molina2 Louvain Interaction Laboratory, Louvain School of Management (LSM)  Place des Doyens, 1 Université catholique de Louvain (UCL)  B-1348 Louvain-la-Neuve, Belgium 2 University of Murcia, Facultad de Informática, 30100 - Campus de Espinardo – Murcia (Spain) {oscar.sanchez, jean.vanderdonckt}@uclouvain.be – {osanchez,jmolina}@um.es 1

Abstract—This paper addresses the problem of modernizing graphical user interfaces of interactive applications by reengineering their resource files in four phases: resource decompilation, which extracts resource files from the executable code of an interactive application; resource recovery, which transforms extracted resources into a Concrete User Interface model based on static analysis and derivation rules; model editing, which applies requested changes on the model, and resource recompilation, which produces a new interactive application or generation, which re-generates a new graphical user interface. The paper motivates and details this re-engineering approach by focusing on methods and algorithms implemented in UsiResourcer, a software that reverse engineers MS Windows resource files into a Concrete User Interface Model for further process. A discussion on the generalization of the approach is also provided. Index Terms— User Interfaces, Modernization, Model Driven Engineering, Reverse Engineering, Reengineering.

I. INTRODUCTION The life duration of an interactive application is an important, yet challenging, aspect. The code we write for an interactive application is expected to run for a long time. It is not desired that it becomes outdated after a few years. A same interaction application could be also produced for a vast range of product lines (i.e., multiple versions) [1] and contexts of use (i.e., user, platform, and environment) [2] and not just one line or context. The Graphical User Interface (GUI) of an interactive application is subject to an intrinsic complexity that goes beyond merely programming algorithms [3]. GUIs are submitted to continual changes in their development life cycle. Organizations devote significant resources to their maintenance and evolution [1]. The problem is to quickly adapt a GUI to these changes [1]. As the technologies evolve, the requirements evolve too (e.g., additional versions [4], migration to the web [5], retargeting to other platforms [6]). The constant evolution of computing platforms and their associated Integrated Development Environments (IDEs) requires more efforts to cope with portability of interactive applications and their associated GUI. Different cases of GUI evolution may occur:  Specifications and/or models exist that are of enough expressiveness to turn a legacy GUI [4] (e.g., using an oldfashioned technology like Character User Interfaces) into a modern GUI (e.g., using today’s technology).  Specifications and/or models are no longer accessible, but the code of the interactive application still exists. When the source code exists, transcoding technologies [7] could reverse engineer the GUI code into a new one; when the

source code is lost, but the executable one is not, a critical case appears where these techniques are no longer applicable. This paper falls in this case. Extreme cases also occur when only the executable code is accessible, in some old or still accessible format, mostly without any documentation or model of any kind. Consequently, re-engineering GUIs remains a challenging concern when modernizing [8], adaptation GUIs [9] of existing interactive applications, whether they are legacy or not. The task of GUI revamping [7] is also difficult: widgets need to be modified without changing the underlying functional core. Reengineering GUIs to a new platform [10] requires dealing with intricate issues in each stage (reverse engineering, restructuring and forward engineering). In some IDEs such as the native applications for Windows that use the Windows API (formerly Win32 API), applications use Resource Files that define some GUI resources to be used, such as menus, dialogs, icons, or key accelerators. A resource file is a text file which defines resources for structural or behavioral aspects of GUIs. Resource files are compiled to machine code and are loaded into memory at runtime only when they are required in the execution, thus inducing file swapping when needed. In this paper, resource files are an expressive starting point for performing GUI reverse engineering to feed a reengineering process in four phases: (i) decompile resource files in textual format from the executable files, (ii) parse the resources defined in the resource files and instantiate a resource model reflecting the resources’ contents, (iii) transform the platform-dependent resource model in a platform-independent Concrete User Interface (CUI) model as defined in the Cameleon Reference Framework (CRF – a commonly used framework for user interface engineering) [2], and (iv) edit this model for obtaining a new GUI or for reusing it for another interactive application. The remainder of this paper is organized as follows. The next section shows that this approach is original with respect to the related work. Section 3 defines a resource file and its contents while motivating the conceptual differences between traditional GUI reverse engineering and our approach based on resource files. Section 4 explains the four phases of the reengineering process based on resource files exemplified on a running example. Section 5 presents UsiResourcer, the software that supports resource recovery, illustrates some realworld cases, and also discusses how to extend the approach to various formats of resources files and its generalization. Section 6 concludes the paper by discussing existing shortcomings and presenting some future avenues.

II. RELATED WORK Reverse engineering [7] is "the process of analyzing an existing system to identify its components and their interrelationships and create representations of the system in another form or at a higher level of abstraction. Reverse engineering is usually undertaken in order to redesign the system for better maintainability or to produce a copy of a system without access to the design from which it was originally produced." TABLE I. STATE-OF-THE-ART IN GUI REVERSE ENGINEERING. Software Vaquita, 2001 [6,10] WebRevenge, 2002 [13] GUIRipping 2003 [19] ReversiXML 2005 [12]

Input HTML 4.0 site HTML 4.0 page GUI

Output XIML CUI model CTT Task model CUI

Static and dynamic analyses

HTML 4.0 site

Swing2Script 2007 [16] ReverseAllUIs 2007 [14] Wrapper, 2008 [5] Event handlers, 2010 [8, 24] GUISurfer, 2010 [20] UI Controls, 2011 [18]

Java

UsiXML CUI, AUI, user, device CUI, then Ajax CUI, then AUI, then task model SOA

Static analysis, model-tomodel transformation, derivation rules Static analysis, abstract interpretation Static analysis, operator merging, XLST transformation Static analysis

Any GUI

Dialog model

Dynamic analysis and modelto-model transformations

Any GUI

PureXML, 2011 [4] Prefab, 2011 [17]

Java GUI, screenshots Any GUI

Muhairat 2011 [23]

Java GUI

Static analysis, syntactic tree building, code slicing Static analysis of HTML, abstract interpretation of JavaScript Image analysis, patternmatching, static analysis Image analysis, pattern matching, pixel-based methods Static and dynamic analyses, capturing into a Petri net, normalization and translation

ReGUI, 2011 [25]

Windows GUI

Behavioural model Control representation UsiXML CUI model GUI own representation Domain model (UML class diagram Spec# CUI model

MariaReverse, 2012 [15] UsiResourcer, 2013

HTML 5 site

MariaXML CUI model

GUI resource file

UsiXML CUI model

XHTML, VoiceXML GUI

Web application

Techniques Static analysis Static analysis

Dynamic analysis of MS Windows code and tree building Static analysis of HTML code and CSS, encapsulation of JavaScript Static analysis, binary decompilation, derivation rules, model-to-model transformation

Table 1 compares related works by chronological order according to three criteria: the “Input” column specifies the GUI type, the “Techniques” column lists all techniques used to support the reverse engineering, and the “Output” column characterizes its results by mentioning the level of abstraction according to the Cameleon Reference Framework (CRF) [2]: task & domain models, Abstract User Interface (AUI) model that is independent of any interaction modality, or Concrete User Interface (CUI) model that is for a given interaction modality (e.g., graphical), but independently of any implementation. All approaches transform some GUI source code because it

is available (e.g., from the past development process [4,22]) or accessible (e.g., HTML and JavaScript codes downloaded from the web [10,12,13,15]) into some sort of a CUI model. Vaquita [10] statically analyses pages of a web site and turn them into a CUI model expressed in eXtensible Interface Markup Language (XIML – www. ximl.org), which serves for retargeting [6] to other platforms or to completely re-engineer [11]. The same process is used in [9] for reverse engineer a GUI also in XIML. ReversiXML [12], the successor of Vaquita [6,10,11], does the same job into a CUI model, a user model, and a platform model expressed jointly expressed in User Interface eXtensible Markup Language (UsiXML V1.8.0 - www. usixml.org). The CUI Model, obtained by derivation rules, is then abstracted into an AUI Model by model-to-model transformations. Legacy GUIs [6], by static analysis [21], are integrated into a Service-Oriented Architecture (SOA). WebRevenge [13] directly transforms a HTML web page into a CTT-compliant task model that could then serve for launching a forward engineering approach or any other purpose. Skipping intermediate levels (from final GUI to task model) is seducing, but challenging since many design intentions could be hidden at different levels of abstraction. For this reason, ReverseAllUIs [14] jointly reverse engineers a XHTML web page and a VoiceXML document into respective CUI models that are merged in an AUI model, from which a task model is obtained. ReverseMaria [15], the successor of WebRevenge [13], automatically generates a CUI model expressed in MariaXML from any web page (local or remote) expressed in HTML, along with CSS and JavaScript. In [16], Java GUI code is also reverse engineered into an Ajax script, which remains at the Final User Interface (FUI) level [2]. Prefab [17] applies image and pattern-matching filters and algorithms to graphically detect which interaction style or technique is active on GUI widgets, to record it, and to reproduce it. This system is independent from any computing platform since its algorithm works on raw pixel-based screen definitions. Prefab also detects any hierarchy of widgets and their contents to perform customization. Sometimes, only controls are subject to reverse engineering as in FireCrow [18], with or without event handlers [8], as opposed to entire web pages or entire GUI containers, thus providing some degree of flexibility. GUIRipping [19] automatically recreates a Concrete User Interface model of a GUI in order to submit it to modelchecking or test case generation. Although the primary goal of this software is to automate the software testing process, the resulting model could also be used for re-engineering. GUISurfer [20] automatically extracts a behavior model from GUI source code by static analysis in order to test it, to maintain it, and to make it evolving with respect to new requirements. For this purpose, a language-dependent parser transforms the GUI source code into an abstract syntax tree, which then gives rise to a CUI model by code slicing. Then, language-independent software acts on the resulting models. Interaction traces [21] detect the user behavior and suggest GUI optimizations according to the most frequently used interaction traces. They are also reverse engineered from C++ source code [22]. A software suite presented in [4] enables designers or end users to draw GUI prototypes in GUILayout++ (with both low and high levels of fidelity) that are automatically abstracted into an AUI model. In this suite, PureXML sup-

ports loading GUI screenshots from a GUI design or an existing interactive application, and creating prototypes for those screenshots. These prototypes then initiate a CUI model for multiple purposes. Muhairat et al. [23] combine static and dynamic analyses in order to reverse engineer a domain model (expressed as a UML Class Diagram) from a Java GUI in three steps: capturing the static and the dynamic aspects of the GUI into a Petri net with transitions expressing potential navigation schemes, normalizing the transitions, and translating it into a Class Diagram. ReGUI [25] performs some dynamic analysis of a Windows GUI code in order to build a CUI model expressed in the Spec# description language that covers both the presentation and the navigation between the various windows, menus, and controls. UsiResourcer, the software listed in the bottom line of Table 1, is different from these related works: - For the “Input”, UsiResourcer is the only software that performs GUI reverse engineering from a resource file coming from the executable code of the application, and not its source code, thus requiring adequate handling of this format. Conceptual differences also exist between a GUI expressed by its source code and a resource file: more controls are described (e.g., menu bars, pull-down menus, error and information messages, icons) with more attributes (e.g., activation/deactivation, shortcuts, mnemonic keys, multiresolution, multi-languages). - For the “Output”, UsiResourcer relies on UsiXML, a fifthgeneration User Interface Description Language (UIDL) that not only captures various models, but also the traceability of the relationships between these models, all according to the same meta-models. - For the “Techniques”, UsiResourcer combines low-level techniques (e.g., static analysis, binary decompilation) and high-level techniques (e.g., derivation rules and model-tomodel transformation) to uncouple the resource file format from the reverse engineering process. III. GUI RESOURCE FILE A resource file is a structured text file that contains resources which are useful to one or many GUIs of an interactive application. The resources can be icons, menus, dialog boxes, strings tables, user-defined binary data, and other types of items. Once compiled into a suitable format, a resource file can be incorporated directly into an executable file, containing both functional code and GUI resources. At run-time, the interactive application can use the resource items in the embedded file. All computing platforms (e.g., Windows 7, Mac OS X, Linux) use some form resource files with their own proprietary format. In a Microsoft Windows 7 interactive application, resources are usually stored in the executable file (*.exe) or in a separate file named Dynamic Link Libraries (*.dll). As the name suggests, these libraries are not linked to the executable when the application is run, but loaded into the system memory at runtime. Windows is an operating system which uses dynamic linking: the same block of library code can be shared between several applications rather than having each application to duplicate this code. A typical example of resource library is the Common Dialog Library (comdlg32.dll) that provides common dialogs used by Windows applications such as the open file and

print dialogs. A Windows 7 resource file is composed of resource-definition statements falling into three categories: 1. Resources: are static elements that can be used at any time, such as: strings, bitmaps, icons, cursors, accelerators. Appearance and function of menus, HTML files. 2. Controls: define the GUI widgets in terms of types, such as: check box, combo box, pushbutton, scroll bars. 3. Statements: assign values to control properties, such as caption, font, language, style, menus, and menu items. In MAC OS, resources files such as nib (*.nib) or images (*.icns) can also be packaged with interactive applications. Nib resource files store GUI information, including windows, dialogs, and GUI elements such as buttons, sliders, text objects, and help tags for these elements. An interactive application can use several nib files, with one of them designated as the main nib file (containing the main menu and any windows appearing when the application starts up). Other nib files can be loaded whenever needed. A good rule for creating nib files is to use one nib for each separate kind of window in the application. They are a bundle, which means they are really a directory structure, not a single file. This paper focuses on Windows 7 resource files as an example throughout the re-engineering process. The approach could be equally used with other formats, as discussed later on in the Section on generalization. IV. THE OVERALL RE-ENGINEERING PROCESS The overall re-engineering process is composed of two parts (Figure 1): (i) a reverse engineering to ensure the decompilation of the original executable file to get a textual representation of the resources, and the recovery and representation of the GUI using a CUI model expressed in UsiXML; and (ii) a forward engineering consisting of the manual or automated edition of the CUI model (many authors identify this as a restructuring task and differentiate this from forward engineering), and some generation step. Two different generation scenarios are depicted in Figure 1: the recompilation of the resources to integrate them in the original application or the generation of new GUI generation in a different technology. All the mentioned tasks are described in the next sub-sections, based on the running example of Figure 1, a MS Windows dialog box for finding words in a text. This dialog box is introduced here only for the purpose of understandability. Case studies will be discussed in details in Section V. A. Phase 1: Resource Decompilation When an interactive application is built, a resource compiler transforms resources from their initial format (structured text or XML format) into binary files to be linked with the application. Resource decompilation does the opposite: it unlinks and decompiles binary files into textual resource files. There are several applications that can decompile executable files in order to retrieve the resources, such as Resource Builder (http:// www.resource-builder.com), Tuner (http://www.restuner.com), and Resource Hacker (http://www.angusj.com/resourcehacker). The resource file generated for each tool for the same window may not be the same, since the same window can be described in different ways. The tools apply their own algorithms to detect and interpret bit patterns in the binary files.

CUI  model

GrafiXML: CUI Model editing

Phase 1: Resource decompilation Executable Interactive  application

Resource decompilation

Resource files

New Re‐ source file

GrafiXML:  GUI generation

New CUI  model

Resource  recompilation

New  Executable Interactive  application

New GUI

Concrete UI level

UsiResourcer: Resource recovery

resource model

Phase 4: Forward engineering

Phase 3: Resource to CUI  M2M transformation

Final UI level

Phase 2: Modeling the source GUI

FIGURE 1. THE OVERALL RE-ENGINEERING PROCESS EXEMPLIFIED ON THE “FIND” DIALOG BOX.

The resources such as dialogs can contain controls. Each control is attached to flags expressing constraints acting on the control: constraints inherited from the parent object (i.e., the parent window) and specific constraints that are local to the control. Such constraints affect properties such as, but not limited to: Child, Disabled, Visible, Border, TabStop, Group, Verti‐ calScrollBar, HorizontalScrollBar. For instance, a combo box cannot use all the specific attributes of a list box and edit controls: only the AutoHScroll, LowerCase, OEMConvert, Upper‐ Case, Sort, DisableNoScroll, HasStrings, NoIntegralHeight, OwnerDrawFixed and OwnerDrawVariable attributes. Most constraints are expressed with type declaration with enumerate values. For example, a menu item can be disabled and greyed at the same time, a title bar cannot contain a question mark

(ContextHelp = true) with a maximize box or a minimize box (MaximizeBox or MinimizeBox  =  true). Flags attached to controls can be expressed by means of a combination of textual identifiers (Figure 2) and/or a hexadecimal number that represents the bits of a flag. For example, the 19 different types of static controls are grouped in the five first bits, thus representing 25 = 36 flags. This raises an issue for resource decompilation, since the decompiler cannot determinate the actual attributes of a control. For instance, a decompiler cannot differentiate whether the text of a static control is both centered (SS_CENTER flag) and right-justified (SS_RIGHT flag) in the rectangle, or it has an icon (SS_ICON flag). Figure 1 (bottom center) contains an excerpt of the textual resource file obtained for the “Find” dialog box decompiled by Resource Hacker. We

conducted a comparative analysis of 6 resource decompilers on 8 case studies. Resource Hacker was observed as the one providing the most complete and accurate resource files in terms of properties and recovered controls.

FIGURE 2. FLAGS FOR STATIC CONTROLS IN WINDOWS.

The first field after the CONTROL keyword is the name of the control, the second field is the identifier of the control and the third field is the type of control (e.g., BUTTON or COM‐ BOBOX). The following field represents the flags that affect the appearance and behavior of the control (e.g., WS_VISIBLE means that the control is visible and WS_TABSTOP means that the control can be navigated by means of the TAB key). The four last fields represent the X and Y coordinates of the upper left position of the control, its width and its height respectively. B. Phase 2: Modeling the source GUI We need to manipulate and query intensively the information contained in the resource files, so an approach that directly deal with the physical files would be neither practical nor efficient. In this case, creating an object model in memory is a better option. Given that each computing platform defines its proprietary resource file format, the object model will be particular of a certain platform, thus posing the need for having one platform-specific resource metamodel for each platform. Based on the Windows 7 resource file format and its definition, at, a large collection of resource files has been examined in order to come up with a metamodel for representing the GUI elements as expressed in resource files. The metamodel is expressed in MetaObject Facility (MOF- http://www.omg.org/ mof/) as a UML 2.0 Class Diagram reproduced in Figure 4. Only some fundamental information that is useful for the examples in the paper will be reported here. (Nota bene: if accepted, the UsiResourcer web site will be open with details) In a graphical Windows-based application, dialog boxes (DIALOG) as well as graphical controls (CONTROL) are considered as windows (WINDOW). A window (WINDOW) of the application has a style (GeneralStyle attribute), which can be: a popup window, which is a temporary subsidiary window; a child window, which divides a window in regions; and an overlapped window, which is used as a main application window. Dialog boxes (DIALOG) are windows inheriting from the window’s attributes in order to communicate with the user and to provide services that are not located in a menu. A dialog box is defined as a pop-up window (GeneralStyle = popup) containing various child controls. A modeless dialog box allows the user to switch between the dialog box and the parent window, which is convenient when the dialog box should remain active. Dialogs have a thin border (Border=true), a caption bar and a potential system menu box (SystemMenu=true). The controls (CONTROL) are

contained in a dialog box and they allow performing input and output tasks. Controls are child windows (GeneralStyle=child) that can use some of the attributes of the windows, such as a thin-line border (Border = true), the possibility that the control is navigated through the TAB key (TabStop=true), or that the element is visible but cannot be used (Disabled  =  true). Note that the TAB key is particular useful for recovering the ordering of fields in the navigation. For example in Figure 1 (bottom left), figures indicate this ordering based on that information. The type of most attributes in the metamodel is Boolean because of the amount of flags that are available to modify the aspect and behavior of the graphical elements. In order to adequately process the textual resource files, an Extended Backus Naur Form (EBNF) abstract grammar has been defined to recognize the syntax the resources. A EBNF grammar has been defined for each class and its related attributes belonging to the metamodel of Figure 2. UsiResourcer therefore parses any resource file (e.g., the bottom right of Figure 1), identifies the appropriate EBNF grammar for each occurrence of a class of Figure 2, and creates an internal record. The structure of this record has been automatically generated from the EBNF grammar. Changing the ENBF automatically propagates the changes into the record structure. The EBNF can be edited with a grammar editor. For instance, the grammar for a dialog is: DIALOG[EX] , , , [, ] STYLE * [EXSTYLE *] CAPTION "" LANGUAGE , FONT , "" [, , ] { }

where  : any entity of syntactical category S  *: suite of 0, 1 or more entities of category S, separated by the token │  text, typeface: a character string (text may contain escape caracters, e.g. quote \”, new line \n, tab \t, backslash \\)  id: entire number or a character string  x, y, width, height, helpId, pointsize: integer numbers  style: window flag beginning with WS_ or a dialog box flag begining with DS_  ex_style: extended window style flag (beginning with WS_EX_)  language: primary language identifier flag beginning with LANG_  sublanguage: sublanguage identifier flag beginning with SUBLANG_  A ::= B : A is defined by B  a b: a followed by b  a & b: a and b (note that this meta-language symbol is different from the language token│used to combine several styles)  val(A) : value of the attribute A, which may requires a binary or hexadecimal to integer or string conversion  upper(A): converts the text A in upper case.  [A]: A may occur only in a exended dialog box template (that is, a DIALOGEX resource and not a DIALOG resource)  control_def : may contain any combination of control definitions (one by line)

 

 

 

WINDOW Text : String GeneralStyle : {popup, overlapped, child} Border : Boolean Caption : Boolean ClipChildren : Boolean ClipSimblings : Boolean Disabled : Boolean DialogFrame : Boolean Group : Boolean TabStop : Boolean HorizontalScrollBar : Boolean MaximizeBox : Boolean Maximized : Boolean MinimizeBox : Boolean Minimized : Boolean SystemMenu : Boolean ThickFrame : Boolean VerticalScrollBar : Boolean Visible : Boolean ClientEdge : Boolean DialogModalFrame : Boolean StaticEdge : Boolean WindowEdge : Boolean AcceptFiles : Boolean AppWindow : Boolean ControlParent : Boolean ExContextHelp : Boolean Layered : Boolean LayoutRTL : Boolean Left : Boolean LeftScrollBar : Boolean LTRReading : Boolean MDIChild : Boolean NoActive : Boolean NoInheritLayout : Boolean NoParentNotify : Boolean Right : Boolean RightScrollBar : Boolean RTLReading : Boolean ToolWindow : Boolean TopMost : Boolean Transparent : Boolean

MENUBAR MenuID Language : String Sublanguage : String 0..1

1

0..*

0..*

POPUPMENU Text : String State : {enabled,disabled,grayed} Position : Integer

0..*

0..*

0..*

MENUITEM CONTROL CtrlID : Integer X : Integer Y : Integer Width : Integer Hight : Integer +is the buddy window of HelpID : Integer Position : Integer

DIALOG DlgID Extended : Boolean X : Integer Y : Integer Width : Integer Hight : Integer HelpID : Integer 3DLook : Boolean AbsoluteAlignment : Boolean Center : Boolean CenterMouse : Boolean ContextHelp : Boolean DialogIsControl : Boolean FixedSys : Boolean LocalEdit : Boolean ModalFrame : Boolean NoFailCreate : Boolean NoIdleMessage : Boolean SetForeGround : Boolean Language : String SubLanguage : String SetFont : Boolean FontName : String FontSize : Integer Italic : Boolean Weight : Integer ShellFont : Boolean

0..* 0..*

1

EDIT Alignment : {left,right,center} Multiline : Boolean AutoHorizontalScroll : Boolean AutoVerticalScroll : Boolean PasswordField : Boolean LowerCase : Boolean UpperCase : Boolean NoHideSelection : Boolean ReadOnly : Boolean Number : Boolean WantReturn : Boolean OEMConvert : Boolean

LISTBOX Sorted : Boolean MultipleSelection : Boolean DisableNoScroll : Boolean ExtendedSelection : Boolean Multicolumn : Boolean NoSelection : Boolean Notify : Boolean OwnerDrawFixed : Boolean OwnerDrawVariable : Boolean HasStrings : Boolean NoIntegralHeight : Boolean UseTabstops : Boolean WantKeyBoardInput : Boolean NoData : Boolean NoRedraw : Boolean

Regroup

BUTTON VerticalAlignment : {top,center,bottom} HorizontalAlignment : {left,center,right} Flat : Boolean Multiline : Boolean Notify : Boolean

PUSHBOX

PUSHBUTTON Default : Boolean Content : {text,bitmap,icon}

RADIOBUTTON Auto : Boolean RightButton : Boolean PushLike : Boolean

COMBOBOX Type : {simple,dropDown,dropDownList} CaseSensitive : Boolean NoEditImage : Boolean NoSizeLimit : Boolean PathwordBreakProc : Boolean

CUSTOMBUTTON

CHECKBOX Auto : Boolean 3state : Boolean RightButton : Boolean PushLike : Boolean

TRACKBAR AutoTicks : Boolean DowIsLeft : Boolean EnableSelectionRange : Boolean FixedLenght : Boolean NoThumb : Boolean NoTicks : Boolean Orientation : {horizontal,vertical} Reversed : Boolean TickMarks : {bottom,top,left,right,both} ToolTips : Boolean

RICHEDIT DisableNoScroll : Boolean NoCallOleInitialize : Boolean NoIME : Boolean SelfIME : Boolean Sunken : Boolean Vertical : Boolean

0..1 GROUPBOX

SEPARATOR Position : Integer

ItemID Text : String Checked : Boolean State : {enabled,disabled,grayed} Position : Integer

Glue To

0..1

1

0..1

SCROLLBAR Type : {horizontal,vertical,sizeBox,sizeGrip} Alignment : {left,right,top,bottom,bottomRight,topLef,none}

PROGRESSBAR Type : {normal,marquee,smooth} Vertical : Boolean

TREEVIEW CheckBoxes : Boolean DisableDragDrop : Boolean EditLabels : Boolean FullRowSelect : Boolean HasButtons : Boolean HasLines : Boolean InfoType : Boolean LinesAtRoot : Boolean NoHorizontalScroll : Boolean NonevenHeight : Boolean NoScroll : Boolean NoToolTips : Boolean RightToLeftReading : Boolean ShowSelectionAlways : Boolean SingleExpand : Boolean TrackSelect : Boolean

UPDOWN Alignment : {left,right,none} ArrowKeys : Boolean AutoBuddy : Boolean Horizontal : Boolean HotTrack : Boolean NoThousands : Boolean SetBuddyInt : Boolean Wrap : Boolean

STATIC Type : {text,frame,image,enhencedMetafile,ownerdraw} Sunken : Boolean Notify : Boolean TextStyle : {left,right,center,simple,leftNoWordWrap,undefined} NoPrefix : Boolean EndEllipsis : Boolean PathEllipsis : Boolean WordEllipsis : Boolean Frame : {black,gray,white,undefined} Rectangle : {black,gray,white,undefined} Etched : {frame,horizontal,vertical,undefined} Icon : Boolean Bitmap : Boolean CenterImage : Boolean RealSizeImage : Boolean RightAdjust : Boolean

HEADER Buttons : Boolean DragDrop : Boolean FilterBar : Boolean Flat : Boolean FullDrag : Boolean Hidden : Boolean Horizontal : Boolean HotTrack : Boolean

TOOLBAR ALTDrag : Boolean CustomErase : Boolean Flat : Boolean Transparent : Boolean List : Boolean RegisterDrop : Boolean ToolTips : Boolean WrapAble : Boolean NoResize : Boolean NoParentAlign : Boolean Bottom : Boolean NoDivider : Boolean Adjustable : Boolean

REBAR AutoSize : Boolean BandBorders : Boolean DoubleClickToggle : Boolean FixedOrder : Boolean NoDivider : Boolean RegisterDrop : Boolean VarHeight : Boolean VerticalGripper : Boolean Vertical : Boolean

LISTVIEW View : {icon,smallIcon,list,report} Alignment : {left,top} EditLabels : Boolean OwnerData : Boolean ShareImageLists : Boolean ShowSelectionAlways : Boolean SingleSelect : Boolean SortAscending : Boolean SortDescending : Boolean CheckBoxes : Boolean OneClickActivate : Boolean TrackSelect : Boolean TwoClickActivate : Boolean AutoArrange : Boolean NoLabelWrap : Boolean NoScroll : Boolean NoColumnHeader : Boolean NoSortHeader : Boolean OwnerDrawFixed : Boolean FullRowSelect : Boolean GridLines : Boolean HeaderDragDrop : Boolean SubItemImages : Boolean

TAB Type : {tabs,buttons} Bottom : Boolean FixedWidth : Boolean FlatButtons : Boolean FocusNever : Boolean FocusOnButtonDown : Boolean ForceLeft : {none,icon,label} HotTrack : Boolean Multiline : Boolean Multiselection : Boolean OwnerDrawFixed : Boolean RaggedRight : Boolean Right : Boolean RightJustify : Boolean ScrollOpposite : Boolean ToolTips : Boolean Vertical : Boolean

DATETIMEPICKER AppCanParse : Boolean Format : {longDate,shortDate,shortDateCentury,time} RightAlign : Boolean ShowNone : Boolean UpDown : Boolean

STATUTBAR SizeGrip : Boolean ToolTips : Boolean Top : Boolean

CUSTOMCONTROL ClassName : String .

PAGER AutoScroll : Boolean DragAndDrop : Boolean Direction : {horizontal,vertical}

ANIMATION AutoPlay : Boolean Center : Boolean Transparent : Boolean

MONTHCALENDAR DayState : Boolean Multiselection : Boolean NoToday : Boolean NoTodayCircle : Boolean WeekNumbers : Boolean

FIGURE 4. WINDOWS 7 RESOURCES METAMODEL. uiModel 1

temporalOperator value : {>>,|||, | = |,(n)} condition isPositive : boolean isNegative : boolean conditionType : {pre,post}

logicalOperator value : {AND, OR, XOR, IMPLIES}

0..n

creationDate : string schemaVersion : string

event id : string eventType : string eventContext : string device : string

initiation

0..1 0..n action id : string 1 name : string description : string 1..n

behavior id : string

0..n

1..n 1

ruleTerm

transformationSystem id : string name : string description : string

0..n MethodCall methodName : String

target targetId : string

cuiModel

termination

1

1

transition transitionIdRef : string

cio id : string name : string icon : uri content : uri defaultContent : string or uri defaultIcon : uri defaultHelp : uri help : string currentValue : string

1..n

1

1

cuiRelationship 1 0..n

id : string name : string

1..n

1..n

rhs

graphicalRelationship

applicationOrder 1

1

1..n transformationRule id : string name : string description : string

1

0..1

1 1 1 1

nac

ruleMapping 0..n sourceId : string targetId : string

0..n

methodCallParam componentIdRef : string componentProperty : string returnValue : string

1

lhs

0..n

1

1 0..n attributeCondition expression : string

separator type : string 0..1 0..n

1..n

toolBar isFloat : boolean isFloatable : boolean

MenuPopUp

MenuBar

source sourceId : string

1..n 1

graphicalContainer width : integer heigth : integer bgImage : uri isAlwaysOnTop : boolean repetition : integer isDetachable : boolean isMigrateable : boolean

table xSize : integer ySize : integer zSize : integer

1..n tabbedItem index : integer

vocalForm

inputText textMargin : integer isEditable : boolean isWordWrapped : boolean forceWordWrapped : boolean maxLength : integer numberOfColumns : integer numberOfLines : integer textVerticalAlign : string textHorizontalAlign : string filter : uri defaultFilter : string isPassword : boolean

outputText defaultHyperLinkTarget : uri hyperLinkTarget : uri visitedLinkColor : string activeLinkColor : string textMargin : integer textVerticalAlign : string textHorizontalAlign : string scrollStyle : string scrollDirection : string scrollHeigth : integer scrollWidth : integer scrollHorizontalSpace : integer scrollVerticalSpace : integer scrollAmount : integer scrollDelay : integer numberOfColumns : integer numberOfLines : integer

1

vocalMenu

graphicalIndividualCompone nt glueVertical : string glueHorizontal : string defaultMnemonic : String mnemonic : String textFont : string isBold : boolean isItalic : boolean isUnderline : boolean isStrikeThrough : boolean isSubScript : boolean isSuperScript : boolean isPreformatted : boolean textSize : integer textColor : String

radioButton defaultState : boolean groupName : string

videoComponent alternateImage : uri autoplay : boolean isLoop : integer builtInControl : boolean subtitle : boolean subtitleContent : uri

grahicalCointainment graphicalTransition transitionType : string transitionEffect : string

vocalFeedback

graphicalEmphasis

vocalContainment

vocalIndividualComponent

vocalOutput volume : integer intonation : integer pitch : string

graphicalAdjacency

vocalInput ellapsedTime : integer grammar : string

vocalMenuItem

vocalPrompt

drawingCanvas

comboBox isEditable : boolean maxlineVisible : integer 1

1 1..n Item 0..n

imageComponent imageHeight : integer imageWidth : integer imageHorizSpace : integer imageBorder : integer hyperLinkTarget : uri defaultHyperLinkTarget : uri

graphicalAlignment isVertical : boolean isHorizontal : boolean isRightCentralLeft : string isUpDown : string

vocalTransition transitionType : string transitionEffect : string

vocalConfirmation

spin orientation : string

toggleButton defaultState : boolean button

window windowLeftMargin : integer windowTopMargin : integer isResizable : boolean

vocalAdjacency delayTime : integer

0..n

tabbedDialogBox 1

cell xIndex : integer yIndex : integer zIndex : integer isHeader : boolean isFooter : boolean

0..n

cuiDialogControl symbol : string

finalComponent location : uri

vocalContainer

0..n

0..n

1

vocalCio isInterruptible : boolean

0..1

1

statusBar

1

0..1

box type : string relativeWidth : integer relativeHeight : integer isSplitable : boolean isBalanced : booolean isResizableHorizontal : boolean isResizableVertical : boolean relativeMinWidth : integer relativeMinHeight : integer isFlow : boolean isScrollable : boolean gridWidth : string gridHeight : string

dialogBox

vocalRelationship graphicalCio isVisible : boolean isEnabled : boolean statusBarContent : uri defaultStatusBarContent : string fgColor : string bgColor : string borderWidth : integer borderType : integer borderTitle : String defaultBorderTitle : String borderTitleAlign : String borderColor : String toolTipDefaultContent : string toolTipContent : uri transparencyRate : integer

colorPicker

menu popUpMenu : boolean toolBarMenu : boolean

0..n

1..n 0..1

1

menuItem type : string keyboardShortcut : string defaultKeyboardShortcut : string

Tree

1 0..n

FIGURE 5. USIXML CUI METAMODEL.

1 datePicker

1

checkBox defaultState : boolean groupName : string

imageZone hyperLinkTarget : uri defaultHyperLinkTarget : uri shape : string coordinates : coord

slider minValue : integer maxValue : integer step : integer orientation : string

1

1..n 0..1

1..n

hourPicker

listBox maxlineVisible : integer isEditable : boolean multiple_selection : boolean

filePicker type : string

progressionBar minValue : integer maxValue : integer orientation : string indeterminate : boolean

1..2 cursor defaultPosition : integer

Similarly, the grammar production that is used to recognize the controls is structured according to the following format: CONTROL "",,,*,,,, [,*,] Based on these grammars, parametrized derivation rules, an extension of derivation rules [?], are used to derive object instances and their properties from the resources. Table 2 provides an example of the parametrized derivation rules to map the controls of type PushButton. In the left column there is a list of the tokens that can be identified (according to the grammar production for controls that we have represented above), and the right column expresses the mapping to the model elements, this is, the values that are assigned (with the