gecaf: a framework for developing context-aware pervasive systems

Comput Sci Res DevDOI 10.1007/s00450-013-0248-2

R E G U L A R PA P E R

GECAF: a framework for developing context-aware pervasivesystems

Angham A. Abdulahad Sabagh · Adil Al-Yasiri

Received: 25 June 2012 / Accepted: 19 August 2013© Springer-Verlag Berlin Heidelberg 2013

Abstract Context-aware systems differ in the way they in-teract with users, the way they interpret the context of theirentities and the actions they take. Each system (or systemtype) is developed in its own way with no common archi-tecture currently available. This fact makes the developmentof every context aware system a challenge. To address thisissue, a generic and extensible framework is needed so thatit can be used for developing various systems. This paperproposes a generic framework that uses the Pipe-and-Filtersoftware architectural style, which is a well-known style, al-lowing developers to create new systems by arranging exist-ing components into various arrangements to meet the sys-tem’s requirements. The paper also analyses the state of theart architectures to study their functionality and architecturalorganisation. The analysis was then used as a basis for com-paring and evaluating the proposed framework.

Keywords Context aware · Pipe and filter · Softwarearchitecture · Framework · Pervasive systems

1 Introduction

Context-aware systems collect a variety of information andadapt their behaviour accordingly. The collected informa-tion is called context which the system interpret into a mean-ingful action based on the current status of the entities that

A.A.A. SabaghSchool of Engineering, Faculty of Science and Engineering,Manchester Metropolitan University, Manchester, M1 5GD, UK

A. Al-Yasiri (B)School of Computing, Science and Engineering, Universityof Salford, Salford, Greater Manchester, M5 4WT, UKe-mail: [email protected]

interact with the system. Context information (acquired byheterogeneous sensors) usually refers to identity, time, loca-tion, activity, and environment. For more relevant and re-liable context, some systems employ a scheme of sensorfusion (combination of multiple sensors) [28]. In order tostore, re-use and interpret context information, a vocabu-lary to model context is needed. In this regard several ap-proaches were introduced, each represents context informa-tion differently. Typical representations of context informa-tion are: key-value, mark-up scheme, logic base, graphicalmodel, object oriented, ontology based, or application spe-cific [14, 35, 36]. Also, different mechanisms can be used todetermine the meaningful context, which is used to take anaction (application). Context-aware systems have differentapplication categories; some systems only tag context infor-mation and make them available for later retrieval and use.Others collect and present the information to the user in a va-riety of means depending on the user’s needs, whereas someothers automatically execute services and take action on be-half of the user [9]. Context-aware systems cover a widerange of applications [21] such as tour guides, reminder sys-tems, emergency response systems, context-aware mobileservices, etc.

In this research an extensive comparative study of stateof the art context-aware systems has been performed. It wasfound that these systems are not widespread as existing sys-tems are complex and difficult to build. The main reasonsthat inhibit the widespread use of these systems are thechoice of the software architecture used in their develop-ment, the absence of a common pattern of system organ-isation and the fact that each system is different and usesdifferent parameters and entities. Nonetheless, our researchshowed that these systems have common usual functions,which can be used repeatedly. Therefore, there is a need fora generic and extensible framework that facilitates efficient

mailto:[email protected]

A.A.A. Sabagh, A. Al-Yasiri

development of context aware applications using reusableand independent functional components.

This paper presents a new way for building context-awaresystems using a generic framework that supports all ele-ments found in existing systems; it is called Generic and Ex-tensible Context Aware Framework (GECAF). This makesit possible to build context aware systems that are easier tomaintain and evolve, and allows less experienced develop-ers to achieve similarly good system designs as experiencedones without the need to go into every detail about the sys-tem specifications. GECAF employs the Pipe-and-Filter ar-chitecture style; the style itself gives guidelines to problemsolving which better fits the design of context-aware sys-tems. It has the advantage of supporting reuse and recon-figuration in various ways that suit the specific needs of thesystem under development. As each context aware systemis different in the way it is implemented, the Pipe-and-Filterstyle becomes more suitable for such systems as it can beused to arrange its components in any way that suits the de-veloped system. Furthermore, multiple and interacting con-texts are commonly used in context-aware systems whichrequire an approach that is more reconfigurable. The Pipe-and-Filter approach provides this flexibility. More informa-tion about this feature is presented later in this paper.

The proposed framework has been evaluated againstother architectures in order to determine its genericity andextensibility and scalability. A combination of a case studyapproach and comparative analysis has been used for thepurpose of the evaluation, which has showed that the frame-work is more generic and extensible than any other existingarchitecture.

The paper is organised in six sections. Section 2 discussesrelated work and analyses existing context-aware systems.Section 3 introduces the GECAF framework using the Pipe-and Filter architectural style. Section 4 presents a case studyfor a smart classroom scenario as a way to validate the ap-plicability of the framework. Section 5 evaluates the newframework using two additional case studies and a com-parative analysis, before concluding the paper’s findings inSect. 6.

2 Related work

This section presents an overview of the state of the art ofcontext-aware systems and their architectures. The rationalebehind this is to become aware of what functional compo-nents constitute these systems, how they work, and whatproblems and gaps they might have. This information will beuseful in identifying the design requirements of the genericframework. Generally, existing systems are application-specific and restricted to specific scenarios. Most of them

used fixed components which are difficult to change or ex-tend to cope with changing requirements requiring new con-texts. They use different software architectural styles [34] intheir design; some also use multiple styles. Typical architec-ture styles used in such systems are:

• Layered,• Agent-based,• Centralised or server-based,• Other styles.

2.1 Layered style systems

Many context aware systems use the layered architecturalstyle such as the Technology for Enabled Awareness project(TEA)-system [29–32], which comprises four layers: sensor,cues, context and script, and the Context Stack [38] whichuses a five layers: acquisition, representation, aggregation,interpretation, and utilisation. Real world modelling (RWM)architecture [18] uses four layers to process the RFID taginformation, retrieve the information about object and inter-pret the situation.

Some systems use a conceptual layered architecture suchas the general architecture [33], the Context-aware Ar-chitecture Based on Context Database (CADBA) [5] andthe framework presented in [1]. These systems feature themain building blocks of a typical context-aware system,such as sensors, raw data retrieval, pre-processing, stor-age/management, and application.

