1. Requirements Analysis
Andrew Zimdars
Learning and Event Services Team
22 October 1998

2. Introduction: Current System
Information distributed on several media
Difficult to maintain up-to-date documents
No facilities for adapting to use patterns or available resources
Fluctuation of network load
Connection speed/cost
Dealer databases
Mobile or disconnected use

3. Functional Requirements
Adapt resource interaction to improve transaction throughput
Adapt update patterns to user connections and information needs
Provide reports on network traffic
Develop extensible framework for gathering information

4. Non-functional Requirements
User interface
Hardware platform
Performance considerations
Extreme conditions
Resource considerations
Subsystem documentation (on-line-readable format)
Learning team has chosen HTML and PowerPoint
User Interface
Most of the work done by the Learning and Event Services subsystems occurs “behind the scenes.” The principal interfaces required are a dealer control panel and an administrator report viewer. In the control panel, dealers will specify their connection type and the frequency (if at all) of update reminders desired. The report viewer allows administrators to examine patterns of network traffic. As of yet, it is unknown whether the Learning team or the User Interface team will implement these features.
Performance Considerations
The analysis and recommended-action components of the Learning model should not produce a noticeable reduction in performance for the end user. To make sure this is the case, the data mining, or analysis, component of the subsystem have been separated from the on-line recommendation process. This allows data mining to occur during slack periods, to minimize interference with database performance. The problem of recommending actions for several thousand end users suggests scalability problems; the Learning team is trying to assess the scope of these challenges.
Resource Considerations
As of now, all Learning components reside on the server side. To support scenarios where dealers are disconnected from the remote server, event services will reside on both the dealer system and the remote server.

5. Event Services Architecture
Learning
Authentication
Database
User
Interface
Network
Event
Services

6. Event Services Architecture
Probably based on ObjectSpace Voyager Event Service
Other platforms still under consideration
“Events” may include database action triggers
Will implement publisher/subscriber model
Dynamic event type creation
Dynamic subscription and creation of new channels

7. Proposed Event Hierarchy
QueryEvent
DealerDBQuery
RemoteDBQuery
AuthenticationEvent
AuthenticationRequestEvent
AuthenticationApprovedEvent
AuthenticationDeniedEvent
TransactionEvent
ItemToDealerCacheEvent
ItemToDealerDBEvent
ItemToMasterDBEvent
ApplicationUpdateEvent
DeferUpdateEvent
This is just a sample of events the system will eventually support. Requirements imposed by other subsystems will guide the exact structure of the event hierarchy, as well as the nature of the data communicated by each event.

8. Learning Architecture
Database
User
Interface
Learning
Authentication
Network
Event
Services

9. Learning Architecture
Scheduler
Enforces update, data mining schedules
LogDB
Records transaction information
DataMiner
Extracts information from LogDB
Database of interesting events
LearnedBehavior
Generates learned responses to stimuli

10. Learning Object Model LogDB logEvent submitEvent DataMiner
requestEventRecord
updateBehavior
analyzeBehavior
LearnedBehavior
modifyScheduler
interceptEvent
Scheduler
startDataMiner
sendUpdateEvent
EventRecord
timeOfEvent
eventType
eventDuration
EventService

11. Learning Dynamic Model

12. Dependencies Network and Database teams Database subsystem
System load
Database subsystem
Notification of database updates
User Interface subsystems
Dealer preferences panel
Administrative reports
Network and Database teams
The Learning and Event Services team will rely on the Network and Database teams to provide estimates of system load and recommend appropriate metrics for measuring load. This will allow the Learning team to determine how intrusive the behavior recommendation and data mining processes can be without significantly disrupting network traffic and transaction volume.
Database subsystem
Notification of database updates is required not only for performing automatic updates of dealer databases, but alerting the Learning subsystem to changes in the dealer population, the product line, or the database structure. The subsystem will then adjust its population of data miners and learned behaviors appropriately.

13. Scenario 3: Impatient Customers
1. (Entry) Event service posts Brad’s DeferUpdateEvent on a subscribed channel.
2. Brad’s record notes this event and updates itself in the dealer update log.
3. Brad’s record also orders the behavior file to recommend an action.
4. (Exit) Based on previous events, the behavior file will later publish an UpdateReminderEvent.

14. Scenario 4.1: New Use Patterns
1. (Entry) The event service posts Klaus’s RemoteDBQuery on a subscribed channel.
2. Klaus’s record notes this event and updates itself in the dealer download log.
3. Klaus’s record also orders the behavior file to recommend an action.
4. (Exit) Based on previous events, the behavior file publishes an ItemToDealerCacheEvent.

15. Scenario 4.2: New Use Patterns
1. (Entry) The scheduler wakes up the dealer information mining agent.
2. The data miner analyzes the dealer download log.
3. (Exit) Based on its analysis, the data miner updates the recommendations in the behavior file.

16. Scenario 4.3: New Use Patterns
1. (Entry) The event service posts Klaus’s RemoteDBQuery on a subscribed channel.
2. Klaus’s record notes this event and updates itself in the dealer download log.
3. Klaus’s record also orders the behavior file to recommend an action.
4. (Exit) Based on previous events it has learned, the behavior file publishes an ItemToDealerDBEvent.

17. Scenario 5.1: Connection Costs
1. (Entry) The event service posts Sam’s event on a subscribed channel.
2. Sam’s record notes this event and updates itself in the appropriate log.
3. Sam’s record also orders the behavior file to recommend an action.
4. (Exit) Knowing that Sam’s connection is inexpensive, the behavior file publishes an event that does not minimize costs.

18. Scenario 5.2: Connection Costs
1. (Entry) The event service posts Klaus’s event on a subscribed channel.
2. Klaus’s record notes this event and updates itself in the appropriate log.
3. Klaus’s record also orders the behavior file to recommend an action.
4. (Exit) Knowing that Klaus’s connection is expensive, the behavior file publishes an event that tries to minimize costs.

19. Scenario 6: Mobile Garage
1. (Entry) The event service posts Brad’s request for Frank’s truck information on a subscribed channel.
2. The mobile repair record for that type of truck notes this event and updates itself in the mobile repair log.
3. Brad’s record also orders the behavior file to recommend an action.
4. (Exit) Based on previous mobile-garage situations with that type of truck, the behavior file publishes events to download the necessary files.

20. Learning Use Case Model

21. Open Issues Learning techniques not finalized
Learning subsystem allows easy interchange of modeling techniques
Relevant data not fully identified yet
Event service architecture not adequately modeled
Most likely provide wrapper for off-the-shelf event server
The Learning team has not decided whether it will choose a single machine-learning paradigm for all tasks, or whether it will allow several different learning methods as suits the task. The team’s design is sufficiently flexible to permit substitution of different techniques if some prove more useful than others. However, different techniques will lend themselves more naturally to monitoring different parameters, even when applied to the same task. The team is currently deciding what data are most useful for modeling transaction patterns, and whether these are better collected directly from the database (in the form of action triggers) or from published events.