The OADAPT Process

A systematic, eight-step guide to developing adaptive interfaces.

OADAPT Process

  • OADAPT has two components: the knowledge component provides structured knowledge about AUI systems (Networked Ontologies (ON)), while the process component describes the steps one should follow to develop AUI systems using the offered structured knowledge at development time (ODD) and run-time (OBA). Figure 01 illustrates an overview of OADAPT.

OADAPT: STEPS

Since the OADAPT process is a software development process, it includes some classic software development steps (Identify System Scope and Users, Elicity System Requirements, Perform System Analysis, Define System Architecture, and Implement and Test the System). In addition to them, it includes three steps (Select Ontology, Define UI Adaptations, and Develop Operational Ontology) designed to address the use of ontologies in the development of AUI systems.

(i) Identify System Scope and Users

This step consists of delimiting the system scope, identifying high-level requirements, the system users, and their characteristics. It focuses on understanding the system's purpose and boundaries, the problem to be addressed, and the expected different types of users. Knowing the user's characteristics will help define the adaptations needed in the Adaptive User Interface (AUI) in the next steps. The main user's needs should also be identified to establish an initial set of functionalities based on high-level requirements.

(ii) Elicity System Requirements

In this step, the results of the previous one are refined by defining the system's functional and non-functional requirements. Functional requirements describe the functions the system should contain. Non-functional requirements, in turn, represent constraints that the system should address. In this sense, non-functional requirements are particularly important to indicate UI adaptation needs. For example, if the system users need UI accessibility options, non-functional requirements specifying such needs should be defined to be further addressed in the UI.

(iii) Select Reference Ontology

In this step, considering the system scope, requirements, and user characteristics, the ON fragment (i.e., the ON extract containing the concepts and relationships from networked ontologies that will serve as the reference ontology) to be used must be selected. The ontology provides a shared vocabulary and a set of rules that will be used to define and communicate the meaning of terms and concepts. Moreover, it will serve as a basis for conceptual modeling and reasoning. If necessary, new concepts can be added to the selected fragment. The use of Ontology-Driven Development (ODD) at this step guides the selection and, if necessary, the extension of the reference ontology, ensuring that it can evolve to include new relevant concepts throughout the development process.

(iv) Perform System Analysis

Comprises developing the system structural and behavioral models. The structural model represents the system's static structure, while the behavioral model represents the system's dynamic behavior. Together, these models provide a comprehensive view of the system and its components. The structural model can be defined through UML class diagrams, which represent entities, their properties, and relationships necessary to develop the system. Behavioral models (e.g., UML activity diagram, use cases, among others) can be used to complement the structural view, detailing dynamic aspects of the system.

(v) Define System Architecture

Consists of defining the system architecture, its components (e.g., domain component, UI component), and related technologies. When adopting Ontology-Based Approach (OBA), the architecture must include components that portray the use of an operational ontology. The role of the operational ontology must be clearly defined in the architecture. For example, it can be used in a semantic reasoning engine to enable the system to make inferences based on the knowledge contained in the ontology. The operational ontology can also be used to support other aspects of the system, such as data integration or knowledge management.

(vi) Define UI Adaptations

In this step, the UI adaptation rules are defined. Considering the reference ontology, the system architectures (mainly the UI component), and the user's characteristics, the UI adaptations to be carried out must be defined. For example, it can be defined that if the user is brightness sensitive, the screen must be turned into the high contrast mode.

(vii) Develop Operational Ontology

Consists of producing the operational ontology that will be used at run-time. If there is an operational version of the reference ontology available in the ON, it should be selected. If there is not, the reference ontology must be translated into a machine-readable one. Inference (reasoning) should be carried out to verify the operational ontology consistency. The use of ODD is essential at this step, as it guides the development of the operational ontology, ensuring alignment with the system requirements (Elicity System Requirements) and preparation for integration into the previously defined architecture (Define System Architecture). ODD also supports the implementation of the adaptation rules defined in the previous step Define UI Adaptations) (e.g., axioms in the operational ontology).

(viii) Implement and Test the System

In this step, the system is implemented by following the system architecture and using the operational ontology to implement UI adaptations at run-time. The operational ontology is used by the semantic reasoning engine to identify the most suitable UI adaptation for a particular user based on their characteristics.

This work is licensed under a Creative Commons Attribution 4.0 International License. Copyright © OADAPT Project 2025.
Creative Commons License