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

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

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

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.

Event Services Architecture Learning Authentication Database User Interface Network Event Services

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

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.

Learning Architecture Database User Interface Learning Authentication Network Event Services

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

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

Learning Dynamic Model

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.

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.

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.

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.

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.

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.

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.

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.

Learning Use Case Model

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.