Contexts, Domains, and Software

We survey some issues that relate to context dependence and context sensitivity in the development of software, particularly in relation to information systems by defining a range of context-related concepts. Domain models are identified as the appropriate framework for dealing with context-related issues. The importance of context is being increasingly recognized in many areas of computing. The aim of this note is to arrive at a classification of contexts in a rather informal way, by defining a number of terms. We hope that this will further the discussion of what effect context has on the design of software systems, and on the relationship between contexts and domain modeling. The interpretation of the word context shows considerable variety — indeed, the definition is itself context-sensitive. Linguists may see it as a psychological construct, a subset of a hearer’s assumptions about the world that is used in interpreting an utterance [1]. To an organizational theorist context is a social environment in which actions are taken [2]. To a sociologist, context is provided by macrosocial forms, such as gender, national ethos, and economic maturity of a society [3]. An axiomatic approach is taken in [4]. As a first step toward a classification of contexts we take a dictionary definition of context: the parts of a written or spoken statement that precede and follow a specific word or passage, or a set of circumstances or facts that surround a particular event, situation, etc [5]. This two-way split suggests a partitioning of contexts into internal and external. The term internal context relates to cases in which the actions of a software system depend on internal factors. For example, computer systems contain clocks, and an operation may be triggered by such an internal clock. When the software actions depend on external factors, such as a temperature reading or a stock market quote, we shall use the term external context. In all cases the effects of the context can be expressed as rules, which we call context rules. A set of context rules relating to a particular setting of interest will be called a contextual domain model (CDM). For uniformity we assume that all context rules of CDMs have the form “if c then q.” An example: “If x is in the United States, then temperatures at x are measured in Fahrenheit.” The c will be called a context; the q will be called an effect. Both c and q form populations that can be partitioned into classes that can be related to domains. Not all software systems are context-dependent. To identify those that are, we partition computations into procedural and transactional. A procedural compuP. Bouquet et al. (Eds.): CONTEXT’99, LNAI 1688, pp. 443–446, 1999. c © Springer-Verlag Berlin Heidelberg 1999