Many other architectures use the layered style inter-nally within their components. Examples are found in theContext-aware Middleware for URC System (CAMUS)[16], the service architecture [7], and the context toolkit[27]. Although the context toolkit uses the concept of con-text widgets that cooperate in peer-to-peer mode, the un-derlying components (generators, interpreters and servers)interact in a layered manner. Another system that uses thelayered architecture internally is the Unified Context-awareApplication Model (ubi-UCAM) system [6], which is builtaround a framework that has two main independent andreusable components (ubiSensor and ubiServices) provid-ing user centric services to multiple users.

The layered style featured in the above systems has thebenefits of supporting separation between context acquisi-tion and context use. But, due to the complexity of context-aware systems they cannot support various applications asthe layered architecture lacks the ability to reconfigure, ex-tend and evolve.

2.2 Agent based systems

Examples of systems that use the agent-based style are theContext Broker Architecture (CoBrA) [4, 17], with an in-telligent agent (broker) central to it. Still, the broker internal

GECAF: a framework for developing context-aware pervasive systems

components communicate in a layered manner. Other agentsused in the architecture are sensors, services, applicationsand web services; all communicate with the central broker.The multi-agent architecture [37] uses three agents for con-text collecting, context reasoning, and information process-ing; again these agents still communicate in a layered man-ner. A Multi Agent service reassembling architecture [24]uses agent-based and service-based architecture for locationaware applications. The Context-aware Learning Architec-ture (CALA) [15] uses a centralised architecture but em-ploys a number of agents known as personal agent, and ac-tivity agent, and central to the architecture is a context-awaremanager to support user-centric services. The agent-basedmobile service architecture [19] also uses this style.

The agent based style is naturally distributed, supportconcurrent execution and re-configurability. However, man-aging agents is time intensive and has bandwidth problemand high communication cost.

2.3 Centralised or server based systems

Examples of systems using centralised or server-based ar-chitectures are the Service-Oriented Context-Aware Middle-ware (SOCAM) [12, 13], the Context-Aware Sub-Structure(CASS) [10] and the MIddleware DemonstrAtor Server(MIDAS) [23].

SOCAM is server based, where the central componentis the context interpreter. It receives abstracted informa-tion from context providers, offers them to the mobile ser-vices and interacts with a discovery services module. Al-though SOCAM used the centralised architecture, the in-ternal components, context providers, context interpreterand context-aware services communicate in a layered man-ner. CASS also uses a centralised server-based middlewarefor mobile applications. The server contains SensorListener,RuleEngine, ContextRetriever, and Interpreter. MIDAS usesa centralised Context Server that communicates with a set ofsensors, interpreters and actuators.

The systems using a server based or centralised brokerarchitecture have the benefit of creating thin clients, thusfreeing the clients from processing resource-intensive tasks.Nonetheless, such style has the drawback of a centralised so-lution which causes a single point of failure as all other com-ponents communicate directly with the centralised module.This contradicts the nature of pervasive systems which aredistributed having independent devices. The centralised ap-proach requires a dedicated server which increases its costand limits its usability. Low fault tolerance and bandwidthproblems may arise if too many clients (demanding compu-tation) are connected to one sever.

2.4 Systems using other styles

Other architectural styles are occasionally used by somesystems. For example, the Context Management Frame-

work (CMF) [17] uses a blackboard style which has fourfunctional entities: the resource server, the context recog-nition service, the application, and the context managerthat is responsible for managing the blackboard. An eventdriven object based style referred to as the sentient objectmodel is used in the CO-operating Real-time sentient ob-jects architecture and Experimental evaluation (CORTEX)[3], which consists of three main components (sensory cap-ture, context hierarchy, and inference engine), and designedfor context-aware applications in ad-hoc mobile environ-ments. The communication between these sentient objectsis based on events. The WCAM architecture [25] adopts theModel View Controller (MVC) style, using four indepen-dent components named as Watcher, Controller, Action andModel; hence the acronym. Some of these components stilluse the layered architecture.

2.5 Comparison of existing context-aware architectures

Table 1 shows a comparison of the functional componentssupported by the above context-aware architectures. The ta-ble shows different styles and supported components in eacharchitecture. Where an architecture having multiple styles,the one presented in the table is the predominant one. In themajority of such cases, it was found that the layered archi-tecture is used internally and most of these architectures arenot reconfigurable. Therefore the architectures are limitedto specific types of system and would be very difficult toadopt in other types. The table also shows that not all ar-chitectures support all functional components listed in thetable. Our research has also revealed that these are all thefunctional components that have been found in the studiedarchitectures.

3 The GECAF framework

A framework is a set of collaborating components that forma reusable design for a particular class of software [11]. Onone hand, a framework will help developers build new sys-tems by reusing some of the components in the framework.On the other hand, it allows developers to extend the capabil-ity of the system by allowing them to add their own compo-nents. The developed software using a framework conformsto a certain organisation of its parts known as the domainarchitecture. The domain architecture is a common architec-ture shared by many systems within the same domain; anysystem developed using the domain architecture is calledan instance of this architecture. Domain architectures usu-ally follow one of common styles known as the architec-tural styles. In this research a new framework for developingcontext-aware pervasive systems is proposed, which uses thePipe-and-Filter architectural style. The framework helps inmanaging the complexity of specifying, designing and de-ploying context-aware systems.


Table 1 Context-aware architectures—styles and functional components comparison

Existing architectures Architectural style Architecture functional components

Sensing Reasoning Aggregation Contextrepresentation

Appl. Management &services

Contextrepository

TEA-system Layered√ √ √ √

Toolkit Peer-to-Peer∗ √ √ √ √ √CMF Blackboard

√ √ √ √ √CoBrA Agent based

√ √ √ √SOCAM Server based∗ √ √ √ √ √CASS Server based

√ √ √CORTEX Sentient object

model∗√ √ √ √

Ubi-UCAM Distributedframework∗

√ √ √ √ √ √ √

Context Stack Layered√ √ √ √ √

RWM architecture Layered√ √ √ √ √

Multi agentarchitecture

Multi agent∗ √ √ √ √

WCAM MVC√ √ √ √ √

CALA Centralized√ √ √ √ √

General architecture Layered√ √ √ √ √ √

Multi agent servicereassemblingarchitecture

Multi agent√ √ √ √ √

MIDAS Server based√ √ √ √

CADBA Layered√ √ √ √ √ √ √

∗ A multi-style architecture with the one mentioned in the table is the predominant one

Fig. 1 The Pipe-and-Filter architecture style

3.1 What is the Pipe-and-Filter architectural style?

This architectural style is a well-known style where pro-cesses are modelled as filters, while information is passedbetween filters using pipes; Fig. 1 shows a graphical pre-sentation of this style. Filters have functional cohesion (welldefined input and output) and can be used in different sit-uations allowing for a high degree of reusability. Whensystems are constructed a number of filters may be joinedtogether (using pipes) to realise the implemented require-ments.

A good example of the Pipe-and-Filter style is found inthe UNIX system, where filters are UNIX utilities and pipesare operating system entities that form the conduits for join-ing the utilities, such that the output from one utility be-comes the input to another. Pipes allow a number of utilitiesto be reused and joined together to form a solution for a

particular problem. In UNIX, it is also possible to developyour own utilities to be used in pipes provided that they con-form to the general design philosophy of the Pipe-and-Filterstyle.

3.2 The GECAF conceptual design

Figure 2 shows a conceptual scheme for the GECAF frame-work. It illustrates how different concepts collaborate to re-alise the framework. Firstly, in order to use the GECAFfor building a new system, a context model is necessaryfor specifying the context primitives needed in the system.The model uses a classification of context information fordescribing the relations between context information cat-egories. The model is then represented using a Context-aware Description Language (CDL), which is written inXML as shown in Example 1. The model also describestime-related information representing the history of the con-text information. Sensors represent the means for acquir-ing information from a smart environment. They also trig-ger the whole operation of the developed system. The sen-sor terminology defines and discusses important terms re-lated to various sensor types. Therefore, when building


Fig. 2 Block diagram of the conceptual design of the GECAF framework

a new system, the sensor terminology is used to charac-

terise the context sources and specify how different pieces

of context information are acquired using different sensortypes.

Example 1 An example of CDL Code<Context CID="c1">

<contextPremitive name="Role" value="Student"><ID>@103</ID><Time>1 April 2011 9:30 Am</Time><Location>Classroom N233</Location><Activity>Sitting</Activity><Environment>Occupied</Environment>

</contextPremitive><History time="1 March 2009 9:30 Am">Lecturer</History>

</Context>

GECAF employs the Pipe-and-Filter architecture stylein which formatted context information is passed through achain of components to be processed and transformed in avariety of arrangements. To describe how the components of

the framework are arranged and joined together, a Context-aware Architecture Deployment Language (CADL) is de-veloped for this purpose. CADL language specifies whichcomponents are used in the deployment, how they are ar-


Table 2 General filter types

Filter type Operation Description

Getter Context acquisition and retrieving Extracts primitive context information from the environment usingheterogeneous sensors.

Formatter Modelling or formatting Represents context information using XML based CDL code.

Adder Context aggregation Enriches the context information.

Interpreter Reasoning and processing Reasons about context information using a suitable rule representation.

Manipulator Storing and retrieving Stores context information or retrieve historical context into/form databases.

Outputer Adapting context-aware environment Specifies the application category (automatic, tagging, or presenting) anduse the abstracted context to change the environment.

ranged and what rules are used in the interpretation of thecontext information. Details of the CADL language is pre-sented in Sect. 3.4.

The system operation is controlled by a ‘System Man-ager and Scheduler’, which is built to schedule events trig-gered by the software and hardware sensors. It also man-ages the deployment of the context-aware system using de-scriptions from the CADL code and instantiates a new sys-tem.

3.3 The GECAF filters

The Pipe-and-Filter architecture can be implemented usingsix major building blocks (filter types) to build a context-aware system. These building blocks perform context ac-quisition, modelling, enriching and aggregating, reasoning,storing/retrieving, and action taking. In the proposed frame-work, the pipes (XML files) are used to glue the componentstogether, where the output file of one filter becomes the inputto another. This solution provides a number of advantagesfor the building of context-aware systems, as described be-low:

• Each filter used in the Pipe-and-Filter style has functionalcohesion and is used independently of other components.Different context aware systems require different stagesof refinement; some systems may need more or fewerstages of refinement than others. Hence, this style maybe more suited for the nature of context-aware systems, asevery filter in the design adds a further refinement stage tothe acquired information; this could be in the form of, forexample, aggregating, enriching, retrieving or interpret-ing information. Thus the flexibility of the Pipe-and-Filterstyle allows developers to re-arrange their components inthe way that best suits their system’s requirements. Noother architecture style provides such flexibility to thesystem design.

• As context aware systems are dynamic in nature withrequirements that are prone to change, this style makesthe system easily maintained or modified by eliminating,changing or adding new filters.

• The framework allows developers to design flexible, ex-tensible, and adaptable systems by means of reusable fil-ters that are independent of each other. This helps inthe way new systems are specified and designed as theframework describes how these filters can be used to-gether.

• Developers describe the arrangement of the filters us-ing the CADL language. With this language new con-text and services can be added easily by using and re-arranging various filters, simply by changing the XMLcode.

In addition to the above advantages, developers may choosefrom a pool of existing filters to perform a specific processor they may build new ones and use them in the pipe. Ac-cordingly, when a new filter is developed it must conformto one of the abstract filter types in order to be used in thepipe. General filter types of the proposed framework are:Getter, Formatter, Adder, Interpreter, Manipulator, and Out-puter, which are described in Table 2.

Figure 3 shows a possible arrangement of the filters, inwhich the environment acts as a pump (producer), while thesink (consumer) is a data target or the action. As shown inthe figure the bold lines represent a given arrangement to thefilters, while the dashed lines illustrate all possible arrange-ments of the architecture filters.

Like any architecture using the Pipe-and-Filter style,there are certain guidelines that should be adhered to whenusing, arranging or adding filters to design a context-awaresystem; these guidelines are:

• The “Getters” should be used as starting filters to acquireprimitive context information from the surrounding envi-ronment or internally from the system itself.

• The input to the “Formatter” is one or more context prim-itives, derived or indirectly derived context produced bythe Getter, Manipulator or Interpreter filters.

• The “Adder” takes several pieces of context (either froma Getter, Manipulator, Interpreter or even from the Adderitself) to be aggregated in an XML document.


Fig. 3 Pipe-and-Filter architecture showing all possible arrangement of the architecture filters

• The “Interpreter” takes an XML formatted context (For-matter output) or aggregated context (Adder output) toproduce a single piece of context (abstracted context).

• The “Manipulator” can either be used to store inter-preted context, or retrieve context information (contexthistory, or any other information) from internal or externalsources (databases) to be fed to the Adder or the Format-ter.

• The “Outputer” takes the abstracted context from the In-terpreter or the Getter to adapt the system’s behaviour(takes an action).

GECAF provides a native implementation for contextreasoning and interpretation using a rule description lan-guage (uses mathematical, logical, conditional, and otherfunctions) written in XML [26]. In addition, the extensibleand generic nature of the framework gives the developers theopportunity to plug in other rule-based implementations forcontext reasoning such as RuleML [20] and SWRL [22] asneeded.

