The Inception Of A User Interface Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

the inception of a user interface (UI) for a new electronic appliance is an overwhelming task. The customer provides system engineers with some high level specifications of the UI of underlying control system of the appliance. These specifications are mostly in the form of abstract picture drawings or tables having no proper semantics. In return, the system engineers model these requirements using some modeling language or start coding using a programming language. While using General Purpose modeling Languages (GPL) like e.g. UML, system engineers have to constantly map back and forth between domain concepts, modeling language semantics and implementation details resulting in more time to market, bugs in manually written interface code and difficulty in communication between experts. As complexity of user interfaces has increased over the past few years in terms of number of components UI needs to provide interface to the underlying functionality of embedded systems, a formal methodology to develop complex UIs through the specifications has become inevitable.

This at one hand would make UI specifications a part of the whole solution where customer can verify requirements correctness at early stages of UI design, and on the other hand help avoid inconsistent UI design by automating code generation from specifications. Usage of formal methods would make verification of certain properties on UI models easier then verifying same properties on the deliverable code. A Domain Specific Language for the User Interfaces (DSL-UI) would bridge the gap between requirements, design and implementation; by providing a specific formalism as per needs of the domain by raising the level of abstractions and hiding the details to concentrate on a solution, which can be transformed to executable code automatically.

Developing such a DSL presents different challenges one of which is representing dynamic behavior of the UI in response to user interaction. There is very few research on this aspect of domain specific languages and requires a thorough analysis of the underlying domain. Current behavioral modeling approaches such as UML state machines are limited since they do not possess sufficient formalisms of specifying dynamics behavior of the particular user interface from one state to another at a higher level of abstraction understandable by domain experts.

1.2. The Domain of User Interfaces for Embedded Systems

The domain is a sphere of activity or interest. In the context of software engineering it can be an application area for which a software system is developed [1]. Domains’ examples include airline reservation systems, spreadsheets, payroll systems and user interfaces. In case of user interfaces, the domain would consist of domain concept such as screen manipulation or mouse interaction etc.

We come across different electronic devices every day and interact with them cognitively or physically. All sorts of such interactions require a user interface with help of which the user communicates with a device or its control system. A user interface can be defined as a place or means with which a user interacts with a control system.

Frequently encountered are the user interfaces of electronic devices or industrial installations, sometimes referred to as Human Machine Interface (HMI). Interaction devices and embedded interactive systems usually contain such interfaces which act as a layer that separates the human user from the machine it self. The domain of interfaces of such devices has certain concepts which, if provided as modeling language constructs, can help in efficient modeling of user interfaces at a higher level of abstraction.

Embedded systems are systems that are composed of custom hardware in accordance with their target environment and have less processing speed, memory and interaction capabilities (e.g. smaller screen area, no keyboard) which make them different from desktop computers [2]. A property of user interfaces of such systems is that they should have a clear separation of concern between the underlying system and the user interface if they are to be reusable for multiple devices.

There exist simple User Interfaces having less complexity in terms of components the interface has to provide control of, so we can use existing technologies for developing them. These UIs are not our target UIs. On the other hand, very large systems with thousands of components e.g. an electron collider, are out of scope for this research. What the research targets are the UIs in between the both. As now simpler devices tend to provide more functionality that the UI has to support, e.g. mobile phones are now not used to make phone calls only, we need a software engineering approach to model and develop the UIs which ensure specification correctness, less errors and less time to deliver.

1.3. Motivation & Objectives


Developing user interfaces (UI) for embedded systems is time consuming, error-prone and expensive. UI design can no longer be over looked and requires special expertise [3]. Furthermore, developing user interfaces especially designed for a variety of devices in less time and cost has become important. Usually programming them by hand is slow and costly. Conventional system development processes usually leave interface design as a last step to be performed even though interface design is widely considered an important factor in success of a product [4].

The Typical approach of user interface development requires the customer, for whom the end product is being developed, to provide system engineers with the desirable properties of the user interface (in addition to those of the underlying embedded system). These UI specifications are sometimes incomplete and usually provided in an informal manner such as simple textual form or in form of pictures having no semantics behind them. These methods leave behind ambiguities and inconsistencies. The subcontractor or system engineer puts the specifications in a model form using either a General Purpose Language (GPL) like UML or starts coding right away.

Initially the problem arises when the model produced in a GPL is difficult for the end customer to understand in case the customers want to verify that the UI is according to their wishes or not. This is because such verification requires the customer to have knowledge of the modeling language so that they can understand the model. Even if the customer approves the model, the implementation is mostly a manual procedure and prone to typos and mistakes. So the solution to these issues can be firstly to provide the customer with models that they easily understand and secondly to generate code automatically from the model thus reducing manual errors. The solution to such problems is in raising the level of abstraction to be able to work with domain concepts.

Current modeling languages can not be efficiently used to help communication between user, system engineer and computer scientists because computer scientists have to understand the modeling language concepts and map them to the code implementation. Current UML tools produce design diagrams which require usage of programming concepts, even for specific domains. This is because they do not relate directly to any particular domain but to the implementation, directly working with programming language concepts such as classes, attributes and return-values, but not with any specific domain concepts. In addition to this problem, sometimes these design diagrams becoming too large and difficult to modify. Modeling specific to the domain has certain challenges and requirements which are normally not easily met by GPLs.

To address these issues, we require a Domain Specific Modeling Language (DSL) which provides expression of this problem in a particular domain with help of abstractions and notations that correspond to domain concepts directly. The need to express domain features familiar to domain experts leads to the demand for DLSs. DSL can ease the design and implementation of a system by reducing the distance between the problem and its implementation and are able to allows generation of executable code from the domain specific models created in the language. A DSL also removes irrelevant details while isolating them and emphasizes those properties and elements that are most helpful for design. Generating code directly from specification ensure the correctness of generated code with the specifications and this mapping to a lower level of abstraction, normally code, removes any chances of manual coding errors. All implementation details are hidden from developers and they can concentrate on finding the solutions in the domain. This methodology helps the system engineers to capture all the aspects of user interfaces and re-use parts of models when the UI models grow large and complex.

Among other issues, the validation and verification process (for checking inconsistencies and errors) are quite slow on the conventional approaches [5]. By using a DSML, designs represented in form of models can be considered valid and well formed early in the design phase [6]. Model verification and checking according to a meta model with available tools is an advantage of DSL [21].


This research work will concentrate mainly on identifying language constructs for UIs of control systems, facilitating their modeling and generation by formally specifying a domain-specific modeling language. The proposed DSL will follow the UI domain abstractions and semantics, allowing the modelers to perceive themselves as working directly with UI concepts. As the implementation concepts are hidden, the system engineers should be able to focus on finding the solution.

This dissertation tries to analyze aspects of the DSL which can lead to a proposal of a User Interface specification Languages helpful in finding appropriate solutions for the problems faced by system engineers while developing a user interface and analyses why it is difficult to achieve the goal with current methodologies.

Typical constraints specific to embedded systems are addressed by our approach. An example of an embedded system taken as a case study is user interface of control system of a fridge. This activity is undertaken to discover certain properties that the final language should allow the designers to model. The language will be proven complete for developing the user interface encountered in the case study and all other user interfaces which are similar to this UI.

The final goal of this dissertation is to create devise a DSL based on a framework that supports the design and creation of interactive systems while maintaining a clear separation between the UI design and the underlying application logic. For this purpose we will take a model based approach where there are different models at different levels interacting with each other.

Conventionally, user interaction is described using UML facilities like state charts or sequence diagrams (interface behavior) and class diagrams (interface structure). We use a DSL instead to specify structure and behavior but at a higher levels as provided by these general purpose approaches.

Major contributions are related work, separation of concern, analysis of approach, propose an approach of language, identify domain concepts, propose ideas, example and case study, layer analysis, and identify issues, language ingredients, Layers and framework. Etc

The final goal of this dissertation is to create a framework that supports the design and creation of interactive systems while sustaining a clear separation between the (user interface) designer and the (application logic) programmer. This would also ensure reusability for Multi-device interactive systems.