A Formal Metamodel for Context Design

8303 words (33 pages) Dissertation

13th Dec 2019 Dissertation Reference this

Tags: Design

Disclaimer: This work has been submitted by a student. This is not an example of the work produced by our Dissertation Writing Service. You can view samples of our professional work here.

Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of NursingAnswers.net.

A Formal Metamodel for Context Design: from Identification to Modeling and Analysis to Integration in Intelligent Systems

Context variability influences the requirements to be satisfied in a system, their alternatives and the quality of each alternative. This drives a variability in system behaviors to keep fulfilling the requirements and accommodating the varying context. The integration of context variability into the system will allow for the creation of intelligent applications. However, an approach that formally associates the software variability with contextual information is still missing. In this paper, we propose a unified approach that facilitates a formal treatment and integration of context variability in the requirements and operational levels. [the advantage of our approach is to be demonstrated with its applicability & usage in model-driven engineering as a promising software development paradigm]

Context influences the requirements to be satisfied in a system, their alternatives and the quality of each alternative. This drives a variability in system behaviors to keep fulfilling the requirements and accommodating the varying context. Hence, identifying and representing context information will allow for the creation of intelligent applications. However, an approach that formally conceptualizes contextual variability for supporting the system adaptability is still missing. In this paper, we propose an approach that facilitates a formal treatment of context and relationshipswith system goals and operations. We apply this approach on a smart conference scenario.

A formal metamodel for context modeling and analysis in intelligent systems

In order to operate in complex environments with a highly varying context, the software systems demand smart engineering that would allow for the provision of intelligent interactions with users and of more appropriate services and information. Context is a key element to the engineering of intelligent systems. Hence, several approaches consider context in the system being developed from different perspectives. However, a methodology that formalizes and integrates the main notions and concepts related to, and influenced by context in a unified framework is still missing. In this paper, we propose a formal metamodel for context modeling and analysis. The architecture of our modeling framework is based on four levels of abstractions, and aligned with the OMG Meta-Object Facility (MOF) specification. A formal method is used to define the abstract syntax and the static semantics of the metamodel.

  1. Introduction + surveys on related work: a general information introduces the topics

