FTF-report-draft-040225 - FTP - Object Management Group

toadspottedincurableInternet και Εφαρμογές Web

4 Δεκ 2013 (πριν από 3 χρόνια και 9 μήνες)

296 εμφανίσεις

Object Management Group

Final FTF Report



Document
{Report

document number}

UML 2.0 Superstructure FTF




FTF Report


of the


UML 2.0 Superstructure

Finalization Task Force

{revision 0.44
5
}


to the

Platform Technical Committee

of the

Object Management Group

{
25
February 2004}




Document Number:

{enter this doc’s No.}

Accompanied by:

{number(s) of

revised
spec, etc}



Table of Contents

Insert ToC only in the final version since the ToC feature seems to be interfering with the
change
-
tracking feature of Word. We need the change bars for regular work to know
what has changed since the previous issue of the d
raft report.


UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

1



Summary of
UML 2.0 Superstructure FTF

Activities

Formation



Chartered By: Platform Technology Committee



On: June 6, 2003 in Paris, France



Comments Due Date: November 7, 2003 (revised from Sept. 8, 2003 at
Boston meeting)



Report Due Date: A
pril 30, 2004


Revision / Finalization Task Force Membership

Member

Organization

Status

ARMSTRONG, Chris

ATC Enterprises


BAST, Wim

Compuware Corporation


BOCK, Conrad

NIST


BOGER, Marco

Gentleware AG


DESFRAY, Philippe

Softeam


FRANK, Karl

Borland

Software Corporation


GERARD, Sebastien

CEA
-
List


GERY, Eran

ILogix


KOBRYN, Cris

Telelogic AB


KOETHE, Manfred

88solutions


MAISONNEUVE,
Julien

Alcatel


MANSUROV, Nikolai

KLOCwork Inc.


MELLOR, Steve

Project Technology


MILLER, Joaquin

X
-
Change

Technologies Group, LLC


UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

2



Member

Organization

Status

MIYAZAKI, Hiroshi

Fujitsu


MOORE, Alan

Artisan Software Tools


MUKERJI, Jishnu

Hewlett
-
Packard


ODELL, Jim

Kabira technologies, Inc.


RAMACKERS, Guus

Oracle

Co
-
chair

RIVETT, Pete

Adaptive Ltd.


RIOUX, Laurent

THALES


SELIC
, Bran

International Business Machines

Co
-
chair

TARLANO, Anthony

DoCoMo Communication Laboratories Europe
GmbH


TOLBERT, Doug

Unisys


VARVERIS, Lou

Popkin Software


VOJTISEK, Didier

INRIA


WEIGERT, Thomas

Motorola


WILKIE, Ian

Kennedy Carter



UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

3



Ini
tial Issues from Architecture Board Review:

None


Issue Disposition:


Disposition

Number of
Occurrences

Meaning of Disposition


Resolved

72

The RTF/FTF agreed that there is a problem that
needs fixing, and has proposed a resolution
(which may or may not a
gree with any resolution
the issue submitter proposed)


Unresolved

369

The RTF/FTF agrees that there is a problem that
needs fixing, but could not agree on a resolution.


Deferred

4

The RTF/FTF agrees that there is a problem that
needs fixing, but dec
ided to defer its resolution to
a future RTF working on this specification
(perhaps because of a lack of time or urgency).


Transferred

14

The RTF/FTF decided that the issue report
relates to another specification, and recommends
that it be transferred to

the relevant RTF.


Closed, no
change

136

The RTF/FTF decided that the issue report does
not, in fact, identify a problem with this (or any
other) OMG specification.


Duplicate or
merged

15

This issue is either an exact duplicate of another
issue, or ver
y closely related to another issue: see
that issue for disposition.







UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

4



Voting Record:

Ballot 1


Poll start date:

October 1, 2003 (12:00 noon EDT)

Poll closing date:

October 15, 2003 (12:00 noon EDT)


Issue Number

YES

NO

ABSTAIN

VETO

1512

See Note 1


=
䡐Ⱐe番u瑳t
=

=
㈰㈰
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㈰㠳
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㈲〸
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㈲㜶
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㈲㜷
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㈳㌷
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㌱㈳
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㌲㤱
=
pee⁎
潴攠o
=

=
䡐Ⱐe番u瑳t
=

=
㌳㐱
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㌳㠲
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㌵㘹
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㌶㌲
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㌶㠲
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㌹㤹
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㐰㠳
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=


=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㐲ㄸ
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㐲㤲
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㐴㔵
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㐴㘴
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㐴㘵
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㐶ㄹ
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㐶㈶
=
pee⁎潴=‱
=

=
䡐Ⱐe番ut

=

=
㐷㈸
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

5



Issue Number

YES

NO

ABSTAIN

VETO

4729

See Note 1


=
䡐Ⱐe番u瑳t
=

=
㐷㌹
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㐸〰
=
pee⁎潴=′
=
䅤A灴p癥I
=
B潲污湤
=
䡐Ⱐe番u瑳t
=

=
㔰〵
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㔲㘷
=
pee⁎潴=″
=
䅤A灴p癥Ⱐ
=
B潲污湤Ⱐ
=
C潭灵睡牥I
=
u
-
C桡ngeⰠ
㠸獯U畴u潮o
=
䡐Ⱐe番u瑳t
=

=
㔲㘸
=
pee⁎潴=″
=
䅤A灴p癥Ⱐ
=
B潲污湤Ⱐ
=
C潭灵睡牥I
=
u
-
C桡ngeⰠ
㠸獯U畴u潮o
=
䡐Ⱐe番u瑳t
=

=
㔵㈵
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㔶㔷
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㔶㠵
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㔷㌰
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㔷㌱
=
pee⁎潴=‴
=
u
-
C桡ng
e
=
䡐Ⱐe番u瑳t
=

=
㔷㌶
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㔷㌹
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㔷㐰
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㔷㐵
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㔷㤸
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㔸〳
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㔸〵
=
pee⁎潴=‱
=

=
䡐Ⱐe番u瑳t
=

=
㔹㈲
=
pee
=
乯瑥‱
=

=
䡐Ⱐe番u瑳t
=

=


Note 1:

(23 votes) Adaptive, Alcatel, Artisan, ATC, Borland, Compuware,
Gentleware, IBM, Ilogix, Kabira, Kennedy
-
Carter, Klocwork, Motorola, NIST,
Oracle, Popkin, Proj.Tech., Softeam, Telelogic, Thales, Unisys, X
-
Change,
88solution
s



Note 2:

(21 votes) Alcatel, Artisan, ATC, Borland, Compuware, Gentleware,
IBM, Ilogix, Kabira, Kennedy
-
Carter, Klocwork, Motorola, NIST, Oracle,
Popkin, Proj.Tech., Softeam, Telelogic, Thales, Unisys, 88solutions

UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

6





Note 3:

(18 votes) Alcatel, Artisan, ATC
, Gentleware, IBM, Ilogix, Kabira,
Kennedy
-
Carter, Klocwork, Motorola, NIST, Oracle, Popkin, Proj.Tech.,
Softeam, Telelogic, Thales, Unisys



Note 4:

(22 votes) Adaptive, Alcatel, Artisan, ATC, Borland, Compuware,
Gentleware, IBM, Ilogix, Kabira, Kennedy
-
Car
ter, Klocwork, Motorola, NIST,
Oracle, Popkin, Proj.Tech., Softeam, Telelogic, Thales, Unisys, 88solutions

