SYSML11 — Suggest permit UML2.1.1 Component for use as parasitic element wrapper Comp

Suggest permit UML2.1.1 Component for use as parasitic element wrapper Component, for nested <<requirement>>s, and for <<view>>s There are at least three applications of the UML2 Component which I consider very beneficial to practical UML-based systems engineering: 1st: I make extremely heavy use of the technique of stereotyped <<composition>>, <<inhertance>>, <<specialisation>> "wrapper" Components to graphically and logically organise model elements in BDDs (and in class diagrams) "parastically", i.e. without stealing ownership of the contained elements. Especially the <<composition>> wrapper Component is very powerful for diagramming and organising hierarchical assemblies of complex systems. In such cases the wrapping Component has Realizations to the wrapped elements, which can be further leveraged to trace the logical groupings. The recipe is consistent with the UML2.1.1 superstructure (although it is not supported in all UML tools). I contend the wrapper Component strategy should be made officially available to those SysML users who wish to use it (at least as a permitted option). 2nd:If one permits the UML2.1.1 Component the SysML <<requirement>> stereotype can be applied to Components so that Requirements can be graphically nested, which is far more graphically stable than just diagramming Class <<requirement>> Dependencies, and can be consistently applied in combination with the existing relationship stereotypes between SysML requirements. 3rd: Components are far better suited to creating orthogonal, parasitic <<views>> of packaged elements than the Package or Model, which both steal ownership.

Suggest permit UML2.1.1 Component for use as parasitic element wrapper Component, for nested <<requirement>>s, and for <<view>>s Discussion:
SysML currently lacks capability to represent system views that define parts or
other substructure differently than other system views. As noted by the issue,
any declaration of ownership or other other model structure in one view cannot
conflict with such declarations in other views. The View stereotype of Package
defined in Chapter 7, Model Elements, only selects elements for inclusion in any
one view, and does not support additional structure which may differ across
views. The proposal to consider Component as a basis for “orthogonal, parasitic
<<views>>” is an interesting possibility, but goes beyond the scope of
incremental change that can be considered in an RTF. Addition of such a fundamental capability to SysML, and a UML profile which bases this capability
on UML Component, could be considered in response to an RFP for a major new
version of SysML.
Disposition: Closed, no change