3.4 The context-aware architecture deployment language(CADL)

To customise the context-aware architecture filters, an XMLlanguage is developed (with its related schema). Accordingto this language developers can specify the architecture fil-ters (processes as used in the CADL code), the contexts inuse, the interpretation rules, the application category, andparameters used in the output functions. This language is ex-tensible as various contexts can be included. It also allowsgeneric elements “Element” to be used for setting differentparameters for different applications. The CADL code alsodifferentiates between different events fired by different sen-sors and maps them to the associated context using a Context

Identification Code (CID). Example 2 illustrates a skeletonof the CADL language. The complete XML schema repre-senting the concrete syntax of the CADL language is foundin Appendix A. In addition, a more complete implementa-tion of the CADL code will be given in Sect. 4.

Example 2 A skeleton of the CADL code, highlighting the main elements of the code.<?xml version="1.0"?><Filters xmlns:an="http://www.w3.org/2001/XMLSchema-instance"

an:noNamespaceSchemaLocation="CADLSchema.xsd"><events>

<event id="an_event_id" CID="context_id"><description>a_given context</description></event>:

</events><process type="main_filter_name" CID="context_id">

<class name="concrete_class" address="associated_address"context="context_value" RID="rule_ID">

<source no="file_number" type="file_type">source_file_name</source>


:<target type="file_type">target_file_name</target><Element name="element_name"value="element_value"type="element_type"fileType="file_type">source_file_name</Element>

:</class>

:</process>

:</Filters>

3.5 The system manager and scheduler

An event driven system manager and scheduler is used tosequence the incoming events from the distributed sensors,and initiates the whole system process. The sequence dia-gram shown in Fig. 4 illustrates the entire process. The Sys-tem Manager has a central queue to sequence the contextinformation in the order of their occurrence. At the deploy-ment time of the architecture, the System Manager readsthe CADL code and instantiate the new Pipe-and-Filter ar-chitecture ready to process context events. As an event oc-curs (Trigger), context information is acquired from one ofthe attached sensors. Then abstracted and attached with anEvent Identification code (EID a unique code attached toeach event and is associated with context primitives) and

saved in the queue. When the timer issues an event (everyx seconds), the System Manager read the queue head andsave it in XML documents. To specify the context in use,the CADL code can map each event with a Context Identifi-cation Code (CID) and return the sequence of the Pipe-and-Filter. This code will then be used to process a series of con-text manipulations according to the instantiated sequence.

4 A case study—smart classroom

To illustrate the architecture’s main concepts and to vali-date the framework operation, a smart classroom scenariois chosen as a case study. The purpose of the case studyis to demonstrate that the framework can be applied to

Fig. 4 A sequence diagram representing the operation of the System Manager


Fig. 5 Filter diagram for the lecture type and font size contexts

a smart environment scenario. This smart environment isequipped with many context-aware innovations. Such inno-vations comprise networked computers, electronic boards,intelligent displays, etc. Consider a student with specialneeds such as visual impairment or hearing difficulties. Sucha student may require that all fonts of delivered materials tobe adjusted (enlarged) and voice amplified. These particularrequirements are only needed when this student is present inthe classroom and when a lecture is being delivered. Pres-ence of other students may place other requirements on theenvironment; for example how many students are currentlypresent but were absent from previous lectures. This smartenvironment has to detect time, identity, role of the class-room inhabitants and their history, and then interpret the in-formation as context to adapt the behaviour of the target ap-plication. Joe Bloggs (a fictitious student) has found such anenvironment particularly useful to aid his learning consider-ing his personal problem (short sighted and hearing disabil-ity). It is nearly 8.45 O’clock on Monday morning when Joearrives at the University building and intends to attend hisfirst lecture of the day. As Joe enters the classroom, his pic-ture together with attendance time is displayed on a smarte-Board hanging on the side wall. When Joe sits down, hispersonal computer (PC) displays the student’s web page, andthe font size is adjusted according to his need. Several mes-sages are displayed telling him about his homework, his-tory of attended lectures, etc. Few minutes later, most of

the students become inside the classroom, sitting in frontof their PCs. As Professor Smith (a fictitious lecturer) entersthe classroom and becomes near the front the e-Board, a re-cap of the last lecture is displayed on the e-Board becausestudents’ attendance was less than 20 % in the preceding lec-ture. The lecturer’s voice amplifier is also adjusted accord-ing to students’ needs. The PC displays of all students areswitched to the lecture webpage viewing the lecture notesand other links.

The GECAF framework has been successfully applied tothis environment and results showed that different contextscan be processed simultaneously by the architecture.

Figure 5 shows an abstract representation of the Role,Font size, and Lecture type contexts using a component di-agram, while the concrete implementation of the system isshown in Example 3 using CADL language snippets. Fig-ure 5 presents each filter type with a specific colour. Get-ters are the first filters that acquire the primitive contextsID, Time and Location. These primitives are formatted andthen interpreted to find the ‘Role’ and ‘FontSize’ contexts.Afterwards, the retrieved lectures’ history, the environmentcontext (existing of students in the classroom) and person’sRole (e.g. lecturer) are formatted and interpreted to find amore abstracted ‘lectureType’ context. Finally an action isperformed to change the context-aware system behaviour.Example 3 shows how GECAF is used to realise the ‘Role’context using concrete code CADL code.

Example 3 The CADL code for the person’s Role context with an automatic action relative to it.<?xml version=’’1.0’’ ?><Filters xmlns:an="http://www.w3.org/2001/XMLSchema-instance"

an:noNamespaceSchemaLocation="CADLSchema.xsd"><events>

<event id="1" CID="123"><description>Person’s Role</description>

</event>:

</events><process type="Get" CID="123">


<class name="ID"><source type="xml">sensor1</source><target type="xml">G1</target>

</class><class name="Time">

<source type="xml">sensor2</source><target type="xml">G2</target>

</class><class name="Location">

<source type="xml">sensor3</source><target type="xml">G3</target>

</class></process><process type="Format" CID="123">

<class name="FormatParameter" context="Role"><source no="1" type="xml">G1</source><source no="2" type="xml">G2</source><source no="3" type="xml">G3</source><target type="xml">p1</target>

</class></process><process type="Interpret" CID="123">

<class name="Role" RID="1"><source type="xml">p1</source><target type="xml">p2</target>

</class></process>

:<process type="Application" category="automatic’’ CID="123">

<class name="SOAPapplication" address="http://localhost/action.php"><Element name="functionName" value="actions" /><Element name="location" value="http://127.0.0.1/soap_server.php"/><Element name="parameter" value="path" type="STRING"

fileType="xml">p2</Element></class>

</process>:

</Filters>

5 Evaluating the new framework

In this section, the proposed framework has been extensivelyevaluated using three different methods.

Firstly, a quantitative approach is used where informationobtained from reviewing the literature is used; then analysedand compared with the new framework in order to verify thecompleteness of the framework’s components for differentsituations. Table 1 presented a number of context-aware sys-tems from various domains and their corresponding archi-tectural styles. It also showed the building blocks that con-stitute various context-aware systems; these were found tobe sensing, modelling, reasoning, storing/retrieving, aggre-gating, application, and managing services. As mentioned inSect. 2, our research revealed that the components presentedin the comparison were found to be the only componentssupported by various context-aware systems which alreadyexist. Also, the table shows that existing systems use some

or all of these functional components which could be ei-ther reusable or tightly coupled with other components. Fur-ther analysis of the data is shown in Fig. 6. It illustrates themain components for various context-aware systems withthe number of systems employing these components. Thecomparison and analysis also show that in order to build ageneric framework for context-aware systems, the genericnature requires that all these functional components must besupported. This is because that, although not all systems useall the functional components, every component is used bymore than one system (at least 44 % of systems) which sug-gests that all components are essential for the generic frame-work.

Secondly and having established which components areessential for ensuring the generic nature of the framework,it is also important to ensure that the framework (and itssupported components) can be used for realising differenttypes of system. For this purpose, the framework has been


applied to two case studies in addition to the previous one.The case studies were selected from the literature for thefollowing two reasons:

1. They represent well-known systems which have beenwidely cited.

2. Since these were defined prior to and independent of thework carried out in this research, the independence of thestudy is guaranteed.

This method is used for verifying the applicability andgeneric nature of the framework. The two well-known se-lected systems are the context Toolkit [8] and SOCAM [13].The GECAF framework’s components were used to imple-ment different context toolkit widgets, such as ‘Presence’and ‘Meeting’. For the SOCAM system different contextswere represented, such as ‘LocatedIn’, ‘hasActivity’, etc.In these applications existing and new concrete filters were

Fig. 6 Architecture components used by the context-aware systems

used; these were derived from the abstract filters Getter, For-matter, Adder, and Interpreter.

Figure 7 shows the component diagram of the Meetingcontext in which the Presence context can be directly de-rived from the formatted primitive information (ID, Time,and Location). These primitives are acquired using concreteGetter filters. Another Interpreter is used on top of the Pres-ence context to determine the attendee numbers. The con-crete filter Aggregator (derived from the Adder abstract fil-ter) is used to accumulate the presence of people. This filteris a specialised Adder that is used to add the contents of theinput stream to the contents of an existing file. The Meetingcontext is derived from the attendee number and the pres-ence of a specific person (chair).

Figure 8 presents the SOCAM’s ‘hasActivity’ context;where different information can be interpreted either di-rectly from the primitives or indirectly using different Inter-preter and Aggregator filters. As shown in the figure someprimitive contexts are manipulated several times before fi-nally used to determine the outcome, while others are onlyused in the latter stage of interpreting. Furthermore, the Lo-cation primitive is used more than once, thanks to the recon-figurable and flexible nature of the framework; somethingthat is difficult to achieve in other styles such as the layeredstyle unless the layers are specifically designed to support acertain application.

Thirdly, the proposed framework has been compared toother state of the art architectures in order to verify itsimprovements over previous ones. A comparative analysishas been conducted for this purpose based on two criteria:genericity and extensibility and scalability. Each criteriondefines a number of metrics that are used in the comparison.

Fig. 7 ‘Meeting’ context for the Context toolkit system

Fig. 8 ‘hasActivity’ context for the SOCAM system


Appendix B summarises the criteria used in the comparisonas shown in Tables 4 and 5. Each table shows the metricsused in one criterion, possible values and the baseline valuefor each metric. The possible values are listed in the orderof their preference; the first is the most preferable.

The results of comparison between GECAF and othercontext-aware architectures (according to the above criteria)are given in Table 3. The table presents the values scoredby each architecture against each metric; the underlined val-ues present the values achieving the baseline for compari-son, while those scoring the best possible value are markedby (∗). As we do not have full access to the architectures pre-sented in the table, the values are based on the claims madeby the authors of the papers reviewed; hence these valuescannot be verified. Some values were inferred from the waythe architectures were described in these papers.

Even though some existing systems use all the functionalcomponents found in this study, they are either applicationspecific or some of their components are tightly coupledwith each other, which makes them difficult to reconfig-ure. Ubi-UCAM and CADBA are the architectures in ques-tion. In contrast, GECAF achieves the baseline in every met-ric and hence is proven to be more generic and extensiblethan any other existing architecture. The closest architec-tures to GECAF are the Context Toolkit and MIDAS whichare both reconfigurable and decoupled. However, GECAFoutperforms them in three other metrics, as it supports morefunctional components (complete), works independently ofany external resources and more efficiently developed dueto the use of a Meta language (CADL) when systems aredeployed. In contrast, developers need more knowledge ofthe other systems in order to deploy them; such knowledgeoften involves some algorithmic complexity.

6 Conclusions

In this research, a new framework for developing contextaware systems has been presented. The main aim of the re-search was to find a generic and extensible approach forbuilding context aware systems which may be applied todifferent types of applications. Context aware systems varyin the way they process context information and the waythey perform actions based on such information. They arealso continuously evolving as new contexts emerge and areincorporated into the system. In order to succeed in find-ing the generic approach, a framework based approach wasadopted. The developed framework (GECAF) needed to be

extensible, reconfigurable, loosely-coupled and reusable inorder to be generic. The framework-based approach pro-vided a development method that allows developers to buildnew systems from existing reusable components, and ex-tend the framework by defining their own ones if needed.

Different types of context aware architectures were studiedin this research in order to identify a common architectureas the basis for the framework. It was found that existingsystems had adopted various architectural styles as differ-ent systems had different requirements. None of the exist-ing styles was suitable for the new framework. Some ar-chitectures supported reuse such as the layered architecture,while others supported decoupling and scalability such asthe agent-based systems. None of the existing styles wasgeneric and supported re-configurability. For this reason, theGECAF framework opted for an architectural style that wasnever used in any of the existing context aware systems,yet it supported all the characteristics which were identifiedabove. This was the Pipe-and-Filter style, where filters arethe reusable components (building blocks) in the frameworkand pipes are the links between these components. A pipe(which is essentially an XML file) represents the interfacebetween components and hence sufficiently decouples everycomponent from all other components. This allows compo-nents to be re-arranged and configured in a variety of ar-rangements depending on the implemented scenario. Theresulted approach was successfully applied to a number ofscenarios, which confirmed that the main aim of the researchhas been fulfilled. In addition, an extensive study of the stateof the art architectures was conducted and then used for acomparative analysis with GECAF. Results from the analy-sis showed that GECAF is more generic and extensible thanany other architecture.

Despite the fact that GECAF has produced a genericframework for developing context-aware systems, there issome cost to the use of GECAF, mainly attributed to thePipe-and-Filter style [2]. Firstly this style is more suitablefor batch processing and hence it is more difficult to main-tain state in the system. As GECAF uses XML files for rep-resenting pipes, these files are often used to store the stateof the system. Secondly, a common data format is neededfor passing information between various filters in this style.Again the use of XML representation made it possible to in-clude pointers to other data formats such as images. Finally,the use of multiple components in a single pipe may posesome delay in processing the context information, althoughcaching has been used to speed up the process.


Tabl

e3

Com

pari

ngG

EC

AF

toot

her

arch

itect

ures

Arc

hite

ctur

eG

ener

icity

crite

rion

Ext

ensi

bilit

yan

dsc

alab

ility

crite

rion

No

ofsu

ppor

ted

com

pone

nts

Reu

sabi

lity

Inde

pend

ence

Func

tiona

lco

hesi

onof

com

pone

nts

Dev

elop

men

tef

ficie

ncy

Mai

ntai

nabi

lity

Re-

confi

gura

bilit

yD

ecou

plin

gM

ultip

leco

ntex

ts

TE

A-s

yste

m4

Part

ially

reus

able

Dep

ende

ntFi

xed

EK

Dif

ficul

tto

mai

ntai

nno

t-re

confi

gura

ble

Cou

pled

Lim

ited

Tool

kit

5Fr

amew

ork

and

com

pone

ntba

sed∗

Part

ially

inde

pend

ent

Lar

gely

inde

pend

ent

SKE

asy

tom

aint

ain∗

Rec

onfig

urab

le∗

Dec

oupl

ed∗

Unl

imite

d∗

CM

F5

Fram

ewor

kan

dco

mpo

nent

base

d∗Pa

rtia

llyin

depe

nden

tPa

rtia

llyde

pend

ent

EK

Dif

ficul

tto

mai

ntai

nno

t-re

confi

gura

ble

Part

ially

deco

uple

dU

nlim

ited∗

CoB

rA4

Part

ially

reus

able

Dep

ende

ntPa

rtia

llyde

pend

ent

SKD

iffic

ultt

om

aint

ain

not-

reco

nfigu

rabl

ePa

rtia

llyde

coup

led

Lim

ited

SOC

AM

5Fr

amew

ork

and

com

pone

ntba

sed∗

Part

ially

inde

pend

ent

Part

ially

depe

nden

tSK

Eas

yto

mai

ntai

n∗no

t-re

confi

gura

ble

Part

ially

deco

uple

dL

imite

d

CA

SS3

Part

ially

reus

able

Dep

ende

ntPa

rtia

llyde

pend

ent

SKD

iffic

ultt

om

aint

ain

not-

reco

nfigu

rabl

eC

oupl

edL

imite

d

CO

RT

EX

4Fr

amew

ork

and

com

pone

ntba

sed∗

Inde

pend

ent∗

Part

ially

depe

nden

tSK

Eas

yto

mai

ntai

n∗R

econ

figur

able

∗Pa

rtia

llyde

coup

led

Unl

imite

d∗

Ubi

-UC

AM

7∗Fr

amew

ork

and

com

pone

ntba

sed∗

Inde

pend

ent∗

Lar

gely

inde

pend

ent

EK

Eas

yto

mai

ntai

n∗no

t-re

confi

gura

ble

Dec

oupl

ed∗

Lim

ited

Con

text

stac

k5

Not

reus

able

Dep

ende

ntFi

xed

EK

Dif

ficul

tto

mai

ntai

nno

t-re

confi

gura

ble

Cou

pled

Lim

ited

RW

Mar

chite

ctur

e5

Part

ially

reus

able

Dep

ende

ntFi

xed

EK

Dif

ficul

tto

mai

ntai

nno

t-re

confi

gura

ble

Cou

pled

Lim

ited

Mul

tiag

ent

arch

itect

ure

4C

ompo

nent

base

dPa

rtia

llyin

depe

nden

tL

arge

lyIn

depe

nden

tE

KE

asy

tom

aint

ain∗

not-

reco

nfigu

rabl

ePa

rtia

llyde

coup

led

Lim

ited

WC

AM

5Fr

amew

ork

and

com

pone

ntba

sed∗

Inde

pend

ent∗

Lar

gely

Inde

pend

ent

SKE

asy

tom

aint

ain∗

not-

reco

nfigu

rabl

eD

ecou

pled

∗L

imite

d

CA

LA

5Pa

rtia

llyre

usab

leD

epen

dent

Fixe

dE

KD

iffic

ultt

om

aint

ain

not-

reco

nfigu

rabl

eC

oupl

edL

imite

d

Gen

eral

arch

itect

ure

6N

otre

usab

leD

epen

dent

Fixe

dE

KD

iffic

ultt

om

aint

ain

not-

reco

nfigu

rabl

eC

oupl

edL

imite

d

Mul

tiag

ent

serv

ice

reas

sem

blin

gar

chite

ctur

e

5Pa

rtia

llyre

usab

lePa

rtia

llyin

depe

nden

tPa

rtia

llyde

pend

ent

EK

Dif

ficul

tto

mai

ntai

nno

t-re

confi

gura

ble

Part

ially

deco

uple

dL

imite

d

CA

DB

A7∗

Fram

ewor

kan

dco

mpo

nent

base

d∗Pa

rtia

llyin

depe

nden

tFi

xed

EK

Dif

ficul

tto

mai

ntai

nno

t-re

confi

gura

ble

Cou

pled

Lim

ited

MID

AS

4Fr

amew

ork

and

com

pone

ntba

sed∗

Part

ially

inde

pend

ent

Lar

gely

inde

pend

ent

EK

Eas

yto

mai

ntai

n∗R

econ

figur

able

∗D

ecou

pled

∗U

nlim

ited∗

GE

CA

F7∗

Fram

ewor

kan

dco

mpo

nent

base

d∗In

depe

nden

t∗L

arge

lyin

depe

nden

tL

K∗

Eas

yto

mai

ntai

n∗R

econ

figur

able

∗D

ecou

pled

∗U

nlim

ited∗

∗D

enot

esto

pva

lue

inth

em

etri

c

Und

erlin

edva

lues

deno

teba

selin

eha

sbe

enac

hiev

ed


Appendix A: CADL XML schema

<?xml version="1.0" encoding="utf-8"?><an:schema xmlns:an="http://www.w3.org/2001/XMLSchema">

<an:element name="Filters"><an:complexType>

<an:sequence><an:element name="events" minOccurs="1" maxOccurs="1">

<an:complexType><an:sequence>

<an:element name="event" minOccurs="1" maxOccurs="unbounded"><an:complexType>

<an:sequence><an:element name="description" type="an:string" />

</an:sequence><an:attribute name="id" type="an:string" default="" /><an:attribute name="CID" type="an:string" default="" />

</an:complexType></an:element>

</an:sequence></an:complexType>

</an:element><an:element name="process" maxOccurs="unbounded">

<an:complexType><an:sequence>

<an:element name="class" minOccurs="1" maxOccurs="6"><an:complexType>

<an:sequence><an:element name="source" minOccurs="0" maxOccurs="6">

<an:complexType><an:simpleContent>

<an:extension base="an:string"><an:attribute name="no" type="an:string" default=""/><an:attribute name="type" type="an:string" default="xml"/>

</an:extension></an:simpleContent>

</an:complexType></an:element><an:element name="target" minOccurs="0" maxOccurs="1">


<an:extension base="an:string"><an:attribute name="type"type="an:string"default="xml"/>


</an:complexType></an:element><an:element name="Element" minOccurs="0" maxOccurs="10">


<an:extension base="an:string"><an:attribute name="name" type="an:string" use="required"/><an:attribute name="value" type="an:string" /><an:attribute name="type" type="an:string" /><an:attribute name="fileType" type="an:string" default="xml"/>



</an:sequence><an:attribute name="name" type="an:string" use="required" />


<an:attribute name="context" type="an:string" /><an:attribute name="address" type="an:string" /><an:attribute name="time" type="an:string" /><an:attribute name="RID" type="an:string" />


</an:sequence><an:attribute name="type" type="an:string" /><an:attribute name="CID" type="an:string" /><an:attribute name="category" type="an:string" />


</an:sequence></an:complexType>

</an:element></an:schema>

Appendix B: Comparison criteria

Table 4 The genericity criterion metrics

Metric Description Possible values Baseline value

No. offunctionalcomponents

This metric measures the completeness of thearchitecture using the number of componentsthat are supported in the architecture.

[7–1] 7

Reuse This metric measures the reusability of thearchitecture.

– Framework based– Component based– Partially reusable– Not reusable

Component based

Independence This metric measures the architecture’ssufficiency by considering its dependency onother external resources.

– Independent– Partially dependent– Dependent

Independent

Functionalcohesion

This metric measures cohesion of thefunctional components used in thearchitecture.

– Completely independent– Largely independent

(but some rules are usedin their organisation)

– Partially dependent– Fixed

Largely independent

Developmentefficiency

This metric measures the degree by whichdevelopers (including less experienced ones)would be able to develop new systems quicklyand with ease.

– Requires limited knowledge of the systemand its components (based on the use ofguidelines) (LK)

– Requires some knowledge of the underly-ing working of the architecture (SK)

– Requires extensive knowledge about theunderlying working of the architecture(EK)

NB We decided that no knowledge isunrealistic and therefore this is not includedas a value

SK


Table 5 The extensibility and scalability criterion metrics

Metric Description Possible values Baseline value

Maintainability This metric measures whether the architectureis easy to maintain or not.

– Easy to maintain– Difficult to maintain

Easy to maintain

Re-configurability This metric measures whether the architecturesupports system reconfiguration or not.

– Reconfigurable or– Not-reconfigurable

Reconfigurable

Decoupling This metric measures the ability of thearchitecture to modify the implementation ofits components without the need to change theoverall system’s architecture.

– Decoupled– Partially decoupled– Coupled

Decoupled

Multiple contexts This metric measures the ability of thearchitecture to add new context informationwithout the need to re-design the system.

– Unlimited number of contexts can beadded later by using a Meta language

– Limited related contexts can be addedto the system which requires limited re-design

– Not possible

Unlimited

References

1. Baldauf M, Dustdar S, Rosenberg F (2007) A survey on context-aware systems. Int J Ad Hoc Ubiq Comput 2(4):263–277.doi:10.1504/IJAHUC.2007.014070

2. Bass L, Clements P, Kazman R (1998) Software architecture inpractice. Addison Wesley, Reading

3. Biegel G, Cahill V (2004) A framework for developing mobile,context-aware applications. In: Proceedings of the second IEEEannual conference on pervasive computing and communications(PERCOM’04), USA

4. Chen H, Finin T, Joshi A (2004) Semantic web in the context bro-ker architecture. In: Proceedings of the 2nd IEEE internationalconference on pervasive computing and communications (Per-Com04), Orlando, FL

5. Chien B-C, Tsai H-C, Hsueh Y-K (2009) CADBA: a context-aware architecture based on context database for mobile comput-ing. In: International workshop on pervasive media. The sixth in-ternational conference on ubiquitous intelligence and trust com-puting, Brisbane, Australia, pp 367–372

6. Choi J (2008) Software architecture for extensible context-awaresystems. In: Proceedings of the international conference on con-vergence and hybrid information technology, pp 811–816

7. Domingo MC (2011) A context-aware service architecture for theintegration of body sensor networks and social networks throughthe IP multimedia subsystem. IEEE Commun Mag 49(1):102–108

8. Dey KA (2000) Providing architectural support for buildingcontext-aware applications. PhD thesis, College of Computing,Georgia Institute of Technology

9. Dey AK, Abowd GD (2000) Towards a better understandingof context and context-awareness. In: Proceedings of workshopon the what, who, where, when and how of context-awareness,Hague, Netherlands

10. Fahy P, Clarke S (2004) CASS: middleware for mobile context-aware applications. In: Workshop on context aware at MobiSys,Boston

11. Gamma E, Helm R, Johnson R, Vlissides J (1994) Design patterns:elements of reusable object-oriented software. Addison-Wesleyprofessional computing series

12. Gu T, Pung HK, Zhang DQ (2004) Toward an osgi-based infras-tructure for context-aware applications. IEEE Pervasive Comput3(4):66–74

13. Gu T, Wang X, Pung H, Zhang D (2004) An ontology-based con-text model in intelligent environments. In: Proceedings of commu-

nication networks and distributed systems modelling and simula-tions conference, San Diego, CA

14. Held A, Buchholz S, Schill A (2002) Modeling of context infor-mation for pervasive computing applications. In: Proceedings ofSCI 2002/ISAS

15. Hong M, Cho D (2008) Ontology context model for context-awarelearning service in ubiquitous learning environments. Int J Com-put 2(3):193–200

16. Hong A, Lee K, Kim H, Kim H (2008) The context-awarenessfor the network-based intelligent robot services. In: Ahn HS (ed)Advances in service robotics. InTech Publishing, Vienna, pp 69–84

17. Korpipää P, Mäntyjärvi J, Kela J, Keränen H, Malm E-J (2003)Managing context information in mobile devices. IEEE PervasiveComput 2(3):42–51

18. Kunito G, Sakamoto K, Yamada N, Takakashi, T, Tanaka, S (2006)Architecture for providing services in the ubiquitous computingenvironment. In: International conference on distributed comput-ing systems, Lisboa, Portugal

19. Kwon OB (2004) Modeling and generating context-aware agent-based applications with amended colored petri nets. Expert SystAppl 27(4):609–621

20. Lee JK, Sohn MM (2003) The extensible rule markup language.Commun ACM 46(5):59–64

21. Loke S (2006) Context-aware pervasive systems: the architectureof a new breed of applications. Monash University: Auerbach pub-lications. Taylor & Francis Group, Australia

22. Mei J, Boley H (2006) Interpreting SWRL rules in RDF graphs.Electron Notes Theor Comput Sci 151:53–69

23. Mohyeldin E, Fahrmair M, Sitou W, Spanfelner B (2005)A generic framework for context aware and adaption behaviour ofreconfigurable systems. In: International symposium on personalindoor and mobile radio communications (PIMRC05)

24. Neelima AV, Sunitha BR, Aghila CG (2009) A multi agent, servicereassembling architecture for context-aware systems. Int J RecentTrends Eng 1(1):563–567

25. Roussaki I, Strimpakou M, Pils C, Kalatzis N, Anagnostou M(2006) Hybrid context modelling: a location-based scheme usingontologyies. In: Proceedings of the 4th annual IEEE internationalconference on pervasive computing and communications work-shops (PERCOME’06)

26. Sabagh A, Al-Yasiri A (2011) An extensible framework forcontext-aware smart environment. Lect Notes Comput Sci6566/2011:98–109

http://dx.doi.org/10.1504/IJAHUC.2007.014070


27. Salber D et al (1999) The context toolkit: aiding the developmentof context-enabled applications. In: Proceedings of the ACM con-ference on human factors in computing systems (CHI’99). ACM,Pittsburgh, pp 434–441

28. Salber D, Dey AK, Orr RJ, Abowd GD (1999) Designing forubiquitous computing: a case study in context sensing. GVUtechnical report, GIT-GVU-99-29, Georgia Institute of Tech-nology. http://smartech.gatech.edu/handle/1853/3396. Accessed02/02/2011

29. Schmidt A, Beigl M, Gellersen H-W (1999) There is more to con-text than location. Comput Graph 33(6):893–902

30. Schmidt A, Aidoo K, Takaluoma A, Tuomela U, Van LaerhovenK, Van de Velde W (1999) Advanced interaction in context. In: 1stinternational symposium on handheld and ubiquitous computing(HUC99). LNCS, vol 1707. ISBN 3-540-66550-1.

31. Schmidt A, Beigl M, Gellersen H (1999) There is more to contextthan location. Comput Graph 33(6):893–902

32. Schmidt A, Van Laerhoven K (2001) How to build smart appli-ances. IEEE Pers Commun 8(4):66–71

33. Schmohl R, Baumgarten U (2008) Context-aware computing: asurvey preparing a generalized approach. In: Proceedings of theinternational multi-conference of engineering and computing sci-ence, IMECS 2008, Hong Kong

34. Shaw M, Garlan D (1996) Software architecture: perspectives onan emerging discipline. Prentice Hall, New Jersey

35. Strang T, Popien CL (2004) A context modelling survey. In: The6th international conference on ubiquitous computing, UbiComp,pp 33–40

36. Uhm Y, Lee M, Kim Y, Kim G, Sehyun P (2007) A context modelby ontology and rule for offering the user-centric services in ubiq-uitous computing. In: Proceedings of the international conferenceon convergence information technolology, pp 77–82

37. Wang C-D, Wang X (2007) Multi-agent based architecture ofcontext-aware systems. In: International conference on multime-dia and ubiquitous engineering (MUE’07), 26–28 April, Seoul,Korea

38. Zhang D, Gu T, Wang X (2005) Enabling context-aware smarthome with semantic web technologies. Int J Hum-Friendly WelfRobot Syst 6(4):12–20

Angham A. Abdulahad Sabaghgraduated from the University ofTechnology, Baghdad in 1984 witha B.Sc. in Systems and Control En-gineering; then she obtained M.Sc.in Computer Engineering from thesame University in 1989. In 2011she obtained her Ph.D. in datatelecommunication and network-ing. Her Ph.D. research was inthe area of Pervasive and Context-Aware Computing. She is currentlyworking as a research associate atManchester Metropolitan Univer-

sity. Previously, Dr. Sabagh worked as a part-time lecturer at the Uni-versity of Salford and as Assistant Professor at the University of Tech-nology. During that period she has been involved in teaching, research,and administrative work, and contributed to the writing of three textbooks for B-Tech Education System.

Adil Al-Yasiri obtained his B.Sc.and M.Sc. in Systems and ControlEngineering in 1984 and 1988 re-spectively, and Ph.D. in ComputerScience in 1997. He is currentlySenior Lecturer in Software Engi-neering at the University of Salfordand a member of the InformaticsResearch Centre within the Univer-sity, where he undertakes researchwithin the area of Smart Environ-ments and Ambient Intelligence.Dr. Al-Yasiri’s career started as aninstrumentation engineer and soon

moved into academia where he lectured in a number of international in-stitutions and at the same time working as IT consultant with a numberof industrial partners around the world. His current research interestsinclude software architectures, cloud computing, ubiquitous comput-ing and user identification within pervasive environments.

http://smartech.gatech.edu/handle/1853/3396

gecaf: a framework for developing context-aware pervasive systems

Documents