I am not sure about your Actual Question .But let me try to Answer it as per my Understanding.

1. if you are referring why UML does not relate to System ?

Answer -

UML has been initially introduced to Design and Development of Software.

In future SysML Profile has been added to UML to specifically concentrate on MBSE for System

Design with addition of Requirements Diagram,Parametric Diagram etc.

2. If you are referring why Use case,Port ,Interface and Components are not measurable with some

Dimension?

Answer -

For Use Case :- Use Case simply explains a particular interaction with System by External Actors.

Consider you want to design a Feature of a System and you listed out who all

External Actors are going to interact with the System of Interest and drawn the

Use cases within System Boundary with all relationships.

In future ,you understand there is a new External Actor who is providing some

valuable Information as per some new requirements for the same Feature.

So here you have to change the same Use case Diagram with addition of new

Use case with New External Actor.

Basically one should depict all use cases that cover your Feature and have traceability

to all High level Requirements ,so there is no Dimension.

For Component :- Component diagrams allow an architect to verify that a system's required

functionality is being implemented by components, thus ensuring that the eventual

system will be acceptable.

A component does not have any location and it can be Logical or Physical ,providing

the Interface. So as per Standard it depends on System Engineer to put a Stereotype

with changes in Profile to signify a Specific Type and Since it's behavioral so there is

no Unit.

For Interface :- Same goes for Interface.These are always realized to provide some Service.

Sometimes there is a request for Service and sometimes to consume a Service.

So Every Component either have Provided Interface or Required Interface or Both.

Interface always exist when there is a need of communication for Data Exchange

so UML standard has not given any specific Dimension and since it is generic to

all domain so No specific Data Type.

Pardon me If I do not get your Question Correctly,I would happy to modify the Answer.

I am very grateful for your observations :)

In my questions I pointed out to some discrepances between UML rules.

The semantic rules are included in clause numbers and the syntactic ones are inferenced from the numbered pictures showing metamodels.

Generally the UML standard presents only two dimensions: structural and behawioral by means of defining two types of diagrams.

But in Annex A it is said, that "it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral elements".

Thus structure diagrams can describe not only structure of the system, but also a behawioral dimension due to such behavior of ports and interfaces.

More interestingly the UML standard does not define functional diagrams. I remember that in the 0.9 version of the UML the elements of the UseCases clause have been qualified into the functional dimension. However since the version 1.0 this classification has disappeared.

How do you think, what dimension describes the component diagram, which has no elements ? None ? Thus the structural component diagram, according to the UML standard, can in fact describe the system also in other dimensions, can’t it ?

As Prasanjit Bhuyan noted above, UML originally specifically addressed object-oriented (OO) software modeling and development. But UML progressively enlarges its application fields and some extensions focus on embedded/real-time systems.

I suggest that you check out the following references for more details:

Your links are very interesting, but what do you think about:

• (1-st link) „The purpose of a modeling language is to support the system developers throughout the process from initial specification to finished product, and enable them at various stages to make predictions about the final system’s characteristics, in particular related to its functionality and performance”
• (2-nd link) „The function of a system is what the system is intended to do, and is described by the functional specification.”
• (3-rd link) „Is it suitable for the real-time context where the system nonfunctional properties, including the timing behavior, are as important as its functionality?”
• (4-th link) „Use Case Diagrams - Used to capture functional requirements”.

And what about this article ? „Possible Improvements in UML Behavior Diagrams”, 2014, Fahad Alhumaidan, Nazir Ahmad Zafar.

• (1-st link) Regarding UML, I would substitute "make predictions about" by "better check for and master" the final system's characteristics. UML is originally a graphical modeling language (by hand/computer-assisted tool). UML is neither a smart/automatic modeling process, nor a formal methodology. One known object-oriented software development methodolgy is built on UML: Unified Process (UP).

In pure software development context, functional specifications are typically designed based on either textual descriptions or use-cases. But other diagrams may also be used depending on the requirement needs. For example, state diagrams may be used to describe some functionality aspects in details if needed. UML is not restrictive when using the diagrams, even if some of them are precisely recommended when facing with usual modeling stages.

In real-time/embedded system modeling field, enriched functionality specification tools are often required. SysUML specifically addresses this kind of needs. To this end, SysUML provides the designer with the additional Requirement Diagram (follow https://re-magazine.ireb.org/print/?article=2015-2-bridging-the-impossible%2Fmodeling-requirements-with-sysml ).

Moreover, Petri nets are more and more integrated to enrich the UML modeling language... Particularly in what concerns functionality specifications!