Allow replacement (override) of connection declarations in extensions

[reteprelief]

Issue: It is a useful capability to extend an implementation and then refine some of its connections so they route through new subcomponents added in the extension. For example, a connection between components A and B might be refined by re-routing from A to a new Filter subcomponent and then adding a connection from that Filter to B. A more elaborate version of this would be to allow a connection to be refined to a flow as long as the flow source and destination denote the same features as the refined connection. There also appear to be some inconsistencies in the standard. Section 9.1 (N1) and section 9.2 (N1) talk about connection refinement referencing the source or destinations of the refined declaration, but the grammar does not seem to permit any reference to the actual feature-to-feature connection part. A comment in the example of section 9.5 says feature group connection refinements may only add properties and that the actual feature-to-feature connection part does not have to be repeated. The grammar does not permit a repeat. The rules for all connections should be as similar as possible. There seems no reason to permit this for port connections but not others (the grammar appears to forbid it even for port connections, although the textual descriptions could be interpreted to imply that it is permitted for port connections).

`-- Illustrates several cases of connection refinements that currently -- generate errors in OSATE2 but seem very useful and in at least one -- case possibly legal.

-- The one in system implementation Sys.Refine2 might be an OSATE2 -- bug, or it might be that the standard is unclear about what is -- legal. (This error message masks subsequent error messages, -- some commenting-out of previous errors is needed to see subsequent -- error messages.)

-- The others are reasonably or clearly illegal in the current AADL -- standard, but they seem like errata (things that are meaningful -- and desirable in use).

package RefineConnect public

system SysPort
    features
        outp: out data port;
        inp: in data port;
end SysPort;

feature group FG
end FG;

system SysGroup
    features
        outg: feature group FG;
        ing: feature group inverse of FG;
end SysGroup;

system Sys
end Sys;

system implementation Sys.Parent
subcomponents
    sysAP: system SysPort;
    sysBP: system SysPort;
    sysAG: system SysGroup;
    sysBG: system SysGroup;
connections
    c_abp: port sysAP.outp -> sysBP.inp;
    c_abg: feature group sysAG.outg <-> sysBG.ing;
end Sys.Parent;

system implementation Sys.Child extends Sys.Parent
subcomponents
    sysCP: system SysPort;
    sysCG: system SysGroup;
end Sys.Child;

system implementation Sys.Refine1 extends Sys.Child
    connections
        -- Accepted by OSATE2
        c_abp: refined to port {Latency => 200ms .. 200ms;};
end Sys.Refine1;

system implementation Sys.Refine2 extends Sys.Child
    connections
        -- Standard grammar seems to rule this out,
        -- but the standard text refers to including
        -- source and destination elements.  This may
        -- be an inconsistency in the standard or an
        -- OSATE bug.
        c_abp: refined to port sysAP.outp <-> sysBP.inp;
end Sys.Refine2;

-- The above error masks error reports in the following -- declarations. To see the additional errors, comment -- out the preceding declarations that generated errors.

system implementation Sys.Refine3 extends Sys.Child
    connections
        -- I couldn't find anything in the standard forbidding
        -- this, and this form of refinement (to
        -- change one end of the connection) is highly
        -- desirable in practice.  If the standard
        -- forbids this, that should be an errata.
        c_abp: refined to port sysAP.outp -> sysCP.inp;
end Sys.Refine3;

system implementation Sys.Refine4 extends Sys.Child
    connections
        -- The standard explicitly forbids this for
        -- feature group connections, but it is
        -- as desirable and meaningful as the port
        -- refinement above.  There should also be as
        -- much symmetry as possible between port connections
        -- and feature group connections. This should
        -- be an errata.
        c_abg: refined to port sysAG.outg <-> sysCG.ing;
end Sys.Refine4;    

end RefineConnect; `

[reteprelief]

Steve Vestal as originator

[stevevestal]

Depending on how the 2.2 standard is interpreted, this should also allow the following issue to be explicitly resolved.

https://groups.google.com/forum/#!topic/osate/6bPIANtcHQ8