Use Case Tutorial - Lessons Learned (7/7)
Upcoming SlideShare
Loading in...5

Use Case Tutorial - Lessons Learned (7/7)



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

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



Total Views
Views on SlideShare
Embed Views



2 Embeds 13 12 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Use Case Tutorial - Lessons Learned (7/7) Use Case Tutorial - Lessons Learned (7/7) Presentation Transcript

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