Use Case Tutorial - Lessons Learned (7/7)

1,533 views
1,411 views

Published on

Part 7 of 7 of the Use Case Tutorial presented at DEBS'2009 in Nashville, TN

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,533
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
98
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Use Case Tutorial - Lessons Learned (7/7)

  1. 1. Use Case TutorialLessons Learned<br />Pedro Bizarro on behalf of the group<br />
  2. 2. Lessons Learned<br />Architecture<br />Lesson 1: State-based event processing<br />Lesson 2: Incident objects<br />Lesson 3: Integration with other data management systems<br />Lesson 4: System of systems<br />Languages<br />Lesson 5: Query languages<br />Lesson 6: Classification and rules groups<br />Lesson 7: Customization<br />Glossary<br />Lesson 8: Changes to glossary<br />Use Cases<br />Lesson 9: Changes to questionnarie<br />Lesson 10: Better instructions on describing a use-case<br />
  3. 3. 3<br />Use Cases<br /><ul><li>Retail Fraud
  4. 4. Thomas Paulus (CITT)
  5. 5. Health Care
  6. 6. Pedro Bizarro, Diogo Guerra (U Coimbra), Dieter Gawlick (Oracle)
  7. 7. Fleet Management
  8. 8. Matthew Cooper (EventZero)
  9. 9. Very Large EPN – Bio-defense
  10. 10. Harvey G. Reed (MITRE) – Dieter on behalf of Harvey
  11. 11. BPM/BAM
  12. 12. Hans-Arno Jacobsen (University of Toronto)</li></li></ul><li>4<br />Expected next steps<br /><ul><li>Other EPTS groups review these lessons
  13. 13. Answer eventual questions and suggestions
  14. 14. Wait for each group to integrate/reject suggestions
  15. 15. Wait for other groups to provide initial recommendation/rework
  16. 16. Develop improved questionnaire</li></li></ul><li>State-based Event Processing(Architecture)<br />Lesson 1<br />5<br />
  17. 17. 6<br />State-based event processing<br />Need to know – in timely fashion – which<br />objects enter/exit specific states, overstay in a state<br />Problems:<br />“state” is undefined, interaction between events are state undef<br />Starting from different architecture views: state in DBMS, cache?<br />Fraud in Retail<br />Health Care<br />Transport Management<br />Very Large EPN (Bio-Defense)<br />BPM/BAM <br />
  18. 18. 7<br />State-based event processing – Fraud in Retail<br />Transaction data has to be captured in a database <br />States have to be derived based on the processed events (e.g., item released from shelf --&gt; state change) <br />State (un)changes can trigger timers(e.g., item longer than x minutes released and not payed) <br />Both state changes and timers can fire new events <br />
  19. 19. 8<br />State-based event processing – Health Care<br />All data is captured in a (temporal) database <br />Registered queries and Rules<br />Registered queries produce internal events on state changes<br />Those events used to fire rules, alarms, and new events<br />Being too long in a state represents an event <br />“Critical Temperature” event: above 42º for more than 10 minutes<br />“Critical Heart Rate” event: above 150 bpm for more than 1 minute<br />
  20. 20. 9<br />State-based event processing – Transport Management<br />Source events are used to build a model of the state of a system (e.g., state as in a business process) <br />Model may be built up over long periods of time (e.g., weeks, months)<br />Models need to be persistent<br />Two engines: for events, for data/state<br />Rules over state and time changes rather thanover the source events themselves<br />if state is still in low voltage state in 5 minutes time then generate alarm<br />If lights are off after current lighting up time then generate alarm<br />
  21. 21. 10<br />State-based event processing – Very Large EPN<br />Determine state from events<br />Associate level of severity to (derived) events<br />Derive state from severity<br />Different levels of bio-toxin / numbers of sick animals  different states of emergency different actions<br />
  22. 22. 11<br />State-based event processing – BPM/BAM<br />State changes should be detected by the CEP engine(&quot;events&quot; are updates on the state in the form of attribute-value pairs)<br />Databases used to support historic queries<br />to include “past events” to correlate with future events<br />
  23. 23. The Incident Object(Architecture)<br />Lesson 2<br />12<br />
  24. 24. The Incident Object<br />Internal data structures created from complex events to facilitate complex queries in the future<br />Capture relevant (updatable) information<br />Health Care<br />Fraud in Retail<br />Very Large EPN (Bio-Defense)<br />BPM/BAM <br />13<br />
  25. 25. The Incident Object – Health Care<br /> Created, updated and deleted in response to events<br />Can be updated by programs<br />Contains a set of properties and references<br />More important than events themselves<br />14<br />
  26. 26. The Incident Object<br />Fraud in Retail: Used to model fraud scenarios<br />Suspicious Customer object created from suspicious activity<br />BPM/BAM:<br />Incident Objects resultant from complex event subscriptions<br />Used to correlate with future events <br />15<br />
  27. 27. The Incident Object – Very Large EPN (Bio-defense)<br />“Interesting Translation” object<br />Otherwise “we end-up in a sea of data”<br />Needs to be acknowledged, verified (false-positive?)<br />Logged, auditable, queriable (OLAP)<br />Joins with raw data<br />16<br />
  28. 28. Integration with otherdata management systems(Architecture)<br />Lesson 3<br />17<br />
  29. 29. 18<br />Integration with other data management systems(Not about input/output adapters)<br />Core functionality and core data more naturallyhandled or stored in more than one system<br />Integrating multiple distinct systems(e.g., CEP, DBMS, DW, Data Mining)<br />Fraud in Retail<br />Health Care<br />BPM/BAM <br />Transport Management<br />
  30. 30. 19<br />Integration – Fraud in Retail<br />Database with business data<br />Event Processing: fraud management as parallel working system which monitors the business data<br />Can notify / influence / control active running business processes <br />Data Mining: used to identify fraud based on stored data <br />
  31. 31. 20<br />Integration – Health Care<br />Event processing as part of data management <br />Event processing provides timely awareness of information <br />Needs to support operational characteristics(e.g., reliability, availability, security, auditing, tracking) <br />Could also perceive event processing as a new operational characteristics: Timeliness (in acquiring information) <br />Integration with data mining: e.g., predict cardiac arrest<br />Integration with data warehousing: e.g., #of reintubations/day<br />Integration with (temporal) databases:e.g., keep complete record<br />
  32. 32. 21<br />Integration – BPM/BAM<br />Databases: to store past events/states<br />Databases: to store past incident objects<br />Integration – Transport Management<br /><ul><li>Databases: to store raw events
  33. 33. Databases: to store summary historical data</li></li></ul><li>System of systems(Architecture)<br />Lesson 4<br />22<br />
  34. 34. 23<br />System of systems<br />Multitude of systems, people, message types, sources, sinks, CEP engines<br />Different use cases reach different conclusions:<br />Use case questionnaire, architecture, glossary do not have enterprise-wide, system-of-systems perspective<br />System-of-systems no different than single system<br />Fraud in Retail<br />Very Large EPN (Bio-Defense)<br />BPM/BAM <br />
  35. 35. 24<br />System of Systems – Fraud in Retail<br />Retail infrastructure naturally decentralized <br />Multiple event processing nodes for local data processing<br />Centralized event processing or storage is necessary<br />Still, no special problem in having system of systems<br />
  36. 36. 25<br />System of Systems – BPM/BAM<br />Event processing carried out in multiple places<br />But still provides point-processing black-box view<br />“joining multiple systems is no different than creating a single system”<br />Hundreds of nodes<br />Assume buffer to re-order out-of-order events<br />
  37. 37. 26<br />System of Systems – Very Large EPN<br />Very Large Event Processing Networks typical of large goverment activities<br />Multitude of systems, people, message types, sources, sinks, CEP engines<br />Peer-to-peer and hierarchical relationships<br />Build for growth/extension: must have clear interfaces<br />Parallel building and parallel extending<br />Need to reconcile CEP with persistence<br />E.g., filtering subscribers based on matching content with Identity, and corresponding fine-grained authorization<br />E.g., filtering out subscribers who fail to meet geo-tagging/proximity tests<br />Crosses system boundaries (on need-to-know basis), different units/timezones/coordinates<br />Which police car(s) should go to some emergency?<br />Should glossary include these differences?<br />
  38. 38. Query Languages(Language)<br />Lesson 5<br />27<br />
  39. 39. 28<br />Query Languages<br />Rules: to support ECA paradigm<br />Continuous queries: stream-based CEP<br />Registered queries: state-based CEP<br />Data mining models: predictions (non-hypothesis driven)<br />Health Care<br />Fraud in Retail<br />Very Large EPN – Bio-defense<br />
  40. 40. Query Languages – Health Care<br />Registered queries: check when state changes<br />E.g., is heart rate different?<br />Rules: check combination of conditions, fires alarms<br />E.g., is heart rate above 150 bpm for more than 1 minute?<br />Data mining models: focused on predictions <br />E.g., predict cardiac arrest<br />Should be embedded in any query language used<br />Scoring<br />Need alignment of query and event language <br />29<br />
  41. 41. Query Languages – Fraud in Retail<br />System listens to all events to detect fraud<br />Detect fraud attempts based on pre-defined fraud scenarios<br />Scenarios can be modeled with continuous queries, rules, data mining, or graph modeling tools.<br />Query Languages – Transport Management<br />Needs language to manipulate/react/query state<br />set low voltage state if below threshold<br />Need alignment between event engine and database<br />Retrieve a trucks current and past stat<br />30<br />
  42. 42. Query Languages – Very Large EPN<br />Needs new Pub/Sub view-oriented subscription language<br />Creates necessary level of abstraction to relate to the Publisher Cloud regardless of where view is materialized<br />E.g., Event Processing or Data Warehousing<br />Subscriptions identify the set of views<br />Each view is identified by<br />unique combination of dimensions<br />unique constraints applied to the dimensions<br />and, if applicable, dimension hierarchies.<br />31<br />
  43. 43. Classification and Groups(Language)<br />Lesson 6<br />32<br />
  44. 44. 33<br />Classifications and Groups<br />Classifications and groups used to climb-up abstraction level<br />Classifications buried in application code<br />Health Care<br />
  45. 45. 34<br />Classifications and Groups – Health Care<br />150 bpm<br />Is it an emergency?<br />OK!<br />Emergency!!<br />
  46. 46. 35<br />Classifications and Groups – Health Care<br />Alert a doctor if:<br />blood value is rapidly deteriorating<br />Oxygen level in serious level or above<br />What is rapidly?<br />What is the seriouslevel? <br />What isabove the serious level?<br />Fire rule if one red-rule fires,<br />or three orange-rules, or five black-rules<br />Think about<br />Consumption and<br />Precedence<br />
  47. 47. Customization(Language)<br />Lesson 7<br />36<br />
  48. 48. Customization – Health Care<br />A patient with a cardiac condition and a patient without a cardiac condition;<br />A male baby with high heart rate and a female senior with high heart rate;<br />A patient that started to have high fever and a patient that has had high fever more than 30 minutes.<br />Precedence needed for:<br />Universal Rules (for all patients)<br />For a specific patient<br />For a specific doctor<br />For a specific patient-doctor<br />37<br />
  49. 49. Customization – Fraud in Retail<br />The customer should easily:<br />add/remove/de-/activate fraud scenarios<br />Stores should be able to override default rules<br />38<br />
  50. 50. Talking about event processing(Glossary)<br />Lesson 8<br />39<br />
  51. 51. 40<br />Glossary<br />Definitions that need work<br />Types of event processing<br />Events / messages / alerts<br />States / state-transitions<br />Online scoring<br />Classification<br />Incident object<br />Remove references to timeWhat time to use? Application? Import? Wall-clocks?<br />Glossary has to be based on reference architecture<br />
  52. 52. Changes to Questionnaire(USE CASES)<br />Lesson 9<br />41<br />
  53. 53. Changes to Questionnaire<br />Entice responders to provide measurable characteristics and evidence (e.g. exact/approximate event rates, event size, etc.)<br />Responses should be precise enough to serve as basis for developing benchmarks.<br />System of systems approach<br />Is it too long?<br />42<br />
  54. 54. Describing Use Cases (USE CASES)<br />Lesson 10<br />43<br />
  55. 55. Describing Use Cases<br />Group should define guidelines for structuring use case presentations<br />44<br />
  56. 56. If you want to participate in these discussions, contribute to this topic and/or others topics, and be part of the community effort to advance the state of the art and state of the practice:<br />JOIN EPTS<br />For details:http://www.ep-ts.com/<br />

×