Development processes for context aware systems

Human behaviour models for activity recognition aim at representing the available a priori knowledge needed for providing rich user related information during the inference phase. Thus, it is reasonable to assume that a model engineering process would improve this knowledge incorporation. Indulska et al. argue that one of the requirements for context modelling is the support for software engineering [70]. They also point out that the majority of approaches are

concerned with runtime context representation, querying, and reasoning, not on requirements analysis, design, or testing. This can be seen in works such as [103, 41]. In this section we

look at some methods for developing context aware systems.

5.2.4.1 Knowledge-based system development lifecycle [61, p. 304]

Gonzalez and Dankel propose a development lifecycle for knowledge-based systems, argu- ing that in the past knowledge engineering has been performed in an improvised manner [61, p. 307]. Additionally, they point out that adapting the popular waterfall model is not sufficient

$QDO\VLV 6SHFLI FD_WLRQ 3UHOLPLQDU\_{GHVLJQ SURWRW\SLQJ},QLWLDO (YDOXDWLRQ )LQDOGHVLJQ

'HVLJQ DGMXVWPHQW ,PSOHPHQWD WLRQ 9DOLGDWLRQ  YHULI FDWLRQ 0DLQWHQDQFH

Figure 5.10: The knowledge-based systems development lifecycle proposed by Gonzalez and Dankel [61, p. 304] (Figure adapted from [61, p. 303].)

for knowledge engineering as it lacks rapid prototyping and incremental development. Thus they propose a model that combines rapid prototyping, incremental development and a cyclical lifecycle.

Fig 5.10 shows the lifecycle. It can be seen that it is divided into 10 phases with process iteration of subset of the phases. The first phase in the model is the problem analysis which regards the problem and the applicability of knowledge based solution to such problem. Addi- tionally, the costs for developing such system are calculated in order to determine whether such system development is warranted. The second phase is the requirements specification where the knowledge obtained in the first phase is formalised. Based on that the objectives of the project are set as well as the means for obtaining them. The third phase is the preliminary de-

sign in which the high level decisions for the initial system implementation are defined. These

are the knowledge representation paradigm, the tool chosen for prototyping, and the selection of system experts. The fourth phase is the rapid prototyping where the initial system proto- type is designed that should look like the complete system but it should be limited in breadth. The prototype is then evaluated in the evaluation phase which deals with deciding whether the prototype could be further developed or discarded. The next phase is the final design which involves the selection of tools and resources needed for developing the system. Additionally, in

this phase a high-level description of the system architecture is provided. The seventh phase is the actual system implementation where the complete knowledge regarding the system has to be implemented in a computer readable format. The eighth phase is the validation and verifi-

cation where it is tested whether the system is able to solve the problem it was designed for and

whether it is consistent with the requirements and objectives defined earlier. The ninth phase is the design adjustment where some changes in the design of the system could be made at the beginning of each iteration. The last phase in the process is the system maintenance and as in conventional software engineering it deals with documenting, storing and adapting the system. A model-based activity recognition system can be considered as a knowledge-based sys- tem, thus the methodology proposed by Gonzalez and Denkel could generally be applied to such kind of problems. However, although the process allows iterations of the later phases, it does not have the ability to return to early phases where conceptual problems could be made. Furthermore, the process does not allow the iteration between some of the phases. This indi- cates that problems in the early phases, discovered later on, cannot be corrected. Finally, here once again comes the problem of developing the probabilistic model components.

5.2.4.2 A model driven development method for developing context-aware pervasive sys-

tems [129]

Serral et al. [129] propose a development method for context aware systems that consists of four phases. The motivation behind the method is to develop context-aware pervasive systems by developing a set of models that are automatically mapped into system code.

&RQFHSWXDO

PRGHOOLQJ &RGHJHQHUDWLRQ

'ULYHU

LPSOHPHQWDWLRQ 'HSOR\PHQW