Companies that did not vote in this ballot:

1.

Computer Associates

2.

Ceira Technologies

3.

DoCoMo Communication

4.

Embarcadero Technologies

5.

INRIA

6.

TNI
-
Valiosys

R
esults:

25 votes cast


exceeds quorum (16)


valid ballot

simple majority required for decision = 13 votes

All issues carried with a YES vote.

UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

7



Ballot 2


Poll start date:

October 29, 2003 (12:00 noon EDT)

Poll closing date:

November 12, 2003 (12:00 noon E
DT)


Issue Number

YES

NO

ABSTAIN

VETO

1790

See Note 1


=

=

=
㌳㤲
=
pee⁎潴=‱
=

=

=

=
㌵ㄳ
=
pee⁎潴=‱
=

=

=

=
㌸〰
=
pee⁎潴=‱
=

=

=

=
㌸㔵
=
pee⁎潴=‱
=

=

=

=
㐱ㄲ
=
pee⁎潴=‱
=

=

=

=
㐱㈱
=
pee⁎潴=‱
=

=

=

=
㐴㔱
=
pee⁎潴=‱
=

=

=

=
㐶㤱
=
pee⁎潴=‱
=

=

=

=
㐶㤲
=
pee⁎
潴攠o
=

=

=

=
㐶㤳
=
pee⁎潴=‱
=

=

=

=
㐶㤴
=
pee⁎潴=‱
=

=

=

=
㔵㠱
=
pee⁎潴=‱
=

=

=

=
㔵㠲
=
pee⁎潴=‱
=

=

=

=


Note 1:

(27 votes) Adaptive, Alcatel, Artisan, Borland, Ceira Technologies,
Compuware, Gentleware, DoCoMo, Fujitsu, Hewlett
-
Packard, IBM, Ilogix,
INRIA
, Kabira, Kennedy
-
Carter, Klocwork, Motorola, NIST, Oracle, Popkin,
Proj.Tech., Softeam, Telelogic, Thales, Unisys, X
-
Change, 88solutions

Companies that did not vote in this ballot:

1.

ATC Enterprises

2.

Computer Associates

3.

Embarcadero Technologies

4.

TNI
-
Valiosys

Companies that did not register a vote in two consecutive ballots:

1.

Computer Associates

2.

TNI Valiosys

3.

Embarcadero Technologies

Since the two consecutive votes in question (Ballot 1 and Ballot 2) were spread across a
6
-
week period, according to the OMG Polic
ies and Procedures the above companies are
automatically removed from the UML 2.0 Superstructure FTF.

UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

8



Results:

27 votes cast


exceeds quorum (16)


valid ballot

simple majority required for decision = 13 votes

All issues carried with a YES vote.

UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

9



Ballot 3


Poll start date:

November 26, 2003 (12:00 noon EST)

Poll closing date:

December 10, 2003 (12:00 noon EST)


Issue Number

YES

NO

ABSTAIN

VETO

3276

See Note 1


=

=

=
㌲㠵
=
pee⁎潴=‱
=

=

=

=
㐴㔷
=
pee⁎潴=‱
=

=

=

=
㐹ㄷ
=
pee⁎潴=‱
=

=

=

=
㐹㈷
=
pee⁎潴=‱
=

=

=

=
㐹㐰
=
pee⁎潴=‱
=

=

=

=
㔲㘹
=
pee⁎潴=′
=
u
-
C桡nge=
呥c桮潬hg楥i
=

=

=
㔶㔵
=
pee⁎潴=‱
=

=

=

=
㔶㔶
=
pee⁎潴=‱
=

=

=

=
㔶㔸
=
pee⁎潴=‱
=

=

=

=
㔶㔹
=
pee⁎潴=‱
=

=

=

=
㘰㤵
=
pee⁎潴=‱
=

=

=

=
㘱㘵
=
pee⁎潴=‱
=

=

=

=
㘲㘱
=
pee⁎潴=‱
=

=

=

=


Note 1:

(26 votes) Adaptive
, Alcatel, Artisan, ATC Enterprises, Borland, Ceira,
Compuware, Gentleware, DoCoMo, Fujitsu, Hewlett
-
Packard, IBM, Ilogix,
INRIA, Kabira, Kennedy
-
Carter, Klocwork, Motorola, NIST, Oracle, Softeam,
Telelogic, Thales, Unisys, X
-
Change, 88solutions



Note 2:

(
25 votes) Adaptive, Alcatel, Artisan, ATC Enterprises, Borland, Ceira,
Compuware, Gentleware, DoCoMo, Fujitsu, Hewlett
-
Packard, IBM, Ilogix,
INRIA, Kabira, Kennedy
-
Carter, Klocwork, Motorola, NIST, Oracle, Softeam,
Telelogic, Thales, Unisys, 88solutions

C
ompanies that did not vote in this ballot
1
:

1.

Popkin Software

2.

Project Technologies

Companies that did not register a vote in two consecutive ballots:


None




1

CEA List did not vote on this ballot, However, since they j
oined the FTF
after

the voting period had
started, because they were not provided the full two
-
week interval to register their vote, they were deemed
exempt from having to vote on this ballot.

UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

10



Results:

27 votes cast


exceeds quorum (15)


valid ballot

simple majority required for decision = 14

votes

Hence, all issue resolutions carried with a YES vote.


UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

11



Ballot 4


Poll start date:

January 7, 2004 (12:00 noon EST)

Poll closing date:

January 21, 2004 (12:00 noon EST)


Issue Number

YES

NO

ABSTAIN

VETO

2291

See Note 1


=

=

=
㐲ㄹ
=
pee⁎潴=‱
=

=

=

=
㐷㈶
=
pee⁎潴=‱
=

=

=

=
㐷㌰
=
pee⁎潴=‱
=

=

=

=
㔷㐴
=
pee⁎潴=‱
=

=

=

=
㘰㜲
=
pee⁎潴=‱
=

=

=

=
㘰㜶
=
pee⁎潴=′
=

=

=

=
㘰㤶
=
pee⁎潴=‱
=

=

=

=
㘱〲
=
pee⁎潴=‱
=

=

=

=
㘱〳
=
pee⁎潴=‱
=

=

=

=
㘱〴
=
pee⁎潴=‱
=

=

=

=
㘱㈴
=
pee⁎潴=‱
=

=

=

=
㘱㈷
=
pee⁎潴=‱
=

=

=

=
㘱㌸
=
pee⁎潴=‱
=

=

=

=
㘱㘱
=
pee⁎潴=‱
=

=

=

=
㘱㘲
=
pee⁎潴=‱
=

=

=

=
㘲〸
=
pee⁎潴=‱
=

=

=

=
㘲㈷
=
pee⁎潴=‱
=

=

=

=
㘲㌹
=
pee⁎潴=‱
=

=

=

=
㘲㐱
=
pee⁎潴=′
=
䅤A灴p癥
=

=

=
㘳㘰
=
pee⁎潴=‱
=

=

=

=
㘳㜱
=
pee⁎潴=‱
=

=

=

=
㘴㐵
=
pee⁎潴=‱
=

=

=

=
㘵〵
=
pee⁎潴=‱
=

=

=

=


Note 1:

