| |
Automated User Interface Software Engineering with a Pattern Reflecting Programming Language
by Anthony Savidis and Constantine Stephanidis
I-GET is a programming language that encompasses language constructs that automate the implementation of commonly recurring programming patterns in user interface development. It has been developed in the context of the TIDE-TP-1001 ACCESS Project.
Historically, a typical pathway towards the genesis and evolution of programming languages is pattern reflection. It is often the case that once complex recurring software patterns appear, reflecting higher levels of maturity in the programming domain, programming languages and libraries evolve to accommodate those patterns as built-in constructs (see Figure 1). For instance, object-oriented programming (OOP) languages appeared as a means to provide built-in support for the effective crafting of structured, re-usable and modular software components. Effectively, while OOP languages are imperative in nature, they provide explicit software organisational elements such as classes, access qualification, inheritance and polymorphism, which require complex programming patterns to be accommodated in non-OOP imperative languages.
 |
| Figure 1: The steps engaged in generating a programming language through pattern reflection, generation and maturity, aiming to accommodate key development requirements. |
In this context, domain-specific languages such as the I-GET User Interface programming language are primarily designed to be domain-optimised, and therefore better suited to addressing domain-related software development problems in comparison to general programming languages. This does not imply that a domain-specific language is computationally more powerful than generic languages. Rather, the domain-specific language automates the resolution of demanding programming patterns leading to source code that is more compact, cleaner, more robust, and more easily re-usable. In Figure 2, the list of the most representative programming patterns for user interface implementation is supplied.
 |
| Figure 2: The list of the frequently occurring user-interface programming patterns, which constituted the design target for the I-GET language |
Reflecting most of the previously identified user-interface programming patterns, the I-GET language supports built-in constructs for interaction object classes, input events and toolkit functions. This allows strong type checking regarding the deployment of those elements for more type-safe source code, when compared to typical libraries of interaction-object classes for general-purpose languages, which are semantically indistinguishable for the compiler from other object classes.
 |
| Figure 3: Excerpt from the API specification of MFC toolkit elements. |
Figure 3 encompasses an excerpt from the definition of the MFC API. As it is shown, the API elements are organised into domain-specific classes, such as lexical objects, input events and output events, while the deployment of those elements is strongly checked by the compiler. For instance, in Figure 4, a callback code is supplied for the ‘quit’ object instance of the ‘Button’ class, to be automatically called when the ‘Pressed’ method is triggered. In this case, the compiler checks that a method named ‘Pressed’ is issued in the API specification of the ‘Button’ object class. Additionally, in Figure 4, the definition of an agent dialogue component class named ‘HelloWorld’ is shown, encompassing various interaction object instances. This class is instantiated automatically once the ‘create if’ precondition becomes true. Agents are domain-specific classes that constitute the interface-component programming model in the I-GET language. They are instantiated during interaction either with a declarative style, relying upon creation preconditions, or with an imperative style, via explicit creation calls. Agents may encompass various definitions such as declarations of interaction object instances, implementation of methods, user-defined data types, local functions, variable declarations, and definitions of embedded agent classes.
 |
| Figure 4: An example of agent classes hosting instances of interaction objects, supporting precondition-based declarative instantiation. |
 |
| Figure 5: Defining monitors and constraints for variables. |
Figure 5 depicts constraints and monitors programming in I-GET. Monitors are code fragments associated with one or more monitored program variables, which are automatically called by the run-time system immediately after any of those monitored variables is modified. Constraints are unidirectional equality relationships that associate constrained variables to a constraining expression. Syntactically, constraints are similar to conventional assignments. Semantically, those assignments must be automatically performed during run-time every time a variable directly engaged in the constraining expression is modified. The deployment of monitors and constraints allows multiple data-views, complex interface inter-dependencies and interrelated conditions to be coped with.
Domain-specific languages such as I-GET are domain-optimised, and in comparison with general programming languages are therefore better suited for addressing domain-related software development. We believe that such languages, when they reflect an in-depth insight and automate the implementation of critical domain-specific programming patterns, can accelerate development and lead to higher quality software.
Link:
Reference manual for the I-GET language:
ftp://ftp.ics.forth.gr/tech-reports/2004/2004.TR332.I-GET_User_Interface_Programming_Language.pdf
Please contact:
Anthony Savidis, ICS-FORTH, Greece
Tel: +30 2810 391749
E-mail: as ics.forth.gr
|
