UML241 — inadequate definition of 'constructor'

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:
Foo::newInstance("bar")
foo.clone()
Foo::make("bar")
Foo::Foo("bar")
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 ...).