This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
research:modelling [2006/11/09 15:10] stijnm Added |
research:modelling [2006/11/09 19:50] stijnm |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Modelling for Ambient Intelligence ====== | ||
- | [[http:// | ||
- | [[http:// | ||
- | [[http:// | ||
- | |||
- | ===== Context ===== | ||
- | In the past few years, special-purpose hardware (e.g. cellular phones, portable music players, game consoles, etc.) has evolved enormously. The most important innovation is not that these devices are becoming ever smaller and more powerful but that they have evolved into networked devices. To make optimal use of the growing network surrounding these devices, co-operative software | ||
- | needs to be developed. | ||
- | |||
- | The development of such co-operative software typically focusses on either the computation level or the domain level. The former is concerned with developing computation models and programming languages that take the inherent characteristics of mobile networks into account. The latter is concerned with high-level concerns on how the software allows its user to interact with (the devices in) their environment. | ||
- | |||
- | We observe that there is a gap between the two aforementioned levels. On one hand, the computational level strives for the development of programming idioms to deal with the inherent and very stringent hardware phenomena of mobile networks. On the other hand, the domain level is concerned with addressing the expected behaviour of the system, e.g. how and when a system responds to changes in the context, when information can be made public etc. Nevertheless, | ||
- | |||
- | ===== Co-Existence of Models and Programs ===== | ||
- | |||
- | Modelling has always been considered an essential part of the software development process as a means to represent the domain of the software without tying to a particular implementation strategy. Therefore, the modelling level seems an apt candidate to express domain level concepts about software for ambient intelligence. | ||
- | |||
- | Evidently, this requires that the model is not simple documentation that accompanies the actual software artifact. The model needs to be intimately connected to its actual implementation. In previous work, we have already explored such a co-evolution of Extended Entity Relationship (EER) models and object-oriented programs. In this work, changes to the model are immediately propagated to the programs, and vice versa whenever possible and meaningful [1]. Furthermore, | ||
- | |||
- | Another concrete instance of the co-evolution of models and implementation provides a means to specify business rules in terms of a high-level domain model. This model is connected to the actual implementation and the business rules are injected into it through a high-level aspect language for connecting the business rules to this application, | ||
- | |||
- | ===== Ambient-Oriented Programming ===== | ||
- | |||
- | Software development for ambient intelligence requires a paradigmatic shift at the computation level. Networks of mobile devices are inherently dynamic and unreliable. Programming software for such a setting in a conventional (synchronous, | ||
- | |||
- | In previous work, we have proposed the ambient-oriented programming paradigm which reconciles traditional programming techniques with the inherently event-based nature of the underlying networks. The work encompasses various communication strategies [3] as well as abstractions for service discovery in a mobile environment [4]. | ||
- | |||
- | ===== Ambient-Oriented Modelling ===== | ||
- | |||
- | Our goal is to bridge the gap between the computation level and the domain level in AmI. We intend to transfer our previous work on the co-existence of models and programs to the field of AmI. We propose to represent knowledge of the AmI domain in models and synchronise them with a dedicated ambient-oriented programming language which expresses the computation level. The models can represent concepts but also behaviour of the domain, such as interaction protocols and policy rules. Moreover, the models have a live link with the computation level, such that certain adaptations, | ||
- | |||
- | ===== References ===== | ||
- | - **SelfSync: A Dynamic Round-Trip Engineering Environment** Ellen Van Paesschen, Wolfgang De Meuter, Maja D' | ||
- | - **Mapping High-level Business Rules to and through Aspects** Maria Agustina Cibrán, Maja D' | ||
- | - **Ambient-Oriented Programming in AmbientTalk** Jessie Dedecker, Tom Van Cutsem, Stijn Mostinckx, Theo D' | ||
- | - **Ambient References: Addressing Objects in Mobile Networks** Tom Van Cutsem, Jessie Dedecker, Stijn Mostinckx, Elisa Gonzalez Boix, Theo D' |