Interface Concepts Modeling Core Team Marc Sarrel Steve Hetfield June 23, 2016

Objectives Establish a set of requirements for a comprehensive concept model of interface as defined in the SEBoK: 1.A shared boundary between two functional units, defined by various characteristics pertaining to the functions, physical signal exchanges, and other characteristics. (ISO/IEC 1993) 2.A hardware or software component that connects two or more other components for the purpose of passing information from one to the other. (ISO/IEC 1993) 3.To connect two or more components for the purpose of passing information from one to the other. (ISO/IEC/IEEE 2009) Interface Concepts2

Starting Point Interface Concepts3

Limitations Lack of clear distinction between interface specification and interface realization. requirement vs. implementation distinction The inability to easily show different abstraction levels and views of the interface. Don’t want to carry redundant information in model. one-wire diagram from pin-to-pin information. “Level” (inferable) Inability to specify how an interface is decomposed in to layers that work together to meet the specification. logical vs. physical distinction, or protocol stack. “Layer” (not inferable) The ability to capture mechanical/geometric interconnections using an IBD is difficult and the result is not very intuitive. Limited ability to specify and enforce compatibility constraints between interface-ends. Internal Connectors – There is a need to be able to show a connector that connects two external ports of a component within the component Interface Concepts4

Specification vsRealization Interface Concepts5

Specification vsRealization Interface Concepts6

Levels of Abstraction Interface Concepts7 Possible to automatically create higher levels based on lower levels. High Level Low Level

Discussion - Levels of Abstraction Two ways to approach model inference for levels of abstraction. Infer and create elements in the model Use Viewpoints to generate views, not in the model First approach would require mechanism to clearly distinguish between user-asserted elements, and inferred elements. Like OWL. Rule based. SysML standard inference rules. User-definable rules. Inferred elements read only. Allows users to make assertions related to inferred elements. Regular re-validation to identify inferred elements that are no longer valid. Manage case where user starts at high level, and then works down. Don’t create inferred element if user has already asserted the result Interface Concepts8

Layers of an Interface Interface Concepts9 User must create all layers. No automatic creation possible.

Discussion - Layers Unlike levels, there is no inference possible between layers. Just because the lower level is Ethernet, doesn’t imply higher level is TCP/IP, and vice versa. Allows intermediate systems to exist at lower layers, but not upper. Hope to extend to kinds of interfaces other than software Mechanical, thermal, etc Interface Concepts10

Discussion - Other Re-use of blocks would be improved if there were a robust system of context-specific values for context blocks. Could re-use block for a router, and specify different values for the IP address value property. Serial number is another example application. Neither stereotype tagged values nor default values of properties work for this. Block specific type approach addresses problem, but doesn’t work well for re-use. CSVs could then appear on IBDs, PARs, etc. Base on UML instances – good tool support needed. Another idea would be better instance management tooling and instance diagrams equivalent to IBDs. Instances constrained to BDD/IBDs and validated regularly. Allows multiple designs that conform to BDD/IBDs Interface Concepts11

Driving Requirements Interface Concepts12

Derived Requirements Interface Concepts13

References Interface Concepts14