Advanced Information and Computing Technologies (ICT) have led to emerging systems and took the computing paradigms out of the standalone and desktop. Context-aware systems, Ambient Intelligence (AmI), context-sensitive systems, adaptive systems, ubiquitous systems, cyber-physical systems and Internet of Things (IoT) bring miniaturized technologies closer to the user’s daily activities [ref#]. From a broad perspective, the intelligence is a common ground between such systems. An Intelligent system is capable of (i) knowing current user’s needs (e.g., a goal, a task being performed), (ii) knowing contextual changes (e.g., locations, environmental conditions) and (iii) responding appropriately at the information and the service levels, and in real-time (e.g., by executing an adaptive action or notifying the user). To do this, the system should observe and reason about the context that is pertinent to the user’s current interests. Here, context is any information that characterizes the situation of an entity that is relevant to the interaction between a user and an application (e.g., place, object, person, device, user and application themselves) [Dey]. To this end, context is a key element should be considered when developing intelligent applications.

At runtime, a varying context is main factor contributing to the variability of the system [1], to unpredictability, uncertainty, and weak controllability, thus causing a failure in meeting users’ needs and software requirements [ref#]. To deal with these challenges, several researchers have made contributions in the endeavor of supporting the design and engineering of intelligent systems and applications considering context at design time and runtime, and across the different phases of the software engineering process, namely requirements engineering, design, implementation, testing, deployment, maintenance and feedback (for a survey see [2,3,4]). Other researchers developed techniques for modelling and reasoning about context information (for a survey see [5]). Also, several approaches address the dynamicity and context particularity when developing the modern generation of software systems (for a taxonomy see [6]).

Requirements Engineering (RE), as a preliminary phase in software projects, concentrates on investigating and precisely specifying the problem world that a machine-based solution is intended to improve [Requirements Engineering: a roadmap, Bashar Nuseibeh, Steve Easterbrook] [7]. The scope of investigation includes problems, opportunities and domain knowledge in the system-as-is (i.e. the system as it exists before developing the machine), and objectives, assumptions, services, constraints, and responsibility assignments in the system-to-be (i.e. the software to be developed and its environment such as people, physical devices, and pre-existing software) [7]. In Goal-Oriented Requirements Engineering (GORE), unlike the traditional RE approaches, the concept of goal plays a central role in the elicitation, modeling, analysis, evaluation and evolution of system and software requirements, where a goal is an objective that the system should achieve through the cooperation of system agents [8]. An agent is an active component playing a specific role in goal satisfaction. The agents may restrict their behavior to ensure such a role by monitoring and controlling system items [8].

KAOS, “Keep All Objectives Satisfied” or “Knowledge Acquisition in autOmated Specification”, was firstly proposed by Dardenne and Van Lamsweerde as a GORE language associated with a set of formal analysis techniques [9,10]. Alternatively, in his PhD thesis Eric Yu proposed the i* language [11] for modeling the social aspects of requirements. Tropos [12] project was proposed by Mylopolos. NFR [13] was firstly proposed by Lurance chang as qualitative analysis framework for modeling and analysis of non-functional requirements.

In intelligent environments, system requirements overlap with context information which is drawn from domain knowledge. The demarcation of the boundary between the system and context in a particular domain is crucial for determining what to be considered as context. To do this, we have to define (1) the relation between domain knowledge and the structural part of context (( i.e., extending domain engineering/analysis with a context theory [])), and (2) the mutual influence relation between the dynamic context and system aspects including user’s intentions and software functionalities (( i.e., exploring together the problem variability (by the users and the environment of the software) and the variability of software (i.e., functional and quality requirements, and operations  [])),  [14]  , [Modeling domain variability in requirements engineering with contexts, ER, 2009], [Towards a computer-aided problem-oriented variability requirements engineering method, CAiSE 2014 workshops], [Exploring the dimensions of variability: a requirements engineering perspective, Sotirios Liaskos// OR// On Goal-based variability Acquisition and analysis, Sotirios Liaskos], [A framework for combining problem frames and goal models to support context analysis during requirements engineering, CD-ARES 2013], [Situ: a situation-theoretic approach to context-aware service evolution], [Analyzing monitoring and switching problems for adaptive systems, Mohamad Salifu, the journal of systems and software, 2012]

Several researchers consider context for engineering computer systems from different perspectives. Problem Frame [PFx] (PF) specifies variations of a class of software development problems in terms of biddable domains and lexical domains (i.e., the world/W), a requirement R, a machine domain (i.e., the specification/S) and interfaces/connections between the domains. To keep the requirement satisfied, each variant represents an alternative specification which corresponds to a particular context [PFx].  For context modeling and analysis. CODA [15] is context-oriented domain analysis method for capturing contextual information, variation points and context-dependent adaptations.  In his PhD thesis [16], Ali proposed an extension to Tropos models by weaving context variability with variation points on the goal level.

In [Context-driven requirements analysis, Jongmyung Choi, 2007] the author proposed context-aware artifacts such as use case and context-switch diagrams. Elicitation techniques for identifying contextual requirement at design time [Eliciting contextual requirements at design time: a case study, Alessia Knauss, Daniela Damian, Kurt Schneider, EmpiRE, 2014]. [Situation-oriented requirements elicitation, Nimanthi L. Atukorala, 2016]

To the best of our knowledge, an approach that formally conceptualizes the dynamic context and its associated concepts centered on user’s interests, and systematically facilitates a formal treatment of context variability in the intentional and functional levels of a system is still missing.

Our research aims at proposing such an approach with the motivation of building a unified framework for identifying and representing contextual information in order to ensure formal and precise specifications that pave the way for smart engineering of software for intelligent systems, and the guidance of five main research questions: (1) How can we identify relevant context in both the user’s world and the software-to-be? (2) How can we unify and formalize the identification process? (3) How can we formally contextualize a system functionality? (4) How can we systematically formalize the dynamic context and its variability including diverse dimensions, sources, and parameters like quality, validity, certainty, volatility, and access types? (5) How can we systematically facilitate the adopting of context-enabled software engineering? the formalized concepts in context modeling and analysis for?

This paper aims to unify the formalization of context and requirements modeling and analysis languages featuring context, entity, goal, operation and agent as main concepts.

Decide what RE language is used, what context approaches are used

RQ1 = identify? relevant context /// Goal-driven and Entity-centered Identification + relevance + relevance level

Goal-driven, entity-centered context identification method: Context is any information that is (1) relevant either to a specific human goal (resp. a system/software requirement) that designates the current interest from the perspective of the user (resp. the system), or to a specific environmental operation (resp. a software operation) that designates how to reach and achieve the current interest in the user’s world (resp. the software system) and (2) characterized and formalizable with respect to an entity of interest.

RQ2 = formalize? and unify? identification///

Introduce the concept of focal element.

Definition. 1. (Focal Element). An interest, capability, constraint or service is a focal element FC to an agent Ag iff Ag directs the most attention on achieving, undertaking or executing FC.

Definition. 1. (Focal Element). A goal or operation is a focal element FC to an agent Ag iff Ag directs the most attention on achieving or executing FC.

Context is any information that is relevant to a focal element on which the most user’s attention is that is a specific goal or operation which encapsulate the current most.

Definition. 2. (Context). Any information that is relevant to a focal element FC and Formalizable in terms of any of interest.

both the user’s world with respect to his interests, and the software-to-be with respect to execution of software services.

= model and represent? identified context /// contextualization

=

Introducing the focal element:

A user’s interest might be in a non-communicative form like a cognitive goal. In the light of the perceived context, the user (re)acts in order to realize his interest which might be evolved to a task undertaken within the environment and/or an interaction with the system. Indeed, the interest takes different forms that are influenced by diverse dimensions of context ranging from environmental conditions, preferences, available technologies, temporal events and so forth. On the other hand, the system dynamically adapts its behavior regarding both the user’s current interest and the current state of context. This requires the acquisition and augmentation of contextual information.

RQ3– In other words, how can we formalize the contextualization of a system at the goal and operation levels? //LF challenge

A context-sensitive system encompasses two types of variability:

  • Problem/Domain variability: {this type is considered as the rationales behind context variability} {we propose several dimensions/sources of contextual variability as follows} 
    • (1) intentions (human goals) and (2) activities (human operations or tasks)
    • (3) environmental conditions and changes, (4) heterogeneity of technologies and computing capabilities/limitations, (5) cognitive abilities, preferences and interests, (6) social situations, (7) the temporal dimension is embedded in everything
    • (8) variations in quality requirements
  • Software variability
    • Requirements: functional requirements
    • software operations
    • //features //
  1. Background and Related Work

A system that is developed to operate in intelligent environments, in contrast to traditional ones, centers its functionality on users’ needs in order to provide smart services, interactions and information taking into account its varying context. Researchers are working to deal with complexities caused by contextual variability (e.g., locations, profiles, conditions, technologies etc.). Several approaches have been proposed to associate the system functionality with context. This section introduces the concept of context and presents different approaches for context modeling and analysis.

  1. The concept of context

There is a lack of consensus about the definition of context. one single, unified and multi-disciplinary definition for context. Context is a multi-defined concept in many disciplines. In computer science, many researches introduced different perspectives on understanding and using context. Dey defined context as any information that characterize the situation of an entity (e.g., a person, a place or an object) [].  One of the wide accepted definition is

Regarding intelligent systems, context-awareness.

Works Definitions and Perspectives
Brezillon and Pomerol, 1999 Context is relevant to the focus that is a step in solving problems, making decisions or performing tasks [].
Dey, 2000 Context is any information that can be used to characterize the situation of an entity.
Dourish, 2004 Representational & interactional views []
Bradley, 2005 A multidisciplinary model of context for representing contextual dimensions of both the user’s world (i.e., human actions and goals) and the application’s world (i.e., software services) [].
Zimmermann et al., 2007 An operation definition of context
Vieira et al., 2007 Extending the notion of focus to include a task and an actor together with a role [].
Ali et al, 2011 Context is a partial state of the world that is relevant to an actor ’goals [14].

Tab. 1. Definition and perspectives on Context

  1.            Context modeling and analysis: Taking context into consideration in the engineering of software

We discuss in this section how researches (RE approaches, design approaches, analysis approaches) take context (internal system states, external environment and users states) in their methods for engineering software systems.

We propose the following criteria for discussing and comparing the approaches:

  • The boundary between a system and context. In other words, what is to be considered as context in a system?
  • The relationship between context, and a functionality or the quality of service that the system should provide or maintain
  • The rationale behind context variability: traceability issue
  • The rationale behind volatile aspects of software functionality: traceability issue
Works Considerations
Jackson, 2000 Problem frames characterize variations of a class of software development problems in terms of contexts W (i.e., biddable domains and lexical domains), a requirement R, the specification S (i.e., machine domains) and interfaces (i.e., connections between domains) []. Each variant represents an alternative specification which corresponds to a particular context [].
Ali et al, 2011 Contextual requirements weave context variability with variation points at the goal level [x].
REUBI [A requirements engineering method for ubiquitous systems]
[ Using Activity theory to identify relevant context parameters]
[ Managing Dynamic context to optimize smart interaction and services

Tab. 1. The relationship between the system and context

  • Map context onto system functionality
  • Related work

Contextual goal model

Problem frames

REUBI

RELAX

  • Discussion
  1.        Requirements Modeling and Analysis(goal-oriented RE): discovering the real world and determining the boundaries of a system: what to do/build, who, why to, how to, how well. RE is about 5W2H (What, When, Why, Where, Who, How and How well).
    1.         Why: goals
    2.         How: requirements
    3.         How well : quality constraints
    4.         who: agents
    5.         What : operations
    6.         When and Where: Context
  2.      Context Modeling and Analysis: definitions, a dynamic nature, different views on context, context dimensions, etc. {this part focuses on the pure characteristics of context}
    1.     Context is a process
    2.     Context characterizes the situation of an entity

{System and Context are in a persistent state of mutual influence}

There is a persistent state of mutual influence between system aspects and the context.

  1.      Tracing goals and requirements volatility to changes on contexts

Give an informal introduction to the notion of tracing requirements volatility to changes on contexts elements, and classifying the rationale behind the evolution/volatility of requirements.

(statement #) We state our findings on this section.

Context intervenes with and propagates its influence to all system items in their traceability link that originates form human goals to system requirements to software services.

  1.      Classifying the rationale behind variability of context:

Give an introduction to the notion of tracing context changes to adoptions of specific systems alternatives and classify the rationale behind the variability of context elements.

  • Environment changes
  • Adoption of specific system alternative
  • Human variability
  • Available technologies and computing resources

(statement #) We state our findings on this section. CVSt

  1.       Considering the relationship between the system and context
  • Contextual goal model approach [14] (Weaving context with goal models) :

Context is a partial state of the world that is relevant to an actor ’goals.

  • context might activate a certain goal/task.
  • context might be required to adopt a certain goal/task.
  • context might influence the quality of  a softgoal.
  • Awareness requirements
  • Problem frames
  • REUBI
  • RELAX
  • Context Features
  1. A Formal Metamodel for context modeling // framework for context modeling and integration
    1. Overview

To the best of our knowledge, a formal and unified approach that integrates the concept of context and its related concepts into the intentional, requirements and functional views of a system is still missing. Note: It would be better if we put this statements in the introduction

The proposed metamodel is based on the contextual classifications and dimensions of domain knowledge in context-sensitive, context-aware and ubiquitous systems engineering [], and uses the dimensional information for modeling and analysis in order to (1) identify contexts relevant to a certain goal or a required functionality, and (2) evaluate the types and levels of impact from contextual factors on functional requirements and software operations in a system. We use the term “Context Design (CD)” to refer to the activities for identifying, analyzing, representing, reasoning about and embodying (i.e., integrating) context information in a system at both the design time and runtime. A “framed context” refers to a formal specification of contextual information as a mean to assist the engineering of a system.

  1. Aims of the metamodel

Based on concepts and notions introduced in research endeavors for context framing, we have developed a formal metamodel for engineering context in intelligent systems. The main analysis and design aims of such metamodel are to support and provide: (1) Un explicit and formal basis for understanding the concept of context, (2) A unified framework in which conceptual abstractions related to context are defined and interrelated, (3) Context enrichment modeling (i.e., artifacts furnished with context), (4) A ground for integrating context-enabled requirements analysis into other phases across the software development lifecycle, (5) A basis for toot support, and (6) A logical schema of the specifications database in which specifications (e.g., semi-formal and formal structures) can be stored and queried for validation and analysis (e.g., structural consistency and competence checks). and analyzing the syntax of the context models and the corresponding context-enriched artifacts in order to check their correctness with respect to inter-view consistency rules. (e.g., constraints between the intentional view and the contextual view).

We propose a metamodel-based framework (MICoIS) for Modeling and Integrating Context within Intelligent Systems.

  1. Four-level metamodel architecture

A meta-model is a model that rises the abstraction level for system engineers including analysts, designers and developers. A metamodel defines a set of high-level conceptual abstractions in terms of which other specifications are constructed. MDA OMG 2003 the meta-modeling techniques (i.e., the abstraction, classification, generalization, specialization, etc.) allow to build, reuse and transform source models into different target implementations. In other words, to design one platform-independent model, and build it on diverse platforms (e.g., Java/EJB, C#/.NET and XML/SOAP). The Meta Object Facility (MOF) standard [x], recommended by the Object Management Group (OMG), provides a metamodeling architecture based on four layers; (i) Meta-metamodel (M3) defines a language for specifying metamodels, (ii) Metamodel (M2) define a more elaborated language for specifying models, (iii) Model level (M1) defines a language for describing information domains and systems, and (iv) Instance level (M0) defines a specific information domain. The architecture of our modeling framework is based on four levels of abstractions and aligned with MOF as follows (see figure 1).

Fig. 1. TheMOF-aligned modeling architecture: the meta-meta, meta, domain and instance levels

  1. The meta-meta level (M3):

This level represents the meta-language within which the highest-level abstractions (i.e., language constructs) are defined for structuring other language metamodels (e.g., a domain-specific language (DSL) metamodel, UML metamodel). MOF meta-meta-model is composed of object-oriented constructs; MetaClass, MetaAttribute, Meta-Reference, Inheritance, and Composition. In our modeling architecture, M3 is aligned with MOF, and is made of the Meta-Concept, Meta-Relationship, Meta-Attribute and Meta-Constraint.

  1. The meta level (M2):

This level represents the language within which domain-independent abstractions are defined for structuring formal specifications of the multiple views and aspects of a system. contextual, structural, intentional, functional and behavioral views of a system. It is composed of meta-concepts(e.g., Context, Entity, Goal, Operation, Agent), meta-relationships linking meta-concepts (e.g., Characterization, Contextualization, Responsibility), meta-attributes of meta-concepts or meta-relationships (e.g., Definition of Context, Type of Contextualization), and meta-constraints on meta-concepts and meta-relationships (e.g., ‘A Context Contextualizing a Goal must has a Entity)

  1. The domain level (M1):

This level represents concepts specific to the modeled domain or system, for example, projector, light, meeting room in a system for smart meeting rooms. It is composed of concepts that are instances of meta-level abstractions. For example, the HostMeeting concept in Figure 1 is an instance of the Context meta-concept; the MeetingRoom concept is an instance of the Entity meta-concept; the concept Achieve [LightsSwitchedOn] is an instance of the Goal meta-concept.

Domain-specific concepts are linked through instances of the meta-relationships linking the corresponding meta-concepts of which they are an instance, for example HostMeeting Contextualizes Achieve [LightsSwitchedOn]; HostMeeting Characterizes MeetingRoom. Domain-specific concepts must satisfy instantiations of the meta-constraints on the corresponding meta-concepts of which they are an instance, for example, …. A model of a system view is structured from domain-specific concepts according to instances of the corresponding meta-relationships inherited from the meta level.

  1. The instance level (M0):

This level represents specific instances of domain-specific concepts in the running application (see figure 1). This level is composed of sensed data and acquired information as well as concrete instances of observed entities, places, devices, people, software and hardware components.

As we have seen before, M3 is made of meta-meta-objects to construct the meta level. Thus, a formal method that support both the object-orientation and the reuse of constructs is appropriate to formalize the context and the associated concepts. We use a UML class diagram [x], and the formal expression language OCL [x] to define our formal metamodel for context modeling (see sections 3.4), and specify its well-formedness rules (see sections 3.5), respectively. We a use natural language (NL) to define semantics (i.e., the meanings) of the formalized constructs (see section 3.6).

 

  1. Abstract Syntax

The abstract syntax is presented in a UML class diagram illustrating the meta-concepts, meta-attributes and meta-relationships. The diagram also presents some of the meta-constraints and well-formedness rules, particularly the multiplicity constraints of the meta-relationships. We use a natural language to define the semantics of (1) the meta-concepts and (2) the meta-relationships as well as their meta-attributes as follows:

 

 

This association should be changed into the opposite direction

 Fig. 1. The metamodel for context modeling and analysis

  1. The meta-concepts
 Goal

 

Denotes an objective that the system should fulfill. The type meta-attribute specifies a category or a type of the goal. Possible values for Goal type are: Human, Functional, Non-functional, Behavioral, Softgoal.
 Operation

 

Denotes a functionality that the system should provide to realize a goal. The type meta-attribute specifies a category or a type of the operation. Possible values for Operation type are: Software, Environmental.
 Agent

 

Denotes an active system resource that plays a specific role in goal satisfaction and operation performance. The type meta-attribute specifies a category or a type of the agent. Possible values for Agent type are: Human, Device, Software.
 Entity Denotes a domain-specific resource that is concerned with system goals, and affected by system operations. The type meta-attribute specifies a type or a category of the entity. Possible values for Entity type are: Person, Object, Device, Place.
 FocalElement Denotes a current matter of concern for an agent. It may refer to a goal to be satisfied or an operation to be executed. The name meta-attribute denotes a unique identifier. The mode meta-attribute specifies the occurrence mode i.e., the way in which a focal element occurs or is performed. Possible values for FocalElement mode are: Meaningful, Incidental. The priority meta-attribute specifies the priority level i.e., the degree to which a focal element is important or preferred. Possible values for FocalElement priority are: Normal, Important, Critical.
 Focus [x] Denotes a step in performing a task, a decision-making or a problem-solving process that an agent (e.g., a software system, an end-user) takes to know and delimit data, information and knowledge (i.e., contexts) that characterize the situation of a specific entity, and strongly influence a specific focal element the agent is responsible for or has to perform. Each focus is made of a distinct set <agent, role, focal element, entity>.
 Context Denotes a situational element that characterizes an entity and influences a focal element. The name meta-attribute denotes a unique identifier of the context. The description meta-attribute defines, in natural language (NL), (characterize entity) what the context prescribes in terms of states of the world that may influence an agent’s focal element, and are not fully controllable by this agent. The formalSpecification meta-attribute provides a formal specification of the informal definition of context. The isFactual meta-attribute specifies whether the context can be verified by an agent and formulated in terms of contextual facts. The isMonitorable meta-attribute specifies whether the context can be supported by means of facts. The isAbstract meta-attribute specifies whether the nature of context is abstract (also, in case there is a lack of information to verify its truth value). An abstract context might be supported by a set of monitorable and factual contexts through further refinement and analysis. The status meta-attribute specifies the status of the context throughout the design process. Possible values for Context status are: Identified, Analyzed, Formalized, Embodied. Embodied indicates that the context has been integrated into a system functionality by specifying the type, impact and arguments for the contextualization of a certain goal or operation.
 Atomic Denotes a simple context.  The dim meta-attribute specifies the category or dimension of the context. Possible values for Atomic dim are: Cognitive, Social, Computing, Physical (Location), User (Identity, Preference), Temporal (Current, Past, Future), Task/Activity.
 Composite Denotes a collection of simple contexts.
 Attribute Denotes the lowest-level of contextual information with which the atomic context is mainly associated. The name meta-attribute denotes a unique identifier of the contextual attribute, like the light level, noise level, time and location, for instance. The value meta-attribute specifies a value of the contextual attribute.
 TimeConstraint Denotes a valid time for the use of the context. The sub-type Fixed denotes a fixed interval of time. The sub-type Relative denotes a relative interval of time.
 ContextSource Denotes the source of context.  The type meta-attribute specifies type of the source; Possibilities are: {External, Internal} {Sensor, RFID,
  1. The meta-relationships
 Role Denotes an association between the Agent and FocalElement meta-concepts. The type meta-attribute specifies the type of the role. Possible values forRole type are: Wish, Responsibility, Performance.
 Relevance Denotes an association between the Focus and Context meta-concepts that represents the identification of relevant Contexts by measuring the type and state of being pertinent to the Focus. The weight meta-attribute specifies the level of relevance. Possible values forRelevance weight are: High, Medium, Low. The rationale meta-attribute specifies the argument that supports or denies an identified relevance association between a focus and context.
 Contextualization Denotes a contextual association between the Context and FocalElement meta-concepts that carries the influence of contextual information on focal elements. The type meta-attribute specifies the type of contextual dependency. Possible values forContextualization type are: Activation, Required, Quality. The impact meta-attribute specifies whether the contextual impact on a focal element is positive or negative. The argument meta-attribute specifies the rationales that support or deny the contextualization (type and impact) of a focal element.
 Characterization Denotes a contextual association between the Entity and Context meta-concepts that links an entity to contexts. The name meta-attribute denotes the name of the contextual situation that characterizes the entity. It has four sub-types: Static, Sensed, Derived, and Profiled. The access meta-attribute specifies an access type or a specific restriction imposed upon a context characterizing an entity. Possible values for Characterization access are: Private, Group, Restricted, All. The multiplicity meta-attribute specifies the type. multiplicityType
 Sensed Denotes a dynamic association linking an entity with context captured from senores. The quality meta-attribute specifies the degree of credibility of the sensed context.
 Derived Denotes a dynamic association linking an entity with context derived from other contextual information. The expression meta-attribute specifies the derivation rule.
 Profiled Denotes a dynamic association linking an entity with contextual information supplied by the user such as the Preference context.
 Static Denotes an association linking an entity with a high constant information such as the Identity context, for instance date of birth.
 Relationship Denotes an association connects the Context meta-concept to itself. It defines a relation between a source context and target contexts. The name meta-attribute provides an identifier for the relationship.
 Refinement Denotes an association linking a refined context to its refining contexts.

The type meta-attribute specifies whether the source context is linked to the target contexts with an OR-refinement or an AND-refinement. OR-refinement means that any refining context implies the refined context, or AND- refinement i.e., the conjunction of refining contexts implies the refined context.

 Support Denotes an association between a supported context and its supporting context. It helps to
 Parallel Denote an association between two
 Cause Denote an association between two
 Validity Denotes an association between the Context and TimeConstraint meta-concepts.
 Acquisition Denotes an association between the Context and ContextSource meta-concepts.

 

 

  1. Well-Formedness Rules: static semantics

The OCL expressions specifies invariants on the meta constructs as follows:

context MetaConstructName

inv: ‘This is an OCL expression with stereotype <invariant> in the context of MetaConstructName’

  1. context Entity /// Meeting Room

derive inv: if self.charSource->any(c: Characterization|c.name=’physicalFactor’)

.charTarget.cxtAttributes->any(a: Attribute|a.name=’noise level’).value = ‘high’

then self.charSource->any(c: Characterization|c.name=’currentActivity’).charTarget.cxtAttributes->any(a: Attribute |a.name=’status’).value = ‘hostMeetingNow’ elseendif

1. context Context

[1] The truth value of an abstract context cannot be verified. Therefore, an abstract context cannot be factual.

inv:Self.isAbstract implies not self.isFactual

[2] The truth value of a monitorable context cannot be verified. Therefore, a monitorable context cannot be factual.

inv:Self.isMonitorable implies not self.isFactual

2. Characterization

[1] The Characterization must have a unique name within

Self.allCo

 

  1. Application Use Case: smart conference system, smart home or smart mobility scenarios
  2. Discussion

We discuss in this section how researches (RE approaches, design approaches, analysis approaches) take context (internal system states, external environment and users states) in their methods for engineering software systems.

We propose the following criteria for discussing and comparing the approaches:

• The boundary between a system and context. In other words, what is to be considered as context in a system?

• The relationship between context, and a functionality or the quality of service that the system should provide or maintain

• The rationale behind context variability: traceability issue

• The rationale behind volatile aspects of software functionality: traceability issue

Surveys compare works contributing to context modeling and metamodeling [ Context Modeling and Metamodeling: A state of the Art, 2016], [A comparison and validation of 13 context meta-models]

Ali et. al REUBI PF Ours
A system boundary + + ++ +
Relevance with G, T E, G, O
Formalization D, CS M2 D, CS, M2, WFR
MDA-alignment +
Base methodology Tropos ~ KAOS
Orientation Goal Goal Goal

 

Relevance with: G= Goal, T= Task, E= Entity, O= Operation

Formalization: D= Definition, CS= Context Syntax, M2= Metamodel, WFR= Well-Formedness Rules

 

  1. Conclusion

References

x

1. Heuer, A., Pohl, K.: Structuring variabiliy of the context of embedded systems during software engineering. (2014)
2. Bauer, C., Dey, A. K.: Considering context in the design of intelligent systems: Current practices and suggestions for improvement. The Journal of Systems and Software, 26–47 (2016)
3. Sánchez Guinea , A., Grégory, N., Le Traon, Y.: A systematic review on the engineering of software for ubiquitous systems. The Journal of Systems and Software, 251–276 (2016)
4. Alegre, U., Augusto, J. C., Clark, T.: Engineering context-aware systems and applications: A survey. Journal of Systems and Software, 55–83 (2016)
5. Bettini, C., Brdiczka, O., Henricksen, K., Indulska, J., Nicklas, D., Ranganathan, A., Riboni, D.: A survey of context modelling and reasoning techniques. Pervasive and Mobile Computing, 161–180 (2010)
6. Mens, K., Capilla, R., Cardozo, N.: A taxonomy of context-aware software variability approches. (2016)
7. van Lamsweerde, A.: Requirements engineering: from system goals to UML models to software specifications 1st edn. Wiley (2009)
8. Lapouchnian, A.: Goal-oriented requirements engineering: An overview of the current research., University of Toronto, Canada (2005)
9. A. Dardenne, A.: Goal-directed requirements acquisition. Science of computer programming 20(1), 3-50 (1993)
10. Letier, A.: From object orientation to goal orientation: A paradigm shift for requirements engineering. In : Radical Innovations of Software and Systems Engineering in the Future, pp.325-340 (2004)
11. Yu, E.: Social modeling. 1998
12. Tropos.
13. Chung, L., Nixon, , Yu, E., Mylopoulos, J.: Non-functional requirements in software engineering. Springer Science & Business Media 5 (2012)
14. Ali, R., Dalpiaz, F., Giorgini, P.: A goal-based framework for contextual requirements modeling and analysis. Requirements Engineering 15(4), 439–458 (2010)
15. Desmet, B., Vallejos, J., Costanza, P., De Meuter, W., D’Hodt, T.: Context-oriented domain analysis. In : In Modeling and Using Context, pp.178-191 (2007)
16. Ali, R.: Modeling and reasoning about cotexual requirements: goal-based framework., University of Trento, Trento (2010)
17. Van Lamsweerde, A., Letier, E.: From object orientation to goal orientation: A paradigm shift for requirements engineering. Radical Innovations of Software and Systems Engineering in the Future, 325-340 (2004)
18. Dardenne, A., Van Lamsweerde, A., Fickas, S.: Goal-directed requirements acquisition. Science of computer programming(20(1)), 3-50 (1993)

x

Cite This Work

To export a reference to this article please select a referencing stye below:

Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.

Related Services

View all

DMCA / Removal Request

If you are the original writer of this dissertation and no longer wish to have your work published on the UKDiss.com website then please: