UML 2.4.1 RTF Avatar
  1. OMG Issue

UML241 — inadequate definition of 'constructor'

  • Key: UML241-36
  • Legacy Issue Number: 7866
  • Status: open  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The current "definition" of constructor, section 9.3.1 "Notation"
    subsection (page 75) leaves some issues.

    The description proposes a notation for associating an instance
    representation with a "constructor", noting only that a constructor is
    an operation that "must have the class as its classifier."

    Given a list of operations (_ _ is static):

    + newInstance(name:String):Foo
    + getFooForName(name:String):Foo
    + identity():Foo
    + clone():Foo
    + Foo(name:String):Foo
    + Foo(name:String):Foo
    + make(name:String):Foo

    Any of the above operations could be viewed as a constructor under the
    definition provided. The only marker suggested in the superstructure
    specification to clearly specify a constructor is a "<<create>>"
    assocation from the default instance created by the constructor.

    Assuming foo:Foo:
    In the predominant commercial OO languages, newInstance(...) and clone()
    are delegating the actual creation to Foo::Foo(...), but clone or copy
    may be the vehicles of instantiation in languages like io or self.

    If UML had a specific marker for constructors, like the stereotype
    "<<constructor>>" then OCL and other notations and tools could treat
    constructors specially where useful.

    The OCL specificaion already includes notation for Tuple and Collection
    "constructors" to specify what are essentially Tuple and Collection
    constants. Providing a standard marker for constructors might reliably
    allow similar clear constructs for all other types (ex. if baz >
    Foo(1.30, Currency::USDollars) then ...).

  • Reported: UML 1.4.2 — Sun, 17 Oct 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT