SPTP 1.0 NO IDEA Avatar
  1. OMG Issue

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

  • Key: SPTP-4
  • Legacy Issue Number: 5035
  • Status: open  
  • Source: Esterel Technologies ( Jean-Paul Rigault)
  • 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.
  • Reported: SPTP 1.0b1 — Wed, 20 Mar 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT