Requirements Analysis

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

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 • Event • QueryEvent • DealerDBQuery • RemoteDBQuery • AuthenticationEvent • AuthenticationRequestEvent • AuthenticationApprovedEvent • AuthenticationDeniedEvent • TransactionEvent • ItemToDealerCacheEvent • ItemToDealerDBEvent • ItemToMasterDBEvent • ApplicationUpdateEvent • DeferUpdateEvent

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

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. LogDB DataMiner requestEventRecord updateBehavior analyzeBehavior logEvent submitEvent LearnedBehavior Scheduler modifyScheduler interceptEvent startDataMiner sendUpdateEvent EventRecord EventService timeOfEvent eventType eventDuration Learning Object Model

11. Learning Dynamic Model

12. Dependencies • Network and Database teams • System load • Database subsystem • Notification of database updates • User Interface subsystems • Dealer preferences panel • Administrative reports

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