際際滷

際際滷Share a Scribd company logo

Automating System-Level Data-Interchange Software through a System Interface Description Language

Martin Tapp
Martin Tapp

This document presents a PhD thesis defense by Martin Tapp on automating system-level data-interchange software through a system interface description language (SIDL). The thesis proposes SIDL as a domain-specific language to formally describe system interfaces and data exchanges in a machine-processable way. SIDL addresses challenges in system integration and interoperability such as data compatibility, representation compatibility, and interface evolution. It captures multi-architecture considerations and enables automation of data-interchange software generation from SIDL descriptions through a two-stage modeling and code generation workflow. The thesis is validated using representative test cases and experimental results demonstrate the generation of fully functional data-interchange software from SIDL models.

1 of 48
Download to read offline
AUTOMATING SYSTEM-LEVEL DATA-INTERCHANGE SOFTWARE THROUGH A SYSTEM INTERFACE DESCRIPTION LANGUAGE PRESENTED BY MARTIN TAPP DEPARTMENT OF COMPUTER ENGINEERING DECEMBER 2, 2013 Ph.D. Thesis Defense
Full Mission Simulator Platforms Context 2 Enable Better System: Integration | Interoperability Focus: System Interfaces | Data Exchanges
Multi-Architecture Environment Background 3
Problem Statement System Integration | Interoperability Challenges 4 Data Compatibility Units: Radians vs. Degrees Frame of Reference: Geodetic vs. Geocentric Data Representation Compatibility Structure: Protocol peculiarities (e.g. Objects vs. Messages) Duplicated Definitions: Copy in each architecture
Problem Statement (cont.) System Integration | Interoperability Challenges 5 System Interface: Evolution | Governance Change Introduction: Complex Impact Prediction + Validation What changed? Change occurs in which architecture? Link between each architecture representation? Common Language: Common Understanding between Stakeholders Unambiguously Capture: System Interfaces | Data Exchanges Machine-Processable System Interface Descriptions
Research Questions 6 Q1 Q2 What should be Formally Described in Order to Capture System Interfaces and the Various Aspects Surrounding their Data Exchanges, and How? How should Multi-Architecture Considerations be Captured? Q3 How should System Interface Descriptions be Used to Automate Some of the Tasks Involved in System Integration and Interoperability?
Proposal 7 System Interface Description Language (SIDL) Addresses Q1 (What + How) What: Relevant language elements identified How: Domain-Specific Language Q2 (Multi-Architecture Considerations) Architecture-Agnostic: From SIDL to specific architectures
Proposal (cont.) 8 Method to Automate the System-Level Data-Interchange Software from System Interface Descriptions Addresses Q3 (Automate) SIDL Model Compiler + Code Generation Data Model Data Serialization Communication Interface
Why a Domain-Specific Language (DSL)? Hiding Software Complexity 9 In the language of its stakeholders Can treat model as source code [Llorente] Scales better than UML [Eysholdt] Simplifies Change Identification [Eysholdt] Compiler enables: Strong Semantics + Validation + Code Generation [Wang]
System Interoperability Facets Taxonomy Basis 10
SIDL Conceptual Model Language Elements 11
Capturing System Interface Descriptions Related Work 12 HLA OMT Interface Data Connection WSDL IDL FACE AADL Transport Multi-Architecture Considerations Complex Validation Rules Change Identification WSDL: Similarity between Services and Systems SIDL
Defining Systems Interfaces Interface Facet 13 Port: input or output data Data type specified with of system RadarSensor: input Entities of Entity output RadarCrossSections of RcsList ... RCS: Radar Cross Section Entities port inputs Entity messages
Defining Data Types Data Facet 14 entity: structure with fields entity Entity: EntityIdentifier as EntityIdentifier RcsSignatureIndex as short ... Fields representation specified with as Value types: integers, floating points chars, strings booleans enumerations
Abstract Level Data Facet 15 Could define EntityIdentifier this way entity EntityIdentifier: Site as ushort AppId as ushort EntId as ushort Context: Multi-Architecture | Heterogeneous Systems How do we relate EntityIdentifier to other kinds of identity? Data models contain many What if identity is represented in other ways? Different size (8bit, 64bit, 128bit) Different structure (UUID, GUID, 4 integers)
Abstract Level (cont.) Data Facet 16 Lets raise the abstract level info: something descriptive in nature fact: concrete info representation Specific identity representation info Name info Description info UniqueIdentity Links all identity representations together fact EntityIdentifier of UniqueIdentity Site as ushort AppId as ushort EntId as ushort fact OtherIdentity of UniqueIdentity Id as uint
Abstract Level (cont.) Data Facet 17 Going further observable: something quantified through physical world measurement measure: concrete observable representation with frame | unit Specific angle representation observable Orientation observable Angle unit Radian frame TrueNorth Links all angle representations together measure AngleRadian of Angle as single: units Radian frame TrueNorth precision 0.000001
Abstract Level (cont.) Data Facet 18 What if a systems interface is not aligned with a reference data model? view: window over one or more entity Specific interest Adapt name Enables System Interface Adaptation view BeamAntennaDegrees: select BeamAntennaStruct.AzimuthWidth as AngleDegree select BeamAntennaStruct.ElevationWidth as AngleDegree view AppAndWideEntityNumber: select EntityIdentifier.AppId select EntityIdentifier.EntId as uint: alias EntityNumber Adapt unit Adapt data representation
Connecting Systems Together Connection Facet 19 bus RadarSystemBus: ... channel Detections of DetectionList: connect RadarProcessor.Detections connect RadarDisplay.Detections Channels connect system ports together
Specifying Protocol Details Transport Facet 20 binding: captures bus protocol details Captures architecture-specific considerations (Q2) binding HlaBinding of RadarSystemBus as HLA.Protocol1516_2010: channels: encode DetectionList as HLA.objectClass Common channel details Specific channel details Describe encoding qos: Reliability = BestEffort channel Detections: qos DetectionList.Items: Reliability = Reliable Specify protocol Describe quality of service (QoS) bus RadarSystemBus: ... channel Detections of DetectionList: connect RadarProcessor.Detections connect RadarDisplay.Detections
Specifying How to Access a Bus Transport Facet 21 network: provides bus access through endpoints network RadarSystemNetwork of RadarSystemBus: endpoint Hla of HlaBinding binding describes how data is exchanged network describes where to access it
Using SIDL Descriptions 22 System implementations refer to specific system | endpoint Unambiguously Captures System Interfaces | Data Exchanges system: Covers Interface | Data endpoint: Covers Transport | Connection Can completely derive the data-interchange software
Data-Interchange Software Automation 23 Two-Stage Workflow Modeling Code Generation Why not One-Stage? Prevents reusing SIDL descriptions directly i.e. reuse library vs. share source code
Modeling Stage Data-Interchange Software Automation 24 What Know-How How SIDL Description(s) SIDL Libraries SIDL Model Compiler SIDL Library Element definitions used in SIDL libraries
Code Generation Stage Data-Interchange Software Automation 25 What System + Endpoint + Settings SIDL Libraries Shared with Modeling Stage Target language e.g. C++, C# Know-How SIDL Code Generator How System-Level Data-Interchange Software Protocol support + code gen. simplification
Validation Strategy 26 Identify use cases with Subject Matter Experts (SMEs) Implement test cases composed of test systems Define language with SMEs Prototype language implementation Model test systems in SIDL Generate data-interchange software Refactor test systems accordingly Validate test cases Improve language from SME feedback Iterate again if Use cases not achieved Data-interchange software requires manual intervention
Discussion 27 Introduced System Interoperability Facets Prior: Levels of Conceptual Interoperability Model [Tolk] Characterized attainable levels of interoperability between systems Proposed New Taxonomy Common language shared by stakeholders
Discussion (cont.) 28 Simplified Validation | Evolution | Governance Dedicated language to describing system interfaces Captured Multi-Architecture Considerations Architecture-Agnostic Format Specific details captured with binding | network | endpoint
Discussion (cont.) 29 Automated the System-Level Data-Interchange Software Generated test cases entirely from SIDL descriptions Architecture-agnostic code generator System Interface, Data Model, Serialization, Architecture-Specific Artifacts Multi-architecture considerations natively captured in SIDL Enabled System Interface Reuse Modeled system interface variability with views Enable system reuse across multiple platforms in support of product lines
Limitations 30 More than Semantic SIDL covers up to Semantic Level of Conceptual Interop. Model [Tolk] Conversion Modeling view support limited to language side Higher levels would enable further System Interoperability | Automation Requires new language elements to cover conversions Configuration in Support of Modeling Information not captured by SIDL left as configuration data E.g. communication middleware configuration Derive new elements only when What to capture in SIDL? Standardized Impact system interoperability in uniform way
Conclusion 31 Problem of formally describing system interfaces Can be generalized to other domains Operational systems: e.g. Aerospace, Automotive Enabled Better System: Integration | Interoperability
Capturing Data Model Mappings Future Work 32 Simplify Gateway Creation Provide architecture-agnostic way of specifying mappings (i.e. Interoperability logic)
Workflow-Driven Development Future Work 33 -Hardware-Aware Software -Legacy Assets Integration Know-How What How -Multi-Language Integration -Debugging at the DSL Level
Questions? 34 Thank You!
References 35 Llorente Eysholdt Moritz Eysholdt and Johannes Rupprecht, "Migrating a large modeling environment from XML/UML to Xtext/GMF," in Proceedings of the ACM international conference companion on Object oriented programming systems languages and applications companion, 2010, pp. 97-104. Wang C辿sar de la Torre Llorente, "Model-Driven SOA with Oslo," The Architecture Journal, vol. 21, pp. 10-15, 2009. Wenguang Wang, Andreas Tolk, and Weiping Wang, "The levels of conceptual interoperability model: Applying systems engineering principles to M&S," in Proceedings of the 2009 Spring Simulation Multiconference, San Diego, 2009. Tolk Andreas Tolk, Charles Turnitsa, and Saikou Diallo, "Implied ontological representation within the levels of conceptual interoperability model," Intelligent Decision Technologies, vol. 2, no. 1, pp. 3-19, February 2008.
References (cont.) 36 HLA OMT WSDL "Technical Standard for Future Airborne Capability Environment (FACE), Edition 2.0," The Open Group, C137, 2013. [Online]. https://www2.opengroup.org/ogsys/catalog/c137 DDS "Architecture Analysis & Design Language (AADL)," SAE, AS5506, 2012. [Online]. http://standards.sae.org/as5506b FACE "Interface Definition Language (IDL) 3.5," Object Management Group, IDL35, 2013. [Online]. http://www.omg.org/spec/IDL35 AADL "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language," W3C, wsdl20, 2007. [Online]. http://www.w3.org/TR/wsdl20 IDL "IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) Object Model Template (OMT) Specification," IEEE, IEEE Std 1516.2-2010, 2010. "Data Distribution Service for Real-time Systems Version 1.2," Object Management Group, formal/0701-01, 2007. DIS "IEEE Standard for Distributed Interactive Simulation-Application Protocols," IEEE, IEEE Std 1278.12012, 2012.
Simulation Background 37 Aircraft Behavior Position Velocity Acceleration Aircraft object Interaction
Distributed Simulation Background 38
Stakeholder Perspectives System Integration | Interoperability Challenges 39 System Integrators Heterogeneous System Interfaces Multiple Suppliers System Suppliers Heterogeneous Platforms Reuse System Across Multiple Platforms (i.e. Enable Product Line Support)
System Interoperability Facets Taxonomy Basis 40 Interface Transport | Data Connection
SIDL Data Model 41
Radar System Example 42 Lets express this in SIDL (RCS = Radar Cross Section)
Modeling Stage Implementation 43 What SIDL Description (SharpDevelop Editor) Know-How SIDL Description Compiler (Boo) How SIDL Library (.NET)
Code Generation Stage Implementation 44 What System + Endpoint + Settings SIDL Libraries (.NET) Know-How SIDL Code Generator (C#) How System Interface (C++, C#)
Test Cases Experimental Results 45 Colliding Balls Ownership Transfer Representative distributed system Typical distributed sim. function Gateway Multi-architecture test case
Automating System-Level Data-Interchange Software Experimental Results 46 Fully generated data-interchange software from SIDL System Interface | Data Model | Data Serialization Architecture-Specific Artifacts C++ | C# Data Model Representations: HLA OMT | DDS IDL Protocol HLA | DDS | DIS
SIDL Modeling SME Feedback Experimental Results 47 Minus Better code + SIDL integration: two development environments No code completion + better syntax highlighting Integrate SIDL in code development environment Support present except not implemented Array syntax Some did not like it Lacks lower bounds
SIDL Modeling SME Feedback (cont.) Experimental Results 48 Plus SIDL as source code Easier understanding of model evolution Same revision control system and comparison tool Meaningful validation errors | Strong semantics Code Generation Breaking changes easily pinpointed (both for Modeling + Code Generation) Increased efficiency as focus not on data-interchange software Multi-architecture peculiarities dealt in uniform way System experts could delegate network and binding to integrators

More Related Content

Automating System-Level Data-Interchange Software through a System Interface Description Language

  • 1. AUTOMATING SYSTEM-LEVEL DATA-INTERCHANGE SOFTWARE THROUGH A SYSTEM INTERFACE DESCRIPTION LANGUAGE PRESENTED BY MARTIN TAPP DEPARTMENT OF COMPUTER ENGINEERING DECEMBER 2, 2013 Ph.D. Thesis Defense
  • 2. Full Mission Simulator Platforms Context 2 Enable Better System: Integration | Interoperability Focus: System Interfaces | Data Exchanges
  • 4. Problem Statement System Integration | Interoperability Challenges 4 Data Compatibility Units: Radians vs. Degrees Frame of Reference: Geodetic vs. Geocentric Data Representation Compatibility Structure: Protocol peculiarities (e.g. Objects vs. Messages) Duplicated Definitions: Copy in each architecture
  • 5. Problem Statement (cont.) System Integration | Interoperability Challenges 5 System Interface: Evolution | Governance Change Introduction: Complex Impact Prediction + Validation What changed? Change occurs in which architecture? Link between each architecture representation? Common Language: Common Understanding between Stakeholders Unambiguously Capture: System Interfaces | Data Exchanges Machine-Processable System Interface Descriptions
  • 6. Research Questions 6 Q1 Q2 What should be Formally Described in Order to Capture System Interfaces and the Various Aspects Surrounding their Data Exchanges, and How? How should Multi-Architecture Considerations be Captured? Q3 How should System Interface Descriptions be Used to Automate Some of the Tasks Involved in System Integration and Interoperability?
  • 7. Proposal 7 System Interface Description Language (SIDL) Addresses Q1 (What + How) What: Relevant language elements identified How: Domain-Specific Language Q2 (Multi-Architecture Considerations) Architecture-Agnostic: From SIDL to specific architectures
  • 8. Proposal (cont.) 8 Method to Automate the System-Level Data-Interchange Software from System Interface Descriptions Addresses Q3 (Automate) SIDL Model Compiler + Code Generation Data Model Data Serialization Communication Interface
  • 9. Why a Domain-Specific Language (DSL)? Hiding Software Complexity 9 In the language of its stakeholders Can treat model as source code [Llorente] Scales better than UML [Eysholdt] Simplifies Change Identification [Eysholdt] Compiler enables: Strong Semantics + Validation + Code Generation [Wang]
  • 12. Capturing System Interface Descriptions Related Work 12 HLA OMT Interface Data Connection WSDL IDL FACE AADL Transport Multi-Architecture Considerations Complex Validation Rules Change Identification WSDL: Similarity between Services and Systems SIDL
  • 13. Defining Systems Interfaces Interface Facet 13 Port: input or output data Data type specified with of system RadarSensor: input Entities of Entity output RadarCrossSections of RcsList ... RCS: Radar Cross Section Entities port inputs Entity messages
  • 14. Defining Data Types Data Facet 14 entity: structure with fields entity Entity: EntityIdentifier as EntityIdentifier RcsSignatureIndex as short ... Fields representation specified with as Value types: integers, floating points chars, strings booleans enumerations
  • 15. Abstract Level Data Facet 15 Could define EntityIdentifier this way entity EntityIdentifier: Site as ushort AppId as ushort EntId as ushort Context: Multi-Architecture | Heterogeneous Systems How do we relate EntityIdentifier to other kinds of identity? Data models contain many What if identity is represented in other ways? Different size (8bit, 64bit, 128bit) Different structure (UUID, GUID, 4 integers)
  • 16. Abstract Level (cont.) Data Facet 16 Lets raise the abstract level info: something descriptive in nature fact: concrete info representation Specific identity representation info Name info Description info UniqueIdentity Links all identity representations together fact EntityIdentifier of UniqueIdentity Site as ushort AppId as ushort EntId as ushort fact OtherIdentity of UniqueIdentity Id as uint
  • 17. Abstract Level (cont.) Data Facet 17 Going further observable: something quantified through physical world measurement measure: concrete observable representation with frame | unit Specific angle representation observable Orientation observable Angle unit Radian frame TrueNorth Links all angle representations together measure AngleRadian of Angle as single: units Radian frame TrueNorth precision 0.000001
  • 18. Abstract Level (cont.) Data Facet 18 What if a systems interface is not aligned with a reference data model? view: window over one or more entity Specific interest Adapt name Enables System Interface Adaptation view BeamAntennaDegrees: select BeamAntennaStruct.AzimuthWidth as AngleDegree select BeamAntennaStruct.ElevationWidth as AngleDegree view AppAndWideEntityNumber: select EntityIdentifier.AppId select EntityIdentifier.EntId as uint: alias EntityNumber Adapt unit Adapt data representation
  • 19. Connecting Systems Together Connection Facet 19 bus RadarSystemBus: ... channel Detections of DetectionList: connect RadarProcessor.Detections connect RadarDisplay.Detections Channels connect system ports together
  • 20. Specifying Protocol Details Transport Facet 20 binding: captures bus protocol details Captures architecture-specific considerations (Q2) binding HlaBinding of RadarSystemBus as HLA.Protocol1516_2010: channels: encode DetectionList as HLA.objectClass Common channel details Specific channel details Describe encoding qos: Reliability = BestEffort channel Detections: qos DetectionList.Items: Reliability = Reliable Specify protocol Describe quality of service (QoS) bus RadarSystemBus: ... channel Detections of DetectionList: connect RadarProcessor.Detections connect RadarDisplay.Detections
  • 21. Specifying How to Access a Bus Transport Facet 21 network: provides bus access through endpoints network RadarSystemNetwork of RadarSystemBus: endpoint Hla of HlaBinding binding describes how data is exchanged network describes where to access it
  • 22. Using SIDL Descriptions 22 System implementations refer to specific system | endpoint Unambiguously Captures System Interfaces | Data Exchanges system: Covers Interface | Data endpoint: Covers Transport | Connection Can completely derive the data-interchange software
  • 23. Data-Interchange Software Automation 23 Two-Stage Workflow Modeling Code Generation Why not One-Stage? Prevents reusing SIDL descriptions directly i.e. reuse library vs. share source code
  • 24. Modeling Stage Data-Interchange Software Automation 24 What Know-How How SIDL Description(s) SIDL Libraries SIDL Model Compiler SIDL Library Element definitions used in SIDL libraries
  • 25. Code Generation Stage Data-Interchange Software Automation 25 What System + Endpoint + Settings SIDL Libraries Shared with Modeling Stage Target language e.g. C++, C# Know-How SIDL Code Generator How System-Level Data-Interchange Software Protocol support + code gen. simplification
  • 26. Validation Strategy 26 Identify use cases with Subject Matter Experts (SMEs) Implement test cases composed of test systems Define language with SMEs Prototype language implementation Model test systems in SIDL Generate data-interchange software Refactor test systems accordingly Validate test cases Improve language from SME feedback Iterate again if Use cases not achieved Data-interchange software requires manual intervention
  • 27. Discussion 27 Introduced System Interoperability Facets Prior: Levels of Conceptual Interoperability Model [Tolk] Characterized attainable levels of interoperability between systems Proposed New Taxonomy Common language shared by stakeholders
  • 28. Discussion (cont.) 28 Simplified Validation | Evolution | Governance Dedicated language to describing system interfaces Captured Multi-Architecture Considerations Architecture-Agnostic Format Specific details captured with binding | network | endpoint
  • 29. Discussion (cont.) 29 Automated the System-Level Data-Interchange Software Generated test cases entirely from SIDL descriptions Architecture-agnostic code generator System Interface, Data Model, Serialization, Architecture-Specific Artifacts Multi-architecture considerations natively captured in SIDL Enabled System Interface Reuse Modeled system interface variability with views Enable system reuse across multiple platforms in support of product lines
  • 30. Limitations 30 More than Semantic SIDL covers up to Semantic Level of Conceptual Interop. Model [Tolk] Conversion Modeling view support limited to language side Higher levels would enable further System Interoperability | Automation Requires new language elements to cover conversions Configuration in Support of Modeling Information not captured by SIDL left as configuration data E.g. communication middleware configuration Derive new elements only when What to capture in SIDL? Standardized Impact system interoperability in uniform way
  • 31. Conclusion 31 Problem of formally describing system interfaces Can be generalized to other domains Operational systems: e.g. Aerospace, Automotive Enabled Better System: Integration | Interoperability
  • 32. Capturing Data Model Mappings Future Work 32 Simplify Gateway Creation Provide architecture-agnostic way of specifying mappings (i.e. Interoperability logic)
  • 33. Workflow-Driven Development Future Work 33 -Hardware-Aware Software -Legacy Assets Integration Know-How What How -Multi-Language Integration -Debugging at the DSL Level
  • 35. References 35 Llorente Eysholdt Moritz Eysholdt and Johannes Rupprecht, "Migrating a large modeling environment from XML/UML to Xtext/GMF," in Proceedings of the ACM international conference companion on Object oriented programming systems languages and applications companion, 2010, pp. 97-104. Wang C辿sar de la Torre Llorente, "Model-Driven SOA with Oslo," The Architecture Journal, vol. 21, pp. 10-15, 2009. Wenguang Wang, Andreas Tolk, and Weiping Wang, "The levels of conceptual interoperability model: Applying systems engineering principles to M&S," in Proceedings of the 2009 Spring Simulation Multiconference, San Diego, 2009. Tolk Andreas Tolk, Charles Turnitsa, and Saikou Diallo, "Implied ontological representation within the levels of conceptual interoperability model," Intelligent Decision Technologies, vol. 2, no. 1, pp. 3-19, February 2008.
  • 36. References (cont.) 36 HLA OMT WSDL "Technical Standard for Future Airborne Capability Environment (FACE), Edition 2.0," The Open Group, C137, 2013. [Online]. https://www2.opengroup.org/ogsys/catalog/c137 DDS "Architecture Analysis & Design Language (AADL)," SAE, AS5506, 2012. [Online]. http://standards.sae.org/as5506b FACE "Interface Definition Language (IDL) 3.5," Object Management Group, IDL35, 2013. [Online]. http://www.omg.org/spec/IDL35 AADL "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language," W3C, wsdl20, 2007. [Online]. http://www.w3.org/TR/wsdl20 IDL "IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) Object Model Template (OMT) Specification," IEEE, IEEE Std 1516.2-2010, 2010. "Data Distribution Service for Real-time Systems Version 1.2," Object Management Group, formal/0701-01, 2007. DIS "IEEE Standard for Distributed Interactive Simulation-Application Protocols," IEEE, IEEE Std 1278.12012, 2012.
  • 39. Stakeholder Perspectives System Integration | Interoperability Challenges 39 System Integrators Heterogeneous System Interfaces Multiple Suppliers System Suppliers Heterogeneous Platforms Reuse System Across Multiple Platforms (i.e. Enable Product Line Support)
  • 40. System Interoperability Facets Taxonomy Basis 40 Interface Transport | Data Connection
  • 42. Radar System Example 42 Lets express this in SIDL (RCS = Radar Cross Section)
  • 43. Modeling Stage Implementation 43 What SIDL Description (SharpDevelop Editor) Know-How SIDL Description Compiler (Boo) How SIDL Library (.NET)
  • 44. Code Generation Stage Implementation 44 What System + Endpoint + Settings SIDL Libraries (.NET) Know-How SIDL Code Generator (C#) How System Interface (C++, C#)
  • 45. Test Cases Experimental Results 45 Colliding Balls Ownership Transfer Representative distributed system Typical distributed sim. function Gateway Multi-architecture test case
  • 46. Automating System-Level Data-Interchange Software Experimental Results 46 Fully generated data-interchange software from SIDL System Interface | Data Model | Data Serialization Architecture-Specific Artifacts C++ | C# Data Model Representations: HLA OMT | DDS IDL Protocol HLA | DDS | DIS
  • 47. SIDL Modeling SME Feedback Experimental Results 47 Minus Better code + SIDL integration: two development environments No code completion + better syntax highlighting Integrate SIDL in code development environment Support present except not implemented Array syntax Some did not like it Lacks lower bounds
  • 48. SIDL Modeling SME Feedback (cont.) Experimental Results 48 Plus SIDL as source code Easier understanding of model evolution Same revision control system and comparison tool Meaningful validation errors | Strong semantics Code Generation Breaking changes easily pinpointed (both for Modeling + Code Generation) Increased efficiency as focus not on data-interchange software Multi-architecture peculiarities dealt in uniform way System experts could delegate network and binding to integrators