Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

UML Profile for DDS

3,353 views

Published on

The OMG has recently standardized a UML Profile for DDS. This brief tutorial, which was presented at the OMG RTWS 2009, provides you with an introduction to the standard.

Published in: Technology, Business
  • Be the first to comment

UML Profile for DDS

  1. 1. UML Profile for DDS a tutorial for OMG Specification in Government Workshop (Real-Time & Embedded Systems) July 13, 2009 Prepared by: Sam Mancarella (Sparx Systems) Presented by: Angelo Corsaro (PrismTech)
  2. 2. Agenda • Part 1 - Introduction – DDS Overview – Motivating the UML4DDS • Part 2 – UML4DDS by Examples – DCPS – DLRL – Application Targets – MDA, PIM  PSM • Part 3 - Conclusion – Other Applications – Concluding Remarks – Discussion
  3. 3. The OMG Data Distribution Service (DDS) • DDS v1.2 API Standard – Language Independent, OS and HW Application architecture independent Object/Relational Mapping – DCPS. Standard API for Data-Centric, Data Local Reconstruction Layer (DLRL) Topic-Based, Real-Time Publish/ Subscribe Ownership Durability Content Subscription – DLRL. Standard API for creating Object Minimum Profile Views out of collection of Topics Data Centric Publish/Subscribe (DCPS) • DDSI/RTPS v2.1 Wire Protocol Real-Time Publish/Subscribe Protocol Standard DDS Interoperability Wire Protocol – Standard wire protocol allowing UDP/IP interoperability between different implementations of the DDS standard
  4. 4. High Performance Pub/Sub The right data, at the right place, at – Fully distributed, the right time Peer-to-Peer -- All the Time. Communication – No Single Point of Subscriber Publisher Failure – No Single Point of Publisher Broke Subscriber Bottleneck – Multicast-enabled Publisher Subscriber – High performance and highly scalable – High availability
  5. 5. Data-Centric Pub/Sub ‣ Data-Centric Features are built-in and don’t rely on an external DBMS ‣ Providing thus performance, scalability, and availability – Distributed Relational Data Model DBMS Subscriber – Local Queries Publisher – Continuous Queries / B m Content Based A F Subscriber Subscriptions Publisher J D C – Windows K E – Object/Relational Mapping Publisher – Support for a subset of Subscriber SQL-92 Perfect Blend of Data-Centric and Real-Time Publish/Subscribe Technologies
  6. 6. Topics and Data-Centric Pub/Sub Topic – Topics. Unit of information exchanged between Publisher and Subscribers. – Data Types. Type associated to a struct TempSensor { long tID; Topic must be a structured type float temp; expressed in IDL Topic Type float humidity; }; #pragma keylist TempSensor tID – Topic Instances. Key values in a datatype uniquely identify a Topic tID temp humidity Instance (like rows in table) 1 21 62 2 27 78 – Content Awareness. SQL 3 25.5 72.3 Expressions can be used to do content-aware subscriptions, SELECT * FROM TempSensor t WHERE t.temp > 25 queries, joins, and correlate topic instances tID temp humidity 2 27 78 3 25.5 72.3
  7. 7. Distributed Relational Information Modeling – Topic Keys can be used to identify instances as well as relationships – Relationships can be navigated by relying on a subset of SQL 92 – One-to-many relationships can be captured using foreign keys – Many-to-many relationships need to be modeled using a topics – Keys can be represented by an arbitrary number of Topic fields
  8. 8. Object/Relational Mapping – Automatically bridges the Object/Relational Impedance Mismatch – Arbitrary object reconstructions – Automatic Relationships Management – Inheritance – Local Operations – Local/Distributed State
  9. 9. Sample QoS Policies QoS Policy Applicability RxO Modifiable DURABILITY T, DR, DW Y N Data Type Matching DURABILITY T, DW N N Availability QoS matching SERVICE QoS QoS QoS QoS QoS QoS QoS Topic LIFESPAN T, DW - Y Publisher Name Subscriber ... DataWriter writes Type reads DataReader ... HISTORY T, DR, DW N N ... DomainParticipant DataWriter writes Type reads DataReader DomainParticipant PRESENTATION P, S Y N Data Name Topic RELIABILITY T, DR, DW Y N Delivery QoS QoS QoS PARTITION P, S N Y DESTINATION T, DR, DW Y N ORDER – Rich set of QoS allow OWNERSHIP T, DR, DW Y N to configure several OWNERSHIP DW - Y STRENGTH different aspects of DEADLINE T, DR, DW Y Y Data data availability, Timeliness LATENCY BUDGET T, DR, DW Y Y delivery and TRANSPORT T, DW - Y timeliness PRIORITY TIME BASED DR - Y Resources – QoS can be used to FILTER control and optimize RESOURCE T, DR, DW N N LIMITS network as well as USER_DATA DP, DR, DW N Y Configuratio computing resource TOPIC_DATA T N Y n GROUP_DATA P, S N Y
  10. 10. Overcoming the Challenges of DDS Design • DDS is a PIM – Provides a platform independent model of entities, roles and QoS Policies – PIM is mapped to specific implementations, or platform specific models (PSM) • Variety of software languages • Variety of runtime platforms • Variety of vendors Radar B m Sensor 1 A F Aircraft X J D Sensor n K E PDA Workstation Workstation
  11. 11. Overcoming the Challenges of DDS Design • Manage Complexity – Complex information models with QoS data • Heterogeneous Design – Different implementations, same information model • Reuse – Repository, Patterns • Change Management – One change in model  00’s changes in code
  12. 12. UML 4 DDS • A UML Profile designed for the analysis and design of object-oriented systems using Data Distribution Service technology. • Provides DDS designers, architects and practitioners with a standard, domain-specific modeling language to design DDS-based distributed information systems in a manner not specific to the underlying implementation of that design.
  13. 13. UML 4 DDS • Beta Specification: mars/2008-06-18 • Joint Submission by: – PrismTech – Real Time Innovations Inc – Sparx Systems • Request For Proposal: mars/2006-09-40
  14. 14. Model - Driven Architecture • Domain-Specific Modeling – Taxonomy of constructs, relationships, constraints – Notation, presentation, diagrams – MOF or UML mappings (UML Profiles) • PIM  PSM Transformation – Platform Independent Model transformed to Platform specific model automatically – One domain-specific model to another
  15. 15. Timeline – RFP Issued September, 2006 – First LOI November, 2006 – First Initial Submission March, 2007 – First Revised Submission September, 2007 – Second LOI October, 2007 – Second Initial Sub December, 2007 – Second Revised Sub February, 2008 – BoD Adoption June, 2008 – FTF Charter June, 2008 – FTF Report Due August 2009
  16. 16. Vendor Support • Sparx Systems – MDG Technology for DDS – Language Addin for Enterprise Architect – DDS-specific Toolboxes, Constructs, Diagrams – Automatically generates PSM code for OpenSplice & RTI DDS • Other DDS platform targets coming soon!
  17. 17. Language Architecture • Part 1 - UML Profile • Defines a collection of constructs that represent: – Data Centric Publish Subscribe Entites (+ QoS) – Data Local Reconstruction Layer • Introduced a collection of common constructs to define: – PSM Application Targets – Topic Data Types (IDL)
  18. 18. Language Architecture • Part 2 – Metamodel • Defines meta-level artifacts for XMI serialization
  19. 19. Worked Example - NetChat Stage 1 – DCPS-only Application Stage 2 – DLRL-Enabled
  20. 20. Designing DDS Systems
  21. 21. DDS Design Steps • Designing DDS-based system can be decomposed in the following few simple steps: – Step#1: Define Information Model – Step #2: Associate QoS representing key non- functional invariants for your system with the Information Model – Step #3: Define Topics / Partition / Domain Mapping – Step #4: Identify Topic Readers/Writers – Step #5: Define QoS requirements for Readers/Writers – Step #6: Bind the model to a specific PSM
  22. 22. NetChat Overview • Hypothetical, peer-to-peer network chat application • Two Components: – “ChatRoom” DDS Dataspace containing conversation threads amongst users – “Directory Server” Application to maintain a collection of active NetChat users • Real-world application of DDS DCPS and DLRL in distributed application designs
  23. 23. DDS Design Steps • Designing DDS-based system can be decomposed in the following few simple steps: – Step#1: Define Information Model – Step #2: Associate QoS representing key non- functional invariants for your system with the Information Model – Step #3: Define Topics / Partition / Domain Mapping – Step #4: Identify Topic Readers/Writers – Step #5: Define QoS requirements for Readers/Writers – Step #6: Bind the model to a specific PSM
  24. 24. DCPS Topics & Data Types • Data Types – Describes the data payloads for DCPS topics – IDL-based library – structs, unions, arrays
  25. 25. DCPS Topics & Data Types • Data Types – Describes the data payloads for DCPS topics – IDL-based library – structs, unions, arrays Attributes can be nominated as DCPS Key fields
  26. 26. DCPS Topics & Data Types • DDS Topics – Describes the DCPS characteristics of the published/ subscribe data type, constrained to QoS Policy
  27. 27. DCPS Topics & Data Types • DDS Topics – Describes the DCPS characteristics of the published/ subscribe data type, constrained to QoS Policy
  28. 28. DCPS Topics & Data Types • DDS Topics – Describes the DCPS characteristics of the published/ subscribe data type, constrained to QoS Policy ContentFilteredTopic, MultiTopic denoted by kind, expression tags
  29. 29. DDS Design Steps • Designing DDS-based system can be decomposed in the following few simple steps: – Step#1: Define Information Model – Step #2: Associate QoS representing key non- functional invariants for your system with the Information Model – Step #3: Define Topics / Partition / Domain Mapping – Step #4: Identify Topic Readers/Writers – Step #5: Define QoS requirements for Readers/Writers – Step #6: Bind the model to a specific PSM
  30. 30. DCPS – QoS Policy Library • qosPolicyLibrary Package – Top-Level Classifiers defining ‘default’ QoS Policies – Define sets of qosPolicyLibraries for domain-specific applications – Template of reusable QoS assets for multiple projects
  31. 31. DCPS – QoS Policy Library
  32. 32. DCPS – QoS Policy Library Defines QoS policy data as tagged values
  33. 33. DDS Design Steps • Designing DDS-based system can be decomposed in the following few simple steps: – Step#1: Define Information Model – Step #2: Associate QoS representing key non- functional invariants for your system with the Information Model – Step #3: Define Topics / Partition / Domain Mapping – Step #4: Identify Topic Readers/Writers – Step #5: Define QoS requirements for Readers/Writers – Step #6: Bind the model to a specific PSM
  34. 34. DCPS Domain & Entities • Domain Entity – Logical ‘grouping’ of DCPS Topics, & DomainParticipants
  35. 35. DCPS Domain & Entities • DomainParticipant Entity – DDS Publish/Subscribe entity
  36. 36. DCPS Domain & Entities • DomainParticipant Entity – Participate in domain nominated by tagged value
  37. 37. DCPS Domain & Entities • DomainParticipant Entity – Qos applied as properties, typed by the QoS Policy types in the qosPolicyLibrary
  38. 38. DDS Design Steps • Designing DDS-based system can be decomposed in the following few simple steps: – Step#1: Define Information Model – Step #2: Associate QoS representing key non- functional invariants for your system with the Information Model – Step #3: Define Topics / Partition / Domain Mapping – Step #4: Identify Topic Readers/Writers – Step #5: Define QoS requirements for Readers/Writers – Step #6: Bind the model to a specific PSM
  39. 39. DCPS Domain & Entities • Added Publisher, Subscriber Entities
  40. 40. DCPS Domain & Entities • Added DataReaders, DataWriters Entities
  41. 41. DCPS Domain & Entities DDS Topics connected to DataReaders & DataWriters
  42. 42. DDS Design Steps • Designing DDS-based system can be decomposed in the following few simple steps: – Step#1: Define Information Model – Step #2: Associate QoS representing key non- functional invariants for your system with the Information Model – Step #3: Define Topics / Partition / Domain Mapping – Step #4: Identify Topic Readers/Writers – Step #5: Define QoS requirements for Readers/Writers – Step #6: Bind the model to a specific PSM
  43. 43. Application Targets • ddsAppTarget – Binds one or more DomainParticipants to a PSM configuration
  44. 44. Application Targets • ddsAppTarget – Binds one or more DomainParticipants to a PSM configuration ‘usage’ Dependency binds the DomainParticipant to the Target
  45. 45. Application Targets • ddsAppTarget – Binds one or more DomainParticipants to a PSM configuration Tagged values specify the desired PSM output
  46. 46. Code (PSM) Generation Tool Specific: Enterprise Architect prompts the user to designate the application targets to a specific DDS output platform
  47. 47. Code (PSM) Generation
  48. 48. Code (PSM) Generation
  49. 49. Worked Example DLRL
  50. 50. Object/Relational Mapping – Automatically bridges the Object/Relational Impedance Mismatch – Arbitrary object reconstructions – Automatic Relationships Management – Inheritance – Local Operations – Local/Distributed State
  51. 51. DLRL: How does it Work? Concepts The mechanism at the foundation is a managed Object Cache: ‣ An Object Cache can be populated by different types (classes) of Objects. ‣ Each object class has its own manager called an ObjectHome. ‣ They can inform the application about object creation/modification/deletion. ‣ Classes may contain navigable relationships to other classes. ‣ Each Object class may inherit from 1 other Object class.
  52. 52. DLRL: How does it Work? DR DR DR OpenSplice DDS Information backbone Processing Updates ‣ ‘vanilla DDS’: updates arrive as separate samples at separate times. ‣ DDS Object Technology: updates are processed in ‘update rounds’: ‣ ObjectHomes read all available samples from the DDS information backbone and update their corresponding objects in the Cache accordingly. ‣ Objects are allocated once and their state is ‘overwritten’ on subsequent updates. ‣ Therefore an Object always contains the latest available state. ‣ Push mode: update rounds start when new data arrives. The application gets notified by Listeners. ‣ Pull mode: the application can determine the start of each update round manually.
  53. 53. Notification Patterns on_object_modified() on_object_created() attach_listener on_begin_ updates() attach_listener on_end_ updates() DR DR DR Application get_modified_objects() OpenSplice DDS Information backbone Notifying the application The Object Caches offer two ways to notify an application of incoming information: ‣ Listeners can be triggered for each modification of an object’s state. ‣ Listeners registered to the Cache indicate the start and end of each update round. ‣ Listeners registered to the ObjectHome pass each modification back as a callback argument. ‣ With a simple mechanism that can be translated into callbacks for Listeners on individual objects. ‣ It is possible to get a separate list of all objects that have been created/modified/deleted in the current update round.
  54. 54. CacheAccess: Examining Objects in Isolation DR DR DR DCPS Using snapshots Some applications want to be able to store temporal ‘snapshots’: ‣ A CacheAccess can be used to contain a temporal graph of objects. ‣ The graph is identified by a so-called ‘cloning contract’. ‣ Objects must physically be cloned from Cache to CacheAccess. ‣ A CacheAccesses is not automatically kept in sync with the main Cache. ‣ A ‘refresh’ operation can be used to resync the contents of CacheAccess with the contents of the main Cache.
  55. 55. CacheAccess: Modifying and Creating Objects DR DR DR DW DW DW DCPS Using snapshots Some applications want to be able to modify or create certain objects: ‣ An initial set of Objects may be cloned into a writeable CacheAccess. ‣ Available objects may then be modified locally. ‣ New objects can be created in the CacheAccess as well. ‣ The ‘write’ operation instructs the ObjectHomes to write any modifications into the system.
  56. 56. Using Selections to Manage Subsets S on_object_in() Application DR DR DR DCPS Creating and managing Selections A Selection mechanism can keep track of subsets of information: ‣ Selections are created and managed by the ObjectHomes. ‣ A Criterion plugged into a Selection determines the boundaries of a subset: ‣ A QueryCriterion determines boundaries based on an SQL statement. ‣ A FilterCriterion determines boundaries based on user-defined callback filters. ‣ Selections can notify the application when objects enter and leave it.
  57. 57. DLRL – Class & Type Mapping • dlrlClass – DLRL Class representing a subscribed DCPS Topic Type
  58. 58. DLRL – Class & Type Mapping • dlrlClass – DLRL Class representing a subscribed DCPS Topic Type
  59. 59. DLRL – Class & Type Mapping • dlrlAttribute – DLRL Attribute representing mapped DCPS Type fields
  60. 60. DLRL – Class & Type Mapping • relation – Association used to aggregate multiple classes using DLRL foreign keys
  61. 61. DLRL – Local Reconstruction • Cache – Describes a DLRL cache entity used to provide dlrl class access to the user
  62. 62. DLRL – Local Reconstruction • Cache – Describes a DLRL cache entity used to provide dlrl class access to the user DCPS ChatRoom DomainParticipant DLRL Classes
  63. 63. DLRL – Local Reconstruction • objectHome, topicManager – Binds the cache to DataReaders to access the specific DCPS Topic, Types
  64. 64. Application Targets • ddsAppTarget – Binds one or more DomainParticipants to a PSM configuration – Binds at most one DLRL cache to the PSM configuration
  65. 65. Conclusion & Wrap Up
  66. 66. Other Applications • Not just a DDS architecture description • Not just a PIM
  67. 67. Other Applications • XMI Serialization  Direct Deployment – XMI Document describes the DDS application configuration with Participants, Topics, QoS, etc – Configuration loaded by runtime to configure nodes – No source code
  68. 68. Other Applications • Visual Deployment Interface – DDS discovery to create a DDS model which visualizes a running deployment – Field Engineers interact with the DDS model to make changes to the deployment – Maintenance, re-engineering, documentation applications
  69. 69. Concluding Remarks • UML Profile for DDS exemplifies the co- operation of multiple OMG standards to: – Overcome the real-world challenges of design complexity management – Provide turnkey rapid-development solutions for DDS applications • Culmination of OMG’s – Real-time distributed data middleware technology – UML extensibility (domain-specific languages) – Model-Driven Development / Architecture – XML Metadata Interchange specifications
  70. 70. Concluding Remarks • Next Steps – Complete the FTF submission – Unleash to the world – promote industry adoption, drive market demand • For More information – Contact us • sam.mancarella@sparxsystems.com • angelo.corsaro@prismtech.com – Visit the Sparx exhibit for more information & demo
  71. 71. Thank you for your attention!

×