(29 votes) Adaptive, Alcatel, Artisan, ATC Enterprises, Borland, CEA,
Ceira, Compuware, Gentleware, DoCoMo, Fujitsu, Hewlett
-
Packard, IBM, Ilogix,
UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

12



INRIA, Kabira, Kennedy
-
Carter, Klocwork, Motorola, NIST, Oracle, Popkin,
Project Technologies, So
fteam, Telelogic, Thales, Unisys, X
-
Change, 88solutions



Note 2:

(28 votes) Alcatel, Artisan, ATC Enterprises, Borland, CEA, Ceira,
Compuware, Gentleware, DoCoMo, Fujitsu, Hewlett
-
Packard, IBM, Ilogix,
INRIA, Kabira, Kennedy
-
Carter, Klocwork, Motorola, NIS
T, Oracle, Popkin,
Project Technologies, Softeam, Telelogic, Thales, Unisys, X
-
Change, 88solutions

Companies that did not vote in this ballot:

None

Results:

29 votes cast


exceeds quorum (15)


valid ballot

simple majority required for decision = 15 vote
s

Hence, all issue resolutions carried with a YES vote.


UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

13



Ballot 5



Poll start date:

January 21, 2004 (6 PM EST)

Poll closing date:

February 4, 2004 (6 PM EST)



Issue Number

YES

NO

ABSTAIN

VETO

2613

See Note 1



Fujitsu



4727

See Note 1



Fujitsu



4
735

See Note 1



Fujitsu



4937

See Note 1



Fujitsu



5995

See Note 1



Fujitsu



6020

See Note 1



Fujitsu



6021

See Note 1



Fujitsu



6079

See Note 1



Fujitsu



6081

See Note 1



Fujitsu



6092

See Note 1



Fujitsu



6093

See Note 1



Fujitsu



6094

See Note 1



Fujitsu



6099

See Note 1



Fujitsu



6105

See Note 1



Fujitsu



6106

See Note 1



Fujitsu



6108

See Note 1



Fujitsu



6110

See Note 1



Fujitsu



6115

See Note 1



Fujitsu



6116

See Note 1



Fujitsu



6118

See Note 1



Fu
jitsu



6119

See Note 1



Fujitsu



6120

See Note 1



Fujitsu



6121

See Note 1



Fujitsu



6122

See Note 1



Fujitsu



6129

See Note 1



Fujitsu



6131

See Note 1



Fujitsu



6132

See Note 1



Fujitsu



6135

See Note 1



Fujitsu



6139

See Note 1



Fujitsu



UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

14



Issue Number

YES

NO

ABSTAIN

VETO

6141

See Note 1



Fujitsu



6151

See Note 1



Fujitsu



6204

See Note 1



Fujitsu



6209

See Note 1



Fujitsu



6224

See Note 1



Fujitsu



6225

See Note 1



Fujitsu



6229

See Note 1



Fujitsu



6238

See Note 1



Fujitsu



6250

See N
ote 1



Fujitsu



6338

See Note 1



Fujitsu



6352

See Note 1



Fujitsu



6358

See Note 1



Fujitsu



6359

See Note 1



Fujitsu



6361

See Note 1



Fujitsu



6363

See Note 1



Fujitsu



6364

See Note 1



Fujitsu



6366

See Note 1



Fujitsu



6370

See Note 1



Fujitsu



6378

See Note 1



Fujitsu



6380

See Note 1



Fujitsu



6396

See Note 1



Fujitsu



6400

See Note 1



Fujitsu



6403

See Note 1



Fujitsu



6406

See Note 1



Fujitsu



6426

See Note 1



Fujitsu



6441

See Note 1



Fujitsu



6443

See Note 1



Fujitsu



6444

See Note 1



Fujitsu



6474

See Note 1



Fujitsu



6477

See Note 1



Fujitsu



6480

See Note 1



Fujitsu



6481

See Note 1



Fujitsu



6482

See Note 1



Fujitsu



6483

See Note 1



Fujitsu



UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

15



Issue Number

YES

NO

ABSTAIN

VETO

6486

See Note 1



Fujits
u



6506

See Note 1



Fujitsu



6510

See Note 1



Fujitsu



6511

See Note 1



Fujitsu



6521

See Note 1



Fujitsu



6522

See Note 1



Fujitsu



6523

See Note 1



Fujitsu



6605

See Note 1



Fujitsu



6606

See Note 1



Fujitsu



6607

See Note 1



F
ujitsu



6676

See Note 1



Fujitsu



6678

See Note 1



Fujitsu



6679

See Note 1



Fujitsu



6680

See Note 2

Adaptive,

X
-
Change

Fujitsu



6728

See Note 1



Fujitsu





Note 1:

(27 votes) Adaptive, Alcatel, Artisan, ATC Enterprises, Borland, CEA,
Ceira
, Compuware, Gentleware, DoCoMo, Hewlett
-
Packard, IBM, Ilogix, INRIA,
Kabira, Kennedy
-
Carter, Klocwork, Motorola, NIST, Oracle, Popkin, Softeam,
Telelogic, Thales, Unisys, X
-
Change, 88solutions



Note 2:

(25 votes) Alcatel, Artisan, ATC Enterprises, Borland
, CEA, Ceira,
Compuware, Gentleware, DoCoMo, Hewlett
-
Packard, IBM, Ilogix, INRIA,
Kabira, Kennedy
-
Carter, Klocwork, Motorola, NIST, Oracle, Popkin, Softeam,
Telelogic, Thales, Unisys, 88solutions

Companies that did not vote in this ballot:



Project Technolo
gy

Results:

28 votes cast


exceeds quorum (15)


valid ballot

simple majority required for decision = 15 votes

Hence, all issue resolutions carried with a YES vote, since each one has at least 24
YES votes.

UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

16



Ballot 6


Poll start date:

January 28, 2004 (6

PM EST)

Poll closing date:

February 11, 2004 (6 PM EST)


Issue Number

YES

NO

ABSTAIN

VETO

2278

See Note 1


=

=


2289

See Note 1


=

=

=
2290

See Note 1


=

=

=
2361

See Note 1


=

=

=
2362

See Note 1


=

=

=
2541

See Note 2

Borland,

X
-
Change, Ceira


=

=
31
27

See Note 1


=

=

=
3735

See Note 1


=

=

=
4446

See Note 3

NIST, Kabira,
Telelogic,

X
-
Change, Ceira


=

=
4447

See Note 1


=

=

=
4449

See Note 1


=

=

=
4452

See Note 1


=

=

=
4617

See Note 1


=

=

=
4732

See Note 1


=

=

=
4738

See Note 1


=

=

=
4810

See No
te 1


=

=

=
4848

See Note 1


=

=

=
4946

See Note 1


=

=

=
5732

See Note 1


=

=

=
5733

See Note 1


=

=

=
5734

See Note 1


=

=

=
5737

See Note 1


=

=

=
5763

See Note 1


=

=

=
5795

See Note 1


=

=

=
5796

See Note 1


=

=

=
5800

See Note 1


=

=

=
5801

See Note
1


=

=

=
5896

See Note 1


=

=

=
UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

17



5923

See Note 1


=

=

=
=


Note 1:

