UML Profile for DDS

2,708 views
2,525 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
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,708
On SlideShare
0
From Embeds
0
Number of Embeds
81
Actions
Shares
0
Downloads
164
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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!

×