Un manageur de contextes résolvant les conflits entre les points de vue des concepteurs

Introduction

Ubiquitous computing

During the past four decades, the rapid development of semiconductors and communication technology has created a revolution in embedded and mobile devices

The trend of embedding computational capabilities into everyday objects is transforming how we interact with technology, enabling seamless communication and efficient task performance with minimal user input Advances in sensor technology, wireless communication, and information infrastructures, including GPS, Wi-Fi, and mobile devices, provide users with access to a vast array of mobile services anytime and anywhere As embedded devices and communication technologies rapidly evolve, computation is becoming increasingly ubiquitous in our daily lives.

Ubiquitous Computing, a term coined by Weiser in 1993, refers to the enhancement of computer usage by seamlessly integrating numerous computers into our physical environment while keeping them largely invisible to users This concept encompasses the incorporation of microcomputers into various objects, such as embedded systems and mobile devices, allowing for an array of services that facilitate interactions between applications and devices The true strength of ubiquitous computing lies in the interconnectedness of diverse computing devices, which communicate via wireless or wired networks and adapt to user needs based on local information Furthermore, ubiquitous computing offers omnipresent and mobile access to services, which automatically adjust to the capabilities of the device in use, be it a smartphone, embedded system, or other mobile technology.

Ubiquitous computing has transformed our interactions with both people and digital devices in physical environments, enabling users to engage with various ubiquitous devices for purposes like entertainment, business, and group activities anytime and anywhere.

Ph.D Thesis, The Can DO, December 2019

Figure 1.1: User applications in ubiquitous computing environments

Ubiquitous computing has transformed our daily interactions with technology, allowing users to rely on self-adaptive systems (SAS) that function autonomously in the background This innovation eliminates the need for explicit instructions or decision-making from users, enhancing convenience and efficiency in everyday tasks.

Ubiquitous computing transcends being merely a technological niche; it represents a significant application of information and communications technology seamlessly woven into our daily lives Its primary objective is to meet user needs anytime and anywhere By utilizing sensors and communication protocols, ubiquitous devices gather data about users and their surroundings, enabling them to adjust their functions accordingly.

Figure 1.2: The adaptation to the environment using self-adaptive system

Context-aware and mobility of the user

In today's rapidly evolving technological landscape, it is unrealistic to rely on a static execution environment for computer applications, as the surrounding context is in constant flux Each scenario presents unique information that changes over time, complicating the interaction and management of various devices a user may employ Additionally, factors such as environment, connection, situation, and device diversity significantly impact user mobility and application performance Numerous studies have explored the concept of "Context" across various fields, including economics, computer science, and philosophy Notably, Bazire et al conducted an analysis of 150 context definitions, highlighting essential elements that enhance our understanding of context prior to its application.

This thesis concentrates on the various definitions of context within the realm of computer science, highlighting several widely accepted interpretations Hull defines context as "the aspects of a current situation" [Hull-1997], while Schilit describes it as "the set of location, identities of nearby people and objects, and changes to those objects" [Schilit-1995] These definitions underscore the multifaceted nature of context as recognized by researchers in the field.

According to Schilit and Brown, context encompasses the user's location, the identities of surrounding individuals, and the time of day In contrast, Brézillon defines context as the factors that influence problem-solving without directly intervening in the process.

Henricksen (2002) emphasized that context encompasses the circumstances surrounding an event, which are crucial for its completion Similarly, Chen et al (2004) defined context as the activities and tasks occurring in a specific location However, Dey's (2001) definition is widely regarded as the most comprehensive, describing context as any information that characterizes the situation of relevant entities—such as people, places, or objects—interacting with a user and an application.

Context is defined in various ways by researchers, leading to a lack of standardization and generality Most definitions emphasize the situations of entities and the interactions between users and applications In this thesis, context is examined from the designer's perspective, rather than being categorized by the attributes or entities involved.

In December 2019, the Ph.D thesis by The Can DO et al defined context as information that reflects changes in circumstances, whether they are static or dynamic This definition emphasizes the importance of context in understanding the current situation and forecasting potential changes.

In this thesis, we build upon Li's definition of context, which aids designers in identifying and classifying contextual elements relevant to their work Context can be divided into various elements that reflect each designer's concerns, shaped by the surrounding circumstances We describe context as a collection of situations comprising multiple environmental components, allowing application designers to observe aspects that align with their interests and perspectives Each designer articulates their viewpoints based on the purpose of their application and contextual considerations These viewpoints are further broken down into distinct states, each defined by specific predicates Consequently, context is understood as the array of possible situations corresponding to particular viewpoints.

Context-awareness is a fundamental aspect of pervasive computing systems, first introduced in the early 1990s The concept of context-aware computing was popularized by Mark Weiser in 1991, while the term "context-aware" was first utilized by Schilit et al in 1995 Researchers have since provided various definitions, including Ryan's assertion that a context-aware application can monitor input from sensors and adapt to the user's needs or interests Additionally, Pascoe described context-aware computing as the capability of devices to detect, interpret, and respond to elements of a user's local environment and the devices themselves.

Context-aware systems are defined as those that utilize context to deliver relevant information and services tailored to the user's task, a definition widely accepted in the research community as outlined by Dey in 2001 Additionally, Weiser's definition from 1991 remains influential, describing context-aware technologies as hardware or software that gathers essential context information about both the user and their environment to enhance user applications This thesis aligns with Weiser’s perspective, employing various devices and observation services to collect context information based on the specific needs of the user's application.

1.2.3 The mobility of user and changes of contextual information

With the advancement of communication technology, users can access ubiquitous applications from virtually anywhere However, when a user's location changes, the system must promptly update contextual information to ensure seamless application continuity For instance, when managing smart home devices via a smartphone, moving from home to office alters the surrounding communication, connections, and devices These changes can significantly affect application behavior and the adaptability of the system In the realm of ubiquitous computing, device communication may occur through various means, including wireless transmission, wired connections, or 4G networks As a user's location shifts, network protocols may also change, necessitating the use of different protocols to maintain functionality.

Location information plays a crucial role in contextual understanding, as it encompasses details about social situations and physical conditions As users move, their interactions with stationary objects and other mobile users evolve, influenced by varying factors such as light, humidity, and temperature at different destinations This underscores the necessity for an adaptive system capable of managing contextual information while automatically adjusting to the dynamic environment and the needs of users and devices.

Figure 1.3: User mobility in dynamic environments

Numerous efforts have been made to develop context-aware and self-adaptive systems that effectively manage essential context information and ensure seamless user application continuity in ubiquitous environments However, developers encounter challenges in various research areas, including context modeling and enhancing the adaptability of these systems.

Overview of challenges

Software applications today can adapt to their environment, thanks to foundational research by Weiser, Dey, Schilit, and others in ubiquitous computing and context-aware systems These advancements have led to numerous solutions centered around self-adaptive systems (SAS), which function through a cycle of observation, decision-making, and action By observing contextual status, SAS can make informed decisions guided by adaptation rules that define the system's adaptation capabilities, enabling automatic adjustments of software applications to dynamic contexts.

Figure 1.4: The classical model of a self-adaptive system

The primary objective of automatic software application adaptation is to ensure continuous service delivery across various contexts As user mobility increases, it is essential to adapt applications to accommodate diverse life situations This necessitates finding solutions to enhance the adaptation capabilities of Software as a Service (SaaS) However, as indicated in Figure 1.4, improving these adaptation capabilities requires modeling a greater number of user situations, which simultaneously presents additional challenges for designers [Siadat-2012].

Challenge A Simplifying the designer’s task on context modeling

As user mobility increases, the variety of user situations also expands significantly However, enhancing the contextual support for these situations complicates context modeling, necessitating the creation of a comprehensive model that integrates multiple concepts This complexity requires designers to possess expertise across various context domains, making their task more challenging, tedious, and potentially unmanageable.

With challenge A, we pose the following two research questions to determine the requirements on context modeling and to indicate how to support designers in context modeling process

1) What are the advantages and limitations of the current context modeling techniques?

2) What is the solution to simplify the designer’s task in the context modeling process?

The first research question provides an overview of the requirements necessary for effective context modeling, while the second question seeks to identify mechanisms that simplify the designer's role in the context modeling process.

Challenge B Improve the adaptation capacities of self-adaptive systems

In classical self-adaptive systems, enhancing adaptation capabilities typically requires the addition of more adaptation rules to guide decision-making However, this increase in rules can result in two significant issues: conflicts among adaptation rules and a decrease in the system's reactivity.

Enhancing the adaptation capabilities of Self-Adaptive Systems (SAS) by introducing additional adaptation rules can lead to increased conflicts among these rules Addressing these conflicts during the design phase is challenging, as it requires anticipating all potential contextual concerns in a ubiquitous environment and evaluating every possible conflict scenario that may not occur in actual system operations To effectively manage the growing number of adaptation rules, it is essential to develop an automated method for conflict detection and resolution.

Challenge B1 addresses research questions three and four, aiming to assess existing solutions within the development adaptation system and to suggest alternative approaches for resolving adaptation conflicts in Sustainable Agricultural Systems (SAS).

3) What are the main requirements that development of adaptation systems should meet?

4) How to detect and solve the conflicts between adaptations at runtime?

B2 Improving reactivity of self-adaptive system

The growing complexity of runtime adaptation rules in self-adaptive systems (SAS) has led to more time-consuming decision-making processes When the system is idle during decision time, contextual information may change, resulting in adjustments that no longer align with the current situation Consequently, this necessitates a new cycle of adaptation based on updated context observations, ultimately diminishing the responsiveness of self-adaptive systems.

With challenge B2, we pose the research question five to indicate the main challenges in improving the reactivity of SAS and figures out the solution for these challenges

5) How to improve the responsiveness of self-adaptive systems?

Outline

This thesis addresses various challenges within the realm of self-adaptive systems, with each chapter dedicated to tackling specific problems in different research domains The state of the art is systematically categorized based on the distinct issues explored in each chapter.

Chapter 2 provides a comprehensive background on the concepts utilized in this thesis and examines the current state of adaptation systems This chapter emphasizes two key areas of research: context modeling and the development of adaptation systems.

Chapter 3 presents state of the art related to using context-aware management in self- adaptive system and shows away for using independent viewpoints to model context based on using the new architecture of self-adaptive system We describe the Context intermediate model and implementation with two special viewpoints: BPMN and CTT

We also propose a solution to filter and validate the state of the applied viewpoints

Chapter 4 presents state of the art in the conflict detection and proposes to use the objective of state in detecting the conflicts between viewpoints

Chapter 5 presents state of the art in adaptation conflict resolution and proposes the method to solve the conflicts between viewpoints in the CAM

Chapter 6 describes the solutions to deploy adaptation rules and implementations of our framework

Chapter 7 concludes the thesis by recalling the context definition and presenting the main contributions of the thesis Finally, we identify the main topics that require further investigation for future work.

Background and State of the Art

Context modeling

The rise of ubiquitous computing devices in our environment, coupled with the need for mobility among users and devices, highlights the importance of context-aware systems and software applications Numerous studies have explored context-awareness as a key solution for developing ubiquitous computing applications, primarily focusing on methods for modeling context information and reasoning techniques Context information is collected through sensors or various heterogeneous sources, while context modeling organizes this data into a comprehensible format.

There are many works in context modeling presented in the researches of [Bettini-

In the realm of ubiquitous computing, various studies, including those by Baldauf (2007), Chen (2000), and Strang (2004), predominantly focus on modeling the physical environment and the current user's situation However, developing a comprehensive context modeling solution that addresses all fundamental issues remains challenging This section provides an overview of context modeling within the ubiquitous computing domain, emphasizing the importance of meeting specific requirements.

10 Chapter 2: Background and State of the Art

Ph.D Thesis, The Can DO, December 2019 that context modeling should meet such as domain-independent, reuse ability, separation of concerns, imperfection, context interpretation, etc

A context metamodel establishes a language and semantics for key concepts essential in defining context Various authors have utilized metamodels to address challenges in context modeling, proposing specific metamodels to guide context modeling across diverse applications This includes the introduction of graphical modeling notations and the use of the specification meta-object facility, which ensures a precise syntax and a unified abstract representation applicable to all models.

In 2005, Fuchs et al introduced a metamodel for defining contextual information and its associations, emphasizing key requirements for context modeling, including evolutionary development, interoperability, reasoning, and user-friendliness Their approach aims to limit service interoperability to those utilizing specific information models and incorporates a widely accepted conceptual metamodeling architecture.

Shishkov et al developed a UML-based meta-model that illustrates a system and its environment through various entities, which can function as components or agents Each entity assumes one of four roles: user, processor, actuator, or sensor, and operates under specific regulations and rules While this solution employs a general context modeling approach applicable to all applications, it lacks the capability to separate concerns during the context modeling process Nonetheless, the meta-model is easily modifiable and reconfigurable for use in diverse adaptation systems.

Figure 2.1: Context meta-model [Shishkov-2018]

Chapter 2: Background and State of the Art 11

TriPlet [Motti-2013] comprises three essential components: a Context-aware metamodel, a Context-aware reference framework, and a Context-aware design space These components collaboratively assist stakeholders in analyzing and evaluating adaptable applications for context-aware systems.

Figure 2.2: CAMN: Context metamodel on TriPlet

The TriPlet approach utilizes a context-aware metamodel called CAMN to abstract necessary concepts for model context, establish relationships between these concepts, and define their properties This study aims to provide a methodology for developing context-aware applications However, TriPlet's mappings between adaptation and context information address all adaptation needs without being tailored to specific application scenarios or domains, which limits the reuse of the context model across different adaptation systems and complicates the designer's task.

Context ontology leverages ontology to effectively represent semantics, concepts, and relationships within context data It is constructed by integrating multiple ontologies that address the existence of entities in a pervasive environment, their classification, hierarchical relationships, and distinctions based on similarities Utilizing ontologies in the development of context models offers numerous advantages and enhancements.

Ph.D Thesis, The Can DO, December 2019 functionalities such as formal knowledge representation, logic reasoning, knowledge sharing and reuse

Some researchers used Ontology techniques to model context such as works of [Chaari-

In recent studies, such as those by Wang (2004) and others, researchers have emphasized the development of a generic context storage and processing model aimed at enhancing the intelligence needed to analyze context information By employing ontologies, these models achieve independence from specific programming and application environments Furthermore, standardizing the structure of context representation facilitates semantic descriptions and clarifies the relationships between various entities.

Wang et al introduced CONON, an encoded context ontology designed for modeling context information in ubiquitous computing environments, utilizing OWL for effective reasoning and representation This approach offers a reusable framework that enhances context-aware mechanisms and facilitates knowledge sharing and learning for context interpretation Additionally, CONON promotes the separation of application domains, which encourages the improved reuse of general concepts.

Figure 2.3: The CONON upper ontology for smart home application

This solution offers a flexible interface for defining application-specific knowledge by dividing the context model into upper ontology and specific ontology The upper ontology captures the general features of basic contextual entities, while the specific ontology collects a set of ontologies to detail general concepts and their attributes across various sub-domains However, implementing this solution necessitates that designers possess expertise in multiple domains, as they must leverage diverse knowledge for effective context modeling.

Xu et al proposed the CACOnt, an ontology-based context model designed for efficient context information modeling and inference mechanisms This model consists of two components: generic context ontologies that capture fundamental context concepts, and context extensibility ontologies that allow for the hierarchical addition of domain-specific ontologies This design enhances the reusability of general concepts while minimizing the complexity of context knowledge Additionally, CACOnt incorporates a hybrid context reasoning approach and a semantic similarity-based rule matching algorithm However, it does not address the separation of contextual concerns across different tasks, limiting the reusability of the context ontology across various independent applications.

Aguilar et al utilized a CAMeOnto meta-ontology for effective context modeling, which is structured around the 5W questions and consists of two levels: a general ontology and a specific domain context ontology The research categorizes context into three types—boundary, external, and internal—and defines it through six contextual classes: user, activity, time, device, services, and location This framework facilitates the reuse of context models in application development with minimal modifications However, it lacks a mechanism for separating concerns in context modeling.

Figure 2.4: Hierarchical design of a Context ontology [Aguilar-2018]

“Graphical models are a marriage between probability theory and graph theory They provide a natural tool for dealing with two problems that occur throughout applied

In the realm of mathematics and engineering, uncertainty and complexity are increasingly significant in the design and analysis of machine learning algorithms (Jordan, 1998) Graphical models play a crucial role in probability theory and statistics, particularly in machine learning for context modeling A widely recognized graphical model for general-purpose modeling is the Unified Modeling Language (UML), which effectively models contextual aspects, as demonstrated in Bauer's approach (Bauer, 2001), where UML extensions are utilized to represent these contextual elements.

Henricksen et al developed a graphics-oriented context model that enhances the Object Role Modeling (ORM) approach by incorporating contextual classification and description properties ORM, introduced by Halpin, is a conceptual modeling methodology that combines graphical notation with design processes, focusing on facts within a pervasive environment This extension allows for categorizing fact types into static, profiled, sensed, or derived, thereby facilitating various context management tasks.

Figure 2.5: The graphical context modeling follows fact type [Henricksen-2003]

Adaptation system

An adaptation system employs middleware and an adaptation platform to deliver user applications tailored to the pervasive environment Over the past two decades, significant research has focused on adaptation systems, including self-adaptive systems, context-aware systems, and context toolkits, as well as adaptation middleware, highlighted by studies such as Dey (2001), Bolchini (2013), Keling (2011), and Cheung et al (2007).

Figure 2.6: Architecture of an adaptation system [Keling-2011]

Both context-aware systems and self-adaptive systems sense environmental changes and adjust their behavior accordingly However, context-aware systems emphasize modeling and reasoning about relevant environmental factors to anticipate changes, while self-adaptive systems concentrate on responding to unforeseen environmental shifts.

Dey et al developed a context toolkit that integrates sensors to facilitate rapid prototyping of contextual applications, enhancing the reusability of model components and supporting complex context acquisition and usage This toolkit translates contextual information into high-level formats, simplifying access for adaptation systems, and separates the acquisition process from context representation Its architecture promotes the development of context-aware applications, allowing component reusability across different applications and supporting their evolution However, the study does not address the separation of context management from the adaptation layer, which may hinder the responsiveness of the adaptation system as the number of user scenarios or applications increases.

Figure 2.7: Architecture diagram of Context Toolkit

An adaptation middleware serves as a crucial intermediary that offers mechanisms and services for executing adaptation tasks It enables user applications to efficiently support numerous concurrent users, connect to various data sources, and seamlessly interoperate with other middleware services.

In recent years, various context-aware middleware architectures have emerged, including those proposed by Li (2015), Yu (2010), Sain (2010), and Fahy (2004), aimed at delivering proactive adaptive behavior in response to dynamic environments These architectures primarily focus on adjusting to the evolving requirements of the adaptation system.

In this section, we explore middleware architectures that align with the requirements of an adaptation system, focusing on context collecting, context controlling, and the separation of context management from applications This discussion is based on insights from the Ph.D thesis titled "The Can DO," published in December 2019.

SOCAM [Gu-2005] is a service-oriented, context-aware middleware designed to support the development of context-aware applications in ubiquitous environments Its core strength lies in transforming contextual information from various physical spaces into a semantic format, facilitating easy sharing and utilization by applications The SOCAM architecture employs OWL for context modeling, enabling developers to establish rules and specify methods triggered by specific conditions Additionally, it records adaptation rules and updates contextual information upon detecting changes, while maintaining a context database that stores both current and historical contexts to enhance system responsiveness However, the study does not address solutions for minimizing conflicts between adaptation rules during runtime.

WComp [Tigli-2009] is an adaptive middleware based on Aspect-Oriented Programming (AOP), utilizing the innovative concept of Aspect of Assembly for its adaptation process The WComp model is organized around three key paradigms: event-based web services, a lightweight component-based methodology for creating dynamic composite services, and the adaptation approach centered on the Aspect of Assembly concept These paradigms collectively offer two effective solutions for the dynamic design of ubiquitous computing applications in common contexts.

The Ph.D thesis titled "The Can DO," completed in December 2019, explores a component-based approach that enhances the design of advanced composite Web services and expands the network of cooperative services for ubiquitous computing applications Additionally, it presents a compositional adaptation system that leverages assembly aspects for improved functionality.

Figure 2.9: Context and user driven self-adaptation [Tigli-2009]

This paradigm is designed to drive composite services that respond to users' changing preferences and contextual information By adopting a user-driven approach, it enables adaptation middleware to adjust applications to their environments effectively Users can directly modify the base assembly, allowing them to add or remove behaviors and functionalities within the adaptation system This study addresses conflicts between adaptations at the adaptation rules level; however, it highlights a limitation in responsiveness as the number of adaptation rules increases significantly.

A context-aware system is designed to collect and analyze environmental information in real-time, enabling it to adapt its behaviors automatically By utilizing both software and hardware, these systems model and reason about their surroundings, employing tools such as ontologies and metamodels to effectively respond to anticipated changes in application or configuration settings.

Numerous studies have explored context-aware frameworks, focusing on key areas such as device communication, self-learning, and application-oriented approaches [David-2005], [Dey-1998], [Nandyala-2016], [Perera-2013].

Ph.D Thesis, The Can DO, December 2019 part, we present some context-aware frameworks based on context-aware application and interaction with context view

PersonisAD [Assad-2007] is an innovative context-aware framework designed to support ubiquitous applications by modeling various entities such as people, sensors, devices, and places in a homogeneous manner It utilizes a tree-structured context model that organizes these components effectively, allowing for a robust response to changing context information A key advantage of the PersonisAD framework is its ability to deliver personalized ubiquitous services by integrating diverse evidence from the environment and interpreting it flexibly However, the study acknowledges limitations, including insufficient context information storage and the absence of mechanisms to resolve conflicts arising from adaptations within the framework.

Costa (2007) introduced an integrated solution for developing context-aware systems, emphasizing context modeling and a context handling platform Their abstractions in context modeling provide application designers with a solid conceptual foundation to tailor applications to specific requirements This approach incorporates a model-driven specification for situational context in applications, where behaviors are defined by event-control and action rules A context processor component is utilized to manage context-related concerns, collect information from the user's environment, and generate relevant context and situation events Additionally, controller components monitor condition rules and events through context processors, triggering actions on the action performer once conditions are met This solution streamlines application development for designers and enhances the integration of multiple applications within a single system However, the study does not address potential conflicts arising from adaptations between applications and the proposed solution.

Achilleo et al (2010) introduced a model-driven methodology that facilitates the creation of a context modeling framework, streamlining the design and implementation of pervasive services Their approach enhances automation in software generation and led to the development of the Context-aware Pervasive Service Creation Framework (CA-PSCF) This framework allows designers to define context models at an abstract level and includes validation features to identify and correct invalid definitions prior to implementation Consequently, designers can create independent context models tailored to their specific needs, enabling reuse across various applications.

However, the CA-PSCF does not mention to the conflict ability between independent models when the system merges them at runtime

Context Broker architecture [Chen H.-2003] is an architecture for supporting context- aware applications, as shown in figure 2.10

Chapter conclusion

Our research indicates that current initiatives fail to effectively address the distribution of specific contextual concerns in context modeling While many approaches provide support for rich and dynamic context modeling, they often overlook the need to simplify expert tasks and enhance the reusability of context concerns across various applications Prioritizing the simplification of expert tasks and increasing the reusability of context concerns is essential for the advancement of context modeling Consequently, these factors should be integral considerations when developing a context handling platform.

Researchers have primarily utilized Context-Aware Middleware (CAM) as a crucial solution for managing and handling contextual information within adaptation systems However, there is a notable lack of discussion regarding the resolution of conflicts that may arise between adaptations in CAM Addressing these conflicts is essential for enhancing the effectiveness of adaptation systems.

In the context of designing a context-aware management system, addressing conflicts between adaptations in Context-Aware Management (CAM) is crucial By effectively resolving these conflicts, we can minimize the number of issues the adaptation system needs to tackle before delivering services to the user This focus on conflict resolution is essential for enhancing the overall efficiency and effectiveness of the system.

This chapter's discussion has addressed the first and third research questions by highlighting the advantages and limitations of existing methods for context modeling and adaptation system development The upcoming chapter will present solutions aimed at overcoming the identified limitations of these current approaches.

Context intermediate model and Architecture pattern

Context-aware management (CAM)

Many researchers are currently utilizing context-aware management to differentiate the execution cycles of context-awareness and adaptation in self-adaptive systems (SAS) This approach enables these systems to allocate more time to address changes in current contextual information According to Henricksen (2005), the role of a context-aware management system is clearly defined.

Context management involves the maintenance, access, update, and synchronization of distributed contexts It provides a seamless interface for handling context, supports ad-hoc context exchanges, and facilitates both real-time and non-real-time context processing.

30 Chapter 3: Context intermediate model and Architecture pattern

The context management layer is designed to create a self-adaptive system that updates and distributes context information independently Context-sensitive systems utilize contextual elements to deliver relevant services or information to users and applications during task execution, as demonstrated by Vieira et al [Vieira-2007] Effective context-aware management is crucial for defining models and systems that facilitate the acquisition, manipulation, and maintenance of a shared repository of contextual elements across various context-sensitive systems The primary aim of context management is to simplify the development of context-aware systems by transferring the complexity of contextual element manipulation to an intermediate layer This approach enables a focus on modeling context, sharing context information, and providing the infrastructure necessary for detecting, updating, and inferring new contextual element sets from existing data.

Figure 3.1: Generic context manager main functionalities [Vieira-2007]

Kim et al developed a context management system that utilizes context metadata to effectively manage context information Their framework comprises six key components: context aggregator service, context discovery service, context provider services, context observer service, context ontology reasoner service, and context query service This context-aware management approach facilitates the collection and administration of context information from diverse devices, including sensors, cameras, embedded systems, and traditional computing devices By employing a service-oriented architecture, the system addresses the challenges of heterogeneity in ubiquitous computing environments, ensuring consistent interfaces and standardized protocols.

Chapter 3: Context intermediate model and Architecture pattern 31

Figure 3.2: Context-aware management structure [Kim-2008]

Recent studies indicate that Context-aware management (CAM) is increasingly utilized to handle contextual information in self-adaptive systems (SAS), allowing these systems to concentrate on their adaptation functions By separating CAM from SAS, the complexity of developing self-adaptive systems can be significantly reduced However, for CAM to effectively gather and process contextual information, it necessitates an appropriate context modeling technique, which currently faces several limitations.

Context model solution

3.2.1 Problem with designing a single big context model

When a user changes their location, their surrounding context also shifts, necessitating enhanced adaptation capabilities in SAS To ensure seamless user services, SAS must deliver mobile applications that intelligently adjust to various environments and user needs This adaptability requires the SAS to accommodate all potential user situations and scenarios However, modeling user context through predictive analysis can complicate the context modeling process by increasing the number of concepts that need to be defined.

Designing a comprehensive context model necessitates the integration of knowledge from various expert domains, complicating the context modeling process for designers.

Developing a single comprehensive context model presents significant challenges, particularly in terms of architecture and algorithm troubleshooting, which requires multi-domain expertise from designers The extensive range of situations modeled complicates context analytics in Context-Aware Middleware (CAM) and results in time-consuming processes Additionally, this specificity limits the model's reusability, making it less applicable to other scenarios Therefore, it is essential to find solutions that address the limitations associated with a singular large context model.

Figure 3.3: A single big context model in self-adaptive system

3.2.2 Separate concerns: the solution to solve the problems related to designing a single big context model

Nešković et al proposed a novel approach for context modeling in complex context-aware systems (SASs) by utilizing independent local context models tailored to the specific needs of individual applications This method enables the integration of multiple independent context models, each representing distinct user scenarios or designer perspectives In our thesis, we advocate for the division of the existing context model into several independent models, allowing experts to leverage their domain knowledge to articulate application scenarios based on their specific viewpoints This strategy simplifies the designer's task, enabling experts to concentrate solely on their areas of expertise, thereby streamlining the development and reconfiguration of context modeling and reducing potential disruptions to system operations.

Different experts utilize various techniques and modeling tools to express their viewpoints, resulting in distinct data types and structures for each model To integrate this data into the Contextual Application Model (CAM), it is essential to convert all viewpoints into a standardized format known as the Context Intermediate Model (CIM) Before users can incorporate their data into CAM, it must be transformed into CIM's standard format, as illustrated in figure 3.4 Employing independent viewpoints to model each context domain during the design phase minimizes operational impacts on the system and enhances the reusability of each designer's perspective in application development.

Figure 3.4: Using CIM as standard data for all viewpoints.

Special viewpoints in context domain

Special viewpoints within the context domain encompass a range of specialized methods established by various experts These viewpoints effectively describe the structure and maintenance of context data, including Scenario Context, Business Process Modeling Notation (BPMN), ConcurTaskTree (CTT), Security Models, and Task Models.

A design scenario outlines the user's interaction with a device within a specific context, highlighting key interaction points that facilitate task completion It emphasizes the relationship between the user and the technology in a dynamic environment Previous research on context modeling in learning scenarios, including studies by Chaabouni (2016), Uchitel (2004), and Greiner (2014), demonstrates the feasibility of representing a dynamic environment through storytelling.

Business Process Modeling Notation (BPMN) is a widely adopted modeling standard developed by the Object Management Group since 2005, designed to capture complex business processes with a range of notational details Its primary goal is to create an intuitive notation for business users while effectively representing intricate process semantics for both technical and non-technical audiences One of BPMN's key strengths lies in its simplicity, making the notation easily understandable and accessible to individuals from various professional backgrounds.

Figure 3.5: The procedure for managing architectural contests [Marcinkowski-2012]

David Schumm and colleagues demonstrate how to leverage the graphical features of BPMN for modeling BPEL processes, enabling the creation of executable processes without the need for model transformations Their research reveals that BPEL processes can be effectively developed using graphical representations, such as icons and connecting components, while adhering to the semantics established in BPMN.

According to Ruiz et al (2012), BPMN is recognized as the industry standard for modeling business processes, allowing for abstract problem modeling and enhancing execution and reusability The authors highlight that BPMN serves as an effective communication bridge between domain experts and computer scientists, enabling both business users and technical personnel to collaborate using their respective terminologies.

A task model serves as a specialized framework that bridges user interface design with engineering methodologies, as noted by Paternò in 2002 This model enables designers to represent and manipulate a formal abstraction of the activities necessary to achieve user objectives effectively.

Figure 3.6: Use of task models in the design cycle [Paternò-2002]

ConcurTaskTrees (CTT), created by Paternò, is a user-friendly notation for task model specifications designed to address the shortcomings of previous notations used in interactive application development Its primary goal is to facilitate collaboration between developers and users while effectively supporting the design of medium-scale applications in real-world industrial settings.

Contextual concerns each have unique models that can effectively illustrate specific viewpoints in the context modeling process By utilizing these specialized models, experts can develop targeted viewpoints, which is a key reason for advocating the use of special viewpoints in context modeling.

Using special viewpoints to separate concerns in context modeling

In our analysis, we identified the potential to separate context concerns by employing an independent Context model for each specific domain Our proposed solution, illustrated in figure 3.7, utilizes distinct special viewpoints for context modeling Designers within each domain leverage their specialized knowledge to create user scenario applications By adopting an independent viewpoint for context description, we can effectively minimize the impact of related concerns across different applications.

Figure 3.7: Using special viewpoints in context modeling

Our approach utilizes Context-aware Management (CAM) to gather contextual information and manage various specialized viewpoints of applications Each designer employs a unique viewpoint to model their user scenario, leading to diverse structures, properties, and languages for each viewpoint This results in multiple data types following the modeling process To address challenges related to converting and synchronizing context information, we introduce a Context Intermediate Model (CIM) as an intermediary between expert-specific models and CAM All specialized viewpoints, such as BPMN and CTT, must be transformed into the CIM format for effective integration.

In December 2019, the Ph.D thesis titled "The Can DO" explored a process that can be executed either manually by a designer or automatically through conversion tools This approach involved the development of tools that facilitate the automatic conversion of data from specific viewpoints, which is further elaborated in the implementation section.

Activity design: Architecture of self-adaptive system and context intermediate

3.5.1 The model architecture of self-adaptive system

We propose a novel architecture for a self-adaptive system that utilizes specific tools to convert special viewpoints into XML files adhering to the CIM format during the design phase At runtime, these viewpoints are integrated through context-aware management (CAM), which oversees all special viewpoints and identifies context changes, as noted in Rey-2017 CAM also resolves conflicts between viewpoints before implementing adaptation rules in the self-adaptive system (SAS) Our approach introduces two independent observation cycles for CAM and SAS, allowing CAM to focus on context information management When CAM detects changes in context or modifications to special viewpoints, it triggers a reconfiguration of the self-adaptive system, enhancing CAM's analysis time while maintaining SAS responsiveness.

Figure 3.8: Model architecture of system

The independence of the execution cycles for the SAS and CAM allows application layer operations to function autonomously during the CAM's decision-making phase This means that system applications can continue running while the CAM identifies context switches, only pausing for the implementation of the adaptation plan Consequently, the SAS effectively reduces adaptation time and alleviates issues related to system resource consumption The CAM assesses each predicate from its viewpoint to determine the current situation, enabling the application of relevant adaptation rules, with the SAS providing appropriate actions or decisions based on the evaluated context.

In our approach, the Context Intermediate Model (CIM) is an XML description of the specific type of the Moore automaton described by the following 6-tuples (S, s0, Σ, Ʌ, δ, g):

- S is a finite set of viewpoint states

- Σ is a set of input predicate vector that is defined as a finite set of predicates

- Λ: Λ → (Ω) is an output alphabet defined as a finite set of Objectives of State

- δ: F(Σi) → si is a Surjective function mapping an input alphabet Σ to the state

- g: S → Λ is an output function mapping each state to the output alphabet Λ

The data flow of viewpoint G1 is illustrated in Figure 3.9, where the input alphabet consists of a finite set of n predicates used to identify states in S This leads to a maximum of 2^n possible state vectors In this methodology, we employ a specific type of Moore automaton, utilizing a Surjective function to replace the traditional transition function By focusing on one state of the viewpoint at a time, we concentrate solely on the observation predicate, which justifies the use of the Surjective function introduced by Nicolas Bourbaki in 1968 as a substitute for the transition function in the Moore automaton.

Figure 3.9: The data flow of viewpoint in CAM

A function f from a set X to a set Y is considered surjective, or a surjection, if every element y in the codomain Y has at least one corresponding element x in the domain X such that f(x) = y Importantly, it is not necessary for x to be unique, meaning that multiple elements from X can map to the same element in Y.

When utilizing K distinct viewpoints within a single system, it is essential to employ K unique tools to transform information from these specialized perspectives into CIM format Both tools implement a Surjective function to substitute the transition function typically found in a standard Moore automaton However, due to variations in structures and formats, each tool applies different algorithms to effectively convert the information corresponding to each specific viewpoint.

Figure 3.10: Each viewpoint is managed independently in CAM

To understand the application of Moore automata theory for the Context intermediate model, we might see in the following example

The designer must create a user scenario in which a user arrives at the laboratory to complete specific tasks To gain access, the user is required to present an ID card that unlocks the door Once the door is opened, the system automatically activates the necessary tools for the user to utilize.

- Predicate 1 (P1): Check ID (The system will check the ID card provided: “true or wrong

- Predicate 2 (P2): Check door opened (The system will check the Door situation: “open or close”)

- Predicate 3 (P3): Tool activate? (The system will check the Tool activate situation:

In this example, we typically have eight states due to the presence of three predicates However, by using a specific notation, we can merge some states For instance, the notation P1 & P2̅̅̅̅ represents two distinct states: P1 & P2̅̅̅̅ & P3 and P1 & P2̅̅̅̅ & P3̅̅̅̅.

- s1: 𝑃1̅̅̅̅ (not P1, this state happens when the system detects ID supported wrong or not valid)

- s2: P1& 𝑃2̅̅̅̅ (P1 and not P2, this state happens when the system detects ID true but the

- s3: P1&P2&𝑃3̅̅̅̅ (P1, P2 and not P3, this state happens when the system detects ID true, the Door opened, but the Tool still deactivated)

- s4: P1&P2&P3 (P1, P2 and P3, this state happens when the system detects ID true, the

Door opened, and the Tool activated)

- The user’s scenario above can be captured by Moor automaton following our description, then we have:

) = sn+1 (where Pi(t) is the value of predicate at the time t)

- λ = {si, output function} (i: the number of states in the set of state)

Figure 3.11 illustrates the CIM schema utilized as the output standard data for the converting tool developed in our previous research [Rey-2017] This diagram features distinct viewpoints, referred to as "Viewpoints," each organized into three components: "Description," among others.

The "Description" section holds unstructured comments and information from programmers, intended for designers, which can include details like the view name and version Meanwhile, the "Predicate" section contains all identified predicates, each uniquely identified by a PredicateID specific to a view.

The "ObservationRulesSet" outlines the guidelines for constructing an observation mechanism that retrieves predicate values The "State" element comprises two components: "Evaluation" and "AdaptationRulesSet." The "Evaluation" section holds the vector of predicate values necessary for state identification, while the "AdaptationRulesSet" contains the adaptation rules to be implemented within the SAS upon state identification and execution Additionally, the "Attributes" for viewpoint, predicate, and state solely store their respective IDs.

Figure 3.11: The XML schema of context Intermediate model

Each Adaptation Rule (AR) is designed to store a specific set of guidelines that enable the SAS system to adjust its service functions based on the current state The adaptation rules are tailored by individual designers and are influenced by the hardware of each application An example of this can be seen in our project, Continuum.

The AR is divided into two sections: the first section involves searching all active devices or services for names that include the terms "switch" and "lamp," where "switch" is represented as switch* and "lamp" as lamp*.

If at least one switch and one lamp are identified, the system establishes a connection between them This is achieved by linking the lamp method (lamp.SetTarget) to the event (Status_Event) triggered by the switch, which corresponds to a change in its state, enabling the lamp to illuminate.

(lamp.SetTarget)

The methods of generating the context model from the models of concerns

In the context domain, various specialized viewpoints utilize distinct languages for modeling context This section showcases two examples that demonstrate the conversion of domain-specific models into intermediate context models The examples include a Business Process model utilizing Business Process Modeling Notation (BPMN) and a Task Model based on ConcurTaskTree (CTT) notation.

3.6.1 Generating the context model with the Business process viewpoint

The Business Process Modeling Notation (BPMN) is a widely used graphical notation that facilitates the representation of business processes through business process diagrams Its primary goal is to serve as an effective process management tool for both business and technical users A White's work in 2004 offers a solution for defining and executing business processes using XML Process Definition Language (XPDL), which standardizes the description and analysis of these processes.

In our methodology, we utilize BPMN as a targeted tool to illustrate specific viewpoints, such as application or user scenarios While BPMN serves as a straightforward resource for business professionals, the XPDL data exported from it often contains extraneous information, including graphical object details like location and size This complexity makes the transfer of information from BPMN to CAM a challenging task To address this, we developed a specialized tool using C# that converts XPDL files from BPMN into XML files conforming to the CIM schema Our focus is on mapping only the essential BPMN elements rather than all graphical objects, and we recommend employing Sub-process objects to streamline the representation of extensive business processes.

Figure 3.12: Using BPMN to describe specific viewpoint in context modeling

We propose utilizing CIM as the standard data framework for all perspectives, necessitating the conversion of XPDL data from the BPMN viewpoint into an XML file that adheres to CIM standards As highlighted in Table 3.1, A White's contributions focus on the mapping from BPMN to XPDL, while our research specifically addresses the mapping of XPDL to the standard data format of CIM.

Table 3.1: The mapping from BPMN to CIM standard data type

This article explores the connections between BPMN, XPDL, and CIM by examining a business process modeled using a BPMN tool, which will then be analyzed and mapped to the CIM standard.

The BPMN process begins with the receipt of an order, which is subsequently checked for availability If the item is available, the order data proceeds to the "Ship article" task Following shipment, the order data is processed through a "Financial settlement" application, culminating in the final step where payment is received.

Figure 3.13: The E-Order process that is described by graphical notation

When an order is unavailable, it enters a "Situation" task, which may lead to a Process Error or Escalation, indicated by Intermediate Events linked to the task's boundary Following these events, a task to "Inform customer" is initiated If a problem with the order process is detected at this stage, a "Remove article" task is executed, and the order information is updated to reflect the "Article removed" action, finalizing the process Details of the mapping process will be discussed in the next section.

After creating a business process application using a business process modeler tool, designers can utilize the export data function to convert the graphical representation of the process into a text file format known as XPDL For instance, the E-Order process can be exported into an XPDL file using the business process modeler tool, demonstrating the tool's capability to facilitate seamless data conversion.

Once we obtain the XPDL file from the Business Process Modeler tool, we proceed to convert it into XML format according to the standard data type of the context intermediate model This conversion can be performed either manually by the designer or automatically using a conversion tool, which will be detailed in Chapter 6 The outcome of this conversion process is illustrated in the XML file provided below.

This section highlights BPMN as a straightforward example of graphical notation for modeling business processes, emphasizing that similar representations can be achieved using other models, provided they offer a manipulable format such as XML, XPDL, or JSON.

3.6.2 Generating the context model with Tasks model viewpoint

Many task models are utilized in the design of interactive applications, with ConcurTaskTrees (CTT) notation being the most widely used tool CTT is specifically designed for user interface model-based design, making it a key resource for creating effective interactive applications.

ConcurTaskTrees (CTT) is an advanced task modeling tool that builds on previous experiences to offer an intuitive and robust notation for describing dialogues in interactive systems It enables users to derive user interfaces for various platforms directly from CTT specifications, facilitating the application development process The hierarchical structure of tasks allows for interrelation through a comprehensive set of operators that define the temporal relationships between subtasks Additionally, CTT provides designers with the flexibility to specify optional task attributes, including type, category, object manipulation, and performance time The framework of ConcurTaskTrees consists of three key components: a hierarchical structure, graphical syntax, and concurrent notation.

We use the ConcurTaskTrees tool to describe a special viewpoint that is related to using graphical notation in building the application, as shown in figure 3.14

Figure 3.14: Using CTT to describe specific viewpoint in context modeling

And, we also establish a specific tool which was developed by C# to convert information from CTT into an XML file following CIM schema In our approach, we use the mapping

Ph.D Thesis, The Can DO, December 2019 solution of Nobrega et al to find the relationship between tasks in a CTT process as shown in figure 3.15

Figure 3.15: The UML notation for activity diagram [Nóbrega-2005]

In our mapping of CTT data to the CIM standard, each task element in the CTT model is treated as a Predicate (P) within the CIM schema The composition of these Predicates must consider the precedence of temporal operators in CTT, which include enabling (>>), deactivation ([>), suspend-resume (|>), choice ([]), concurrency with information exchange (|[]|), order independence (|=|), and independent concurrency (|||).

- Independent Concurrency (P1 ||| P2): Actions corresponding to the situation of two Predicates can be performed in any order without any specific constraint

In the choice mechanism, users can select from a range of predicates, enabling them to execute the corresponding action associated with their selection Once a choice is made, the chosen action becomes active, while the other options remain unavailable until the selected action is completed.

- Concurrency with information exchange (P1 | [] | P2): Two actions corresponding to two predicates can be executed concurrently, but they have to synchronize in order to exchange information

- Order Independence (P1 | = | P2): Both actions corresponding to two predicates have to be performed, but when one is started then it has to be finished before starting the second one

- Deactivation (P1 [> P2): The action corresponding to P1 is definitively deactivated once the second action has been performed

- Enabling (P1 >> P2): In this case, one action corresponding to P1 enables a second one when it terminates

- Enabling with information passing (P1 []>> P2): In this case, the action corresponding to P1 provides some information to action in P2 other than enabling it

The Suspend-Resume operator allows the action in P2 to interrupt the ongoing action in P1 Once the action in P2 is completed, the action in P1 can be resumed from the state it was in prior to the interruption.

Valid and Invalid state

In section 3.5, each viewpoint is assigned a specific state determined by its predicate value vector, which is derived from the evaluation of all predicates associated with that viewpoint, as outlined in the CIM However, it's important to note that not all combinations of predicate value vectors correspond to meaningful states of the viewpoint; some combinations may be theoretically impossible or lack significance.

In our previous project [Continuum-2012], the viewpoints with n predicates have exactly

The use of 2n states or grouped states can effectively identify overlooked states by the viewpoint designer, but it also requires considering all states as valid, which may not always be the case Many states defined by vector predicates lack real significance or correspond to impossible scenarios Designers often associate these states with nonsensical rules, which generally function well, as one typically should not encounter these states However, this approach necessitates that designers identify all such states, leaving the system vulnerable if it inadvertently enters one of them.

In this framework, we categorize viewpoints into two distinct types: valid states and invalid states Valid states represent the potential scenarios that designers aim to identify for implementing adaptation rules Conversely, invalid states are characterized as unnatural or non-conforming to the natural order of execution.

Utilizing invalid states enables the identification of errors within the observation mechanism, which relies on physical sensors These sensors may produce erroneous values due to factors like signal noise or sensor malfunctions, leading to inaccuracies Consequently, the observations may reflect states that deviate from the expected normal conditions.

To ensure an appropriate reaction for self-adaptive systems, the Context Adaptation Model (CAM) must effectively manage both valid and invalid states Consequently, it is essential to modify our Context Intermediate Model by incorporating the invalid state, as illustrated in Figure 3.17 This introduction of invalid states provides designers with two distinct options.

1) They identify all the invalid states as they did for the states left empty in our previous model [Continuum-2012] This does not save time for the design, but it allows us to detect the states that have been forgotten (and also allows managing invalid states)

2) They indicate that all other states (different from the valid states) are invalid states (InvalidstateDefault) And in this case, they do not need to identify all invalid states These states correspond to all unlisted states This saves time for the design and greatly simplifies the designer’s task On the other hand, although the management of invalid states remains assured, it will no longer be possible to check if the designer has forgotten a state

Figure 3.17: The updated version of CIM with adding Invalid state

It is essential to address the identification of invalid states by logging system errors and notifying the administrator or user about the issue The CIM provides a state ID for each state, including both valid and invalid ones, as illustrated in examples 1 and 2 in section 3.6.

In December 2019, the Ph.D thesis titled "The Can DO" explored the analysis of application scenarios to identify valid and invalid states By incorporating viewpoints into the Contextual Application Model (CAM), the model is capable of detecting these states using a state ID.

There are several cases with the appearance of invalid states that can occur:

Repeated occurrences of the same invalid states across multiple observation cycles suggest a potential error in the observation system, likely linked to the viewpoint predicate To assist in identifying and resolving these issues, the CAM can notify administrators or users of any error situations.

During multiple observation cycles, random invalid states may arise, often due to noise signals In such instances, the CAM has the capability to alert the user or administrator about the noise and can also initiate an emergency protocol by sending a request for system checks to the admin.

3.7.3 The proposed solution to filter states and react to invalid states

Following the "Identify State" step, which determines whether the current state is valid or invalid, we implement the "Filter State" step This process gathers valid states for adaptation while flagging invalid states to notify both users and administrators of any system issues, as previously discussed.

Figure 3.18: The filter state in CAM

The details about our proposal for filtering the valid and invalid state process at runtime described in the below example

In a viewpoint store n predicate (nP), there are 2^n states, denoted as Si (where i ranges from 1 to 2^n), each of which can be classified as either a valid or invalid state To effectively identify these states, we utilize two counters, C and Cd, for detection purposes.

In the Ph.D thesis titled "The Can DO," published in December 2019, the focus is on detecting changes in invalid states The primary objective is to either maintain or alter the previous state to establish appropriate adaptation rules, as illustrated in Figure 3.19.

- In case of invalid state repeat many times:

+ If only one invalid state appearance on many observation cycles: Add a Counter (C) of each invalid state, if situation of state does not change in next cycle of observation then

C = C +1; Check Counter: if C > K (K is constants proposed by designer depend on application)→ Send command Error to user → Check “Set of predicate in this state”

When multiple random invalid states occur, establish a counter for these invalid states (Cd) and increment it with each occurrence If the counter Cd exceeds a predefined threshold (Q), determined by the application designer, trigger an error message and transition to an emergency state, during which the system will await further checks.

Figure 3.19: Detection Invalid states algorithm

Chapter conclusion

Incorporating independent viewpoints in context modeling effectively addresses the challenges outlined in research question two, particularly in streamlining the experts' tasks By allowing each expert to concentrate solely on their specific knowledge domain, the context modeling process becomes more efficient Additionally, this approach simplifies the development and reconfiguration of context models, making them easier to manage and adapt.

Within this thesis, the data of a specific viewpoint is converted into an XML file following the Context intermediate model schema automatically It is a critical step to support

CAM effectively manages contextual information by incorporating various specific viewpoints based on application requirements and user needs Following a thorough conversion and validation process, these viewpoints are integrated into CAM The system then employs a filter state process to identify both valid and invalid states Utilizing CAM to support SAS in managing contextual information enhances its adaptability, ultimately improving the responsiveness of SAS, as highlighted in the fifth research question.

In the Contextual Architecture Model (CAM), multiple independent viewpoints, each crafted by different designers, coexist within a single system, leading to potential conflicts This article will address the detection and resolution of these conflicts in the upcoming chapters.

Conflict detection and solution

Solving conflicts between objective of states

Adaptation rules deployment and Implementations

Conclusion and Future works

Định dạng
Số trang	153
Dung lượng	6,74 MB