(29 votes) Adaptive, Alcatel, Artisan, ATC Enterprises, Borland, CEA,
Ceira, Compuware, Fujitsu, Gentleware, DoCoMo, Hewlett
-
Packard, IBM, Ilogix,
INRIA, Kabira, Kennedy
-
Carter, Klocwork, Moto
rola, NIST, Oracle, Popkin,
Projtech, Softeam, Telelogic, Thales, Unisys, X
-
Change, 88solutions



Note 2:

(26 votes) Adaptive, Alcatel, Artisan, ATC Enterprises, CEA,
Compuware, Fujitsu, Gentleware, DoCoMo, Hewlett
-
Packard, IBM, Ilogix,
INRIA, Kabira, Kenne
dy
-
Carter, Klocwork, Motorola, NIST, Oracle, Popkin,
Projtech, Softeam, Telelogic, Thales, Unisys, 88solutions



Note 3:

(24 votes) Adaptive, Alcatel, Artisan, ATC Enterprises, Borland, CEA,
Compuware, Fujitsu, Gentleware, DoCoMo, Hewlett
-
Packard, IBM, Ilog
ix,
INRIA, Kennedy
-
Carter, Klocwork, Motorola, Oracle, Popkin, Projtech, Softeam,
Thales, Unisys, 88solutions


Companies that did not vote in this ballot:



All companies voted

Results:

29 votes cast


exceeds quorum (15)


valid ballot

simple majority requ
ired for decision = 15 votes


Hence, all issue resolutions carried with a YES vote, since each one has at
least 24 YES votes.

UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

18



Ballot 7 Results


Poll start date:

February 14, 2004 (6 PM EST)

Poll closing date:

February 18, 2004 (6 PM EST)


Issue Number

YES

NO

ABSTAIN

VETO

1209

See Note 1


=

=


3368

See Note 1


=

=

=
3376

See Note 1


=

=

=
4645

See Note 1


=

=

=
4662

See Note 1


=

=

=
4733

See Note 1


=

=

=
4734

See Note 1


=

=

=
4736

See Note 1


=

=

=
4740

See Note 1


=

=

=
5735

See Note 1


=

=

=
5738

See

Note 1


=

=

=
5797

See Note 1


=

=

=
5982

See Note 1


=

=

=
6014

See Note 1


=

=

=
6016

See Note 1


=

=

=
6017

See Note 1


=

=

=
6022

See Note 1


=

=

=
6023

See Note 1


=

=

=
6066

See Note 1


=

=

=
6073

See Note 1


=

=

=
6112

See Note 1


=

=

=
6123

See No
te 1


=

=

=
6147

See Note 1


=

=

=
6152

See Note 1


=

=

=
6182

See Note 1


=

=

=
6240

See Note 1


=

=

=
6310

See Note 2

Adaptive, Borland,
Kabira, NIST,
Telelogic,
88solutions


=

=
UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

19



6316

See Note 3

Borland, Kabira,
NIST, Telelogic,
88solutions


=

=
6350

See

Note 1


=

=

=
6354

See Note 4

Kabira, NIST,
Telelogic,
88solutions


=

=
6357

See Note 1


=

=

=
6439

See Note 1


=

=

=
6450

See Note 1


=

=

=
6485

See Note 1


=

=

=
6490

See Note 1


=

=

=
6508

See Note 1


=

=

=
=


Note 1:

(29 votes) Adaptive, Alcatel, Artisa
n, ATC Enterprises, Borland, CEA,
Ceira, Compuware, Fujitsu, Gentleware, DoCoMo, Hewlett
-
Packard, IBM, Ilogix,
INRIA, Kabira, Kennedy
-
Carter, Klocwork, Motorola, NIST, Oracle, Popkin,
Projtech, Softeam, Telelogic, Thales, Unisys, X
-
Change, 88solutions



Not
e 2:

(23 votes) Alcatel, Artisan, ATC Enterprises, CEA, Ceira, Compuware,
Fujitsu, Gentleware, DoCoMo, Hewlett
-
Packard, IBM, Ilogix, INRIA, Kennedy
-
Carter, Klocwork, Motorola, Oracle, Popkin, Projtech, Softeam, Thales, Unisys,
X
-
Change



Note 3:

(24 votes) A
daptive, Alcatel, Artisan, ATC Enterprises, CEA, Ceira,
Compuware, Fujitsu, Gentleware, DoCoMo, Hewlett
-
Packard, IBM, Ilogix,
INRIA, Kennedy
-
Carter, Klocwork, Motorola, Oracle, Popkin, Projtech, Softeam,
Thales, Unisys, X
-
Change



Note 2:

(25 votes) Adaptive
, Alcatel, Artisan, ATC Enterprises, Borland, CEA,
Ceira, Compuware, Fujitsu, Gentleware, DoCoMo, Hewlett
-
Packard, IBM, Ilogix,
INRIA, Kennedy
-
Carter, Klocwork, Motorola, Oracle, Popkin, Projtech, Softeam,
Thales, Unisys, X
-
Change


Companies that did not v
ote in this ballot:



All companies voted


Results:

29 votes cast


exceeds quorum (15)


valid ballot

simple majority required for decision = 15 votes


Hence, all issue resolutions carried with a YES vote, since each one has at least 23
YES votes.

UML 2.0 Superstrucure FTF

Final Report



Document
{Report document number}

Page

20



Summary
of Changes Made

The UML 2.0 Superstructure FTF made changes that:



{summarize the effect of the changes here


overall, not detailed.
Here are just three examples: 1). Corrected features that impeded
implementation or did not serve the original intent of

the specification,
2). Provided additional convenience for implementers, 3). Increased
the clarity of the specification}

The following is a table that categorizes the issues as to the degree of changes
that were made in resolving them.

Extent of Change

Number
of Issues

OMG Issue Numbers

Significant
-

Fixed
problems with normative
parts of the specification
that raised concern about
implementability

0

{enter OMG issue numbers here}

Minor
-

Fixed minor
problems with normative
parts of the specification

0

{enter OMG issue numbers here}

Support Text
-
Changes to
descriptive, explanatory, or
supporting material.

0

{enter OMG issue numbers here}



UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 2336


Document
{Report document number}

Page

21



Disposition: Unresolved

OMG Issue No: 2336

Title:

extension to the notation for a transition

Source:

Summary:

I would like to make an appeal for an extension to the notation for a transition to allow
its effect to be specified declaratively rather than only imperatively by means of an
action sequence, e.g.





e() / [p]



While I realize there are ways to work

around this (e.g. by writing "e() / pTrue()" where
the query pTrue() has the postcondition "result = p and in targetState"), I think the issues
are readability and ease of use.

Discussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be reso
lved
and/or why it wasn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 2582


Document
{Report document number}

Page

22



OMG Issue No: 2582

Title:

class EnumerationLiteral issue

Source:

Summary:

I think that the class EnumerationLiteral should be an heir of DataValue (this inheritance
relationship is currently missing).



Once this is fixed, the association between EnumerationLiteral and Enumeration should
be seen as a refinement of the association between DataValue and DataType (itself
implicitly inherited from the association between Instance and classifier), with a
suppl
ementary OCL constraint in the case of EnumerationLiteral, namely that
self.classifier.oclIsKindOf(Enumeration) (to ensure covariance, as is done for DataValue
wrt DataType).



BTW, shouldn"t there be a symetric OCL constraint in DataType specifying that

its
Instances are all DataValues, and similarly in Enumeration specifying that its instances
are all EnumerationLiterals ?

Discussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 3202


Document
{Report document number}

Page

23




O
MG Issue No: 3202

Title:

Another State machine issue

Source:
Klasse Objecten (Dr. Jos Warmer,
j.warmer@klasse.nl
)

Summary:

The metaclass StateVertext, including its subclasses PseudoState, StubState and
SyncState
is not owned by a StateMachine.


The associations from StateVertext to


-

container : CompositeState


-

outgoing : Transition


-

incoming : Tranision

can all be empty. If they are all empty in a model, we do not know to which statemachine
thi
s StateVertex belongs. IS this the intention ?

Discussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 3391


Document
{Report document number}

Page

24




OMG Issue No: 3391

Title:

UML 1.4 RTF Issue: Multiple languages for uninterpr
eted
strings

Source:
ObjectSwitch (Mr. Conrad Bock,
conrad.bock@objectswitch.com
)

Summary:

Multiple languages for uninterpreted strings


The various places that uninterpreted strings are used in UML shou
ld support multiple
languages. For example, the Expression metaclass has an metaattribute for language and
another for the uninterpreted string. This should be a set of such pairs. Then code
generators can target multiple languages from the same model.

D
iscussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 3783


Document
{Report document number}

Page

25




OMG Issue No: 3783

Title:

Interface of an object

Source:
X
-
Change Technologies Group, LLC (Mr. Joaquin Miller,
joaquin.no.spam@acm.org
miller@joaquin.net
)

Summary:

This is a request for an interpretation of UML 1.3.


The question is: Is there a UML 1.3 model element that represents the concept of an
interface on
an object?


--------

Background
-------


Evidently the way to get an interpretation of the meaning of an OMG specification is this:
"If you file the interpretation request as an issue against the relevant FTF/RTF then the
resolution will be your interpre
tation."


The UML submission said:


"... An interface is only a collection of operations with a name; it cannot be directly
instantiated. Instantiable classifiers, such as class or use case, ..."


"UML objects are not modeled as presenting interfaces. A U
ML interface is not
instantiable, so there is not a UML model element that corresponds directly to the
interface of an OMG object."


UML 1.3 says:


"2.5.4 Semantics


"Interface


"... An interface is only a collection of operations with a name. It cannot b
e directly
instantiated. Instantiable classifiers, such as class or use case, ..."


In UML 1.3, there are Instance and Link, which stand for instances of Classifier and
Association. Instance includes DataValue, NodeInstance, ComponentInstance, Object,
an
d LinkObject. SubsystemInstance has been proposed for UML 1.4. There is not any
model element that is a subtype of Instance and corresponds to Interface. (That is, the
association, classifier, of Instance and Classifier does not associate any model elem
ent
with Interface.)


[It is clear that a UML model may include an object that is an instance of a class that
realizes an interface.]

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 3783


Document
{Report document number}

Page

26



--------


I am hoping this is easy to interpret and can be resolved quickly.

Discussion:

{
IF APPLICABLE

-

Summary of how t
he issue was proposed to be resolved
and/or why it wasn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 3898


Document
{Report document number}

Page

27



OMG Issue No: 3898

Title:

Specify XMI parameters for the UML / XMI interchange
format

Source:
DSTC (Dr. Stephen Crawley,
crawle
y@dstc.edu.au
)

Summary:

When the UML spec standardises an XMI
-
generated interchange format for UML
models, it should include:



* the "input" MOF meta
-
model for UML that was used to generate the


interchange format, and



* a formal statement of the
other XMI "parameters" used to generate


the interchange format.


If possible, the UML spec should include a definitive meta
-
model for UML expressed as
a MOF / XMI document. This is a MOF alignment issue.

Discussion:

{
IF APPLICABLE

-

Summary of how th
e issue was proposed to be resolved
and/or why it wasn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 4110


Document
{Report document number}

Page

28



OMG Issue No: 4110

Title:

Semantics of firing compound transitions still appears to
be circular

Source:

Summary:

In UML 1.4 beta R1, the semantics of firing compound trans
itions still appears to be
circular and therefore incorrect. At any rate I am confused by the text so it may be
confusing to others.


As far as I can see the "Least Common Ancestor" is needed to determine the "main
source", but actions following exit from

the "main source" must be performed before the
targets following a choice point are known, so without known targets there is no known
LCA and therefore no specified "main source".


On page 2
-
173 of 2.12:


*** The least common ancestor (LCA) state of a t
ransition is the lowest composite state
that contains all the explicit source states and explicit target states of the compound
transition. In case of junction segments, only the states related to the dynamically
selected path are considered explicit targe
ts (bypassed branches are not considered).


If the LCA is not a concurrent state, the main source is a direct substate of the least
common ancestor that contains the explicit source states, and the main target is a substate
of the least common ancestor th
at contains the explicit target states. In case where the
LCA is a concurrent state, the main source and main target are the concurrent state itself.
The reason is that if a concurrent region is exited, it forces exit of the entire concurrent
state.


[...
]


Once a transition is enabled and is selected to fire, the following steps are carried out in
order:


• The main source state is properly exited.


• Actions are executed in sequence following their linear order along the segments of the
transition: Th
e closer the action to the source state, the earlier it is executed.


• If a choice point is encountered, the guards following that choice point are evaluated
dynamically and a path whose guards are true is selected.


• The main target state is properly
entered. ***

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 4110


Document
{Report document number}

Page

29




This is certainly much better than 1.3. But I still find it difficult to follow:


Since guards following a choice point are evaluated dynamically, the targets are still
unknown when the "main source" is exited. Therefore the LCA is still un
known. How
then does one determine the "main source" as a "direct substate" of the (unknown) LCA?


The (target) "states related to the dynamically selected path" referred to above for
determining the LCA cannot be determined in the case of choice points,
without having
first determined which branches will be taken from the choice points. That requires
performing exit actions for the "main source", then additional actions along the path to
the choice point, in order to determine which branch will be taken.
So the "main source"
must be already known in order to determine the targets.


If one defined the "initial source" as the LCA of the source states then the "main source"
might be any superstate of that "initial source".


With different targets, there mig
ht be additional actions to "properly exit" from enclosing
superstates of the "initial source" before actions along the transition to a choice point.
These could affect which branch is taken and therefore which enclosing superstate of the
"initial source"
must be "properly exited", which would affect which actions are
performed before reaching the choice, and therefore affect the branch taken from the
choice.

Discussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wa
sn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 4263


Document
{Report document number}

Page

30



OMG Issue No: 4263

Title:

Events, signals, stimuli, etc.

Source:
Ecole Polytechnique Federale de Lausanne (Mr. Shane Sendall,
shane.sendall@epfl.ch
)

Summary:

Here is my understa
nding of communication between instances on an example (all quotes
are from UML 1.4 draft (Feb 2001) of the spec). An instance i1 performs a SendAction,
according to the spec: "A send action is an action that results in the (asynchronous)
sending of a sign
al". Then, the signal is delivered to say instance i2, and as a consequence
of the receipt, a SignalEvent is generated (according to the spec, "A signal event
represents the RECEPTION of a particular (asynchronous) signal")

Now the problems:

1) the spec go
es on further to say about the signal event that "A signal event instance
should not be confused with the action (e.g., send action) that generated it". The problem
I have with my above understanding is that the send action should not be the one
generating

the send event but rather the reception of the signal should be the one
generating it.

2)According to the spec: "A signal is a specification of an asynchronous stimulus
communicated between instances" where a stimulus is more general "In the metamodel
Sti
mulus is a communication, i.e. a Signal sent to an Instance, or an invocation of an
Operation". Thus, I conclude that the things sent between instances are stimuli. However,
I'm a little confused of the relationship between events and stimuli with the foll
owing
sentence taken from the spec "Event instances are generated as a result of some action
either within the system or in the environment surrounding the system. An event is then
conveyed to one or more targets. The means by which event instances are tra
nsported to
their destination depend on the type of action, the target,..." Furthermore, how are stimuli
and signals related in the metamodel?

Discussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't}

Disposit
ion:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 4298


Document
{Report document number}

Page

31



OMG Issue No: 4298

Title:

Issue: Conflicting WFRs on Transition

Source:
InteliData Technologies Corporation (Mr. Ed Seidewitz,
eseidewitz@intelidata.com
)

Summary:

WFR 5 for the class Trans
ition states that "Transitions outgoing pseudostates may not
have a trigger" and the OCL supports this absolute statement. However, WFR 6 is
intended to allow transitions out of initial states, which are a kind of pseudostate, to have
"a trigger with the s
tereotype 'create'". Unfortunately, WFR 5 prevents this from ever
being legal.


Recommendation:

Change WFR 5 as follows.


[5] Transitions outgoing pseudostates other than initial states may not have a trigger.


self.source.oclIsKindOf(Pseudostate) implies


self.source.oclAsType(Pseudostate).kind<>#initial implies


(self.trigger
-
>isEmpty())

Discussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 4448


Document
{Report document number}

Page

32




OMG Issue No: 4448

Title:

Doe
s visibility apply to creating an destroying links?

Source:
Kabira Technologies, Inc. (Mr. Conrad Bock,
conrad.bock@nist.gov
)

Summary:

It isn't clear whether visibility of association ends applies to creating an
d destroying
links. If it does, then what if one end is private and the other public, can the private end
create or destroy a link?

Discussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't}

Disposition:

Unres
olved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 4456


Document
{Report document number}

Page

33




OMG Issue No: 4456

Title:

Event => Event Specification

Source:
Kabira Technologies, Inc. (Mr. Conrad Bock,
conrad.bock@nist.gov
)

Summary:

The event metaclass would better called "event specification".
Or at least the runtime
event should be called "occurences" rather than instances.

Discussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 4466


Document
{Report document number}

Page

34



OMG Issue No: 4466

Title:

Compliance ambigu
ity

Source:
Telelogic AB (Mr. Cris Kobryn,
ckobryn@acm.org
)

Summary:

Although the current specification defines the basic units of compliance for UML, it does
not clearly specify the extent to which they may be omitt
ed (via the "no/incomplete"
Valid Options in the summary table on p. xxv) before the implementation is not
considered OMG UML. (As a degenerate case, it could be argued that they all could be
omitted and that an implementation might still claim compliance
.) Further note that the
optional compliance of OCL is discussed as a special case on p. xxiii, although no special
treatment of its compliance is reflected in the summary table. Optional compliance needs
to be more clearly specified before we consider fut
ure optional compliance points, as
some are proposing for the Action Semantics.

Discussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 4504


Document
{Report document number}

Page

35



OMG Issue No: 4504

Title:

Optimize Instance da
ta values

Source:
Adaptive Ltd. (Mr. Pete Rivett,
pete.rivett@adaptive.com
)

Summary:

Although the DataValue class claims to 'have no identity' it nonetheless inherits from
ModelElement and is represented as
a 'normal' object in the interchange as well as the
logical metamodel (so will also inherit annotation and name
-

though presumably it's
'name' that is used to hold the actual value of the DataValue since no attribute seems to be
actually defined for that
purpose). And will it end up becming a first class object by
default in most automatically
-
generated repositories or tool implementations.


There are applictions of UML, and CWM which reuses it, which require a large number
(several thousand) of data inst
ances to be modeled
-

for which requiring a separate
physical/interchange object for each data value is extremely inefficient. Not only does it
double the number of objects, the DataValues have to be contained somewhere
-

which
results in a parent package
not only owning the Instance objects but a large number of
DataValues also which must be filtered out if wanting to navigate from an Instance
Model (for example) to its instances.


Since a DataValue in practice has a 1
-
1 relationship with an AttributeLink
, it is proposed
that in the Interchange Model at least that DataValues be represented as a String attribute
on AttributeLink. For forward compatibility it might be necessary to introduce a subclass
of AttributeLink for this
-

which could even be called 'D
ataSlot' for compatibility with
CWM (an equivalent proposal has been made to CWM RTF which uses 'Slot' instead of
'AttributeLink') And one could retain DataValue in deprecated mode.


NB There is no practical benefit in having the current Link from dataVal
ue to Classifier
(DataType), since this is already linked from the Attribute (and the ability to record that a
DataValue has a subtype of its Attribute's type seems too obscure in comparison to the
cost).

Discussion:

{
IF APPLICABLE

-

Summary of how the is
sue was proposed to be resolved
and/or why it wasn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 4731


Document
{Report document number}

Page

36




OMG Issue No: 4731

Title:

Transition containment problem

Source:

Summary:

According to the UML 1.4 standard, a Transition [UML 1.4, pp. 2
-
147] is contained
either as an "inter
nalTransition" in a State, as a "transition" in a StateMachine, or as an
"ownedElement" [UML 1.4, pp. 2
-
13] in a Model, Package, Artifact, Node or
ClassifierRole (other containers excluded because of restrictions they make on the
"ownedElement" containment

in their wellformedness rules). The latter containment does
not seem to make a lot of sense.


The question is: is the containment of a Transition as an "ownedElement" intended? If so,
please explain the meaning of e.g. a Transition contained directly in a
n otherwise empty
Package.


If not, it should be stated unambiguously so in the wellformedness rules for Transition,
e.g.:



self.namespace = null

Discussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't}

Disp
osition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 4746


Document
{Report document number}

Page

37



OMG Issue No: 4746

Title:

Composite relationship between Event and StateMachine

Source:
Data Access (Eugenio Alvarez,
eugenio
-
a@dataaccess.com
)

Summary:

As previously mentioned in issues

3558 (Who owns an Event?) and 4734 (Event
containment problem). Based upon issue 3558 response I believe that an Event should be
owned by a StateMachine. A composite relationship should be added between Event and
StateMachine in the UML Meta
-
Model.

Discu
ssion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 4816


Document
{Report document number}

Page

38




OMG Issue No: 4816

Title:

Suggest that alternate syntax used in section 6.5.5 be
adopted thoughout

Source:

Summary:

Subclassing of

associations for various reasons leads to having duplicate opposite
association ends with in the same class hierarchy unless the association ends are renamed
for each subclass. A specific example where this has been miss
-
used is throughout the
DMTF CIM sp
ecification.


This rule is derived from section 6.5.4 and is expressed in the well
-
formedness rules in
2.5.3.8 for Classifiers. However, if opposite association end name(rolename) was
qualified by association name, then the navigational reason to not allo
w duplicates goes
away.


Suggest that the alternate syntax used in section 6.5.5 be adopted thoughout. Specifically,
define "rolename = associationName[oppositeassociationend]" Then specify
"classifier.rolename" instead of "classifier.oppositeassociatione
nd." Can then optionally
allow use of "classifier.oppositeassociationend" when usage would not be ambiquous.

Discussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 4932


Document
{Report document number}

Page

39



OMG Issue No: 493
2

Title:

Starting state machine

Source:
Project Technology (Mr. Stephen J. Mellor,
steve@projtech.com
)

Summary:

The action semantics has an action that starts a state machine. The state machine starts in
some kno
wn initial (pseudo
-
)state.


There are many cases where one wants to initialize a state machine so that starts in a
specified (non
-
initial) state.


Therefore the StartStateMachineAction needs to accept a state (possibly multi
-
leveled) as
an input. The stat
e machine will not execute any procedures or actions until after the
state machine is in the target state and then detects an event.

Discussion:

[Action Semantics FTF]:

Application: restoring state.

Requires static specification of state, so complexity wi
ll be the same as having transitions
to each state, and sending an event.

Would make a dependence of actions on state machines.

Similar problems with restoring attribute values, etc, of objects.

Requires tracking and restoring execution execution.

Too much

for FTF to do consistently

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 4936


Document
{Report document number}

Page

40



OMG Issue No: 4936

Title:

StartStateMachine clarification

Source:
Kabira Technologies, Inc. (Mr. Conrad Bock,
conrad.bock@nist.gov
)

Summary:

Does StartStateMa
chine cause the intial state to be entered and its outgoing transition
taken? Ie, what is the semantics in relation to the RTC step.

Discussion:

[Action Semantics FTF]: The 1.4 is contradictory is a couple places:



-

State machine can't rest in pseudost
ate, but transition wf 5 says


transitions from initial states may not have trigger event.



-

and wf 6 says it may have a call event stereotyped as «create».


Defer the above to UML RTF.


Reword StartObjectStateMachine semantics to say it starts the e
xecutions

of the object's state machines.


Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 5107


Document
{Report document number}

Page

41



OMG Issue No: 5107

Title:

Starting a state machine

Source:
InteliData Technologies Corporation (Mr. Ed Seidewitz,
eseidewitz@intelidata.com
)

Summary:

Description:

The State Machines chapter (Section 2.12) does not provide a clear description of what it
means to "start" a state machine.


Syntactically, we have the following:


o Well
-
formedness rule [1] for Pseudostate (p. 2
-
157) says "An in
itial vertex [i.e., a
initial pseudostate] can have at most one outgoing transition and no incoming
transitions". Presumably, it is the single transition from the initial pseudostate at the top
level that is taken when the state machine starts.


o Well
-
fo
rmedness rule [6] for Transition (p. 2
-
160) says "An initial transition at the
topmost level either has no trigger [i.e., event] or it has a trigger with the stereotype
'create'." Thus, the ONLY kind of event allowed on an initial transition is a "creation

event".


o The definition of the stereotype «create» is (p. 2
-
149):


"Create is a stereotyped call event denoting that the instance receiving

that event has just been created. For state machines, it triggers the

initial transition at the topmost level
of the state machine (and is the

only kind of trigger that may be applied to an initial transition)."


Thus, a "creation event" MUST be a call event.


o However, well
-
formedness rule [5] for Transition (p. 2
-
160) states without
qualification, that "Tran
sitions outgoing pseudostates may not have a trigger"! This
prohibits all together the "creation events" allowed by rule [6].


Semantically, there is no specific discussion of how a state machine "starts". Section
2.12.4.3 describes "Entering a non
-
concurr
ent composite state" on p. 2
-
162 and "Entering
a concurrent composite state" on p. 2
-
163. Since the top state of a state machine must be
a composite state, one could assume that "starting" a state machine has the semantics of
entering the composite top sta
te. However, this does not provide an explanation of the
"creation events" allowed (or at least seem intended to be allowed) in the special case of
the initial transition at the top level.


UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 5107


Document
{Report document number}

Page

42



Now, well
-
formedness rule [5] of StateMachine says "If a StateMach
ine describes a
behavioral feature, it contains no triggers of type CallEvent, apart from the trigger on the
initial transition (see OCL for Transition [8])" (this is probably intended to refer to
Transition rule [6]). Presumably, then, the call event on t
he initial transition is suppose to
be the call event for the behavioral feature described by the state machine, at least in this
case, but this is not described in the semantics (and it doesn't make sense for this event to
be a "creation" event, anyway).


This issue came out during the finalization of the Action Semantics. In the Action
Semantics, when an object is created, any state machine associated with the object (via its
classifiers) are NOT started automatically. Instead, there is an explicit
"Start
StateMachineAction" which is supposed to "start the execution of the state
machines." However, it is not clear from the current state machine semantics what it
really means to do this.


Recommendation:


1. Describe the "start" of the execution of a state
machine as an RTC step from an
implicit "not started" state (that is, not explicitly modeled in the state machine) to the
target of the initial transition of the state machine (that is, the single transition with the
top
-
level initial pseudo
-
state as its s
ource). This RTC step includes the execution of any
relevant transition actions and entry actions, per the usual state machine semantics.


2. Define that, if no other explicit specification is given in a model, a state machine
associated with a classifier
is assumed to start when an instance of the classifier is created
and a state machine associated with a behavioral feature is assumed to start when that
feature is invoked. (When the action semantics is included, a formal specification of the
start of a st
ate machine can be given with the StartStateMachineAction.)


3. Change well
-
formedness rule [5] to exclude the top initial pseudo
-
state.


4. Change well
-
formedness rule [6] to allow, if the state machine describes a behavioral
feature, a trigger (call eve
nt or signal event) on the initial transition that corresponds to
that behavioral feature.


5. If the state machine describes a classifier, then, in the absence of the action semantics,
it is unclear whether a "creation event" is really useful at all (par
ticularly since it would
only allow for a single creation operation). With the action semantics, such an event is
probably unnecessary, since the procedure for a creation operation will then be able to
explicitly create an instance (using CreateObjectActio
n), start the state machine of that
instance (using a StartStateMachineAction), which will get the state machine into a "real"
state, and then send the instance a message (using an ExplicitInvocationAction), which
can be handled by an event on the state ma
chine, with any additional data required for
initialization.

Discussion:

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 5107


Document
{Report document number}

Page

43



{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 5273


Document
{Report document number}

Page

44



OMG Issue No: 5273

Title:

Initial state for composite states
-

OC
L example and
missing constraint

Source:
Adaptive Ltd. (Mr. Pete Rivett,
pete.rivett@adaptive.com
)

Summary:

This issue was triggered by what seemed to be an ill
-
formed state machine example
which revealed a
deeper lack of rigor in the spec.


The example state machine in section 6.5.10 (illustrating oclInState) does not have an
initial pseudostate within the 'Off' state. Section 3.80.2 indicates that this is mandatory:

"A transition drawn to a composite state
boundary indicates a transition to the composite
state. This is equivalent to a transition to the initial pseudostate within the composite state
region. The initial pseudostate must be present."


[Aside: There's also typo in the list of valid OCL expressio
ns in 6.5.10:
object.oclInState(Off:NoPower) should have a double colon:
object.oclInState(Off::NoPower)].


If indeed it is mandatory to have an initial state where there is a transition to a composite
state (this does seem sensible for predictability), th
is should be reflected in a constraint
within the abstract Syntax (section 2.12) to the effect that a CompositeState with
'incoming' Transitions must contain an initial PseudoState.


For example 2.12.4.3 contains the following which implies an initial pseu
dostate, though
uses the ill
-
defined 'default transition' as well as 'initial transition':

"Entering a non
-
concurrent composite state Upon entering a composite state, the
following cases are differentiated:

• Default entry: Graphically, this is indicated b
y an incoming transition that terminates on
the outside edge of the composite state. In this case, the default transition is taken. If
there is a guard on the transition it must be enabled (true). (A disabled initial transition is
an ill
-
defined execution
state and its handling is not defined.) The entry action of the state
is executed before the action associated with the initial transition."


Proposed Resolution

-------------------


1. Change example in 6.5.10 to add an initial pseudostate within the 'Off
' composite with
a transition to 'Standby'.


2. Correct typo in 6.5.10 valid expressions: object.oclInState(Off:NoPower) should have
a double colon: object.oclInState(Off::NoPower)


UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 5273


Document
{Report document number}

Page

45



3. Add the following constraint to section 2.12.3.1


[7] A composite stat
e with an incoming transition must have an initial state.


self.incoming
-
>notEmpty() implies


self.subvertex
-
>select (v | v.oclIsKindOf(Pseudostate))
-
>select(p
:

Pseudostate | p.kind = #initial)
-
>size = 1


4. Alter the section in 2.12.4.3 to read as
follows:

"Entering a non
-
concurrent composite state Upon entering a composite state, the
following cases are differentiated:

• Default entry: Graphically, this is indicated by an incoming transition that terminates on
the outside edge of the composite stat
e. In this case, there must be an initial state and the
initial transition is taken. If there is a guard on the transition it must be enabled (true). (A
disabled initial transition is an ill
-
defined execution state and its handling is not defined.)
The ent
ry action of the state is executed before the action associated with the initial
transition."

Discussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 5433


Document
{Report document number}

Page

46



OMG Issue No: 5433

Title:

How to

properly designate exception returned from
message sent to Java object

Source:
ObjectShare (Ms. Rebecca Wirfs
-
Brock,
rebecca@parcplace.com
)

Summary:

I am trying to properly designate an exception returned from

a message sent to a Java
object.


In UML a return is drawn as a dashed line with an open arrow. But is that the same for an
exception returned? I can stereotype a return with the «exception» which is fine , but how
do I properly draw the returned excepti
on. I don't think the exception should be drawn the
same as an asynchronous signal because control pops out from the exception raiser and
returns to the callee at the exception handling point (it is the result of the original call, but
the exception return

is to a different point in the flow).... so it isn't exactly a signal.... but
it does alter the control flow..


So in my mind, if I wanted to show a returned exception, I should draw it like a return
(dashed line with open stick arrowhead) labelled «exce
ption»


But I defer to someone with more expertise to untangle this for me. I spent time and
could not find an answer to this in the UML 1.4 docs

Discussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't}

Disp
osition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 5799


Document
{Report document number}

Page

47




OMG Issue No: 5799

Title:

2.5.2.27 ModelElement

Source:
ManaSoft (Mr. Jeff Barnes,
jeff.barnes@mnsft.com
)

Summary:

The text:


implementationLocation The component that an implemented mode
l element resides in.


disagrees with the * cardinality of the implementationLocation association end of the
ModelElement
-

Component association in Figure 2
-
8 Core Package
-

Classifiers on page
2
-
16.

Discussion:

{
IF APPLICABLE

-

Summary of how the issue
was proposed to be resolved
and/or why it wasn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 5802


Document
{Report document number}

Page

48



OMG Issue No: 5802

Title:

2.5.2.15 Dependency

Source:
ManaSoft (Mr. Jeff Barnes,
jeff.barnes@mnsft.com
)

Summary:

The text "client The
element that is affected by the supplier element. In some cases (such
as a Trace Abstraction) the direction is unimportant and serves only to distinguish the two
elements." disagrees with the 1..* cardinality on the client association end of the
associatio
n between Dependency and ModelElement (Figure 2
-
7 on page 2
-
15).


The same issue applies to the supplier association end and its documentation.

Discussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't}

Dispos
ition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 5886


Document
{Report document number}

Page

49



OMG Issue No: 5886

Title:

behaviour of the shallow history state and deep history
state

Source:
Remedy IT (Mr. Johnny Willemsen,
jwillemsen@remedy.nl
)

Summary:

In the UML specification the beh
aviour of the shallow history state and deep history state
are described (added below). The final state is seen as a real state in UML which can
have entry actions and in which can be stayed. When a child composite state is in its final
state and at a high
er level a transition is taken to an other state and then to the deep
history state we expect that the final state is set active again, instead that then default
history state is made active. For example we have a composite state that does the setup of
a p
iece of hardware and it is in the final state, but it doesn't leave the composite state
because another condition is not true yet. When now the composite state is left at a higher
level (for example emergency), then we go back according to the spec to the
default
history state, so we do the complete setup again, but we expect to return in the final state.


Shallow history entry: If the transition terminates on a shallow history pseudostate, the
active substate becomes the most recently active substate prio
r to this entry, unless the
most recently active substate is the final state or if this is the first entry into this state. In
the latter two cases, the default history state is entered. This is the substate that is target
of the transition originating fro
m the history pseudostate. (If no such transition is
specified, the situation is illegal and its handling is not defined.) If the active substate
determined by history is a composite state, then it proceeds with its default entry. • Deep
history entry: The

rule here is the same as for shallow history except that the rule is
applied recursively to all levels in the active state configuration below this one.

Discussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't
}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 5924


Document
{Report document number}

Page

50



OMG Issue No: 5924

Title:

representation of arrays of values in an action language

Source:

Summary:

While looking at the representation of arrays of values in an action language we
discovered, that it is not clear whether arrays

may be represented as structural features
with a multiplicity according to the array dimension. Example: int[23] foo; would be
represented as attribute foo:int [0..23];


However, an attribute is a structural feature and the multiplicity of it is defined
as "the
cardinality of the set of values" (chap. 2.5.2.37, p. 2
-
49). This leads us to the conclusion,
that attributes with a multiplicity range greater than one have set characteristics (in a
mathematical sense), that is, no duplicate values would be allow
ed. Is our assumption to
use multiplicities for representation of arrays wrong, or is our view of a "set of values" as
a mathematical set too strict?


Anyway, another question in this context arises: Regarding the figure 2
-
47 (chap. 2.21.2
p. 2
-
254) we wo
nder if the association with the "insertAt" rolename at InputPin of
AddAttributeValueAction is an indicator for bag characteristics (array semantics)? On the
other hand the definition of RemoveAttributeValueAction suggests that every value
exists only once
, in other words, set characteristics.

Discussion:

{
IF APPLICABLE

-

Summary of how the issue was proposed to be resolved
and/or why it wasn't}

Disposition:

Unresolved

UML
2.0 Superstructure FTF


Disposition: Unresolved

OMG Issue No: 5951


Document
{Report document number}

Page

51



OMG Issue No: 5951

Title:

UML 2.0 Superstructure: Operation vs. Attribute notation

Sour
ce:
Mercury Computer Systems (Mr. Frank Pilhofer,
fp@mc.com
)

Summary:


For reference, my copy here is ad/03