Context-Based Programming
The idea of context-based programming comes from the observation that many applications, more all the time, change core behavior based on changes in their context. While it’s easy to get hung up on precisely defining ‘behavior changes’ and ‘context’, I’ve developed what I think of as a simple clarifying design method that helps me think about both issues.
Start with Data-Driven Programming
I see context-based programming as a natural extension of data-driven programming, an idea with a rich history in computer science / software engineering. Stated briefly, and from my own perspective, data-driven programming is an approach to software design that favors moving program control information from the ‘hard-coded’ language of the program to a data-structure populated from some other source (constant definitions, config file, user parameters, database, or external message). There are a lot of implications and analysis questions that go into decided how much a given program should be data-driven but they usually boil down to issues of
- Time: how rapidly (over what time period) will a given variable need to be changed relative to other changes in the source code. For example, a user preference for large or small text in a browser should be modifiable without going back to the original programmers.
- Difference in deployment environment: How will one deployment of the software legitimately differ from other deployments. For example, online-game players will want to choose a game server close enough on the net to insure fast response.
- Difference in development responsibilities: Separating out development responsibilities often leads to the realization that significant differences occur in expertise, representation requirements, and time cycles. Computer games typically create level editors (data file editors) to allow artists and game designers to work a level that is comfortable to their skills and that better represents the game abstractions. The files from this editor are then input as data into the game.
To sum up, data-driven programming is about paying a price for reading control data elements from a structure external to the source code in order to improve some needed system capability.
Extending Data-driven programming into Context-based programming
If a program can read in control data elements, than it can read in more than one set of control elements at different times. We can think of each set of control elements as a policy. User A (big text) or Deployment A (server 1, game level 1) has a different policy than User B (small text) or Deployment B (server 2, game level 2). If the system can load multiple policies there must be a mechanism for loading the policy. This mechanism may be as simple as a configuration file loader or data base query and happen once at program load or may involve continual update by an interactive user or by back end functions. Regardless of how it is implemented, conceptually each program that supports policies must provide some code that acts as a policy manager. The pattern then is from fully internalized source code we move some variables or constants out to external policies that are injected by a policy manager.
What about the policy manager, though? Isn’t it just another block of code that can be implemented (as needed) in a data-driven manner? What if in one circumstance, an event (system start, user action, external data update) causes the instantiation of Policy A and under another circumstance that same event should cause the instantiation of Policy B?
For example, imagine the ringer function in a cell phone software application. Typical cell phones allow the user to define a policy that includes the volume of the ringer output and the specific file to play for each member of a contact list (and incoming calls not in the contact list). This ringer policy allows each cell phone to reflect the personality of the phone owner, an important consideration in the world of consumer electronics. This policy, though is fairly rigid. My cell phone is configured to play, moderately loudly, the rowdy goofy song Yakety Sax, from the Benny Hill show when either of my two brothers call. I love this because it captures, for me, an important part of my relationship with my brothers and how I imagine them. It would, however, be embarrassing if one of them were to call while I was in a serious meeting. (Something that has happened at least once recently). To avoid this, most phones allow the default policy to be modified on the fly. At any time I can easily lower the phone volume or change the ring tone. But what if the phone designer wanted to do better? Today’s phones often have the phone owner’s calendar available to them. What if I could create my default policy (which contains Yakety Sax) and a second “meeting” policy which overrides Policy A by setting the ringer to “vibrate - audio volume = 0”. The phone would then select which policy to apply based on the externalized calendar data.
This is the essence of context-based programming. In context-based programming, the policy manager itself is designed according to data-driven programming principles. This allows the system to provide different behaviors at different times based on a set of observable conditions. This then requires a set of meta-policies that define the conditions under which the primary policies are applied. We’ve now entered the world of AI and user-adaptive systems.
A design method for Context-Based Programming
While is absolutely true that the calendar-based ringer manager described above could be designed and implemented by a skilled software engineer without ever cracking open an AI reference book (AI code is just code, after all), it is equally true that this kind of pattern-matching of observable conditions to dynamically modify system behaviors has been far more studied and described in the AI community than in the traditional software community. Particularly for meta-policies that use non-trivial conditions. What if the ringer manager needed select a ringer policy by including both the calendar, the location of the phone owner (driving or not), the users current phone use, the output modes available (volume, vibrate, screen) and the background noise level? Each of these elements, and probably a lot more, are part of the policy manager’s context and could be included in the meta-policy. The bottom line is that the larger the set of context elements available and the larger the set of possible system configurations possible, the more context-driven programming pushes for the inclusion of AI techniques including Dialog Management, Agent Based Systems, Formal Logic, Heuristic Search, Constraint-Based Reasoning, Probabilistic Reasoning, and Decision Trees.
Before I worry about whether to apply an AI technique or which AI technique to apply, I start with analyzing the system from the perspective of policies and meta-policies.
- What are the core changes (policy elements) that should be defined in data and how will moving these policy elements into data impact the system. What can we really do here that makes sense. (Users want to set ringer sound on their cell phone. While the cost of this may be high and involve adding memory to the phone, new management UIs, network performance issues, and server design issues, the feature will be popular enough to drive additional fee and/or ringtone sales to justify the effort)
- What is the life cycle of these core changes? Which of these core changes will be well supported by a set of static (not-conditional) policies. Which ones require dynamic (conditional) policies? (Users would like their ringer policies to change reflect their calendar; for other reasons phone designers are already investing in providing calendar data on phones).
- What are the conditions (context) that drive changing from one policy to another and what are the algorithms for organizing the context, selecting the policy, and applying the policy.
3 comments:
Why haven't cell phone makers implemented a system like the one that you describe? Is it that: a) they don't know how to and that your essays will show the way, or b) the complexity of such a system would outweigh the benefits? How can one perform a cost benefit analysis for context-based programming?
In general I think that your A and B are tightly coupled. If we can develop design methods that limit the complexity, then the cost benefit equation becomes more attractive.
I haven't worked through how to do a cost benefit analysis, but my intuition is that computing cost would include two factors:
1. Context data pattern complexity - how well structured & understood is the input stream and how well do we know how to create (design or learn) patterns for that stream. Does the stream have all the necessary data? How well can we efficiently do matching of these patterns against the stream? Are the relevant techniques packaged in a manner that a moderately skilled engineer can build and maintain such a system?
2. Interface Complexity: In many environments, such as the cell phone example, the context-driven patterns are expected to be managed by end users. This means that we need to be able to provide interfaces that allow end users to manage the patterns. Do we have appropriate end-user reasonable abstractions? Are interface designers and engineers familiar with them? Have they been tested in the field? Are standard design templates or patterns available? This also includes feedback loops so end users can understand when the meta-policies are changing. In the cell phone example, a simple icon on the screen to show that it was in 'meeting' mode could be applied, but how many such icons would be needed?
I clearly can't speak for the telco's, but I can see how the location based and event based context could be intimidating but I can imagine reasonable designs for both that would be easy to engineer and interface with. I'm guessing this is a typical chicken-egg problem that users aren't asking so the telco's aren't offering and users won't ask until they see it works.
The other reason why, I think, the telcon's have not gone with a more context-driven approach is that there is a reasonable, non-context-driven, solution. They make a single critical policy variable, volume, easily reachable. This requires manual work by the user, but also gives them excellent control & feedback.
The implication for context-driven programming is there is often a non-context-driven approach that gives some reasonable results. It would be great to work out guide lines / design patterns to suggest how / when to apply context-driven approaches.
Post a Comment