Issue 5035: Chap. 5, p. 47 and following (4.2.1 Modeling Realization Relationships) (uml-scheduling-ftf)
Source: Esterel Technologies (Mr. Jean-Paul Rigault, )
Nature: Uncategorized Issue
Severity: 
Summary: The distinction between Refinement and Realization becomes less and less clear to
me. I understand the logical difference between presenting the same model with vari-ous
levels of details (refinement) and setting a bridge between two different models,
one realizing/implementing/deploying the other (realization). However, as far as the
modeling elements and their relationships are concerned, the mechanisms seem to be
identical and the frontier often appears fuzzy.
This trouble and confusion is apparent in the submission itself since one category of
realization may well be considered as refinement (replacement, p. 51), as indicated by
the authors themselves. The argument that hardware and software are still different
entities is not completely convincing to make it a realization: indeed the hardware
manipulates (although under different forms) the same information as the software, at
run-time.
Another question: why restrict replacement to the deploy mapping and to a relation-ship
between hardware and software? Is not «code» a form of replacement?
• I was also expecting a general notation for representing the Realization (or Realiza-tion/
Refinement) relationship in UML. This is only sketched in the document (p. 48)
but far from expressing the whole richness. The following characteristics seem of
interest to me:
- multiplicity, both on client and supplier sides
- conjunction or disjunction
- exclusivity or not
- "optionality" or "mandatority"
- static or dynamic nature of the relationship and of all the above characteristics
- combination of functionalities (additive, replacement...)
I am not sure that the simple distinction between require on the one hand and inclu-sive
and exclusive (static or dynamic) on the other hand (p. 50) is sufficient to repre-sent
all the useful and significant cases.
However, I am already late to send this review so I have no time to elaborate more on
this, but I would be pleased to discussed it with anybody, if this is found interesting.
Of course, this submission might not be the place to set up a general model of Real-ization/
Refinement.
Resolution: 
Revised Text: 
Actions taken:
March 20, 2002: received issue
Discussion: 
This has been pointed out as one of the major weak areas of the submission and needs to be elaborated further or maybe removed (Bran). As indicated in previous discussions, this is indeed considered to be a major weak point in the spec and at least warrants some additional clarifications to the text in sections 4.1.8.1 and 4.1.8.2. However, it is not expected that these will be sufficient to remove the issue.
Also, the issuer seems to have missed the fact that at least some of the characteristics he mentions as being omitted (multiplicty, conjunction/disjunction, etc.) are in fact addressed in section 4.2.1.2.
Keep the issue open for the 2.0 version of the profile.


End of Annotations:=====
This is issue # 5035

Chap. 5, p. 47 and following (4.2.1 Modeling Realization
Relationships)

The distinction between Refinement and Realization becomes less and
less clear to
me. I understand the logical difference between presenting the same
model with vari-ous
levels of details (refinement) and setting a bridge between two
different models,
one realizing/implementing/deploying the other (realization). However,
as far as the
modeling elements and their relationships are concerned, the
mechanisms seem to be
identical and the frontier often appears fuzzy.
This trouble and confusion is apparent in the submission itself since
one category of
realization may well be considered as refinement (replacement, p. 51),
as indicated by
the authors themselves. The argument that hardware and software are
still different
entities is not completely convincing to make it a realization: indeed
the hardware
manipulates (although under different forms) the same information as
the software, at
run-time.
Another question: why restrict replacement to the deploy mapping and
to a relation-ship
between hardware and software? Is not codebut far from expressing the
whole richness. The following characteristics seem of
interest to me:
- multiplicity, both on client and supplier sides
- conjunction or disjunction
- exclusivity or not
- "optionality" or "mandatority"
- static or dynamic nature of the relationship and of all the above
characteristics
- combination of functionalities (additive, replacement...)
I am not sure that the simple distinction between require on the one
hand and inclu-sive
and exclusive (static or dynamic) on the other hand (p. 50) is
sufficient to repre-sent
all the useful and significant cases.
However, I am already late to send this review so I have no time to
elaborate more on
this, but I would be pleased to discussed it with anybody, if this is
found interesting.
Of course, this submission might not be the place to set up a general
model of Real-ization/
Refinement.