Figure 5.11: The development method for context-aware systems proposed by Serral et al. [129]. The development process can be seen in Fig. 5.11. It is rather simple and straight forward. The first phase is the conceptual modelling where the system is specified at a high level of abstraction in the form of PervML models [129]. These models are later used in the second phase for code generation. In it the PervML models are mapped into Java code and OWL specifications. The Java code represents the functionalities of the system whereas the OWL specifications the PervML ontology. The third phase is the driver implementation where the drivers needed for managing the access from the implementation framework to the devices are implemented. The final step is the system deployment where the Java implementation is configured to use the selected drivers.

The proposed method, although labelled as a software engineering method, is rather an example of the statement by Indulska et al. [70] that most context-aware systems deal with the runtime model implementation and configuration rather than with problem analysis and conceptual models. Furthermore, the method is linear and does not allow returning to earlier phases which could be a disadvantage when conceptual problems are discovered in the later phases.

5.2.4.3 A context-driven development methodology for context-aware systems [25]

A more complex method for developing context-aware systems is proposed by Choi et al. [25]. As they explain, context-aware systems demand custom development methodology be-

cause they have specific features such as the need of context modelling and the implementation of context-dependent services. The process they propose consists of three phases each of which

,QFHSWLRQ (ODERUDWLRQ &RQVWUXFWLRQ EXVLQHVVPRGHOOLQJ EXVLQHVVUHTXLUHPHQWV FRQWH[WUHTXLUHPHQWV DQDO\VLV LPSOHPHQWDWLRQ WHVW LPSOHPHQWDWLRQ WHVW EXVLQHVVPRGHOOLQJ EXVLQHVVUHTXLUHPHQWV FRQWH[WUHTXLUHPHQWV DQDO\VLV LPSOHPHQWDWLRQ WHVW

Figure 5.12: The development method for context-aware systems proposed by Choi et al. [25] (Figure adapted from [25].).

has various workflows. The first phase is the inception where stakeholders define the scope of the project, the associated risks and costs. Additionally, the relevant context is identified. The phase consists of six workflows. The first is the business modelling where the business rules are defined and the business information is gathered. The second workflow is the business re-

quirements where the stakeholders requirements are collected, the use cases are gathered, and

a specification of both is documented. The next workflow is the context requirements where in difference with the business requirements, the goal is to gather context information from previ- ously identified context-sensitive use cases. The fourth workflow in this phase is the analysis. In it the draft solutions of the use cases are defined. The two main tasks here are to determine the system platform and to create context-aware use cases. The fifth workflow is the implemen-

tation where a prototype is realised in order to prove the developed concept. The last workflow

is the testing. It involves establishing test cases for acceptance tests.

The second phase is the elaboration phase where the stakeholders analyse the problem, define the system structure architecture and implement the core architecture. This phase has the same workflows as the inception phase but in a different context. During the business

modelling the business processes and rules are refined and the business modelling process is

completed. During the business requirements the requirements are also refined and specified in detail. During the context requirements workflow the gathered context information is cat- egorised in similar groups in preparation for the context modelling. Additionally, context re- quirements are elicited. The next workflow is the context modelling where the context model is designed to meet functional and nonfunctional requirements. During the analysis workflow the system architecture is determined such that it meets the functional, nonfunctional and context requirements. Additionally, preliminary system design is performed. This is followed by the system design where the preliminary design is refined and the realisation of the context repre- sentation and storage is defined. Later the preliminary architecture framework is implemented during the implementation workflow.

The last phase is the construction phase where the different system modules are imple- mented, tested and integrated into the complete system. This phase consists of only two work- flows. The first is the implementation where the preliminary system implementation is com- pleted and subcomponents and detailed services are added. The second is the test workflow, where the different modules are tested to check whether they operate correctly for a given con-

text. Additionally, the system as a whole is tested whether it operates correctly for the given context.

The proposed methodology is much more detailed than the one proposed by Serral et al. [129]. It also allows refinement of the workflows and has a detailed analysis and conceptu- alising steps. Still, it is possible that the system needs more than just three iterations to be successfully completed and that could mean iterating the whole process, which is not part of the proposed process. Here the same problem as in the previous two processes exists: in the case there is a problem in the early stages, the process does not allow the ability to return to a previous phase. Furthermore, not surprisingly, it is not able to cope with the development of the model’s probabilistic elements.