OMG Specification

Unified Modeling Language — All Issues

Acronym: UML
Issues Count: 903
Description: All Issues

Issues Summary

Key	Issue	Reported	Fixed	Disposition	Status
UML22-1381	presentation option for transitions	UML 2.0	UML 2.1.1	Resolved	closed
UML22-1379	Figure 109, p162	UML 2.0	UML 2.1	Resolved	closed
UML22-1378	LinkEndData - Inconsistency with Figure 146	UML 2.0	UML 2.1	Closed; No Change	closed
UML22-1377	UML-2 deployment diagram notation	UML 2.0	UML 2.1	Resolved	closed
UML22-1376	section on connectors in the component chapter	UML 2.0	UML 2.1	Resolved	closed
UML22-1375	7.3.41 Parameter (from Kernel, AssociationClasses)"	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1374	Profiles::ObjectNode has wrong default multiplicity	UML 2.1	UML 2.1.1	Resolved	closed
UML22-1373	Section: 12.3.52	UML 2.0	UML 2.1	Resolved	closed
UML22-1367	Section: Composite Structures/Abstract syntax	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1366	ptc/06-01-02:14.3.14, Notation	UML 2.1	UML 2.1.1	Resolved	closed
UML22-1365	Events	UML 2.0	UML 2.1	Resolved	closed
UML22-1364	Additional events for Interactions	UML 2.0	UML 2.1	Resolved	closed
UML22-1363	Incorrect constraints on Pin and ObjectFlow On Pin	UML 2.0	UML 2.1	Resolved	closed
UML22-1362	resolution to issue 6093 removed too much constraint	UML 2.0	UML 2.1	Resolved	closed
UML22-1361	Section: 9.3.12	UML 2.0	UML 2.1	Resolved	closed
UML22-1360	Section: 7.11.4	UML 2.0	UML 2.1	Resolved	closed
UML22-1359	Notation for property has gone missing	UML 2.0	UML 2.1	Resolved	closed
UML22-1358	ReadSelfAction	UML 2.0	UML 2.1	Resolved	closed
UML22-1357	Attribute scope is of type StructuredActivityNode instead of StructuredActi	UML 2.0	UML 2.1	Resolved	closed
UML22-1356	Section: 12.3.16	UML 2.0	UML 2.1	Resolved	closed
UML22-1355	What are the "edges" we're talking about?	UML 2.0	UML 2.1	Resolved	closed
UML22-1354	Section: 12.3.3	UML 2.0	UML 2.1	Resolved	closed
UML22-1353	Figure 205, p292:	UML 2.0	UML 2.1	Resolved	closed
UML22-1350	Figure 51, p106	UML 2.0	UML 2.1	Resolved	closed
UML22-1349	ExceptionHandler	UML 2.0	UML 2.1	Resolved	closed
UML22-1352	figure 175	UML 2.0	UML 2.1	Resolved	closed
UML22-1351	Figure 52, p107: shouldn't the <> relationship be reversed ?	UML 2.0	UML 2.1	Resolved	closed
UML22-1348	Section: 12.3.16 -- Typo	UML 2.0	UML 2.1	Resolved	closed
UML22-1347	Templates, Classifier	UML 2.0	UML 2.1	Resolved	closed
UML22-1346	ProtocolConformance - inconsistency with Figure 356	UML 2.0	UML 2.1	Resolved	closed
UML22-1341	Can connectors co-operate?	UML 2.0	UML 2.1	Resolved	closed
UML22-1345	ParameterableElement - constraint [2] - error in OCL	UML 2.0	UML 2.1	Resolved	closed
UML22-1344	TemplateableElement - inconsistency	UML 2.0	UML 2.1	Resolved	closed
UML22-1343	TemplateSignature - Typo	UML 2.0	UML 2.1	Resolved	closed
UML22-1342	TemplateSignature - inconsistency	UML 2.0	UML 2.1	Resolved	closed
UML22-1338	association "implementingClassifier	UML 2.0	UML 2.1	Resolved	closed
UML22-1340	Removed text in 9.3.3	UML 2.0	UML 2.1	Resolved	closed
UML22-1339	$issue.summary	UML 2.0	UML 2.1	Resolved	closed
UML22-1337	PrimitiveFunction	UML 2.0	UML 2.1	Resolved	closed
UML22-1336	MarshallAction and UnmarshallAction	UML 2.0	UML 2.1	Resolved	closed
UML22-1335	Constraint 2 of AcceptEventAction - typo	UML 2.0	UML 2.1	Resolved	closed
UML22-1334	SAN semantics for starting and stopping	UML 2.0	UML 2.1	Resolved	closed
UML22-1333	Variable pins Extend input and output pins to get and set variables	UML 2.0	UML 2.1	Resolved	closed
UML22-1332	Activities	UML 2.0	UML 2.1	Resolved	closed
UML22-1331	p.352, section 12.3.35. The attribute Parameter.isStream is inappropriate	UML 2.0	UML 2.1	Resolved	closed
UML22-1330	empty sections in activities chapter	UML 2.0	UML 2.1	Resolved	closed
UML22-1329	p.328, Figure 245, and p.331, Figure 249	UML 2.0	UML 2.1	Resolved	closed
UML22-1328	Inappropriate to reference RFP documents	UML 2.0	UML 2.1	Resolved	closed
UML22-1327	attribute Activity.isSingleExecution	UML 2.0	UML 2.1	Resolved	closed
UML22-1326	Section 9.3.5. (ConnectableElement)	UML 2.0	UML 2.1	Resolved	closed
UML22-1325	Section 9.3.1	UML 2.0	UML 2.1	Resolved	closed
UML22-1324	typo	UML 2.0	UML 2.1	Resolved	closed
UML22-1323	typo	UML 2.0	UML 2.1	Resolved	closed
UML22-1322	component deployment	UML 2.0	UML 2.1	Resolved	closed
UML22-1321	signal	UML 2.0	UML 2.1	Resolved	closed
UML22-1320	association between two Nodes	UML 2.0	UML 2.1	Resolved	closed
UML22-1319	Figure 273 - Arrow direction Figure 273	UML 2.0	UML 2.1	Resolved	closed
UML22-1318	ParameterSet - Typo	UML 2.0	UML 2.1	Resolved	closed
UML22-1317	ObjectNode	UML 2.0	UML 2.1	Resolved	closed
UML22-1316	ActivityEdge - Typo	UML 2.0	UML 2.1	Resolved	closed
UML22-1315	ActivityEdge - Section Semantics - Typo	UML 2.0	UML 2.1	Resolved	closed
UML22-1313	formal parameter or a return result	UML 2.0	UML 2.1	Resolved	closed
UML22-1314	typo p. 149	UML 2.0	UML 2.1	Resolved	closed
UML22-1312	association "context"	UML 2.0	UML 2.1	Resolved	closed
UML22-1311	behaviors	UML 2.0	UML 2.1	Resolved	closed
UML22-1309	Page: 589	UML 2.0	UML 2.1	Resolved	closed
UML22-1308	Section: 12.3.20	UML 2.0	UML 2.1	Resolved	closed
UML22-1307	enumerated type MessageSort	UML 2.0	UML 2.1	Resolved	closed
UML22-1310	There is no redefinitionContext established	UML 2.0	UML 2.1	Resolved	closed
UML22-1306	heading of table 19	UML 2.0	UML 2.1	Resolved	closed
UML22-1305	Notation of ExecutionOccurrence	UML 2.0	UML 2.1	Resolved	closed
UML22-1304	Section: 15.3.12	UML 2.0	UML 2.1	Resolved	closed
UML22-1303	introductory text for Property states	UML 2.0	UML 2.1	Resolved	closed
UML22-1301	notation for statemachine transitions omitted from spec	UML 2.0	UML 2.1	Resolved	closed
UML22-1300	behavior packages (Interactions, Statemachines	UML 2.0	UML 2.1	Resolved	closed
UML22-1302	"Implementation" is ommitted	UML 2.0	UML 2.1	Resolved	closed
UML22-1299	InformationItem - Typo	UML 2.0	UML 2.1	Resolved	closed
UML22-1298	ReadLinkObjectEndQualifierAction - errors in OCL	UML 2.0	UML 2.1	Resolved	closed
UML22-1296	StartOwnedBehaviorAction - OCL error in constraint	UML 2.0	UML 2.1	Resolved	closed
UML22-1297	ReadLinkObjectEndAction - errors in OCL	UML 2.0	UML 2.1	Resolved	closed
UML22-1294	ReplyAction - Typo	UML 2.0	UML 2.1	Resolved	closed
UML22-1293	ReplyAction - Inconsistency with Figure 150	UML 2.0	UML 2.1	Resolved	closed
UML22-1292	AcceptCallEvent - inconsistent multiplicity " trigger	UML 2.0	UML 2.1	Resolved	closed
UML22-1295	ReadIsClassifiedObjectAction - OCL errors in constraints	UML 2.0	UML 2.1	Resolved	closed
UML22-1291	AcceptEventAction - inconsistencies in Semantics and typos	UML 2.0	UML 2.1	Resolved	closed
UML22-1290	AcceptEventAction - inconsistency	UML 2.0	UML 2.1	Resolved	closed
UML22-1289	AcceptEventAction - inconsistent multiplicities	UML 2.0	UML 2.1	Resolved	closed
UML22-1288	Message - inconsistency "Messageident equalling *	UML 2.0	UML 2.1	Resolved	closed
UML22-1287	Message - inconsistency (02)	UML 2.0	UML 2.1	Resolved	closed
UML22-1286	Message - inconsistency	UML 2.0	UML 2.1	Resolved	closed
UML22-1285	Figure 77	UML 2.0	UML 2.1	Resolved	closed
UML22-1284	Interface - Typos in Figure 63	UML 2.0	UML 2.1	Resolved	closed
UML22-1282	Connector - inconsistency	UML 2.0	UML 2.1	Resolved	closed
UML22-1281	Connector - typo and inconsistency	UML 2.0	UML 2.1	Resolved	closed
UML22-1283	ConnectorEnd - multipliciy of role	UML 2.0	UML 2.1	Resolved	closed
UML22-1280	Connector - inconsistency	UML 2.0	UML 2.1	Resolved	closed
UML22-1279	Typo in ptc/03-08-02 p. 178	UML 2.0	UML 2.1	Resolved	closed
UML22-1278	Typo Section: 12.3.8	UML 2.0	UML 2.1	Resolved	closed
UML22-1275	Stereotype - Inconsistency in notation Section "Notation", last sentence	UML 2.0	UML 2.1	Resolved	closed
UML22-1274	Stereotype - typo in OCL	UML 2.0	UML 2.1	Resolved	closed
UML22-1277	ActivityPartition - inconsistencies	UML 2.0	UML 2.1	Resolved	closed
UML22-1276	Typo In section "Description"	UML 2.0	UML 2.1	Resolved	closed
UML22-1271	AddVariableValueAction - OCL in constraint [1] not correct	UML 2.0	UML 2.1	Resolved	closed
UML22-1273	Stereotype	UML 2.0	UML 2.1	Resolved	closed
UML22-1272	Typo, section "Description", paragraph 1	UML 2.0	UML 2.1	Resolved	closed
UML22-1270	VariableAction - undefined query	UML 2.0	UML 2.1	Resolved	closed
UML22-1267	ReadLinkAction - Constraints use deprecated UML elements	UML 2.0	UML 2.1	Resolved	closed
UML22-1266	ReadLinkAction - inconsistency with Figure 147	UML 2.0	UML 2.1	Resolved	closed
UML22-1269	Variable - Typo in Attributes	UML 2.0	UML 2.1	Resolved	closed
UML22-1268	DestroyLinkAction - Semantics based on non existing "settability addOnly"	UML 2.0	UML 2.1	Resolved	closed
UML22-1265	MultiplicityElement - section is obsolete	UML 2.0	UML 2.1	Resolved	closed
UML22-1264	LinkEndData - Additional operation not correct	UML 2.0	UML 2.1	Resolved	closed
UML22-1263	LinkEndData - Typo in OCL	UML 2.0	UML 2.1	Resolved	closed
UML22-1262	AddStructuralFeatureValueAction - Settability removeOnly does not exist	UML 2.0	UML 2.1	Resolved	closed
UML22-1260	DestroyObjectAction - inconsistency in constraints	UML 2.0	UML 2.1	Resolved	closed
UML22-1259	Component - problem with provided interfaces (see also Issue 6875, 6338)	UML 2.0	UML 2.1	Resolved	closed
UML22-1261	Typo - section Description, first sentence	UML 2.0	UML 2.1	Resolved	closed
UML22-1258	Manifestation - visual representation should be dashed arrow	UML 2.0	UML 2.1	Resolved	closed
UML22-1256	Deployment - keyword <> not introduced	UML 2.0	UML 2.1	Resolved	closed
UML22-1255	InteractionOccurrence - Syntax rules for name not clear	UML 2.0	UML 2.1	Resolved	closed
UML22-1257	DeploymentTarget - Missing OCL expression	UML 2.0	UML 2.1	Resolved	closed
UML22-1254	Figure 95	UML 2.0	UML 2.1	Resolved	closed
UML22-1253	Connector - Constraint [3] not necessary ?	UML 2.0	UML 2.1	Resolved	closed
UML22-1252	Connector - Constraint [2] is inprecise	UML 2.0	UML 2.1	Resolved	closed
UML22-1251	ReadSelfAction - Typos in OCL constraints	UML 2.0	UML 2.1	Resolved	closed
UML22-1249	Typo	UML 2.0	UML 2.1	Resolved	closed
UML22-1248	Typo	UML 2.0	UML 2.1	Resolved	closed
UML22-1250	ReadSelfAction - delete constraint [4]	UML 2.0	UML 2.1	Resolved	closed
UML22-1247	TestIdentityAction - additional constraint	UML 2.0	UML 2.1	Resolved	closed
UML22-1246	TestIdentityAction- delete constraint [2]	UML 2.0	UML 2.1	Resolved	closed
UML22-1245	Typo	UML 2.0	UML 2.1	Resolved	closed
UML22-1244	DeleteObjectAction - delete constraint [1]	UML 2.0	UML 2.1	Resolved	closed
UML22-1241	SendSignalAction	UML 2.0	UML 2.1	Resolved	closed
UML22-1240	Delete the following sentence in section "Notation":	UML 2.0	UML 2.1	Resolved	closed
UML22-1243	CreateObjectAction - delete constraint [4]	UML 2.0	UML 2.1	Resolved	closed
UML22-1242	Typo	UML 2.0	UML 2.1	Resolved	closed
UML22-1239	Sentence not finished in section "Changes from previous UML"	UML 2.0	UML 2.1	Resolved	closed
UML22-1235	Collaboration - inconsistency with Figure 99	UML 2.0	UML 2.1	Resolved	closed
UML22-1237	Typo in Figure 124 on page 182	UML 2.0	UML 2.1	Resolved	closed
UML22-1236	StructuredClassifier - Regular expression for namestring too complicated	UML 2.0	UML 2.1	Resolved	closed
UML22-1238	Typo	UML 2.0	UML 2.1	Resolved	closed
UML22-1233	GeneralizationSet - constraints expressed in OCL	UML 2.0	UML 2.1	Resolved	closed
UML22-1232	GeneralizationSet - Incorrect Mulitiplicities of associations	UML 2.0	UML 2.1	Resolved	closed
UML22-1234	GeneralizationSet - example in section "Semantics" is not clear	UML 2.0	UML 2.1	Resolved	closed
UML22-1231	GeneralizationSet description conf. about meaning of "specific" + "general	UML 2.0	UML 2.1	Resolved	closed
UML22-1230	GeneralizationSet - outdated description	UML 2.0	UML 2.1	Resolved	closed
UML22-1229	Region - Additional structural constraints necessary	UML 2.0	UML 2.1	Resolved	closed
UML22-1228	Constraint [2], p.70	UML 2.0	UML 2.1	Resolved	closed
UML22-1227	Figure 355 - mulitplicities of redefinitionContext should be 0..1	UML 2.0	UML 2.1	Resolved	closed
UML22-1226	Figure 355 - ownedStateMachine should subset ownedBehavior	UML 2.0	UML 2.1	Resolved	closed
UML22-1225	Typo p 497	UML 2.0	UML 2.1	Resolved	closed
UML22-1221	State - Constraints - errors in OCL and inconsistencies	UML 2.0	UML 2.1	Resolved	closed
UML22-1223	Change Constraint [1] to	UML 2.0	UML 2.1	Resolved	closed
UML22-1222	Non-existent property isFinal referenced	UML 2.0	UML 2.1	Resolved	closed
UML22-1224	ownedStateMachine not described correctly	UML 2.0	UML 2.1	Resolved	closed
UML22-1220	Define containingStateMachine() for Vertex	UML 2.0	UML 2.1	Resolved	closed
UML22-1219	State - Inconsistency	UML 2.0	UML 2.1	Resolved	closed
UML22-1218	p.461, first sentence:	UML 2.0	UML 2.1	Resolved	closed
UML22-1216	AssociationClass - Additional Operation [1] should be deleted	UML 2.0	UML 2.1	Resolved	closed
UML22-1215	AssociationClass Constraint [1] should be reformulated	UML 2.0	UML 2.1	Resolved	closed
UML22-1214	Association - endType should be of type Classifier	UML 2.0	UML 2.1	Resolved	closed
UML22-1217	Constraints of ConnectionPointReference - OCL not correct	UML 2.0	UML 2.1	Resolved	closed
UML22-1213	Stereotype «buildComponent» defined twice, description not clear	UML 2.0	UML 2.1	Resolved	closed
UML22-1212	Typo p 589	UML 2.0	UML 2.1	Resolved	closed
UML22-1210	ExtensionPoint should be a specialization of Feature (from Kernel)	UML 2.0	UML 2.1	Resolved	closed
UML22-1211	Typo p 587	UML 2.0	UML 2.1	Resolved	closed
UML22-1209	Multiplicity of extensionLocation should be 1..1 instead of 1..*	UML 2.0	UML 2.1	Resolved	closed
UML22-1207	Constraint not precise enough	UML 2.0	UML 2.1	Resolved	closed
UML22-1206	Unnecessary sentence p 339	UML 2.0	UML 2.1	Resolved	closed
UML22-1208	Imprecise sentence p 334	UML 2.0	UML 2.1	Resolved	closed
UML22-1205	"Joining of tokens" not clear	UML 2.0	UML 2.1	Resolved	closed
UML22-1204	Typo p 339	UML 2.0	UML 2.1	Resolved	closed
UML22-1203	Typo - Missing colon p 302	UML 2.0	UML 2.1	Resolved	closed
UML22-1201	Constraint not precise enough	UML 2.0	UML 2.1	Resolved	closed
UML22-1200	Typo p 320	UML 2.0	UML 2.1	Resolved	closed
UML22-1202	No Activity Edges from with equal source and target	UML 2.0	UML 2.1	Resolved	closed
UML22-1197	Typo p 161	UML 2.0	UML 2.1	Resolved	closed
UML22-1196	Another Inconsistency with Figure 100	UML 2.0	UML 2.1	Resolved	closed
UML22-1199	Multiple activity edges between a given pair of activity nodes possible ?	UML 2.0	UML 2.1	Resolved	closed
UML22-1198	Inconsistency between constraint of ControlNode and Semantics of JoinNode	UML 2.0	UML 2.1	Resolved	closed
UML22-1195	Inconsistency with Figure 100	UML 2.0	UML 2.1	Resolved	closed
UML22-1194	Figure 103 at the wrong place	UML 2.0	UML 2.1	Resolved	closed
UML22-1193	Connector - default value für "kind"	UML 2.0	UML 2.1	Resolved	closed
UML22-1192	Typo p 137	UML 2.0	UML 2.1	Resolved	closed
UML22-1191	Missing multiplicities	UML 2.0	UML 2.1	Resolved	closed
UML22-1190	Typo p. 595, Table 25, row 6, column 3	UML 2.0	UML 2.1	Resolved	closed
UML22-1189	Additional Operations specification of NamedElement::allNamespaces()	UML 2.0	UML 2.1	Resolved	closed
UML22-1186	Second row of table 22, column "Notation", labels switched	UML 2.0	UML 2.1	Resolved	closed
UML22-1185	UseCase - Inconsistencies with Figure 401	UML 2.0	UML 2.1	Resolved	closed
UML22-1188	typo	UML 2.0	UML 2.1	Resolved	closed
UML22-1187	Typo in OCL	UML 2.0	UML 2.1	Resolved	closed
UML22-1184	UseCase - Extend is not a Namespace	UML 2.0	UML 2.1	Resolved	closed
UML22-1183	Inconsistent multiplicity	UML 2.0	UML 2.1	Resolved	closed
UML22-1182	Inconsistency betw. Figure 328 and associations listed in s. Associations	UML 2.0	UML 2.1	Resolved	closed
UML22-1180	Wrong association name	UML 2.0	UML 2.1	Resolved	closed
UML22-1179	Constraint [2] - Missing parenthesis in OCL	UML 2.0	UML 2.1	Resolved	closed
UML22-1181	type p 419	UML 2.0	UML 2.1	Resolved	closed
UML22-1178	Inconsistency between section "Associations" and Figure 327	UML 2.0	UML 2.1	Resolved	closed
UML22-1177	typo p 340	UML 2.0	UML 2.1	Resolved	closed
UML22-1176	object edges" should be replaced by "object flows	UML 2.0	UML 2.1	Resolved	closed
UML22-1172	graphic nodes	UML 2.0	UML 2.1	Resolved	closed
UML22-1171	typo p 421	UML 2.0	UML 2.1	Resolved	closed
UML22-1175	object edges" sould be replaced by "object flows	UML 2.0	UML 2.1	Resolved	closed
UML22-1174	typo p 356	UML 2.0	UML 2.1	Resolved	closed
UML22-1173	typo p 240	UML 2.0	UML 2.1	Resolved	closed
UML22-1170	typo p 420	UML 2.0	UML 2.1	Resolved	closed
UML22-1169	typo p 403	UML 2.0	UML 2.1	Resolved	closed
UML22-1168	Inconsistencies between Figure 43 and the detailled description of Package	UML 2.0	UML 2.1	Resolved	closed
UML22-1165	The section "Associations (BasicActivities)" is not complete	UML 2.0	UML 2.1	Resolved	closed
UML22-1164	The query 'hostElement' has some errors	UML 2.0	UML 2.1	Resolved	closed
UML22-1167	Inconsistencies between Figure 3 and the detailled description of package	UML 2.0	UML 2.1	Resolved	closed
UML22-1166	/context : Classifier [0..1]	UML 2.0	UML 2.1	Resolved	closed
UML22-1163	See CommonBehavior for a description of Event specifications	UML 2.0	UML 2.1	Resolved	closed
UML22-1162	page 95 diagram	UML 2.0	UML 2.1	Resolved	closed
UML22-1161	On templateableElment - additonal features	UML 2.0	UML 2.1	Resolved	closed
UML22-1160	Figure 346 needs updating	UML 2.0	UML 2.1	Resolved	closed
UML22-1157	Incorrect mentioning of General Order On p 412	UML 2.0	UML 2.1	Resolved	closed
UML22-1159	Omission of non-terminal arguments (p. 424)	UML 2.0	UML 2.1	Resolved	closed
UML22-1158	Remove occurrences of TBD	UML 2.0	UML 2.1	Resolved	closed
UML22-1153	Message notation. Incorrect notation in Figure 333 p.414	UML 2.0	UML 2.1	Resolved	closed
UML22-1155	Message End association to Interaction should be removed	UML 2.0	UML 2.1	Resolved	closed
UML22-1154	Strict ordering in Inline Part Decomposition	UML 2.0	UML 2.1	Resolved	closed
UML22-1156	EventOccurrence, multiplicities incorrect in metamodel diagram	UML 2.0	UML 2.1	Resolved	closed
UML22-1152	On page 140, the title for Parameter is "Parameter (Collaboration, as speci	UML 2.0	UML 2.1	Resolved	closed
UML22-1151	The title of the Property description on page 144	UML 2.0	UML 2.1	Resolved	closed
UML22-1150	labels for ExecutionOccurrence	UML 2.0	UML 2.1	Resolved	closed
UML22-1149	duration observation" vs DurationObservationAction etc	UML 2.0	UML 2.1	Resolved	closed
UML22-1148	Missing sections for for enumeration MessageKind or MessageSor	UML 2.0	UML 2.1	Resolved	closed
UML22-1147	figure 8-137 and 8-139	UML 2.0	UML 2.1	Resolved	closed
UML22-1146	CommonBehaviors describes "Operation (from Communications, as specialized)	UML 2.0	UML 2.1	Resolved	closed
UML22-1144	inconsistency between figure 5.1 on page 179 and figure 7-122 on page 337.	UML 2.0	UML 2.1	Resolved	closed
UML22-1143	OpaqueExpression in CommonBehaviors	UML 2.0	UML 2.1	Resolved	closed
UML22-1145	CommonBehaviors	UML 2.0	UML 2.1	Resolved	closed
UML22-1142	Output tokens	UML 2.1	UML 2.1.1	Duplicate or Merged	closed
UML22-1141	Section: Activities: Modifications to the approved resolution of 10815	SysML 1.0	UML 2.1.2	Resolved	closed
UML22-1122	Diagram metaclass shall be introduced and shall be subclass of Element	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1121	Setting structural features of a data type	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1124	Figure 7.14: "Type" does not show its inheritance from "PackageableElement"	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1123	ConnectorEnd shall have references to provided or required interfaces	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1134	constraining Classifiers	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1133	defaultClassifier of ClassifierTemplateParameter	SysML 1.0	UML 2.1.2	Resolved	closed
UML22-1129	Section: 9.3.11 p 182	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1128	Wrong notation description	SysML 1.0	UML 2.1.2	Resolved	closed
UML22-1127	Section: 9.3.8	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1126	page 449 chapter 13.3.24 (Signal (from Communications)	SysML 1.0	UML 2.1.2	Resolved	closed
UML22-1125	UML 2 superstructure -- figure 9.4 is duplicate of figure 9.3	SysML 1.0	UML 2.1.2	Resolved	closed
UML22-1136	Change multiplicity of ClassifierTemplateParameter role	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1135	Any ownedBehavior should be able to have AcceptEventAction	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1132	composite values	SysML 1.0	UML 2.1.2	Resolved	closed
UML22-1131	Section: 9 composite structures	SysML 1.0	UML 2.1.2	Resolved	closed
UML22-1130	"representation"	SysML 1.0	UML 2.1.2	Resolved	closed
UML22-1138	TimeEvent	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1137	Figure 14.5 - Messages.	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1140	Section: 7.3.7	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1139	Figures 9.4 identical to figure 9.3	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1120	Flowing data into decision input behaviors	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1119	Section: Composite Structures	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1107	issue regarding required and provided interfaces	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1106	UML 2: Semantics of isOrdered need to be clarified	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1118	Ptc/06-04-02/Pg 188	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1117	Section: 7.3.32	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1116	A notation for Trigger	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1102	Section: Activities - Action semantic clarification	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1101	Section: Activities -StartClassifeirBehaviorAction and classifier behaviors	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1100	Section: Activities - isSingleExecution default	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1105	Profile Structure Diagrams are missing from Annex A	SysML 1.0b1	UML 2.1.2	Resolved	closed
UML22-1104	Missing inheritance in 9.3.12	SysML 1.0b1	UML 2.1.2	Resolved	closed
UML22-1103	No default value specified for Generalization::isSubstitutable	SysML 1.0b1	UML 2.1.2	Resolved	closed
UML22-1115	consistent descriptions of semantics of event consumption needed	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1114	section 13.3.2 doc ptc/2006-04-02, v.2.1	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1113	Uses notation "Subsets Element::ownedElement" and similar	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1112	UML2: Behavior without a specification should not be a classifier behavior	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1109	Figure 13.8 shows the wrong diagram	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1108	Section: 13.3.25	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1111	Section: 13 SimpleTime	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1110	Section: 13.2	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1084	UML2: No notation for BehavioredClassifier::ownedTrigger	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1083	UML 2/Templates -- single argument?	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1082	Use the new 'dot' notation in examples	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1099	Section: Activities - Join node edge constraint	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1098	Section: Activities - Offer ordering on joins	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1097	Section: Activities - Multiple activity parameters nodes for a single inout	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1088	A notation for Trigger	SysML 1.0b1	UML 2.1.2	Resolved	closed
UML22-1087	Section: 9.3.13 - connectors	UML 2.1	UML 2.1.2	Resolved	closed
UML22-1096	Section: Activities - Semantics of fork node wording	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1095	ReadLinkAction	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1094	Section: Activities - Weight notation	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1093	Section: Activities - Weight description	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1092	Section: Activities	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1091	Section: 9.3.11	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1090	Section: 9.3.11	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1089	Section: 9.2	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1086	Section: 13.3.24 Signal (from Communications)	UML 2.1.1	UML 2.1.2	Resolved	closed
UML22-1085	page 467, Section 13.3.24	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1081	UML 2 Superstructure / CommonBehaviors / Incorrect types in text	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1080	7.3.41 Parameter (from Kernel, AssociationClasses)"	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1063	UML 2.0 issue: ownedMember xsi:type="uml:Stereotype" should be used	UML 2.0	UML 2.1	Resolved	closed
UML22-1062	UML 2.0: CMOF/UML mixup for profiles	UML 2.0	UML 2.1	Resolved	closed
UML22-1069	Required attributes	UML 2.0	UML 2.1	Resolved	closed
UML22-1068	Parameter::effect	UML 2.0	UML 2.1	Resolved	closed
UML22-1065	UML 2.1 XMI Issue	UML 2.0	UML 2.1	Resolved	closed
UML22-1064	UML 2.0: Inconsistencies in profile example XMI	UML 2.0	UML 2.1	Resolved	closed
UML22-1073	parameter of operation isRedefinitionContextValid() is inconistently named	UML 2.0	UML 2.1	Resolved	closed
UML22-1072	Compliance package L2 does not merge StructuredActions in the metamodel	UML 2.0	UML 2.1	Resolved	closed
UML22-1071	The following properties should not subset DirectedRelationship::target	UML 2.0	UML 2.1	Resolved	closed
UML22-1070	The following properties should not subset DirectedRelationship::source	UML 2.0	UML 2.1	Resolved	closed
UML22-1067	Artifact::fileName	UML 2.0	UML 2.1	Resolved	closed
UML22-1066	uml::Extension::ownedEnd should not subset uml::Association::ownedEnd	UML 2.0	UML 2.1	Resolved	closed
UML22-1079	Figure 12.18: Small typo: "subsets ownedMember" not "ownedmember"	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1078	Page: 161	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1075	Issue regarding "Action::effect : String"	UML 1.3	UML 2.1	Resolved	closed
UML22-1074	Transition guards cannot currently be evaluated because they have no contex	UML 2.0	UML 2.1	Resolved	closed
UML22-1077	StateMachine::extendedStateMachine should have a multiplicity of 0..*.	UML 2.0	UML 2.1	Resolved	closed
UML22-1076	Behavior::context	UML 2.0	UML 2.1	Resolved	closed
UML22-1058	UML 2.0 issue: Package Primitive Types not merged	UML 2.0	UML 2.1	Resolved	closed
UML22-1057	Section: Appendix A: Diagrams	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1056	Section 7.2.1 of ptc/04-10-14	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1055	Section: 7.3.36 Operation	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1054	Section 8 Issue - Component Realization-Classifier multiplicity	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1053	Section: Actions, Figure 156	UML 2.0	UML 2.1	Resolved	closed
UML22-1052	UML 2.1 Regressions	UML 2.0	UML 2.1	Resolved	closed
UML22-1051	Realization classifier	UML 2.0	UML 2.1	Resolved	closed
UML22-1050	UML 2 issue: redefining isComposite on association ends	UML 2.0	UML 2.1	Resolved	closed
UML22-1049	Classifier::parameter, Operation::parameter, and ConnectableElement::parame	UML 2.0	UML 2.1	Resolved	closed
UML22-1048	Component::realization should NOT be derived	UML 2.0	UML 2.1	Resolved	closed
UML22-1047	Rename ActivityGroup::activity to containingActivity	UML 2.0	UML 2.1	Resolved	closed
UML22-1046	Rename OpaqueAction::output to outputPin.	UML 2.0	UML 2.1	Resolved	closed
UML22-1045	Make ActivityGroup::containedNode a derived union	UML 2.0	UML 2.1	Resolved	closed
UML22-1044	Make ActivityGroup::containedEdge a derived union	UML 2.0	UML 2.1	Resolved	closed
UML22-1039	compliance levels L2 and L3	UML 2.0	UML 2.1	Resolved	closed
UML22-1038	Change type of WriteStructuralFeatureAction::value to ValueSpecification	UML 2.0	UML 2.1	Resolved	closed
UML22-1037	Change type of WriteStructuralFeatureAction::value	UML 2.0	UML 2.1	Resolved	closed
UML22-1061	UML 2.0: separate profile application from profile importing	UML 2.0	UML 2.1	Resolved	closed
UML22-1060	UML 2.0: invalid package merge diagrams for compliance points	UML 2.0	UML 2.1	Resolved	closed
UML22-1059	UML 2.0 issue: Profile::ownedStereotype should be derived	UML 2.0	UML 2.1	Resolved	closed
UML22-1043	Rename LinkAction::input to inputPin	UML 2.0	UML 2.1	Resolved	closed
UML22-1042	Rename OpaqueAction::input to inputPin	UML 2.0	UML 2.1	Resolved	closed
UML22-1041	Rename InformationFlow::source	UML 2.0	UML 2.1	Resolved	closed
UML22-1040	Rename InformationFlow::target	UML 2.0	UML 2.1	Resolved	closed
UML22-1036	Rename ActivityPartition::subgroup to subpartition	UML 2.0	UML 2.1	Resolved	closed
UML22-1035	Replace {redefines redefinedElement}	UML 2.0	UML 2.1	Resolved	closed
UML22-1034	Replace {redefines redefinedElement}	UML 2.0	UML 2.1	Resolved	closed
UML22-1033	Replace {redefines redefinedElement}	UML 2.0	UML 2.1	Resolved	closed
UML22-1026	body expression for Property::isConsistentWith(RedefinableElement)	UML 2.0	UML 2.1	Resolved	closed
UML22-1025	following imports from merged packages to unmerged packages should be remov	UML 2.0	UML 2.1	Resolved	closed
UML22-1024	UML2 Superstructure Fig 2.2 Incomplete	UML 2.0	UML 2.1	Resolved	closed
UML22-1023	Section: 14.4	UML 2.0	UML 2.1	Resolved	closed
UML22-1020	Section: Common Behaviors	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1019	Section: Actions	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1022	7.3.22 InstanceSpecification	UML 2.0	UML 2.1	Resolved	closed
UML22-1021	Section: Activities	UML 2.0	UML 2.1	Resolved	closed
UML22-1018	Section: Classes	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1017	Section: Activities	UML 2.0	UML 2.1	Resolved	closed
UML22-1016	Invalid stereotype in StandardProfile	UML 2.0	UML 2.1	Resolved	closed
UML22-1015	UML 2 Super / miscellaneous figure-text discrepancies	UML 2.0	UML 2.1	Resolved	closed
UML22-1028	Rename Package::ownedMember	UML 2.0	UML 2.1	Resolved	closed
UML22-1027	Rename Constraint::namespace	UML 2.0	UML 2.1	Resolved	closed
UML22-1030	Rename ActivityEdge::redefinedElement	UML 2.0	UML 2.1	Resolved	closed
UML22-1029	Rename Component::ownedMember	UML 2.0	UML 2.1	Resolved	closed
UML22-1032	Replace {redefines redefinedElement}	UML 2.0	UML 2.1	Resolved	closed
UML22-1031	Rename ActivityNode::redefinedElement	UML 2.0	UML 2.1	Resolved	closed
UML22-1012	Section: 6.5	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1011	UML2 should specify default property ownership for association ends	UML 2.0	UML 2.1	Resolved	closed
UML22-1002	Figure 430 references invalid metaclass	UML 2.0	UML 2.1	Resolved	closed
UML22-1001	Section: 9.3.5	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1006	UML2 Navigability Impact on Tools	UML 2.0	UML 2.1	Resolved	closed
UML22-1005	UML 2 XMI DTD requirement	UML 2.0	UML 2.1	Resolved	closed
UML22-998	UML2 issue: {unrestricted} described in text but not BNF	UML 2.0	UML 2.1	Resolved	closed
UML22-997	UML Superstructure / Actions / Missing package heading	UML 2.0	UML 2.1	Resolved	closed
UML22-1010	UML 2 Super / Undocumented properties	UML 2.0	UML 2.1	Resolved	closed
UML22-1009	Page: 591,592	UML 2.0	UML 2.1	Resolved	closed
UML22-1008	Core::Constructs::Operation	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1007	Interaction::lifeline should be ordered	UML 2.0	UML 2.1.2	Resolved	closed
UML22-1004	UML 2 Classes Notation for association end ownership	UML 2.0	UML 2.1	Resolved	closed
UML22-1003	connection point reference	UML 2.0	UML 2.1	Resolved	closed
UML22-1014	UML 2 Super / Collaboration use issues (02)	UML 2.0	UML 2.1	Resolved	closed
UML22-1013	UML 2 Super / Collaboration use issues (01)	UML 2.0	UML 2.1	Resolved	closed
UML22-1000	Section: 12.3.18 and 12.3.35	UML 2.0	UML 2.1	Resolved	closed
UML22-999	Section: 15.3.14	UML 2.0	UML 2.1	Resolved	closed
UML22-987	p. 732: Show examples of new stereotype notation	RAS 2.2	UML 2.1	Resolved	closed
UML22-986	p. 732: Change example to be consistent with new definition of Clock	RAS 2.2	UML 2.1	Resolved	closed
UML22-994	Section: 12.3.5	UML 2.0	UML 2.1	Resolved	closed
UML22-993	Page: 163	UML 2.0	UML 2.1	Resolved	closed
UML22-983	Make instance model consistent with new definition of Clock	RAS 2.2	UML 2.1	Resolved	closed
UML22-982	p. 729: Extend the Clock example to show metaclass property	RAS 2.2	UML 2.1	Resolved	closed
UML22-985	p. 731: Make example consistent with new definition of Clock.	RAS 2.2	UML 2.1	Resolved	closed
UML22-984	p. 731: Make this example consistent with the new definition of Clock	RAS 2.2	UML 2.1	Resolved	closed
UML22-989	Section: 12.3.37 ObjectFlow	UML 2.0	UML 2.1	Resolved	closed
UML22-996	UML Superstructure / Actions / incorrect form for subsetting	UML 2.0	UML 2.1	Resolved	closed
UML22-995	Section: 12.3.9	UML 2.0	UML 2.1	Resolved	closed
UML22-988	pp. 733-734: Add association as valid graphic path	RAS 2.2	UML 2.1	Resolved	closed
UML22-991	TimeExpression	RAS 2.2	UML 2.1	Resolved	closed
UML22-990	OpaqueAction	UML 2.0	UML 2.1	Resolved	closed
UML22-992	abstract Action in Activity diagram	RAS 2.2	UML 2.1	Resolved	closed
UML22-981	p. 728: New presentation options. Replace the following paragraph	RAS 2.2	UML 2.1	Resolved	closed
UML22-980	p. 721: Allow stereotypes to have properties that are typed by metaclasses	RAS 2.2	UML 2.1	Resolved	closed
UML22-968	Can't specify mutator semantics for derived properties	RAS 2.2	UML 2.1	Resolved	closed
UML22-967	Section: 12.3.37	RAS 2.2	UML 2.1	Resolved	closed
UML22-976	MessageEnd	RAS 2.2	UML 2.1	Resolved	closed
UML22-975	ExecutableNode should be abstract in Figure 195. It is in Figure 197.	UML 2.0	UML 2.1	Resolved	closed
UML22-979	Section: 12 and 13	UML 2.0	UML 2.1	Resolved	closed
UML22-978	Incorrect Communication Domain Model	RAS 2.2	UML 2.1	Resolved	closed
UML22-977	Obsolete term EventOccurrence still used in multiple places	RAS 2.2	UML 2.1	Resolved	closed
UML22-972	Notation of Attributes and Associations subsections	RAS 2.2	UML 2.1.2	Resolved	closed
UML22-971	Page: 330	UML 2.0	UML 2.1.2	Resolved	closed
UML22-970	Section: 11.3.48	UML 2.0	UML 2.1	Resolved	closed
UML22-969	Section: Actions	UML 2.0	UML 2.1	Resolved	closed
UML22-974	Actions should be able to overlap partitions, to support multiple participa	UML 2.0	UML 2.1	Resolved	closed
UML22-973	Section: 8.3.1 Page: 156 ff	UML 2.0	UML 2.1.2	Resolved	closed
UML22-966	OpaqueAction	RAS 2.2	UML 2.1	Resolved	closed
UML22-965	Page: 591	UML 2.0	UML 2.1	Resolved	closed
UML22-961	Clarify caption of Figure 56	UML 2.0	UML 2.1	Resolved	closed
UML22-960	Section: Interactions	UML 2.0	UML 2.1	Resolved	closed
UML22-953	Clarify first constraint on InputPin and OutputPin, move "only" to before "	UML 2.0	UML 2.1	Resolved	closed
UML22-952	LoopNode should move rather than copy values to/from loop variables	UML 2.0	UML 2.1	Resolved	closed
UML22-951	In Figure 210, put merge before Use Part to merge the incoming flows	UML 2.0	UML 2.1	Resolved	closed
UML22-950	Exceptions thrown across synchronous invocations	UML 2.0	UML 2.1	Resolved	closed
UML22-949	Multiple exception handlers	UML 2.0	UML 2.1	Resolved	closed
UML22-955	Actions, CallBehaviorAction, third sentence,	UML 2.0	UML 2.1	Resolved	closed
UML22-954	The Syle Guidelines for Stereotype	UML 2.0	UML 2.1	Resolved	closed
UML22-959	CollaborationUse: Constraint 1,	UML 2.0	UML 2.1.2	Resolved	closed
UML22-958	ConditionalNode and LoopNode test and bodies should be ExecutableNodes	UML 2.0	UML 2.1	Resolved	closed
UML22-957	ExpansionRegion	UML 2.0	UML 2.1	Resolved	closed
UML22-956	ControlFlow	UML 2.0	UML 2.1	Resolved	closed
UML22-964	Last element in transition BNF	UML 2.0	UML 2.1	Resolved	closed
UML22-962	Notation for connector end multiplicities.	UML 2.0	UML 2.1.2	Resolved	closed
UML22-963	ParameterSet, first line: "inputs or outputs".	UML 2.0	UML 2.1	Resolved	closed
UML22-942	In Activities, Figure 176, Action should be abstract	UML 2.0	UML 2.1	Resolved	closed
UML22-941	Profile Semantics, pag 723	RAS 2.2	UML 2.1	Resolved	closed
UML22-935	Section: 12	UML 1.4.2	UML 2.1	Resolved	closed
UML22-934	token	UML 1.4.2	UML 2.1	Resolved	closed
UML22-944	String is primitive but has structure.	UML 2.0	UML 2.1	Resolved	closed
UML22-937	``conditional node or conditional node'' delete one.	UML 1.4.2	UML 2.1	Resolved	closed
UML22-936	add the rule of ``natural termination''	UML 1.4.2	UML 2.1	Resolved	closed
UML22-948	Solid triange notation for Association	UML 2.0	UML 2.1	Resolved	closed
UML22-947	The create stereotype on Usage dependency	UML 2.0	UML 2.1.2	Resolved	closed
UML22-939	Section: 12.2	UML 2.0	UML 2.1	Resolved	closed
UML22-938	Delete sentence	UML 1.4.2	UML 2.1	Resolved	closed
UML22-946	Element to Constraint navigation	UML 2.0	UML 2.1.2	Resolved	closed
UML22-945	Disjointness should be independent of generalization	UML 2.0	UML 2.1.2	Resolved	closed
UML22-943	Semantics for instances applies to InstanceSpecification?	UML 2.0	UML 2.1	Resolved	closed
UML22-940	policy to describe the Associations sub section of a meta class description	RAS 2.2	UML 2.1	Resolved	closed
UML22-933	UML 2 -- Need explanations of XMI structure and usage	UML 1.4.2	UML 2.1	Resolved	closed
UML22-932	token movement	UML 1.4.2	UML 2.1	Resolved	closed
UML22-931	output tokens (02)	UML 1.4.2	UML 2.1	Resolved	closed
UML22-927	Section: 12	UML 1.4.2	UML 2.1	Resolved	closed
UML22-926	Section: Appendix F	UML 2.0	UML 2.1	Resolved	closed
UML22-925	Section: E.1	UML 2.0	UML 2.1	Resolved	closed
UML22-930	text p.297	UML 1.4.2	UML 2.1	Resolved	closed
UML22-929	Section 12 (03)	UML 1.4.2	UML 2.1	Resolved	closed
UML22-928	Section 12 (02)	UML 1.4.2	UML 2.1.2	Resolved	closed
UML22-920	Section: Appendix C Table 27	UML 2.0	UML 2.1	Resolved	closed
UML22-919	Section: Appendix C Table 26	UML 2.0	UML 2.1	Resolved	closed
UML22-922	Section: D.1	UML 2.0	UML 2.1	Resolved	closed
UML22-921	Section: 15.3.8	UML 2.0	UML 2.1	Resolved	closed
UML22-924	Section: D.3	UML 2.0	UML 2.1	Resolved	closed
UML22-923	Section: D.2	UML 2.0	UML 2.1	Resolved	closed
UML22-915	Section: 18	UML 2.0	UML 2.1	Resolved	closed
UML22-914	Section: 18.4	UML 2.0	UML 2.1	Resolved	closed
UML22-913	Section: 18.3.8	UML 2.0	UML 2.1	Resolved	closed
UML22-918	Section: Appendix C Table 25	UML 2.0	UML 2.1	Resolved	closed
UML22-917	Section: Appendix B (02)	UML 2.0	UML 2.1	Resolved	closed
UML22-916	Section: Appendix B	UML 2.0	UML 2.1	Resolved	closed
UML22-912	Section: 18.3.7	UML 2.0	UML 2.1	Resolved	closed
UML22-911	Section: 18.3.3	UML 2.0	UML 2.1	Resolved	closed
UML22-910	Section: 18.3.2	UML 2.0	UML 2.1	Resolved	closed
UML22-909	Section: 18.2	UML 2.0	UML 2.1	Resolved	closed
UML22-908	Section: 18.3.2	UML 2.0	UML 2.1	Resolved	closed
UML22-893	Section: 17.5.6	UML 2.0	UML 2.1	Resolved	closed
UML22-892	Section: 17.5.5	UML 2.0	UML 2.1	Resolved	closed
UML22-891	Section: 17.5.4	UML 2.0	UML 2.1	Resolved	closed
UML22-895	Section: 17.5.7	UML 2.0	UML 2.1	Resolved	closed
UML22-894	Section: 17.1	UML 2.0	UML 2.1	Resolved	closed
UML22-901	Section: 17.5.15	UML 2.0	UML 2.1	Resolved	closed
UML22-900	Section: 17.5.14	UML 2.0	UML 2.1	Resolved	closed
UML22-897	Section: 17.5.12	UML 2.0	UML 2.1	Resolved	closed
UML22-896	Section: 17.5.8	UML 2.0	UML 2.1	Resolved	closed
UML22-907	Section: 18.1.2	UML 2.0	UML 2.1	Resolved	closed
UML22-906	Section: 17.5.20	UML 2.0	UML 2.1	Resolved	closed
UML22-899	Section: 12 Activities	UML 2.0	UML 2.1	Resolved	closed
UML22-898	Section: 17.5.13	UML 2.0	UML 2.1	Resolved	closed
UML22-903	Section: 17.5.17	UML 2.0	UML 2.1	Resolved	closed
UML22-902	Section: 17.5.16	UML 2.0	UML 2.1	Resolved	closed
UML22-905	Section: 17.5.19	UML 2.0	UML 2.1	Resolved	closed
UML22-904	Section: 17.5.18	UML 2.0	UML 2.1	Resolved	closed
UML22-883	Section: 17.2.2	UML 2.0	UML 2.1	Resolved	closed
UML22-882	Section: 17.2.1	UML 2.0	UML 2.1	Resolved	closed
UML22-872	Expansion region description	UML 2.0	UML 2.1	Resolved	closed
UML22-871	ExpansionRegioin example, Figure 261: concurrent => parallel	UML 2.0	UML 2.1	Resolved	closed
UML22-870	Section: Activities, ExpansionRegion (05)	UML 2.0	UML 2.1	Resolved	closed
UML22-879	mustIsolate:	UML 2.0	UML 2.1	Resolved	closed
UML22-878	No notation	UML 2.0	UML 2.1	Resolved	closed
UML22-875	Semantics of isAssured/isDeterminant in conditional node	UML 2.0	UML 2.1	Resolved	closed
UML22-874	Add constraint in LoopNode	UML 2.0	UML 2.1	Resolved	closed
UML22-873	Section: Activities	UML 2.0	UML 2.1	Resolved	closed
UML22-890	Section: 17.5.3	UML 2.0	UML 2.1	Resolved	closed
UML22-889	Section: 17.5.3	UML 2.0	UML 2.1	Resolved	closed
UML22-888	Section: 17.5.1	UML 2.0	UML 2.1	Resolved	closed
UML22-885	Section: 17.4	UML 2.0	UML 2.1	Resolved	closed
UML22-884	Section: 17.3.1	UML 2.0	UML 2.1	Resolved	closed
UML22-887	Section: 17.5.2	UML 2.0	UML 2.1	Resolved	closed
UML22-886	Section: 17.5.1	UML 2.0	UML 2.1	Resolved	closed
UML22-881	Clarify the semantics of minimum multiplicity > 0 for streaming parameters	UML 2.0	UML 2.1	Resolved	closed
UML22-880	Figure 209 of Activites	UML 2.0	UML 2.1	Resolved	closed
UML22-877	Add constraints on conditional and loop nodes (02)	UML 2.0	UML 2.1	Resolved	closed
UML22-876	Add constraints on conditional and loop nodes	UML 2.0	UML 2.1	Resolved	closed
UML22-853	UML 2 Super / Conformance / inconsistencies	UML 1.4.2	UML 2.1	Resolved	closed
UML22-852	UML 2 Super / General / missing merges	UML 1.4.2	UML 2.1	Resolved	closed
UML22-851	UML 2 Super / General / improper subsetting	UML 1.4.2	UML 2.1	Resolved	closed
UML22-855	UML 2 Super / General / invalid subset rule too strict	UML 1.4.2	UML 2.1	Resolved	closed
UML22-854	UML 2 Super / Kernel / excessive restriction on redefinition	UML 1.4.2	UML 2.1	Resolved	closed
UML22-861	Section: 14.3.3	UML 2.0	UML 2.1	Resolved	closed
UML22-860	Section: 16.3.6	UML 2.0	UML 2.1	Resolved	closed
UML22-869	Section: Activities, ExpansionRegion (04)	UML 2.0	UML 2.1	Resolved	closed
UML22-868	Section: Activities, ExpansionRegion (03)	UML 2.0	UML 2.1	Resolved	closed
UML22-867	Section: Activities, ExpansionRegion (02)	UML 2.0	UML 2.1	Resolved	closed
UML22-859	Section: 16.3.5	UML 2.0	UML 2.1	Resolved	closed
UML22-858	Section: 16.3.4	UML 2.0	UML 2.1	Resolved	closed
UML22-857	Section: 16.3.3	UML 2.0	UML 2.1	Resolved	closed
UML22-856	UML 2 Super / Common Behaviors / missing multiplicites	UML 1.4.2	UML 2.1	Resolved	closed
UML22-866	Section: Activities, ExpansionRegion	UML 2.0	UML 2.1	Resolved	closed
UML22-865	Section: Activities	UML 2.0	UML 2.1	Resolved	closed
UML22-864	ValueSpecificationAction, Attribute section, is missing the return pin	UML 2.0	UML 2.1	Resolved	closed
UML22-863	Section: Actions	UML 2.0	UML 2.1	Resolved	closed
UML22-862	Section: Common Behavior	UML 2.0	UML 2.1	Resolved	closed
UML22-841	Section: 15.3.14	UML 2.0	UML 2.1	Resolved	closed
UML22-840	Section: Appendix A	UML 2.0	UML 2.1	Resolved	closed
UML22-837	Section: 15.3.11	UML 2.0	UML 2.1	Resolved	closed
UML22-836	Section: 15.3.11	UML 2.0	UML 2.1	Resolved	closed
UML22-835	Action Semantics Section: 9.5	UML 1.4.2	UML 2.1	Resolved	closed
UML22-839	Appendix C.1	UML 2.0	UML 2.1	Resolved	closed
UML22-838	Section: 15.3.12	UML 2.0	UML 2.1	Resolved	closed
UML22-834	Specification: Action Semantics Section: 9.5	UML 1.4.2	UML 2.1	Resolved	closed
UML22-833	Section: 15.3.10	UML 2.0	UML 2.1	Resolved	closed
UML22-832	Section: 15.3.9	UML 2.0	UML 2.1	Resolved	closed
UML22-843	Section: 15.3.16	UML 2.0	UML 2.1	Resolved	closed
UML22-842	Section: 15.3.15	UML 2.0	UML 2.1	Resolved	closed
UML22-850	UML 2 Super / Collaborations / improper subset	UML 1.4.2	UML 2.1	Resolved	closed
UML22-849	Profiles::ObjectNode has wrong default multiplicity	UML 1.4.2	UML 2.1	Resolved	closed
UML22-848	Profiles::ExtensionEnd has wrong default multiplicity	UML 1.4.2	UML 2.1	Resolved	closed
UML22-845	Should Profiles::Image be an Element?	UML 1.4.2	UML 2.1	Resolved	closed
UML22-844	Section: 15.3.7	UML 2.0	UML 2.1	Resolved	closed
UML22-847	Remove redundant superclass for Element	UML 1.4.2	UML 2.1	Resolved	closed
UML22-846	OCL for Property::opposite() is incorrect:	UML 1.4.2	UML 2.1	Resolved	closed
UML22-831	Section: 15.3.8	UML 2.0	UML 2.1	Resolved	closed
UML22-830	Section: 15.3.7	UML 2.0	UML 2.1	Resolved	closed
UML22-817	Section: 14.3.26	UML 2.0	UML 2.1	Resolved	closed
UML22-816	Section: 14.3.25	UML 2.0	UML 2.1	Resolved	closed
UML22-823	Section: 15.3.1	UML 2.0	UML 2.1	Resolved	closed
UML22-822	Section: 8.3.1	UML 2.0	UML 2.1.2	Resolved	closed
UML22-829	Section: 15.3.6	UML 2.0	UML 2.1	Resolved	closed
UML22-828	Section: 11.3.42	UML 2.0	UML 2.1	Resolved	closed
UML22-812	Section: 14.3.20	UML 2.0	UML 2.1	Resolved	closed
UML22-811	Section: 14.3.19	UML 2.0	UML 2.1	Resolved	closed
UML22-815	Section: 14.3.24	UML 1.4.2	UML 2.1	Resolved	closed
UML22-814	Section: 14.3.21	UML 2.0	UML 2.1	Resolved	closed
UML22-813	Section: 14.3.21	UML 2.0	UML 2.1	Resolved	closed
UML22-827	Section: 15.3.5	UML 2.0	UML 2.1	Resolved	closed
UML22-826	Section: 15.3.5	UML 2.0	UML 2.1	Resolved	closed
UML22-819	Section: 14.4	UML 2.0	UML 2.1	Resolved	closed
UML22-818	Section: 14.3.29	UML 2.0	UML 2.1	Resolved	closed
UML22-821	Section: 12.3.4	UML 2.0	UML 2.1	Resolved	closed
UML22-820	Section: 11.3.5	UML 2.0	UML 2.1	Resolved	closed
UML22-825	Section: 15.3.3	UML 2.0	UML 2.1	Resolved	closed
UML22-824	Section: 15.3.2	UML 2.0	UML 2.1	Resolved	closed
UML22-810	Section: 14.3.17	UML 2.0	UML 2.1	Resolved	closed
UML22-809	Section: 14.3.16	UML 2.0	UML 2.1	Resolved	closed
UML22-808	Section: 14.3.15	UML 2.0	UML 2.1	Resolved	closed
UML22-797	Section: 14.3.2	UML 2.0	UML 2.1	Resolved	closed
UML22-796	Section: 13	UML 2.0	UML 2.1	Resolved	closed
UML22-795	Section: 13.3.30	UML 2.0	UML 2.1	Resolved	closed
UML22-807	Section: 14.3.13	UML 2.0	UML 2.1	Resolved	closed
UML22-806	Section: 14.3.14	UML 2.0	UML 2.1	Resolved	closed
UML22-799	Section: 14.3.4	UML 2.0	UML 2.1	Resolved	closed
UML22-798	Section: 14.3.3	UML 2.0	UML 2.1	Resolved	closed
UML22-803	Section: 14.3.10	UML 2.0	UML 2.1	Resolved	closed
UML22-802	Section: 14.3.8	UML 2.0	UML 2.1	Resolved	closed
UML22-801	Section: 14.3.6	UML 2.0	UML 2.1	Resolved	closed
UML22-800	Section: 14.3.5	UML 2.0	UML 2.1	Resolved	closed
UML22-794	Section: 13.3.29	UML 2.0	UML 2.1	Resolved	closed
UML22-793	Section: 13.3.28	UML 2.0	UML 2.1	Resolved	closed
UML22-792	Section: 13.3.27	UML 2.0	UML 2.1	Resolved	closed
UML22-805	Section: 14.3.12	UML 2.0	UML 2.1	Resolved	closed
UML22-804	Section: 14.3.3 & 14.3.11	UML 2.0	UML 2.1	Resolved	closed
UML22-791	Section: 13.3.26	UML 2.0	UML 2.1	Resolved	closed
UML22-790	Section: 13.3.24	UML 2.0	UML 2.1	Resolved	closed
UML22-776	Section: 13.3.3	UML 2.0	UML 2.1	Resolved	closed
UML22-775	Section: 13.3.2	UML 2.0	UML 2.1.2	Resolved	closed
UML22-784	Section: 13.3.14	UML 2.0	UML 2.1	Resolved	closed
UML22-783	Section: 13.3.12	UML 2.0	UML 2.1	Resolved	closed
UML22-778	Section: 13.3.4	UML 2.0	UML 2.1	Resolved	closed
UML22-780	Section: 13.3.8	UML 2.0	UML 2.1	Resolved	closed
UML22-779	Section: 13.3.7	UML 2.0	UML 2.1	Resolved	closed
UML22-789	Section: 13.3.23	UML 2.0	UML 2.1	Resolved	closed
UML22-788	Section: 13.3.22	UML 2.0	UML 2.1	Resolved	closed
UML22-782	Section: 13.3.9	UML 2.0	UML 2.1	Resolved	closed
UML22-781	Section: 13.3.10	UML 2.0	UML 2.1	Resolved	closed
UML22-786	Section: 13.3.19	UML 2.0	UML 2.1	Resolved	closed
UML22-785	Section: 13.3.15	UML 2.0	UML 2.1	Resolved	closed
UML22-787	Section: 13.3.20	UML 2.0	UML 2.1	Resolved	closed
UML22-777	Section: 7.3.36	UML 2.0	UML 2.1	Resolved	closed
UML22-755	Section: 12.3.35	UML 2.0	UML 2.1	Resolved	closed
UML22-754	Section: 12.3	UML 2.0	UML 2.1	Resolved	closed
UML22-753	Section: 12.3.35	UML 2.0	UML 2.1	Resolved	closed
UML22-767	Section: 11.3.48	UML 2.0	UML 2.1	Resolved	closed
UML22-766	Section: 12.3.48	UML 2.0	UML 2.1	Resolved	closed
UML22-771	Section: 12	UML 2.0	UML 2.1	Resolved	closed
UML22-770	Section: 12.4	UML 2.0	UML 2.1	Resolved	closed
UML22-758	Section: 12.3.38	UML 2.0	UML 2.1	Resolved	closed
UML22-757	Section: 12.3.37	UML 2.0	UML 2.1	Resolved	closed
UML22-756	Profiles:Extension End	UML 1.4.2	UML 2.1	Resolved	closed
UML22-765	Section: 12.2	UML 2.0	UML 2.1	Resolved	closed
UML22-764	Section: 12.3.47	UML 2.0	UML 2.1	Resolved	closed
UML22-763	UML 2 super/templates/	UML 1.4.2	UML 2.1	Resolved	closed
UML22-760	Section: 12.3.43	UML 2.0	UML 2.1	Resolved	closed
UML22-759	Section: 12.3.41	UML 2.0	UML 2.1	Resolved	closed
UML22-774	Section: 12.3.49	UML 2.0	UML 2.1	Resolved	closed
UML22-773	Section: 12.3.46	UML 2.0	UML 2.1	Resolved	closed
UML22-772	Section: 13.1	UML 2.0	UML 2.1	Resolved	closed
UML22-762	UML 2 Super/templates/inexplicable constraint on defaults	UML 1.4.2	UML 2.1	Resolved	closed
UML22-761	Section: 12.3.44	UML 2.0	UML 2.1	Resolved	closed
UML22-769	Section: 12.3.51	UML 2.0	UML 2.1	Resolved	closed
UML22-768	Section: 12.3.50	UML 2.0	UML 2.1	Resolved	closed
UML22-752	Section: 12.3.34	UML 2.0	UML 2.1	Resolved	closed
UML22-751	Section: 12.3.33	UML 2.0	UML 2.1	Resolved	closed
UML22-738	Section: 12.3.17	UML 2.0	UML 2.1	Resolved	closed
UML22-737	Section: 12.3.16	UML 2.0	UML 2.1	Resolved	closed
UML22-736	Section: 12.3.15	UML 2.0	UML 2.1	Resolved	closed
UML22-735	Section: 12.3.14	UML 2.0	UML 2.1.2	Resolved	closed
UML22-731	MultiplicityElement BNF too restrictive	UML 1.4.2	UML 2.1	Resolved	closed
UML22-730	Section: 12.3.13	UML 2.0	UML 2.1	Resolved	closed
UML22-741	Section: 12.3.6 & 12.3.19	UML 2.0	UML 2.1	Resolved	closed
UML22-740	Section: 12.3.19	UML 2.0	UML 2.1	Resolved	closed
UML22-739	Section: 12.3.18	UML 2.0	UML 2.1	Resolved	closed
UML22-746	Section: 12.3.28	UML 2.0	UML 2.1	Resolved	closed
UML22-745	Section: 12.3.27	UML 2.0	UML 2.1	Resolved	closed
UML22-744	Section: 12.3.23	UML 2.0	UML 2.1	Resolved	closed
UML22-734	Used of "Redefines ...from Abstractions" in descriptions is misleading	UML 1.4.2	UML 2.1	Resolved	closed
UML22-733	BNF Notation for Operation is too restrictive	UML 1.4.2	UML 2.1	Resolved	closed
UML22-732	Incomplete BNF for Property	UML 1.4.2	UML 2.1	Resolved	closed
UML22-743	Section: 12.3.24	UML 2.0	UML 2.1	Resolved	closed
UML22-742	Section: 12.3.22	UML 2.0	UML 2.1	Resolved	closed
UML22-748	Section: 12.3.38	UML 2.0	UML 2.1	Resolved	closed
UML22-747	Section: 12.3.30	UML 2.0	UML 2.1	Resolved	closed
UML22-750	Section: 12.3.32	UML 2.0	UML 2.1	Resolved	closed
UML22-749	Section: 12.3.31	UML 2.0	UML 2.1	Resolved	closed
UML22-729	Section: 12.1	UML 2.0	UML 2.1	Resolved	closed
UML22-728	Section: 12.3.12	UML 2.0	UML 2.1	Resolved	closed
UML22-727	Section: 12.3.10	UML 2.0	UML 2.1	Resolved	closed
UML22-726	Section: 12	UML 2.0	UML 2.1	Resolved	closed
UML22-725	Section: 12.3.9	UML 2.0	UML 2.1	Resolved	closed
UML22-716	Section: 12.3.4	UML 2.0	UML 2.1	Resolved	closed
UML22-715	Section: 12.3.2	UML 2.0	UML 2.1	Resolved	closed
UML22-714	Section: 12.2	UML 2.0	UML 2.1	Resolved	closed
UML22-721	Section: 12.3.8	UML 2.0	UML 2.1	Resolved	closed
UML22-720	Section: 12.3.7	UML 2.0	UML 2.1	Resolved	closed
UML22-719	Section: 12.3.6	UML 2.0	UML 2.1	Resolved	closed
UML22-683	Section: 11.3.25	UML 2.0	UML 2.1	Resolved	closed
UML22-682	Section: 11.3.24	UML 2.0	UML 2.1	Resolved	closed
UML22-629	Section: 7.3.35	UML 2.0	UML 2.1	Resolved	closed
UML22-631	Section: 8.3.1 - typo	UML 2.0	UML 2.1	Resolved	closed
UML22-630	Section: 8.3.1	UML 2.0	UML 2.1	Resolved	closed
UML22-628	Section: 7.3.34	UML 2.0	UML 2.1	Resolved	closed
UML22-627	Section: 7.3.33	UML 2.0	UML 2.1	Resolved	closed
UML22-637	Section: 9.3.5	UML 2.0	UML 2.1	Resolved	closed
UML22-636	Section: 9.3.3	UML 1.4.2	UML 2.1	Resolved	closed
UML22-635	Section: 9.3.2	UML 2.0	UML 2.1	Resolved	closed
UML22-632	Section: 8.3.1	UML 2.0	UML 2.1	Resolved	closed
UML22-633	Section: 9.20.2	UML 2.0	UML 2.1	Resolved	closed
UML22-634	Section: 9.3.1	UML 2.0	UML 2.1	Resolved	closed
UML22-638	Section: 9.3.9	UML 2.0	UML 2.1	Resolved	closed
UML22-561	InfrastructureLibrary defines, but should not use package merge	UML 1.4.2	UML 2.1	Resolved	closed
UML22-557	section 2.10.4.1 detailed semantics of collaborations	UML 1.4.2	UML 2.1	Resolved	closed
UML22-554	Section: 7.3.43	UML 2.0	UML 2.1	Resolved	closed
UML22-559	Interactions	UML 1.4.2	UML 2.1	Resolved	closed
UML22-558	Section: 7.3.44 - OCL incorrect	UML 1.4.2	UML 2.1	Resolved	closed
UML22-555	Section: 7.2.8	UML 1.4.2	UML 2.1	Resolved	closed
UML22-560	UML 2 Super Basic Interactions	UML 1.4.2	UML 2.1.2	Resolved	closed
UML22-562	An observed time value must be written into a structural feature	UML 2.0	UML 2.1.2	Resolved	closed
UML22-556	Classes	UML 1.4.2	UML 2.1	Resolved	closed
UML22-691	Section: 11.3.34	UML 2.0	UML 2.1	Resolved	closed
UML22-690	Section: 11.3.33	UML 2.0	UML 2.1	Resolved	closed
UML22-689	Section: 11.3.31	UML 2.0	UML 2.1	Resolved	closed
UML22-684	Section: 11.3.26	UML 2.0	UML 2.1	Resolved	closed
UML22-694	Section: 11.3.27	UML 2.0	UML 2.1	Resolved	closed
UML22-693	Section: 11.3.36	UML 2.0	UML 2.1	Resolved	closed
UML22-686	Section: 11.3.28	UML 2.0	UML 2.1	Resolved	closed
UML22-687	Section: 11.3.29	UML 2.0	UML 2.1	Resolved	closed
UML22-692	Section: 11.3.35	UML 2.0	UML 2.1	Resolved	closed
UML22-688	Section: 11.3.30	UML 2.0	UML 2.1	Resolved	closed
UML22-685	Section: 11.3.27	UML 2.0	UML 2.1	Resolved	closed
UML22-588	Optional inputs	UML 2.0	UML 2.1	Resolved	closed
UML22-587	Preserve order in result of read actions	UML 2.0	UML 2.1	Resolved	closed
UML22-582	Interactions chapter refers to ActivityInvocations	UML 2.0	UML 2.1	Resolved	closed
UML22-583	Destruction semantics in StructuredClassifier	UML 2.0	UML 2.1	Resolved	closed
UML22-585	Figure 119 missing multiplicity	UML 2.0	UML 2.1	Resolved	closed
UML22-584	Link maintenance in StructuredClassifier	UML 2.0	UML 2.1	Resolved	closed
UML22-591	ObjectNode, constraint 1 In ObjectNode	UML 2.0	UML 2.1	Resolved	closed
UML22-590	DestroyObjectAction semantics	UML 2.0	UML 2.1	Resolved	closed
UML22-589	IsReadOnly constriant	UML 2.0	UML 2.1	Resolved	closed
UML22-586	Notation for method	UML 2.0	UML 2.1	Resolved	closed
UML22-659	Section: 11.3.1	UML 2.0	UML 2.1	Resolved	closed
UML22-658	Section: 11.1	UML 2.0	UML 2.1	Resolved	closed
UML22-621	Section: 7.3.15	UML 2.0	UML 2.1	Resolved	closed
UML22-620	Section: 7.3.12	UML 2.0	UML 2.1	Resolved	closed
UML22-626	Section: 7.3.32 Page: 96-99	UML 2.0	UML 2.1	Resolved	closed
UML22-625	Section: 7.3.32	UML 2.0	UML 2.1	Resolved	closed
UML22-624	Section: 7.3.22	UML 2.0	UML 2.1	Resolved	closed
UML22-616	Section: 6.5.1: Error in example	UML 2.0	UML 2.1	Resolved	closed
UML22-619	Section: 7.3.10	UML 2.0	UML 2.1	Resolved	closed
UML22-622	Section: 7.3.20	UML 2.0	UML 2.1	Resolved	closed
UML22-618	Section: 7.3.8	UML 2.0	UML 2.1	Resolved	closed
UML22-623	Stereotypes applying in UML 2.0	UML 1.4.2	UML 2.1	Resolved	closed
UML22-617	Section: 7.3.3	UML 2.0	UML 2.1	Resolved	closed
UML22-678	Section: 11.3.20	UML 2.0	UML 2.1	Resolved	closed
UML22-677	Section: 11.3.19	UML 2.0	UML 2.1	Resolved	closed
UML22-680	Section: 11.3.22 -- significant revision?	UML 2.0	UML 2.1	Resolved	closed
UML22-679	Section: 11.3.21	UML 2.0	UML 2.1	Resolved	closed
UML22-696	Section: 11.3.40	UML 2.0	UML 2.1	Resolved	closed
UML22-695	Section: 11.3.38	UML 2.0	UML 2.1	Resolved	closed
UML22-681	Section: 11.3.23 -- significant revision?	UML 2.0	UML 2.1	Resolved	closed
UML22-672	Section: 11.3.14	UML 2.0	UML 2.1	Resolved	closed
UML22-676	Section: 11.3.18	UML 2.0	UML 2.1	Resolved	closed
UML22-674	Section: 11.3.16	UML 2.0	UML 2.1	Resolved	closed
UML22-675	Section: 11.3.17	UML 2.0	UML 2.1	Resolved	closed
UML22-673	Section: 11.3.15	UML 2.0	UML 2.1	Resolved	closed
UML22-709	Section: 11.3.53	UML 2.0	UML 2.1	Resolved	closed
UML22-708	Section: 11.3.42	UML 2.0	UML 2.1	Resolved	closed
UML22-698	Section: 11.3.43	UML 2.0	UML 2.1	Resolved	closed
UML22-697	Section: 11.3.41	UML 2.0	UML 2.1	Resolved	closed
UML22-660	Section: 11.3.2	UML 2.0	UML 2.1	Resolved	closed
UML22-667	Section: 11.3.9	UML 2.0	UML 2.1	Resolved	closed
UML22-666	Section: 11.3.8	UML 2.0	UML 2.1	Resolved	closed
UML22-670	Section: 11.3.12	UML 2.0	UML 2.1	Resolved	closed
UML22-669	Section: 11.3.11	UML 2.0	UML 2.1.2	Resolved	closed
UML22-668	Section: 11.3.10	UML 2.0	UML 2.1	Resolved	closed
UML22-664	Section: 11.3.6	UML 2.0	UML 2.1	Resolved	closed
UML22-665	Section: 11.3.7	UML 2.0	UML 2.1	Resolved	closed
UML22-663	Section: 11.3.5	UML 2.0	UML 2.1	Resolved	closed
UML22-671	Section: 11.3.13	UML 2.0	UML 2.1	Resolved	closed
UML22-579	Connector multiplicity notation	UML 2.0	UML 2.1	Resolved	closed
UML22-578	Associations between interfaces	UML 2.0	UML 2.1	Resolved	closed
UML22-580	create dependency Figures 103 and 121	UML 2.0	UML 2.1	Resolved	closed
UML22-573	Transitivity in composition	UML 2.0	UML 2.1	Resolved	closed
UML22-581	underlined association name	UML 2.0	UML 2.1.2	Resolved	closed
UML22-577	Section: Classes	UML 2.0	UML 2.1	Resolved	closed
UML22-572	Add concept "StateInvariant"	UML 2.0	UML 2.1	Resolved	closed
UML22-574	Pin/parameter matching constraints	UML 2.0	UML 2.1	Resolved	closed
UML22-576	Section: Classes	UML 2.0	UML 2.1	Resolved	closed
UML22-575	Section: CB/ACT	UML 2.0	UML 2.1	Resolved	closed
UML22-723	Section: 12.3.9	UML 2.0	UML 2.1	Resolved	closed
UML22-722	Section: 12.1	UML 2.0	UML 2.1	Resolved	closed
UML22-641	Section: 8.3.4	UML 2.0	UML 2.1	Resolved	closed
UML22-640	Section: 9.3.10	UML 2.0	UML 2.1	Resolved	closed
UML22-647	Section: 10.3.1	UML 2.0	UML 2.1	Resolved	closed
UML22-648	Section: 10.3.1	UML 2.0	UML 2.1	Resolved	closed
UML22-644	Section: 12.3.13	UML 2.0	UML 2.1	Resolved	closed
UML22-645	Section: 12.3.13	UML 2.0	UML 2.1	Resolved	closed
UML22-643	Section: 9.3.13	UML 2.0	UML 2.1	Resolved	closed
UML22-639	Section: 9.3.9	UML 2.0	UML 2.1	Resolved	closed
UML22-646	Section: 9.2	UML 2.0	UML 2.1	Resolved	closed
UML22-642	Section: 9.3.12	UML 2.0	UML 2.1	Resolved	closed
UML22-615	Section: 7.4.1	UML 2.0	UML 2.1	Resolved	closed
UML22-614	Section: 7.3.6	UML 2.0	UML 2.1	Resolved	closed
UML22-610	Section: 11.8.3	UML 2.0	UML 2.1	Resolved	closed
UML22-609	Section: 11.6.1	UML 2.0	UML 2.1	Resolved	closed
UML22-613	Section: 7.3.3	UML 2.0	UML 2.1	Resolved	closed
UML22-612	Section: 13.1.5	UML 2.0	UML 2.1	Resolved	closed
UML22-607	Section: 11.5	UML 2.0	UML 2.1	Resolved	closed
UML22-606	search for referenced item -- Section: 11.3.4	UML 2.0	UML 2.1	Resolved	closed
UML22-603	Figure 68	UML 2.0	UML 2.1	Resolved	closed
UML22-602	methods not defined under attributes	UML 2.0	UML 2.1	Resolved	closed
UML22-611	Section: 13.1.2	UML 2.0	UML 2.1	Resolved	closed
UML22-605	Section: 11.3.3	UML 2.0	UML 2.1	Resolved	closed
UML22-604	Section: 11.3.1	UML 2.0	UML 2.1	Resolved	closed
UML22-608	Actor is a specialized Classifier and not BehavioredClassifier	UML 2.0	UML 2.1	Resolved	closed
UML22-711	Section: 12.1	UML 2.0	UML 2.1	Resolved	closed
UML22-710	Section: 11.3.54	UML 2.0	UML 2.1	Resolved	closed
UML22-713	{redefined } should be named {redefines }	UML 2.0	UML 2.1	Resolved	closed
UML22-712	Property string {bag} is redundant	UML 2.0	UML 2.1.2	Resolved	closed
UML22-718	Section: 12.3.5	UML 2.0	UML 2.1	Resolved	closed
UML22-717	Section: 12.3.4	UML 2.0	UML 2.1	Resolved	closed
UML22-703	Section: 11.3.48	UML 2.0	UML 2.1	Resolved	closed
UML22-701	Section: 11.3.46	UML 2.0	UML 2.1	Resolved	closed
UML22-700	Section: 11.3.45	UML 2.0	UML 2.1	Resolved	closed
UML22-707	Section: 11.3.52	UML 2.0	UML 2.1	Resolved	closed
UML22-706	Section: 11.3.51	UML 2.0	UML 2.1	Resolved	closed
UML22-705	Section: 11.3.50	UML 2.0	UML 2.1	Resolved	closed
UML22-699	Section: 11.3.44	UML 2.0	UML 2.1	Resolved	closed
UML22-704	Section: 11.3.49	UML 2.0	UML 2.1	Resolved	closed
UML22-702	Section: 11.3.47	UML 2.0	UML 2.1	Resolved	closed
UML22-596	unclear statement	UML 2.0	UML 2.1	Resolved	closed
UML22-595	Text references Figure 8 and the correct figure number is 6	UML 2.0	UML 2.1	Resolved	closed
UML22-599	Section is badly worded and does not make a lot of sense	UML 2.0	UML 2.1	Resolved	closed
UML22-598	clarify what a directed association is	UML 2.0	UML 2.1	Resolved	closed
UML22-593	Terminology Issue	UML 1.4.2	UML 2.1.2	Resolved	closed
UML22-600	typing error in the statement :unrestricted ?	UML 2.0	UML 2.1	Resolved	closed
UML22-597	extra word in the last sentence of the paragraph under Attributes	UML 2.0	UML 2.1	Resolved	closed
UML22-594	section 9.20.2 VisibilityKind lists two types of visibility	UML 2.0	UML 2.1	Resolved	closed
UML22-592	StructuredActivityNode specialized multiplicity	UML 2.0	UML 2.1	Resolved	closed
UML22-601	What happened to real numbers	UML 2.0	UML 2.1	Resolved	closed
UML22-724	Section: 12	UML 2.0	UML 2.1	Resolved	closed
UML22-662	Section: 11.3.4	UML 2.0	UML 2.1	Resolved	closed
UML22-661	Section: 11.3.3	UML 2.0	UML 2.1	Resolved	closed
UML22-655	Section: 10.3.10	UML 2.0	UML 2.1	Resolved	closed
UML22-654	Section: 10.3.9	UML 2.0	UML 2.1	Resolved	closed
UML22-657	Section: 10.4	UML 1.4.2	UML 2.1	Resolved	closed
UML22-652	Section: 10.3.6	UML 2.0	UML 2.1	Resolved	closed
UML22-656	Section: 10.3.11	UML 2.0	UML 2.1	Resolved	closed
UML22-650	Section: 10.3.4	UML 2.0	UML 2.1	Resolved	closed
UML22-653	Section: 10.3.8	UML 2.0	UML 2.1	Resolved	closed
UML22-649	Section: 10.3.3	UML 2.0	UML 2.1	Resolved	closed
UML22-651	Section: 10.3.5	UML 2.0	UML 2.1	Resolved	closed
UML22-565	ReduceAction	UML 1.4.2	UML 2.1	Resolved	closed
UML22-564	UML 2 Super / Incorrect statement on port visibility	UML 1.4.2	UML 2.1	Resolved	closed
UML22-566	Section: 14.3.7	UML 2.0	UML 2.1	Resolved	closed
UML22-563	Minor error in BNF of an message argument	UML 2.0	UML 2.1	Resolved	closed
UML22-568	Section: 14.3.14	UML 2.0	UML 2.1	Resolved	closed
UML22-569	Section: 14.3.16	UML 2.0	UML 2.1	Resolved	closed
UML22-571	StateInvariants/Continuations	UML 2.0	UML 2.1	Resolved	closed
UML22-570	Section: Table 14	UML 2.0	UML 2.1	Resolved	closed
UML22-567	Section: 14.3.13	UML 2.0	UML 2.1	Resolved	closed
UML22-553	DataType attributes UML 2 Super (ptc/04-10-02)	UML 1.4.2	UML 2.1	Resolved	closed
UML22-534	In normative XMI file for the metamodel, no Associations have a name.	XMI 2.0	UML 2.1	Resolved	closed
UML22-533	UML 2 Super/Interactions/Constraints for create messages	XMI 2.0	UML 2.1	Resolved	closed
UML22-536	UML2 Infra/11.5.1/Invalid reference to Attribute class	XMI 2.0	UML 2.1	Resolved	closed
UML22-535	Figure 78	UML 2.0	UML 2.1.2	Resolved	closed
UML22-532	Class InfrastructureLibrary::Core::Basic::Property	UML 2.0	UML 2.1	Resolved	closed
UML22-531	In 2.13.3, the first sub-section about ActivityGraph is not numbered	UML 1.5	UML 2.1	Resolved	closed
UML22-529	missing closing parenthesis	UML 1.5	UML 2.1	Resolved	closed
UML22-528	The Composition section does not follow the usual conventions	UML 1.5	UML 2.1	Resolved	closed
UML22-526	In "2.9.3.5 Instance", numbering of different well-formedness rules wrong	UML 1.5	UML 2.1	Resolved	closed
UML22-525	The numbering of the sub-sections in 2.7.2 is wrong	UML 1.5	UML 2.1	Resolved	closed
UML22-523	Associations section of element JumpHandler	UML 1.5	UML 2.1	Resolved	closed
UML22-522	Remove one of the dots between protectedAction and availableOutput	UML 1.5	UML 2.1	Resolved	closed
UML22-524	UML 2.0 infra and super Constraints Diagram of the Kernel	UML 1.5	UML 2.1	Resolved	closed
UML22-527	The section about Procedure does not contain any well-formedness rules	UML 1.5	UML 2.1	Resolved	closed
UML22-530	At the bottom of the page, the characters "antics." should be removed	UML 1.5	UML 2.1	Resolved	closed
UML22-549	Inconsistent use of 'Element' between MOF and UML	UML 1.4.2	UML 2.1	Resolved	closed
UML22-548	Missing XMI tags in spec and XMI rendition of metamodel	UML 1.4.2	UML 2.1	Resolved	closed
UML22-504	ptc-03-09-15/Constructs::Class superClass property	UML 1.5	UML 2.1	Resolved	closed
UML22-503	ptc-03-09-15/Non-navigable ends with no role names nor multiplicities	UML 1.5	UML 2.1	Resolved	closed
UML22-502	UML 2 Issue: Message notation	UML 1.5	UML 2.1	Resolved	closed
UML22-508	Why not using the UML1 activity symbol for UML2 actions?	UML 1.5	UML 2.1	Resolved	closed
UML22-507	Multiplicity seems to be broken - UML2 Infra & Super	UML 1.5	UML 2.1	Resolved	closed
UML22-499	UML 2 Super / Dependency / ownership of dependencies	UML 1.5	UML 2.1	Resolved	closed
UML22-498	Clarification of Information Flow semantics	UML 1.5	UML 2.1	Resolved	closed
UML22-497	Activity diagram problems	UML 1.5	UML 2.1	Resolved	closed
UML22-490	UML 2 Infra/Metamodel::Constructs/invalid OCL constraint for "opposite"	UML 1.5	UML 2.1	Resolved	closed
UML22-489	UML 2 Super/Metamodel::Kernel/missing merges	UML 1.5	UML 2.1	Resolved	closed
UML22-488	UML 2 Super/Package merge/redefinitions issue - lost association ends	UML 1.5	UML 2.1	Resolved	closed
UML22-487	UML 2 Super/Metamodel::Super/missing merge	UML 1.5	UML 2.1	Resolved	closed
UML22-493	raisedException	UML 1.5	UML 2.1	Resolved	closed
UML22-492	UML 2 Super / Templates / TemplateParameter not named	UML 1.5	UML 2.1	Resolved	closed
UML22-491	UML 2 Super/pg.75/kinds of changeability	UML 1.5	UML 2.1	Resolved	closed
UML22-496	Section 9.3.4 page 161, Presentation Option	UML 1.5	UML 2.1	Resolved	closed
UML22-495	UML 2 Super / Kernel features / cannot exclude superclass properties	UML 1.5	UML 2.1	Resolved	closed
UML22-494	Syntax of names	UML 1.5	UML 2.1	Resolved	closed
UML22-501	UML 2 Issue: definition of navigability	UML 1.5	UML 2.1.2	Resolved	closed
UML22-500	Use 'represent' for the relationship of a model	UML 1.5	UML 2.1	Resolved	closed
UML22-506	Rose Model of UML 2.0 spec	UML 1.5	UML 2.1	Resolved	closed
UML22-505	ptc-03-09-15/Relationships among Core packages	UML 1.5	UML 2.1	Resolved	closed
UML22-547	Move Comment into Basic and add Kind	UML 1.4.2	UML 2.1	Resolved	closed
UML22-546	Unconsistent Profile extension description (02)	UML 1.4.2	UML 2.1	Resolved	closed
UML22-545	Unconsistent association extension description	UML 1.4.2	UML 2.1	Resolved	closed
UML22-538	Section 11.7	UML 2.0	UML 2.1	Resolved	closed
UML22-537	simple time model" in CommonBehavior	UML 2.0	UML 2.1.2	Resolved	closed
UML22-551	Problem with diagram references in Profiles section	UML 1.4.2	UML 2.1	Resolved	closed
UML22-550	Design principles	UML 1.4.2	UML 2.1	Resolved	closed
UML22-544	The specification is fond of using 'typically.'	UML 2.0	UML 2.1	Resolved	closed
UML22-543	TimeObservationAction and DurationObservationAction	UML 2.0	UML 2.1.2	Resolved	closed
UML22-541	add an interaction fragment	UML 2.0	UML 2.1	Resolved	closed
UML22-540	Interactions model sequences of events	UML 2.0	UML 2.1.2	Resolved	closed
UML22-539	Clarify example in figure 133	UML 2.0	UML 2.1	Resolved	closed
UML22-542	XMI schema	RAS 2.0b1	UML 2.1	Resolved	closed
UML22-552	DataType attributes UML 2 Super (ptc/04-10-02)	UML 1.4.2	UML 2.1	Resolved	closed
UML22-486	UML 2 Super/Metamodel::Constructs/owningComment	UML 1.5	UML 2.1	Resolved	closed
UML22-485	Classes diagram of the Core::Constructs package	UML 2.0	UML 2.1	Resolved	closed
UML22-484	cross-reference missing	UML 2.0	UML 2.1	Resolved	closed
UML22-483	Relationship and DirectedRelationship in Core::Constructs	UML 2.0	UML 2.1	Resolved	closed
UML22-482	document appears to be inconsistent in how it handles concepts	UML 2.0	UML 2.1	Resolved	closed
UML22-477	Designates a Generalization	UML 1.4	UML 2.1	Resolved	closed
UML22-476	Namespace issue (UML 1.4 formal/2002-09-67, 2.5.3.26 Namespace )	UML 1.4	UML 2.1.2	Resolved	closed
UML22-475	Sending a signal after a delay	XMI 1.3	UML 2.1.2	Resolved	closed
UML22-474	Does visibility apply to creating an destroying links?	XMI 1.2	UML 2.1	Resolved	closed
UML22-481	relationship should just be a cross-reference	UML 1.5	UML 2.1	Resolved	closed
UML22-480	formal/03-03-01 : Omission of definition of Class "Action"	UML 1.5	UML 2.1	Resolved	closed
UML22-473	Specify XMI parameters for the UML / XMI interchange format	UML 1.3	UML 2.1	Resolved	closed
UML22-479	logic upperbound is the same as the lower bound.	UML 1.5	UML 2.1	Resolved	closed
UML22-478	2.5.2.27 ModelElement	UML 1.4	UML 2.1	Resolved	closed
UML22-511	UML 2 Super / Classes / dependencies should be unidirectional	UML 1.5	UML 2.1	Resolved	closed
UML22-510	two classes "NamedElement	UML 1.5	UML 2.1	Resolved	closed
UML22-515	well-formedness rules are not numbered correctly	UML 1.5	UML 2.1	Resolved	closed
UML22-514	number of the figure is wrong	UML 1.5	UML 2.1	Resolved	closed
UML22-520	UML 1.5 table of contents	XMI 2.0	UML 2.1	Resolved	closed
UML22-519	In the last paragraph, the period after the word "collections" on the secon	UML 1.5	UML 2.1	Resolved	closed
UML22-518	In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11	UML 1.5	UML 2.1	Resolved	closed
UML22-517	The multiplicity of association named subaction of type Action ill formed	UML 1.5	UML 2.1	Resolved	closed
UML22-521	Operations and derived attributes	UML 1.5	UML 2.1	Resolved	closed
UML22-509	class "InfrastructureLibrary.core.constructs.Association",	UML 1.5	UML 2.1	Resolved	closed
UML22-513	remove paragraph	UML 1.5	UML 2.1	Resolved	closed
UML22-512	UML 2 Infra/Metamodel/missing derivation indicators	UML 1.5	UML 2.1.2	Resolved	closed
UML22-516	multiplicity of the association named "type" of type DataType	UML 1.5	UML 2.1	Resolved	closed

Issues Descriptions

presentation option for transitions

Key: UML22-1381
Legacy Issue Number: 7643
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
The presentation option for transitions, p.599 of UML2-Super.book.040814.pdf, has the following two short-comings: * It does not make clear that this presentation option is mapped to an Activity as the effect Behavior, albeit all the mapping described subsequently assumes that this is the case. * The mapping for the action sequence symbol is ambiguous.
Reported: UML 2.0 — Thu, 19 Aug 2004 04:00 GMT
Disposition: Resolved — UML 2.1.1
Disposition Summary:
see above
Updated: Thu, 12 Mar 2015 01:38 GMT

Figure 109, p162

Key: UML22-1379
Legacy Issue Number: 7434
Status: closed
Source: Silogic ( Yves BERNARD)
Summary:
Figure 109, p162: according to the metamodel presented in figure 100, I think that the dependencies shown in this diagram are inverted.
Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Discussion
This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change
Updated: Sun, 8 Mar 2015 15:16 GMT

LinkEndData - Inconsistency with Figure 146

Key: UML22-1378
Legacy Issue Number: 7182
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
LinkEndData defines an association "input" which is not depicted in Figure 146.

Is this a derived association, as described below in Constraint [3] ? Should its name be changed to "/input" ?
Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
Disposition: Closed; No Change — UML 2.1
Disposition Summary:
No Data Available
Updated: Sun, 8 Mar 2015 15:16 GMT

UML-2 deployment diagram notation

Key: UML22-1377
Legacy Issue Number: 6924
Status: closed
Source: International Business Machines ( Mr. Anders Ek)
Summary:
An issue concerning UML-2 deployment diagram notation.

The ExecutionEnvironment notation is a Node symbol with a keyword within guillemots. But what is the keyword? The text says <<ExecutionEnvironment>> but in the examples says <<container>> (figure 136) and <<execution env>> (Table 8, covering the symbols in a deployment diagram).
Reported: UML 2.0 — Mon, 26 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Sun, 8 Mar 2015 15:13 GMT

section on connectors in the component chapter

Key: UML22-1376
Legacy Issue Number: 7364
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
The section on connectors in the component chapter does not add any new functionality to the connectors defined in internal structure. It does provide an additional notation for assembly connectors. There is no reason to have this section in components. Everything that is said semantically about connectors here applies equally to the more general connector. Suggestion: Do not subtype connector in component but move the content of this section to the connector section in internal structure and merge with the section there. Adjust the examples to apply to structured classifiers in general (i.e., delete the component symbol). Further, the ConnectorKind should be derived as it is determined by the manner in which the connector is attached to connectable elements. Deriving this connector ensures that constraints are always true and allows to do away with some consistency constraints. (Actually, it is not clear what the value of this attribute is, as it is already determined from the attachments.) Alternatively, if the presentation option is not in general desired (albeit I cannot see why this additional consistency would not be wanted), the text can be moved up but the presentation option can be added in this section.
Reported: UML 2.0 — Wed, 19 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Moving all of BasicComponents.Connector into InternalStructures, although perhaps strategically a good idea, seems like a bridge too far for the RTF. Also Thomas is not entirely accurate when he says it adds no new functionality apart from the notation. In particular BasicComponents adds the idea of a connector contract, which is a set of Behaviors.
Therefore I propose that we leave the text where it is, albeit we should fix the many bugs in it that are the topics of this and other issues.
However the proposal that kind:ConnectorKind should be derived is entirely sensible, especially since the current constraints on connector kind are the topic of numerous issues (7248-7251).
Updated: Sun, 8 Mar 2015 15:08 GMT

7.3.41 Parameter (from Kernel, AssociationClasses)"

Key: UML22-1375
Legacy Issue Number: 9338
Status: closed
Source: Anonymous
Summary:
Please note however, that (as far as I can see) Parameter only occurs in Kernel, NOT in AssociationClasses. So the correct statement would be "Parameter (from Kernel). This might bear a relation to the already existing FTF issue 8117.
Reported: UML 2.1 — Mon, 30 Jan 2006 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
This is an exact duplicate of issue 9337 Revised Text: N/A Disposition: Duplicate
Updated: Sun, 8 Mar 2015 14:22 GMT

Profiles::ObjectNode has wrong default multiplicity

Key: UML22-1374
Legacy Issue Number: 8455
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
ObjectNode::upper should have default multiplicity unbounded (“*”) in order of object nodes to be multi-valued by default.

Recommendation:

Redefine inherited MultiplicityElement::upper to have default “*” in ObjectNode.
Reported: UML 2.1 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1.1
Disposition Summary:
See issue 8454 for disposition
Updated: Sun, 8 Mar 2015 14:22 GMT

Section: 12.3.52

Key: UML22-1373
Legacy Issue Number: 8277
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The association activityScope:Activity[0..1] substes owner as indicated in fit. 195. Add OCL notation to Constraints. Type - lower case the second letter in the second sentence of sub-section Additional Operations.
Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
OCL is duplicate with 6346. Subsets addressed in issue 9000.
Updated: Sun, 8 Mar 2015 14:18 GMT

Section: Composite Structures/Abstract syntax

Key: UML22-1367
Legacy Issue Number: 11503
Status: closed
Source: Validas AG ( Reinhard Jeschull)
Summary:
There are two diagrams on page 164, 'Connectors' and 'The port metaclass'. The two diagrams are the same. Can you send me the picture of this diagram via e-mail? We need it to create a metamodel.
Reported: UML 2.1.1 — Thu, 20 Sep 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
withdrawn, this issue has been resolved
Updated: Fri, 6 Mar 2015 22:56 GMT

ptc/06-01-02:14.3.14, Notation

Key: UML22-1366
Legacy Issue Number: 9606
Status: closed
Source: The MathWorks ( Mr. Alan Moore)
Summary:
The following notation expression isn’t well formed:

<interactionconstraint> ::= [‘[‘ (<Boolean-expression’ | ‘else‘) ‘]’]
Reported: UML 2.1 — Mon, 24 Apr 2006 04:00 GMT
Disposition: Resolved — UML 2.1.1
Disposition Summary:
withdrawn by submitter
Updated: Fri, 6 Mar 2015 22:55 GMT

Events

Key: UML22-1365
Legacy Issue Number: 7638
Status: closed
Source: International Business Machines ( Mr. Anders Ek)
Summary:
'Events' are in the spec defined as standalone entities using the Trigger concept. In the ongoing FTF work the relation between event and trigger has been changed and the has been changed and there is now an Event metaclass in addition to the existing Trigger class. However, the text does not give any syntax for defining standalone event and it does not state how to refer to an event defined as a standalone entity from e.g. a transition in a statemachine. So two issues: - syntax for standalone events - clarification the how to refer to standalone events from e.g. transitions in statemachines
Reported: UML 2.0 — Wed, 18 Aug 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Additional events for Interactions

Key: UML22-1364
Legacy Issue Number: 7637
Status: closed
Source: X-Change Technologies and Klocwork ( Joaquin Miller for Nikolai Mansurov)
Summary:
13.1 Overview of Common Behaviors discusses occurrences for which there is no event in the FAS nor in the proposed revision to triggers and events. Figure 307 - Invocation Domain Model shows occurrences of Start, Termination, Trigger, and CallBehavior events. Figure 308 - Communication Domain Model shows occurrences of Invocation and Receiving events. Figure 309 - Domain Model Showing Request Kinds shows occurrences of SendInvocation, CallInvocation, SendRequest, Call Request, Signal, and Call events. These are all discussed in the text, along with occurrences of change and time events. Figure 310 - Domain Model Showing Event Kinds shows two supertypes, for occurrences of Trigger and Spontaneous events. These are discussed in the text. It appears that AcceptEventAction is intended to be used with any kind of event and AcceptCallAction for call request events. [by Nick:] I've reviewed the effects of the proposed alignment of event/occurences/types on Interactions. I believe, the proposed changes will have a very positive effect indeed on making the new Interactions a better part of the overall spec. I would suggest that we do add more subtypes of event in order to have a better match with Interactions: - CreationEvent - DestructionEvent - ExecutionStartEvent - ExecutionFinishEvent
Reported: UML 2.0 — Mon, 16 Aug 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Incorrect constraints on Pin and ObjectFlow On Pin

Key: UML22-1363
Legacy Issue Number: 7631
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Incorrect constraints on Pin and ObjectFlow On Pin, the constraint isUnique = false introduced by 6090 should be on ObjectNode, and the text should be "Object nodes are not unique typed elements." On ObjectFlow, Constraints (BasicActivities), rule 1 still reflects the time when pins were connected to actions by flows, during the submission process. It should be "Object flows may not have actions at either end.".
Reported: UML 2.0 — Sun, 15 Aug 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

resolution to issue 6093 removed too much constraint

Key: UML22-1362
Legacy Issue Number: 7630
Status: closed
Source: Universitaet Paderborn ( Jan Hendrik Hausmann)
Summary:
The resolution to issue 6093 removed too much constraint. It should be left in place for decision, merge, and fork nodes.
Reported: UML 2.0 — Fri, 13 Aug 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 9.3.12

Key: UML22-1361
Legacy Issue Number: 7613
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
The notation for property states that the namestring is as in the Classes chapter, and gives an incorrect chapter number. In fact, the namestring syntax is as for properties in the Classes chapter in Kernel, which should be properly referenced.
Reported: UML 2.0 — Tue, 3 Aug 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 7.11.4

Key: UML22-1360
Legacy Issue Number: 7612
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
The notation for properties is missing in this section. There are references to examples in other sections, and the notation for AssociationClasses is defined, but there is no notation described for properties
Reported: UML 2.0 — Tue, 3 Aug 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This is a duplicate of issue 7575
Updated: Fri, 6 Mar 2015 22:55 GMT

Notation for property has gone missing

Key: UML22-1359
Legacy Issue Number: 7575
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
Notation for property has gone missing. The notation section merely states that "Notation for properties is defined separately for their use as attributes and association ends." Give details for the namestring for attributes and for association ends (the latter is currently described in the association section, but probably should be described in the property section and referenced from the association section). The namestring for attributes is not described at all.
Reported: UML 2.0 — Sun, 11 Jul 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

ReadSelfAction

Key: UML22-1358
Legacy Issue Number: 7562
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
ReadSelfAction has the contraint: "The action must be contained in an activity that has a host classifier." On the other hand the semantic section describes: "For activities that have no other context object, the activity itself is the context object." A ReadSelfAction within an activity without a host classifier object returns the activity object. So the constraint is superfluous.
Reported: UML 2.0 — Mon, 5 Jul 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This was fixed as part of 7319.
Updated: Fri, 6 Mar 2015 22:55 GMT

Attribute scope is of type StructuredActivityNode instead of StructuredActi

Key: UML22-1357
Legacy Issue Number: 7554
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Attribute scope is of type StructuredActivityNode instead of StructuredActivityGroup
Reported: UML 2.0 — Thu, 1 Jul 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 12.3.16

Key: UML22-1356
Legacy Issue Number: 7440
Status: closed
Source: Silogic ( Yves BERNARD)
Summary:
It's explicitly stated that all tokens within the protected node terminate if an exception isn't caught but nothing is written about how the tokens are managed when the exception is caught, except that the handler will provide the output pins of the protected node. It could implicitly indicate that tokens in the protected nodes are terminated in this case also. Is it right ? Is a semantic variation point?
Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

What are the "edges" we're talking about?

Key: UML22-1355
Legacy Issue Number: 7439
Status: closed
Source: Silogic ( Yves BERNARD)
Summary:
Constraints #3, #4 and #5, p304: the descriptions of the constraints aren't clear and seem inconsistent. What are the "edges" we're talking about? From inside the activity, inputs pins have only outgoing edges, but from the outside they 've only incomming edges, haven't they?
Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 12.3.3

Key: UML22-1354
Legacy Issue Number: 7438
Status: closed
Source: Silogic ( Yves BERNARD)
Summary:
To review the paragraph just below the figure 207. It seems that the name in the circle symbole is the connector name rather that the edge name (cf. figure 208). A connector name is unique, what isn't the case of an edge name.
Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Figure 205, p292:

Key: UML22-1353
Legacy Issue Number: 7437
Status: closed
Source: Silogic ( Yves BERNARD)
Summary:
Figure 205, p292: several guard conditions seem misplaced in this diagram (e.g. one of the [else], [cannot reproduce probem], ...)
Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Figure 51, p106

Key: UML22-1350
Legacy Issue Number: 7432
Status: closed
Source: Silogic ( Yves BERNARD)
Summary:
Figure 51, p106: the multiplicity of the "mapping" role in the association between Abstraction and Expression isn't consistent with the description of this association in §7.14.1, p107: "The mapping expression is optional and may be omitted...". Shouldn't it be "0..1" rather than "1"?
Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This was resolved by the resolution to issue 6926
Updated: Fri, 6 Mar 2015 22:55 GMT

ExceptionHandler

Key: UML22-1349
Legacy Issue Number: 7429
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
ExceptionHandler - Presentation Option The connection between an ExecutableNode and an ExceptionHandler is shown by drawing a “lightning bolt” symbol. This is similar to an interrupting edge for which the same symbol is used. According to Figure 259, an option for notating an interrupting edge is a zig zag adornment on a straight line. I suggest to allow the same notation as a presentation option for the connection between an ExecutableNode and an ExceptionHandlers.
Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

figure 175

Key: UML22-1352
Legacy Issue Number: 7436
Status: closed
Source: Silogic ( Yves BERNARD)
Summary:
the figure 175 shows a <<merge>> dependency from the IntermediateActivity package to the StructuredActivity package. This isn't consistent with the description of the IntermediateAcitvityPackage, p266.
Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This was resolved as part of the resolution to issue 6179 and issue 7436.
Updated: Fri, 6 Mar 2015 22:55 GMT

Figure 52, p107: shouldn't the <> relationship be reversed ?

Key: UML22-1351
Legacy Issue Number: 7433
Status: closed
Source: Silogic ( Yves BERNARD)
Summary:
Figure 52, p107: shouldn't the <<refine>> relationship be reversed ?
Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This misleading example was removed by the resolution to issue 6173.
Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 12.3.16 -- Typo

Key: UML22-1348
Legacy Issue Number: 7428
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Typo "Multiple exception handlers may may attached to the same protected node, each by its own lightning bolt." should be ("may" occuring twice) "Multiple exception handlers may be attached to the same protected node, each by its own lightning bolt."
Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Templates, Classifier

Key: UML22-1347
Legacy Issue Number: 7427
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Templates, Classifier - OCL errors in constraint "Classifier::isTemplate() : Boolean; isTemplate = TemplatableElement::isTemplate() or general->exists(isTemplate())" should be "context Classifier::isTemplate() : Boolean body: – returns true, if a least one of the parent classifiers (including the current – classfier) is a template result = self.oclAsType(TemplateableElement).isTemplate() or general->exists(isTemplate())"
Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

ProtocolConformance - inconsistency with Figure 356

Key: UML22-1346
Legacy Issue Number: 7425
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
ProtocolConformance - inconsistency with Figure 356 On page 473 the spec says: "specificMachine: StateMachine [1] : Specifies the state machine which conforms to the general state machine." If this is correct (which would be consistent with the Description section above), then in Figure 356 +specificMachine should end in StateMachine not in ProtocolStateMachine.
Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Can connectors co-operate?

Key: UML22-1341
Legacy Issue Number: 7418
Status: closed
Source: X-Change Technologies ( Joaquin Miller)
Summary:
"A collaboration occurrence indicates a set of roles and connectors that cooperate within the classifier ..." Is it roles that cooperate, or the instances playing those roles? Can connectors co-operate, or do instances playing roles cooperate using connectors?
Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

ParameterableElement - constraint [2] - error in OCL

Key: UML22-1345
Legacy Issue Number: 7424
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
ParameterableElement - constraint [2] - error in OCL "ParameterableElement::isTemplateParameter() : Boolean; isTemplateParameter = parameter->notEmpty()" should be ("templateParamter" instead of parameter; general OCL 2.0 syntax) "context ParameterableElement::isTemplateParameter() : Boolean body: result = templateParameter->notEmpty()"
Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

TemplateableElement - inconsistency

Key: UML22-1344
Legacy Issue Number: 7423
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
TemplateableElement - inconsistency " ownedSignature : TemplateSignature[0..1]The optional template signature specifying the formal template parameters. Subsets Element::ownedElement." The name of this association is inconsistent with Figure 427. There it is called "ownedTemplateSignature". See also OCL navigation expression in constraint [2] on the next page.
Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

TemplateSignature - Typo

Key: UML22-1343
Legacy Issue Number: 7422
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
TemplateSignature - Typo " template : TemplateableElementr[1]The element that owns this template signature. Subsets Element::owner." should be (removed 'r' before multiplicity) " template : TemplateableElement[1]The element that owns this template signature. Subsets Element::owner."
Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

TemplateSignature - inconsistency

Key: UML22-1342
Legacy Issue Number: 7421
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
TemplateSignature - inconsistency Section "Description" says: "A TemplateSignature may reference a set of nested template signatures to reflect the hierarchical nature of a template." There is no such association from TemplateSignature to TemplateSignature in Figure 427. I guess that this sentence is a leftover from a former iteration. Suggestion: remove this sentence.
Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

association "implementingClassifier

Key: UML22-1338
Legacy Issue Number: 7413
Status: closed
Source: X-Change Technologies ( Joaquin Miller)
Summary:
The association "implementingClassifier: Classifier [1] References the operations owned by the Interface." The type declaration says the association connects to Classifier, the drawing says it connects to BehavioredClassifer, but the text seems to say it connects to Operations.
Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Removed text in 9.3.3

Key: UML22-1340
Legacy Issue Number: 7417
Status: closed
Source: X-Change Technologies ( Joaquin Miller)
Summary:
This text was removed from the draft adopted text in preparing the final adopted test: "There is some tension here in that we might want to describe also non-observable or structural aspects of a classifier in a collaboration role, which would not work with an interface. Maybe there is a need for a separate role concept? This would be similar to an abstract classifier but saying that this classifier must be realized like an interface?" What gives?
Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:55 GMT

${issue.summary}

Key: UML22-1339
Legacy Issue Number: 7414
Status: closed
Source: X-Change Technologies ( Joaquin Miller)
Summary:
There will not necessarily be a property implementing the classifier corresponding to the property of the interface." is likely an editorial error
Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

PrimitiveFunction

Key: UML22-1337
Legacy Issue Number: 7405
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
Reading the specification a PrimitiveFunction seems to be the equivalent of OpaqueExpression and OpaqueBehavior (once introduced, see issue 7335), but to be invoked by ApplyFunctionAction (i.e., some uninterpreted behavior defined by body and language). As issue 6625 correctly points out, it misses parameters. ApplyFunctionAction then imposes the additional constraint that the behavior it invokes does not access object memory or have side effects. So the first question to ask is what is the difference between OpaqueBehavior (once introduced) and PrimitiveFunction? They seem to be identical. Clearly there is duplication that should be eliminated. Of course, one could argue that one is a generic behavior and the other is a non-sideeffecting behavior, but in the current specification that is imposed by the invocation action, not by the behavior. So, assuming that we want this non-sideeffecting business, I see two strategies: Have just one kind of behavior, and two kinds of ways of invoking behavior (ignore a third kind, CallOperationAction as it does not have a bearing on this discussion): CallBehaviorAction and ApplyFunctionAction. Both would apply a behavior, but the latter have the constraint that the behavior will not have any side-effects. (ii) Have just one kind of behavior invocation, but two kinds of behavior: OpaqueBehavior and PrimitiveFunction, where the latter has no side effects. Of course, the difference between these two kinds of behaviors could just as easy be made by a Boolean flag (which would be preferable). I see no reason to rule out the use of PrimitiveFunction or a side-effect free behavior as a method. After all, a method need not have a side effect. There seems to be the additional constraint that the primitive function cannot access any object memory, so it would not be able to use the context object. However, to me that seems to be an unjustified constraint; what value does this constraint have? Note that option would not result in non-sideeffecting methods (not existing today). The minimal recommendation is to eliminate one of the superfluous metaclasss by using either or (ii) above. The preferred solution is to eliminate both PrimitiveFunction and ApplyFunctionAction as they are redundant. There is no clear need for the constraints imposed by this behavior.
Reported: UML 2.0 — Sat, 29 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

MarshallAction and UnmarshallAction

Key: UML22-1336
Legacy Issue Number: 7399
Status: closed
Source: International Business Machines ( Dr. Tracy Gardner)
Summary:
MarshallAction and UnmarshallAction What can we use in place of the UML 1.5 MarshallAction and UnmarshallAction actions? SendSignalAction marshalls, but AcceptEventAction doesn't
Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Constraint 2 of AcceptEventAction - typo

Key: UML22-1335
Legacy Issue Number: 7396
Status: closed
Source: International Business Machines ( Dr. Tracy Gardner)
Summary:
Constraint 2 of AcceptEventAction - typo Constraint 2 of AcceptEventAction should refer to AcceptEventAction, not AcceptCallAction.
Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

SAN semantics for starting and stopping

Key: UML22-1334
Legacy Issue Number: 7395
Status: closed
Source: International Business Machines ( Dr. Tracy Gardner)
Summary:
SAN semantics for starting and stopping The SAN semantics for starting and stopping gives only necessary conditions. It should give sufficient conditions
Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Variable pins Extend input and output pins to get and set variables

Key: UML22-1333
Legacy Issue Number: 7394
Status: closed
Source: International Business Machines ( Dr. Tracy Gardner)
Summary:
Variable pins Extend input and output pins to get and set variables.
Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Activities

Key: UML22-1332
Legacy Issue Number: 7393
Status: closed
Source: International Business Machines ( Dr. Tracy Gardner)
Summary:
Activities should be able to have variables without introducing a structured node containing all the other nodes
Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

p.352, section 12.3.35. The attribute Parameter.isStream is inappropriate

Key: UML22-1331
Legacy Issue Number: 7378
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
p.352, section 12.3.35. The attribute Parameter.isStream is inappropriate as it creates a mechanism for activities to pass data different from the other behaviors. CommonBehavior specifies that parameters obtain data when a behavior is invoked and generate outputs when a behavior terminates. Behaviors may generate data during the execution of the behavior by signal send and receipts. There is no reason for activities not to use the same mechanism; it is no more difficult to use than the isStream mechanism introduced. Whether outputs are generated during the lifetime of a behavior or upon termination only, and whether inputs are accepted only at the beginning of an execution are properties of the action, not the parameters, and should such be treated.
Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:55 GMT

empty sections in activities chapter

Key: UML22-1330
Legacy Issue Number: 7377
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
Throughout the activities chapter there are empty sections (i.e., sections consisting merely of a header). These sections should be removed
Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
duplicate
Updated: Fri, 6 Mar 2015 22:55 GMT

p.328, Figure 245, and p.331, Figure 249

Key: UML22-1329
Legacy Issue Number: 7376
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
p.328, Figure 245, and p.331, Figure 249. The text keeps referring to a "UML 1.5 notation" which is confusing. I believe that this section specifies a presentation option, using a "*" in the top right-hand corner of the icon. This presentation option should be explained, rather than saying, that the "UML 1.5 notation for unlimited dynamicMultiplicity" is used, as the reader will not know what that is without going to UML 1.5. Similarly, p.331 should refer to the presentation option, not to UML 1.5.
Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Inappropriate to reference RFP documents

Key: UML22-1328
Legacy Issue Number: 7374
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
p.290, below figure 203. It is inappropriate to reference RFP documents or any other non-standards. Just delete the reference. Also, that same paragraph contains a typo "Schedule Pat Mod Workflow" should be "Part". Also, p.299, below figure 215.
Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

attribute Activity.isSingleExecution

Key: UML22-1327
Legacy Issue Number: 7373
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
The attribute Activity.isSingleExecution creates, for activities, something akin to what the difference is between behavior as BehavioredClassifier.classifierBehavior vs. behavior as method of a behavioral feature. In the former case, there is exactly one execution during the life of the classifier (and the behavior would accept many tokens), while in the latter there is one execution for every invocation. Activity should not confusingly add another means of doing the same thing. At minimum, it should be explained what the effect of this attribute is when dealing with classifier behavior vs. method. In particular, it is very confusing what it would mean to have a behavior that is its own context and uses a separate execution for each token. Further, the definition of the attribute: "If true, tokens from separate invocations of the activity may interact" is completely meaningless as a definition.
Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Section 9.3.5. (ConnectableElement)

Key: UML22-1326
Legacy Issue Number: 7371
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
Section 9.3.5. (ConnectableElement) speaks in the description section that a connectable element represents a set of instances that are owned by a containing classifier. However, there are connectable elements that represent instances not owned by the classifier (e.g., the ROOM "slide-in capsules") or the instances might be owned by the classifier only indirectly.
Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Section 9.3.1

Key: UML22-1325
Legacy Issue Number: 7370
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
Section 9.3.1. gives a presentation option to show the constructor for a class graphically, i.e., show an operation associated with a class which is invoked as the constructor function. However, there seems to be no means of associating that graphical depiction of a constructor to an element in the metamodel.
Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

typo

Key: UML22-1324
Legacy Issue Number: 7361
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
Summary:
Typo error, stereotype instead of tagged value in the following sentence:” Non-normative examples of standard <tagged values> stereotypes that a profile ”
Reported: UML 2.0 — Wed, 19 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

typo

Key: UML22-1323
Legacy Issue Number: 7360
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
Summary:
Typo error => “The deployment target owns <the> a set of deployments that target it.”
Reported: UML 2.0 — Wed, 19 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:55 GMT

component deployment

Key: UML22-1322
Legacy Issue Number: 7359
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
Summary:
“A component deployment is the deployment of one or more executable artifacts or artifact instances to a deployment target” ? Why is it mandatory that an artefact has to be executable to be deployed? Is it not possible to deploy a non-executable file, like a configuration file? Even if a configurable file may be encapsulated in an executable artefact, sometime one configuration file may be used by different executable artefacts.
Reported: UML 2.0 — Wed, 19 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

signal

Key: UML22-1321
Legacy Issue Number: 7358
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
Summary:
As signal is a kind of message, I propose to replace “A communication path is an association that can only be defined between nodes, to model the exchange of signals and messages between them.” by “A communication path is an association that can only be defined between nodes, to model the exchange of messages between them."
Reported: UML 2.0 — Wed, 19 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:55 GMT

association between two Nodes

Key: UML22-1320
Legacy Issue Number: 7357
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
Summary:
A communication path is an association between two Nodes, through which Nodes are able to exchange signals and messages.” Signal is a kind of message, so I think this sentence may be simplified by: “A communication path is an association between two Nodes, through which Nodes are able to exchange signals and messages.
Reported: UML 2.0 — Wed, 19 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:55 GMT

Figure 273 - Arrow direction Figure 273

Key: UML22-1319
Legacy Issue Number: 7350
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Figure 273 - Arrow direction Figure 273 - Arrow should point from QuoteResponses to AwardQuote, not from AwardQuote to QuoteResponses
Reported: UML 2.0 — Mon, 17 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This is the same issue as issue 7230.
Updated: Fri, 6 Mar 2015 22:55 GMT

ParameterSet - Typo

Key: UML22-1318
Legacy Issue Number: 7349
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
ParameterSet - Typo " parameter : ParameterPin [1..*] Parameters in the parameter set." should probably be " parameter : Parameter[1..*] Parameters in the parameter set."
Reported: UML 2.0 — Mon, 17 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

ObjectNode

Key: UML22-1317
Legacy Issue Number: 7348
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
ObjectNode - modelling of upperBound upperBound is currently an association to ValueSpecification. According to section Semantics, it is either a LiteralInteger or a LiteralNull. The later is used to specify an unbound upper limit. There are two problems with this approach: - one could define a upper bound of "5" which is legal LiteralInteger, but probably not a desired value for the maximum number of tokens allowed in the node - if upperBound had multiplicity "0..1", one would not have to encode the absence of a specific upper bound with a LiteralNull I suggest to model "upperBound" in analogy to "upperBound" from MultiplicityElement (see 7.4.1). - replace upperBound with upperBoundValue as follows: upperBoundValue: LiteralUnlimitedNatural[0..1] and update Figure 187 accordingly - add the following Additional Operation context ObjectNode::upperBound():UnlimitedNatural post: result = if upperBoundValue>isEmpty() then '*' – infinity else upperBoundValue.unlimitedValue() end if - on page 344, replace "The upper bound must be a positive LiteralInteger or a LiteralNull. An upper bound that is a LiteralNull means the upper bound is unlimited." with "An upper bound that is empty means the upper bound is unlimited."
Reported: UML 2.0 — Mon, 17 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

ActivityEdge - Typo

Key: UML22-1316
Legacy Issue Number: 7347
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
ActivityEdge - Typo "Other rules for when tokens may be passed along the edge depend on the kind of edge and characteristics of its source and target."
Reported: UML 2.0 — Mon, 17 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

ActivityEdge - Section Semantics - Typo

Key: UML22-1315
Legacy Issue Number: 7346
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
ActivityEdge - Section Semantics - Typo "See examples in Figure 210." should be "See examples in Figure 213."
Reported: UML 2.0 — Mon, 17 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

formal parameter or a return result

Key: UML22-1313
Legacy Issue Number: 7344
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
There appears to be an inconsistency in the specification as to what it means to be a formal parameter or a return result. Please choose between the following two interpretations: A. A return result is a parameter that is specially indicated to be the return result. All other parameters are formal parameters. B. A return result is any parameter with direction return, out, or inout. A formal parameter is any parameter with direction in or inout. You could view (A) as focusing on the syntactical role the parameters play, while (B) focuses on when they communicate data. The difficulty arises from that the infrastructure and the superstructure have differing machineries of dealing with parameters. This question affects Kernel (BehavioralFeature.parameter) and CommonBehavior (Behavior.parameter)
Reported: UML 2.0 — Sun, 16 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

typo p. 149

Key: UML22-1314
Legacy Issue Number: 7345
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Typo "A collaboration occurrence relates a feature in its collaboration type to connectable a element in the classifier or operation that owns the collaboration occurrence."
Reported: UML 2.0 — Mon, 17 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

association "context"

Key: UML22-1312
Legacy Issue Number: 7342
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
The association "context" is defined as referencing the classifier owning the behavior. However, when behaviors are embedded within other behaviors, such as when a statemachine state owns a transition, this does not work. Instead, derive the context of the behavior in the following way: If the behavior is owned by a BehavioredClassifier, that classifier is the context. Otherwise, follow the chain of ownerships until you reach a BehavioredClassifier. That classifier is the context.
Reported: UML 2.0 — Sun, 16 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

behaviors

Key: UML22-1311
Legacy Issue Number: 7335
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
In all areas of the specification, when behaviors are referenced, it is the abstract metaclass Behavior that is used. This class can then be specialized to any concrete subclass of behavior. The only exception is statemachines, where Activity is referenced. Replace Activity by Behavior as the type of State.doActivity State.entry State.exit Transition.effect
Reported: UML 2.0 — Wed, 12 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See resolution to 7319. It replaces Activity with Behavior in state machines.
Updated: Fri, 6 Mar 2015 22:55 GMT

Page: 589

Key: UML22-1309
Legacy Issue Number: 7331
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
The bottom of the page says "Note Short forms of these names should also be defined, e.g. pkg for package." If this is a note to the editor, this either should be done or the note removed. The specification should not say that something "should be done."
Reported: UML 2.0 — Sun, 9 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 12.3.20

Key: UML22-1308
Legacy Issue Number: 7330
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
The second paragraph in the description section of ExpansionRegion ends upruptly in mid sentence
Reported: UML 2.0 — Sun, 9 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

enumerated type MessageSort

Key: UML22-1307
Legacy Issue Number: 7328
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
The enumerated type MessageSort (used in Message to indicate the kind of communication reflected by the message) has been omitted. The enumeration literals should be synchCall, synchSignal, asynchCall, asynchSignal (see p.428).
Reported: UML 2.0 — Sun, 9 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

There is no redefinitionContext established

Key: UML22-1310
Legacy Issue Number: 7333
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
There is no redefinitionContext established for the redefinable elements of the Activity package. This probably should be the activity itself
Reported: UML 2.0 — Wed, 12 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This is resolved by 6185.
Updated: Fri, 6 Mar 2015 22:55 GMT

heading of table 19

Key: UML22-1306
Legacy Issue Number: 7327
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
The heading of table 19 is "Graphic nodes and paths included in sequence diagrams" but should be "Graphic nodes and paths included in timing diagrams".
Reported: UML 2.0 — Sun, 9 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This issue was resolved by the resolution to issue 6977.
Updated: Fri, 6 Mar 2015 22:55 GMT

Notation of ExecutionOccurrence

Key: UML22-1305
Legacy Issue Number: 7326
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
The discussion of the Notation of ExecutionOccurrence speaks of Actions referenced by ExecutionOccurrence, while the meta model shows that ExecutionOccurrenc is related to behavior. Note that if ExecutionOccurrence is related to behavior, it is not possible to show, in an interaction, specific Actions, but only the events that start and end the behavior that contains some actions. However, this is consistent with the spirit of interactions as showing sequences of events, that may derive from actions.
Reported: UML 2.0 — Sun, 9 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This is a duplicate of issue 6153
Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 15.3.12

Key: UML22-1304
Legacy Issue Number: 7325
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
This section contains two subsections entitled "Changes from previous UML".
Reported: UML 2.0 — Sun, 9 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

introductory text for Property states

Key: UML22-1303
Legacy Issue Number: 7324
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
The introductory text for Property states that "When a property is owned by a class..." where it should say "When a property is owned by a classifier...."
Reported: UML 2.0 — Sat, 8 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

notation for statemachine transitions omitted from spec

Key: UML22-1301
Legacy Issue Number: 7320
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
The notation for statemachine transitions has been omitted from the specification. Add to the notation section for Statemachines::TRansition a description of the surface syntax denoting a transition: A line from the symbol for the source vertex to the symbol denoting the target vertex, and associated with this line is a textual string with the syntax: <transition-text> ::= <trigger> [<guard>][/<action>]; <guard> ::= '[' <expression> ']'; where <trigger> is defined in CommonBehavior::Trigger, <expression> is an expression in some language, and <action> is a behavior in some language.
Reported: UML 2.0 — Fri, 7 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

behavior packages (Interactions, Statemachines

Key: UML22-1300
Legacy Issue Number: 7319
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
Several of the behavior packages (Interactions, Statemachines) are dependent on actions, and consequentially, on the activity package. However, they rely only on a very small part of the action model. Primitive, non-structured, actions need to be independent of the activity model. This can be solved by: (a) Create an Actions::Action metaclass that is independent of Activities::Action. In the activity chapter, Activities::Action should subclass this new action. (b) Move Activities::InputPin and Activities::OutputPin into the Actions package, again adding additional features in the Activities package later. (c) Move Figure 178 "Actions" to the Actions package. This would give the two other behavior types independence of activities in a minimal way. Preferably we would also allow connection of actions: (d) Move figure 177 "Flows", minus the ownership by activity to the Actions chapter (it would be best to rename the abstract node names to something less refering to Activities, but that is no big deal). Add that ActivityEdge is owned by Behavior, and specialize that ownership in the Activity package to activities only.
Reported: UML 2.0 — Thu, 6 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above first, then continue below
Updated: Fri, 6 Mar 2015 22:55 GMT

"Implementation" is ommitted

Key: UML22-1302
Legacy Issue Number: 7322
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
"Implementation" is ommitted as one of the legal and typical elements in the diagram section of the Classes chapter and should be added, both in the table and the list below. (Note that legality in diagrams is not inheritable, so just because Realization is legal does not mean Implementation is.)
Reported: UML 2.0 — Sat, 8 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:55 GMT

InformationItem - Typo

Key: UML22-1299
Legacy Issue Number: 7300
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
InformationItem - Typo "It is a kind of classifier intended for representing information at a very abstract way, which is cannot be instanciated."
Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

ReadLinkObjectEndQualifierAction - errors in OCL

Key: UML22-1298
Legacy Issue Number: 7299
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
ReadLinkObjectEndQualifierAction - errors in OCL "[3] The ends of the association must not be static. self.qualifier.associationEnd.association.end->forall(oclIsKindOf(NavigableEnd) implies isStatic = #false)" There is not metaclass "NavigableEnd". This should be "[3] The ends of the association must not be static. self.qualifier.associationEnd.association.memberEnd->forAll(isStatic = #false)" ------------------------------------------------------ "[5] The multiplicity of the qualifier attribute is 1..1. self.qualifier.multiplicity.is(1,1)" should be "[5] The multiplicity of the qualifier attribute is 1..1. self.qualifier.lowerBound() = 1 and self.qualifier.upperBound() = 1 ------------------------------------------------------ "[6] The multiplicity of the object input pin is “1..1”. self.object.multiplicity.is(1,1)" "object" does not have a multiplicity. ------------------------------------------------------ "[8] The multiplicity of the result output pin is “1..1”. self.result.multiplicity.is(1,1)" "result" does not have an attribute "multiplicity"
Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

StartOwnedBehaviorAction - OCL error in constraint

Key: UML22-1296
Legacy Issue Number: 7297
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
StartOwnedBehaviorAction - OCL error in constraint [1] "[1] The input pin has no type. self.argument.type->size() = 0" should be "[1] The input pin has no type. self.object.type->size() = 0"
Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

ReadLinkObjectEndAction - errors in OCL

Key: UML22-1297
Legacy Issue Number: 7298
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
ReadLinkObjectEndAction - errors in OCL " [1] The property must be an association end. self.end.association->size = 1" should be " [1] The property must be an association end. self.end.association->size() = 1" -------------------------------------------------- "[3] The ends of the association must not be static. self.end.association.end->forall(oclIsKindOf(NavigableEnd) implies isStatic = #false)" There is not metaclass "NavigableEnd". This should be "[3] The ends of the association must not be static. self.end.association.memberEnd->forAll(isStatic = #false)" -------------------------------------------------- " [5] The multiplicity of the object input pin is “1..1”. self.object.multiplicity.is(1,1)" "object" does not have a multiplicity. -------------------------------------------------- "[7] The multiplicity of the result output pin is 1..1. self.result.multiplicity.is(1,1)" "result" does not have a multiplicity
Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

ReplyAction - Typo

Key: UML22-1294
Legacy Issue Number: 7295
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
ReplyAction - Typo "It is not intended that any profile give any other meaning the the return information."
Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

ReplyAction - Inconsistency with Figure 150

Key: UML22-1293
Legacy Issue Number: 7294
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
ReplyAction - Inconsistency with Figure 150 In page 245, replyValues is defined as follows: "replyValue : OutputPin [0..*] A list of pins containing the reply values of the operation. These values are returned to the caller." This is probably OK, but then, Figure 150 should have an association between ReplyAction and OutputPin, not between ReplyAction and InputPin.
Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

AcceptCallEvent - inconsistent multiplicity " trigger

Key: UML22-1292
Legacy Issue Number: 7293
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
AcceptCallEvent - inconsistent multiplicity " trigger: CallTrigger The operation call trigger accepted by the action. " should be " trigger: CallTrigger[1] The operation call trigger accepted by the action.
Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
In AcceptCallAction, Associations, insert multiplicity "[1]" for trigger.
Updated: Fri, 6 Mar 2015 22:54 GMT

ReadIsClassifiedObjectAction - OCL errors in constraints

Key: UML22-1295
Legacy Issue Number: 7296
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
ReadIsClassifiedObjectAction - OCL errors in constraints "[1] The multiplicity of the input pin is 1..1. self.argument.multiplicity.is(1,1)" Probably, it should be self.object instead of self.argument, but then again, self.object does not have a multiplicity. " [2] The input pin has no type. self.argument.type->size() = 0" "self.argument" should be "self.object" "[3] The multiplicity of the output pin is 1..1. self.result.multiplicity.is(1,1)" "self.result" is an OutputPin which does not have a multiplicity.
Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

AcceptEventAction - inconsistencies in Semantics and typos

Key: UML22-1291
Legacy Issue Number: 7292
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
AcceptEventAction - inconsistencies in Semantics and typos "If the event is a SignalEvent, the result token contains a signal object whose reception by the owning object caused the event. Signal objects may be copied in transmission and storage by the owning object, so identity might not be preserved. An action whose event is a signal event is informally called an accept signal action. If the event is a TimeEvent, the result token contains the time at which the event occurred. Such an action is informally called a wait time action. If the event is a ChangeEvent ot a CallEvent, the result is a control token, there are no output pins. See CommonBehavior for a description of Event specifications." - There is no metaclass SignalEvent. Probably, this should be SignalTrigger. - There is no metaclass TimeEvent. Probably, this should be TimeTrigger. - There is no metaclass ChangeEvent. Probably, this should be ChangeTrigger. - There is no metaclass CallEvent. Probably, this should be CallTrigger. Suggestion for editorial change: "If the trigger is a SignalTrigger, the result token contains a signal object whose reception by the owning object caused the event. Signal objects may be copied in transmission and storage by the owning object, so identity might not be preserved. An action whose trigger is a SignalTrigger is informally called an accept signal action. If the trigger is a TimeTrigger, there is exactly one output pin which contains the time at which the event occurred. Such an action is informally called a wait time action. If the trigger is a ChangeTrigger, the result is a control token, there are no output pins. See CommonBehavior for a description of Trigger specifications."
Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See resolution to 7399. Suggested editorial change has the same text as the FAS.
Updated: Fri, 6 Mar 2015 22:54 GMT

AcceptEventAction - inconsistency

Key: UML22-1290
Legacy Issue Number: 7291
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
AcceptEventAction - inconsistency " ... then the accept signal action completes and outputs a token describing the event." should be " ... then the accept event action completes and outputs a token describing the event."
Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See resolution to 6236.
Updated: Fri, 6 Mar 2015 22:54 GMT

AcceptEventAction - inconsistent multiplicities

Key: UML22-1289
Legacy Issue Number: 7290
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
AcceptEventAction - inconsistent multiplicities " result: OutputPin [1] Pin holding the event object that has been received. Event objects may be copied in transmission, so identity might not be preserved." Multiplicity should be "0..", not "1", because - in case of an accept signal action (see Semantics on the next page), the output pin holds a signal - in case of an time action (see Semantics on the next page), the output pin holds the time at which the event occured - in case of ChangeTrigger, "... there are no output pins." (see Semantics on the next page) - in case of an AcceptCallEventAction (which is a specialization of AcceptEventAction), the output pins hold 0.. argument values of a call. Thus, the multiplicity "0..*" in Figure 150 is probably correct and the respective multiplicity on page 207 should be updated.
Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See resolution to 6236.
Updated: Fri, 6 Mar 2015 22:54 GMT

Message - inconsistency "Messageident equalling *

Key: UML22-1288
Legacy Issue Number: 7289
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Message - inconsistency "Messageident equalling ‘’ is a shorthand for more complex alternative CombinedInteraction to represent a message of any type. This is to match asterisk triggers in State Machines." Notes: - There is no metaclass CombinedInteraction. This should probably be CombinedFragment. - "asterisk triggers" should probably be "AnyTrigger" - According to 13.3.2, an AnyTrigger is represented with the keyword "all". Shouldn't we replace "" in the grammar on page 430 by "all"? Suggested replacement: "Messageident equalling ‘all’ is a shorthand for more complex alternative CombinedFragment to represent a message of any type. This is to match AnyTriggers in State Machines."
Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Message - inconsistency (02)

Key: UML22-1287
Legacy Issue Number: 7288
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Message - inconsistency "When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline." Notes: - CallEvent has been replaced by CallTrigger in UML2. - CallAction should probably be CallOperationAction. - A CallEvent (now CallTrigger) has no arguments, but it refers to an operation which has arguments Suggested replacement: "When a Message represents an Operation the arguments of the Message are the arguments of the CallOperationAction on the sending Lifeline and the formal Parameters of the Operation the CallTrigger on the receiving Lifeline refers to."
Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This is an exact (word- for-word) duplicate of issue 7287.
Updated: Fri, 6 Mar 2015 22:54 GMT

Message - inconsistency

Key: UML22-1286
Legacy Issue Number: 7287
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Message - inconsistency "When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline." Notes: - CallEvent has been replaced by CallTrigger in UML2. - CallAction should probably be CallOperationAction. - A CallEvent (now CallTrigger) has no arguments, but it refers to an operation which has arguments Suggested replacement: "When a Message represents an Operation the arguments of the Message are the arguments of the CallOperationAction on the sending Lifeline and the formal Parameters of the Operation the CallTrigger on the receiving Lifeline refers to."
Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Figure 77

Key: UML22-1285
Legacy Issue Number: 7245
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Figure 77 - show the generalization from Realization to Realization (from Kernel) In Figure 77, show that Realization is a specialization of Realization (from Kernel).
Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

Interface - Typos in Figure 63

Key: UML22-1284
Legacy Issue Number: 7244
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Interface - Typos in Figure 63 In Figure 63, - open guillemets should be added to interface IAlaram (see also Issue 6070) - stereotypes <<Interface>> should be changed to <<interface>> - name of right interface should be changed from "sensor" to "ISensor" - in the caption, "Isensor" should be replaced by "ISensor"
Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
These issues were resolved by the resolutions to issues 6069 and 6070.
Updated: Fri, 6 Mar 2015 22:54 GMT

Connector - inconsistency

Key: UML22-1282
Legacy Issue Number: 7241
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Connector - inconsistency In order to be consistent with 7.15.3 (Interface) and 13.3.5 (Interface) "At a minimum, the provided interfaces must support a superset of the operations and signals specified in the required interfaces." should be "At a minimum, the provided interfaces must support a superset of the operations and receptions specified in the required interfaces."
Reported: UML 2.0 — Wed, 14 Apr 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Connector - typo and inconsistency

Key: UML22-1281
Legacy Issue Number: 7240
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Connector - typo and inconsistency "A connector consists of at two connector ends, each of which represents the participation of instances of the classifiers typing the connectable elements attached to this end. The set of connector ends is ordered. (Subsets Element.ownedElement.)" should be "A connector consists of at least two connector ends, each of which represents the participation of instances of the classifiers typing the connectable elements attached to this end. The set of connector ends is ordered. (Subsets Element::ownedElement.)" Also, "instances of the classifiers typing the connectable elements attached to this end" is not correct, because ConnectableElement is not a specialization of TypedElement. But all known specializations of ConnectableElement, namely Parameter, Variable, Port, and Property, are (indirect) specializations of TypedElement. I suggest to replace NamedElement in Figure 96 by TypedElement. ConnectableElement then automatically becomes a specialization of both TypedElement and NamedElement.
Reported: UML 2.0 — Wed, 14 Apr 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

ConnectorEnd - multipliciy of role

Key: UML22-1283
Legacy Issue Number: 7243
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
ConnectorEnd - multipliciy of role - inconsistency with Figure 96 According to Figure 96, the multiplicity of role is 0..1. Therefore, " role: ConnectableElement [1] The connectable element attached at this connector end." should be " role: ConnectableElement [0..1] The connectable element attached at this connector end."
Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Connector - inconsistency

Key: UML22-1280
Legacy Issue Number: 7239
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Connector - inconsistency According to Figure 96, type has multipliciy 0..1. Therefore, " type: Association An optional association that specifies the link corresponding to this connector." should be " type: Association[0..1] An optional association that specifies the link corresponding to this connector
Reported: UML 2.0 — Wed, 14 Apr 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo in ptc/03-08-02 p. 178

Key: UML22-1279
Legacy Issue Number: 7238
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Typo "A composite structure diagram depicts the internal structure of a classifier, , as well as the use of a collaboration in a collaboration occurrence." should be "A composite structure diagram depicts the internal structure of a classifier, as well as the use of a collaboration in a collaboration occurrence."
Reported: UML 2.0 — Wed, 14 Apr 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo Section: 12.3.8

Key: UML22-1278
Legacy Issue Number: 7237
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Typo "For example, an activity may be have one dimension of partitions for location ..."
Reported: UML 2.0 — Mon, 12 Apr 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Stereotype - Inconsistency in notation Section "Notation", last sentence

Key: UML22-1275
Legacy Issue Number: 7234
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Stereotype - Inconsistency in notation Section "Notation", last sentence: "If multiple stereotypes are applied, the names of the applied stereotypes is shown as a comma-separated list with a pair of guillemets." ==> Example matching with this rule: <<stereotype1, stereotype2,stereotype3>> Section "Presentation Options", first sentence: "If multiple stereotypes are applied to an element, it is possible to show this by enclosing each stereotype name within a pair of guillemets and list them after each other." ==> Example matching with this rule: <<stereotype1>> <<stereotype2>> <<stereotype3>> I suggest to remove the second presentation option. Examples in the spec are always based on the first one.
Reported: UML 2.0 — Mon, 12 Apr 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Stereotype - typo in OCL

Key: UML22-1274
Legacy Issue Number: 7233
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Stereotype - typo in OCL "[2] A concrete Stereotype must directly or indirectly extend a Class. not self.isAbstract implies self.extensionEnd->union(self.parents.extensionEnd)~~>notEmpty()" should be "[2] A concrete Stereotype must directly or indirectly extend a Class. not self.isAbstract implies self.extensionEnd~~>union(self.allParents().extensionEnd)->notEmpty()" because parents() only specifies the direct generalization whereas allParents() also includes classes which are indirectly extended
Reported: UML 2.0 — Mon, 12 Apr 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

ActivityPartition - inconsistencies

Key: UML22-1277
Legacy Issue Number: 7236
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
ActivityPartition - inconsistencies " partition : ActivityPartition [0..1] Partition immediately containing the partition. Specialized from ActivityGroup::group." should be " superPartition : ActivityPartition [0..1] Partition immediately containing the partition. Specialized from ActivityGroup::superGroup." " superPartition : ActivityPartition [0..1] Partitions immediately containing the partition. Specialized from ActivityGroup::subgroup." should be " subPartition : ActivityPartition [0..1] Partitions immediately contained in the partition. Specialized from ActivityGroup::subgroup." Figure 183 should also be updated. There, "+subgroup" should be "+subPartition".
Reported: UML 2.0 — Mon, 12 Apr 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo In section "Description"

Key: UML22-1276
Legacy Issue Number: 7235
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Typo In section "Description": "Nodes and edges can belong to more than one group. "
:
Reported: UML 2.0 — Mon, 12 Apr 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
In ActivityGroup class, Description, second sentence, insert "one" before "group".
Updated: Fri, 6 Mar 2015 22:54 GMT

AddVariableValueAction - OCL in constraint [1] not correct

Key: UML22-1271
Legacy Issue Number: 7191
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Here's an annotated copy of constraint [1]:

let insertAtPins : Collection = self.insertAt in – NOTE: Variable does not have an attibute ordering if self.variable.ordering = #unordered – NOTE: currently, it is "then insertAtPins->size() = 0", but this – is not compatible with the return type. Now, an – empty set is returned instead. then {} else let insertAtPin : InputPin = insertAt->asSequence()~~>first() in insertAtPins~~>size() = 1 and insertAtPin.type = UnlimitedNatural – NOTE: an InputPin is not a multiplicity element and insertAtPin.multiplicity.is(1,1)) endif
Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Variables have ordering and multiplicity due to resolution of 6090.
Updated: Fri, 6 Mar 2015 22:54 GMT

Stereotype

Key: UML22-1273
Legacy Issue Number: 7232
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"[1] A Stereotype may only generalize or specialize another Stereotype. self.generalization.general->forAll(e | e.oclIsKindOf(Stereotype)) and self.specialization.specific->forAll(e | e.oclIsKindOf(Stereotype))" should be "[1] A Stereotype may only generalize or specialize another Stereotype. self.generalization.general->forAll(e | e.oclIsKindOf(Stereotype)) and self.generalization.specific->forAll(e | e.oclIsKindOf(Stereotype))"
Reported: UML 2.0 — Mon, 12 Apr 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo, section "Description", paragraph 1

Key: UML22-1272
Legacy Issue Number: 7196
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"In addition, because a itself Class is a subtype of an EncapsulatedClassifier, ..."
Reported: UML 2.0 — Mon, 22 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

VariableAction - undefined query

Key: UML22-1270
Legacy Issue Number: 7190
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
isAccessibleBy() in the following constraint is not defined.

"[1] The action must be in the scope of the variable. self.variable.isAccessibleBy(self)"

Suggestion:

"[1] The action must be in the scope of the variable. self.variable.scope = self.inStructuredNode"
Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

ReadLinkAction - Constraints use deprecated UML elements

Key: UML22-1267
Legacy Issue Number: 7187
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
The constraints of ReadLinkAction use deprecated UML elements like AssociationEnd and refer to undefined properties like "isNavigable".

Here's a proposal for updated OCL fragments:

[2] The type and ordering of the result output pin are same as the type and ordering of the open association end.

let openend : Property = self.endData->select(ed | ed.value->size() = 0)~~>asSequence()~~>first().end in self.result.type = openend.type and self.result.isOrdered = openend.isOrdered

[3] The multiplicity of the open association end must be compatible with the multiplicity of the result output pin.

let openend : Property = self.endData->select(ed | ed.value->size() = 0)~~>asSequence()~~>first().end in – NOTE: does not make sense, as long as OutputPin is not a specialization of – MultiplicityElement ! openend.includesMultiplicity(self.result)

[4] The open end must be navigable. let openend : Property = self.endData->select(ed | ed.value->size() = 0)~~>asSequence()~~>first().end in – the property is navigable, if it is not owned by an association, but by – a classifier openend.association->isEmpty() and openend.classifier->notEmpty()

[5] Visibility of the open end must allow access to the object performing the action. let host : Classifier = self.activity.hostClassifier() in let openend : Property = self.endData->select(ed | ed.value->size() = 0)~~>asSequence()~~>first().end in

– NOTE: not clear, what the following OCL fragment specifies. For instance, what is – "oed.end.participant" ? – openend.visibility = #public or self.endData->exists(oed | not oed.end = openend and (host = oed.end.participant or (openend.visibility = #protected and host.allParents()->includes(oed.end.participant))))
Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

ReadLinkAction - inconsistency with Figure 147

Key: UML22-1266
Legacy Issue Number: 7186
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
According to Figure 147, the multiplicity of result is "1", whereas in section "Associations" it is described as result : OutputPin [0..*]

Multiplicity "1" is probably correct, since one OutputPin is meant to hold a possibly multivalued set of objects.
Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
In ReadLinkAction, Associations, change multiplicity of result to "1".
Updated: Fri, 6 Mar 2015 22:54 GMT

Variable - Typo in Attributes

Key: UML22-1269
Legacy Issue Number: 7189
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
scope : StructuredActivityGroup [1]The structured activity group that owns the variable.
- replace StructuredActivityGroup by StructuredActivityNode - move it from section "Attributes" to section "Associations"
Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
In Variable class, Attributes, move entry for scope to Associations section.
Updated: Fri, 6 Mar 2015 22:54 GMT

DestroyLinkAction - Semantics based on non existing "settability addOnly"

Key: UML22-1268
Legacy Issue Number: 7188
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Section "Semantics" refers to a "settability addOnly" which does not exist in UML 2. (In UML 1.5, there was a "changeability addOnly")
Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

MultiplicityElement - section is obsolete

Key: UML22-1265
Legacy Issue Number: 7185
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
MultiplicityElement - section is obsolete (see also Issue 6090, Issue 6627, Issue 7111)

Section 11.3.22 is obsolete because - MultiplicityElement as defined in this chapter is never used in generalization hierarchy
- There are a lot of constraints and operations in this chapter making use of the operation "is(..)" and "compatibleWith(..)" defined for MultiplicityElement in this section, but usually these operations are applied to Pins (InputPins and OutputPins) which are not a specialization of MultiplicityElement
Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This is covered by issue 6090.
Updated: Fri, 6 Mar 2015 22:54 GMT

LinkEndData - Additional operation not correct

Key: UML22-1264
Legacy Issue Number: 7184
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"Additional operations: [1] association operates on LinkAction. It returns the association of the action. association(); association = self.endData->asSequence().first().end.association"

This operation is already defined for LinkAction on page 237. Here, it should be

Additional operations

[1] association operates on LinkEndDate. It returns the association represented by this LinkEndData.

context LinkEndData::association():Association post: result = end.association

Then the operation association() on page 237 could be changed to

[1] association operates on LinkAction. It returns the association of the action.

context LinkAction::association():Assocation post: result = endData->asSequence().first().association()
Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

LinkEndData - Typo in OCL

Key: UML22-1263
Legacy Issue Number: 7183
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Constraint [1] should be changed from self.end.association->size = 1 to self.end.association->size() = 1
Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

AddStructuralFeatureValueAction - Settability removeOnly does not exist

Key: UML22-1262
Legacy Issue Number: 7181
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
The spec says: "The semantics is undefined for adding a new value for a structural feature with settability readOnly or removeOnly after initialization of the owning object."

StructuralFeature just has a boolean attribute "isReadOnly". There is no such attribute as "settability" or "isRemoveOnly".
Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

DestroyObjectAction - inconsistency in constraints

Key: UML22-1260
Legacy Issue Number: 7179
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Constraint [1] and [2] use the navigation expression self.input which should be self.target according to Figure 143 and section "Associations".
Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Component - problem with provided interfaces (see also Issue 6875, 6338)

Key: UML22-1259
Legacy Issue Number: 7178
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Section "Associations" states that the derived association /provided consists (1)of the implemented or realized interfaces of the component union (2) the provided interfaces on any of its realizing classifiers union (3) the types of any of its owned ports.

There is a problem with this definition, because the type of an owned port does not have to be an interface and because this definition does not include the set of interfaces provided by a port.

I suggest to update the definition to:

"provided: Interface[*] The interfaces that the component exposes to its environment. These interfaces may be Implemented or Realized by the Component or any of its realizingClassifiers, or they may be implemented by the type of any of its owned public Ports, or they may be provided by any of its owned public Ports. The provided interfaces association is a derived association (see constraint below)."

Here's a more formal definition (which, according to the note "(OCL version of the derivation above to be added)" on page 136 is still missing )

Constraints

[1] provided = providedInterfaces()

Additional Operations

[1] providedInterfaces replies the set of interfaces the component provides

context Component::providedInterfaces():Set(Interface) post: result = – the set of interfaces provided by the component itself – self.clientDependency >select(oclIsTypeOf(Implementation) or oclIsTypeOf(Realization)).supplier ->collect(oclIsTypeOf(Interface)) union – the set of interfaces provided by any of its realizing classifiers – self.realization.realizingClassifier.clientDependency ->select(oclIsTypeOf(Implementation) or oclIsTypeOf(Realization)).supplier ->collect(oclIsTypeOf(Interface)) union – the set of interfaces implemented by the type of any of its – owning ports self.ownedPort>select(isService = true).type ~~>select(oclIsTypeOf(Implementation) or oclIsTypeOf(Realization)).supplier ->collect(oclIsTypeOf(Interface)) union – the set of interfaces provided by any of its owned public ports – self.ownedPort~~>select(isService = true).provided
Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo - section Description, first sentence

Key: UML22-1261
Legacy Issue Number: 7180
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"... which is in turn is optionally attached in some way ..."
Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Manifestation - visual representation should be dashed arrow

Key: UML22-1258
Legacy Issue Number: 7155
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
The sample diagram in Table 9, 1st row, 2nd column, on page 200 should use a dashed arrow instead of a solid one.
Reported: UML 2.0 — Sat, 13 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This issue was resolved by the resolution to issue 6234.
Updated: Fri, 6 Mar 2015 22:54 GMT

Deployment - keyword <> not introduced

Key: UML22-1256
Legacy Issue Number: 7152
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
In UML 1.4, the visual representation of a deployment relationship is adorned with the keyword <<deploy>>. I suggest to introduce this is keyword in section "Notation" on page 188. Also, adorn the deployment relationship in Figure 130 on page 188 with <<deploy>>.

Table 9 on page 199 includes the notation for a deployment dependency including the keyword <<deploy>>, but the depencendy arrow should be drawn with a dashed line.
Reported: UML 2.0 — Sat, 13 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

InteractionOccurrence - Syntax rules for name not clear

Key: UML22-1255
Legacy Issue Number: 7151
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"name ::=[ attribute-name = ][collaborationoccurrence.] interactionname[‘(‘arguments’)’] [: return-value] argument ::= in-argument [ out out-argument]"

should be changed to

"name ::= [ attribute-name '=' ][collaborationoccurrence '.'] interactionname[‘(‘arguments’)’] [':' return-value] arguments ::= argument [ ',' arguments ] argument ::= value | 'out' name [ ':' value] " | ''

Four paragraphs below, the spec says that the same syntax is used as for Messages. This sentence should be deleted unless the syntax rules are actually updated to reflect the syntax rules of Message names on page 428.
Reported: UML 2.0 — Sat, 13 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

DeploymentTarget - Missing OCL expression

Key: UML22-1257
Legacy Issue Number: 7153
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
The spec says:

" / deployedElement : PackageableElement [*] The set of elements that are manifested in an Artifact that is involved in Deployment to a DeploymentTarget.The association is a derived association (OCL for informal derivation above to be provided)."

Here's a proposal for the missing OCL expression mentioned above:

self.deployment.deployedArtifact->select(da | da.oclIsKindOf(Artifact) )->collect(da | da.oclAsType(Artifact).manifestation.utilizedElement )
Reported: UML 2.0 — Sat, 13 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Figure 95

Key: UML22-1254
Legacy Issue Number: 7124
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Figure 95 - Property should also specialize from Property (from Kernel).
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

Connector - Constraint [3] not necessary ?

Key: UML22-1253
Legacy Issue Number: 7123
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
It is not clear why Constraint [3] is necessary in addition to Constraint [2].
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Connector - Constraint [2] is inprecise

Key: UML22-1252
Legacy Issue Number: 7122
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
2] If a connector is attached to a connectable element which has required interfaces, then the connectable elements attached to the other ends must realize interfaces that are compatible with these required interfaces.

What is the meaning of this constraint ?
- For each required interface I1 of a port P1 attached to a connector, every other port connected to the same connector must have at least one provided interface which is compatible to I1 ? - For each required interface I1 of a port P1 attached to a connector, there must be at least one other port connected to the to the same connector with at least one provided interface which is compatible to I1 ? - ....
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

ReadSelfAction - Typos in OCL constraints

Key: UML22-1251
Legacy Issue Number: 7121
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Replace "activity()" by "activity" in the OCL expressions of Constraint [1], [2], and [3], i.e.

[1] The action must be contained in an activity that has a host classifier. self.activity.hostClassifier()->size() = 1
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo

Key: UML22-1249
Legacy Issue Number: 7119
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"Every action is ultimately a part of some activity, which is in turn is optionally attached in some way to the specification of a classifier"
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
duplicate of isue # 7119 ...closed
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo

Key: UML22-1248
Legacy Issue Number: 7118
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"Every action is ultimately a part of some activity, which is in turn is optionally attached in some way to the specification of a classifier"
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

ReadSelfAction - delete constraint [4]

Key: UML22-1250
Legacy Issue Number: 7120
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Constraint [4] is not necessary, because OutputPin is not a specialization of MultiplicityElement - it does not have a multiplicity.
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

TestIdentityAction - additional constraint

Key: UML22-1247
Legacy Issue Number: 7117
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Add the following constraint:

[3] The type of the result is Boolean self.result.type.oclIsTypeOf(Boolean)
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

TestIdentityAction- delete constraint [2]

Key: UML22-1246
Legacy Issue Number: 7116
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Constraint [2] is not necessary, because InputPin is not a specialization of MultiplicityElement - it does not have a multiplicity.
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo

Key: UML22-1245
Legacy Issue Number: 7115
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"TestIdentifyAction is an action that tests if two values are identical objects.t" (last t after period)
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

DeleteObjectAction - delete constraint [1]

Key: UML22-1244
Legacy Issue Number: 7114
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Constraint [1] is not necessary, because InputPin is not a specialization of MultiplicityElement - it does not have a multiplicity.
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

SendSignalAction

Key: UML22-1241
Legacy Issue Number: 7111
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
SendSignalAction - Matching between arguments and Signal attributes not clear

According to Constraint [1] on page 256 arguments to the SendSignalAction and attributes in the Signal should "match by position", which is not immediately clear because the set Signal::attribute is not ordered.

Signal::attribute is equal to Classifier::attribute which subsets Classifier::feature which subsets Namespace::member. None of these sets is ordered.

Furthermore, it is not clear when an "argument" of SendSignalAction and an attribute of Signal match. Probably, the following conditions should hold: - They have the same name - Both are TypedElement, so their types should conform to each other. - Only "attribute" is a MultiplicityElement - an "argument" of type "InputPin" does not have a multiplicity. Is therefore advisable to constraint the multiplicity of "argument" such that it is always "1..1".

I suggest to change this to a kind of "matching by name", i.e.

[1] The number of arguments of SendSignalAction must be the same as the number of attributes of Signal. self.argument->size() = self.signal.attribute->size()

[2] All arguments must have a name self.argument.name->notEmpty()

[3] The multiplicities of all attributes of signal must be 1 self.signal.attribute->forAll(attr | attr.lowerBound() = 1 and attr.upperBound() = 1 )

[4] For each argument there is exactly one attribute in Signal with the same name and a conformant type, if any.

self.argument->forAll(arg | self.signal.attribute->one(attr | attr.name = arg.name and ((attr.type->size() = 1) implies attr.type.conformsTo(arg.type)) ) )
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

Delete the following sentence in section "Notation":

Key: UML22-1240
Legacy Issue Number: 7110
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Delete the following sentence in section "Notation": "The symbol has a control output only." and replace it with the following constraint in section "Constraints":

[2] A SendSignalAction has at most one outgoing activity edge of type ControlFlow

self.outgoing->size() <= 1 and self.outgoing->forAll(ae | ae.oclIsKindOf(ControlFlow))
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

CreateObjectAction - delete constraint [4]

Key: UML22-1243
Legacy Issue Number: 7113
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Constraint [4] is not necessary, because OutputPin is not a specialization of MultiplicityElement - it does not have a multiplicity.
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo

Key: UML22-1242
Legacy Issue Number: 7112
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"Receive signal action" in Figure 165 on p. 256 should be "send signal action".
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
In figure 165 on page 256 replace the phrase word “Receive” by the word “Send”
Updated: Fri, 6 Mar 2015 22:54 GMT

Sentence not finished in section "Changes from previous UML"

Key: UML22-1239
Legacy Issue Number: 7109
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Sentence not finished in section "Changes from previous UML"

"In UML 1.x,"
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
On page 186, remove this incomplete phrase from the end of the paragraph.
Updated: Fri, 6 Mar 2015 22:54 GMT

Collaboration - inconsistency with Figure 99

Key: UML22-1235
Legacy Issue Number: 7075
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
According to Figure 99, the multiplicity of association end collaborationRole should be "*".

collaborationRole: ConnectableElement[*] References connectable elements (possibly owned by other classifiers) which represent roles that instances may play in this collaboration. (Subsets StructuredClassifier.role.)
Reported: UML 2.0 — Thu, 4 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo in Figure 124 on page 182

Key: UML22-1237
Legacy Issue Number: 7107
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"Manisfestation" should be "Manifestation"
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Duplicate of issue 6204
Updated: Fri, 6 Mar 2015 22:54 GMT

StructuredClassifier - Regular expression for namestring too complicated

Key: UML22-1236
Legacy Issue Number: 7106
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
The regular expression on page 175 {{
{[ name [‘/’ rolename]] | ‘/’ rolename}
‘:’ classifiername [
{‘,’ classifiername}
*]} | { name [‘/’ rolename] | ‘/’ rolename}} could be replaced by the following simpler expression name ['/' rolename]} | {'/' rolename [ ':' classifiername
{ ',' classifiername}
*]
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo

Key: UML22-1238
Legacy Issue Number: 7108
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"That is, these model elements are utilized in the construction (or generation) or the artifact."
Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

GeneralizationSet - constraints expressed in OCL

Key: UML22-1233
Legacy Issue Number: 7073
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
GeneralizationSet - constraints expressed in OCL

The constrainst of GeneralizationSet are not expressed in OCL yet. Here are two proposals.

[1] Every Generalization associated with a particular GeneralizationSet must have the same general Classifier. self.generalization->collect(g | g.general)~~>asSet()~~>size() <= 1

[2] The Classifier that maps to a GeneralizationSet may neither be a specific nor a general Classifier in any of the Generalization relationships defined for that GeneralizationSet. In other words, a power type may not be an instance of itself nor may its instances be its subclasses.

let gene = self.generalization in gene->collect(g | g.general->union(g.general->collect(c | c.allParents()~~>union(c.allChildren())))) ->union(gene~~>collect(g | g.specific->union(g.specific->collect(c | c.allParents()->union(c.allChildren()))))) ->excludes(powertype)
Reported: UML 2.0 — Thu, 4 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

GeneralizationSet - Incorrect Mulitiplicities of associations

Key: UML22-1232
Legacy Issue Number: 7072
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
GeneralizationSet - Incorrect Mulitiplicities of associations

" generalization [1] Designates the instances of Generalization which are members of a given Generalization-Set. powertype [2] Designates the Classifier that is defined as the power type for the associated GeneralizationSet."

This should be

" generalization: Generalization[*] Designates the instances of Generalization which are members of a given Generalization-Set. powertype:Classifier [0..1] Designates the Classifier that is defined as the power type for the associated GeneralizationSet."
Reported: UML 2.0 — Thu, 4 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

GeneralizationSet - example in section "Semantics" is not clear

Key: UML22-1234
Legacy Issue Number: 7074
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
GeneralizationSet - example in section "Semantics" is not clear

Here is the respecitive paragraph with some editorial notes:

. i(aaaaa) means insert aaaaa at the position of i . r-------aaaaa means replace everything above ----- with aaaaa

"For example, the Bank Account Type classifier could associate with a Generalization relationship r--------------------------~~GeneralizationSet that has specific classifiers of Checking Account r~~---------refers to Generalizations with specific and Savings Account. Here, then, Checking Account and Savings Account are instances of Bank Account Type. Furthermore, if the Generalization relationship has a general classifier of Bank Account, then Checking Account and Savings Account are r-------------------------GeneralizationSet also subclasses of Bank Account. Therefore, Checking Account and Savings Account are both instances of Bank Account Type and subclasses of Bank Account. (For more explanation and examples, see Examples in the Generalization section, below.)
Reported: UML 2.0 — Thu, 4 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

GeneralizationSet description conf. about meaning of "specific" + "general

Key: UML22-1231
Legacy Issue Number: 7071
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
GeneralizationSet - description is confused about the meaning of "specific" and "general"

In the description on page 121, classifieres are called "specific" when they should be called "generic", and vice versa.

Here is the respecitive paragraph with some editorial notes:

. i(aaaaa) means insert aaaaa at the position of i . r-------aaaaa means replace everything above ----- with aaaaa

Each Generalization is a binary relationship that relates a specific Classifier to a more general Classifier (i.e., a subclass). Each i(i.e. a subclass) r------~~superclass GeneralizationSet defines a particular set of Generalization relationships that describe the way in which a specific Classifier r~~-----generic (or superclass) may be partitioned. For example, a GeneralizationSet could define a partitioning of the class Person into two subclasses: Male Person and Female Person. Here, the GeneralizationSet would associate two instances of Generalization. Both instances would have Person as the specific classifier, however one Generalization would involve Male Person as the r-----~~generic general Classifier and the other would involve Female Person as the general classifier. In other words, the class Person can r~~----specific here be said to be partitioned into two subclasses: Male Person and Female Person. Person could also be partitioned into North American Person, Asian Person, European Person, or something else. This partitioning would define a different GeneralizationSet that would associate with three other Generalization relationships. All three would have Person as the specific Classifier; only the general classifiers would differ: i.e., North AmericanPerson, Asian Person, and European Person. r-----~~generic r~~-----specific
Reported: UML 2.0 — Thu, 4 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Was resolved as part of Issue No. 5980 (item 4).
Updated: Fri, 6 Mar 2015 22:54 GMT

GeneralizationSet - outdated description

Key: UML22-1230
Legacy Issue Number: 7070
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
On page 121, the spec says:

"A GeneralizationSet is an AutonomousElement (from Foundation :: Kernel :: PackagingNamespaces) whose instances define partitioned sets of Generalization relationships."

There is no AutonomousElement in UML 2.0. This should probably be:

"A GeneralizationSet is an PackageableElement (from Kernel) whose instances define partitioned sets of Generalization relationships."
Reported: UML 2.0 — Thu, 4 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Was resolved as part of Issue No. 5980 (item 4).
Updated: Fri, 6 Mar 2015 22:54 GMT

Region - Additional structural constraints necessary

Key: UML22-1229
Legacy Issue Number: 7055
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Add the toe following query to the section "AdditionalOperations":

[1] allParentRegions() replies a set of regions which are direct or indirect ancestors of this region

Context Region::allParentRegions(): Set(Region) allParentRegions = if self.State->isEmpty() then Set{} else self.State.container->union(self.State.container.allParentRegions()) endif

Add the following constraints to the section "Constraint"

[5] A region does not directly belongs to a state machine and to a state self.StateMachine->intersection(self.State)->isEmpty()

[6] Regions are properly nested not self.allParentRegions()->includes(self)
Reported: UML 2.0 — Sun, 29 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

Constraint [2], p.70

Key: UML22-1228
Legacy Issue Number: 7054
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
RedefinableElement::isRedefinitionContexValid(redefinable: RedefinableElement): Boolean; isRedefinitionContextValid = self.redefinitionContext->exists(c | redefinable.redefinitionContext->exists(c | c.allParents()~~>includes(r)) – ^~~- should be r, not c )
Reported: UML 2.0 — Sun, 29 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Figure 355 - mulitplicities of redefinitionContext should be 0..1

Key: UML22-1227
Legacy Issue Number: 7053
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
In Figure 355 there are three occurences of associaten ends named "redefinitionContext". The multiplicities of each should be 0..1, rather than 1, because State, Transition, and Region can exist without being part of StateMachine and thus without having a redefinition context.

The multiplicity should also be updated on page 479 for State, on page 498 for Transition, and on page 476 for Region.
Reported: UML 2.0 — Sun, 29 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

Figure 355 - ownedStateMachine should subset ownedBehavior

Key: UML22-1226
Legacy Issue Number: 7052
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
The association ownedStateMachine should subset rather than redefine ownedBehavior.

+ownedStateMachine {subsets ownedBehavior)

The other end of the association should be +context {redefines context) instead of {subsets redefinitionContext)
Reported: UML 2.0 — Sun, 29 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo p 497

Key: UML22-1225
Legacy Issue Number: 7050
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Typo

"As part of the specialization of a class it is desirable also the specialize the behavior definition
Reported: UML 2.0 — Sun, 29 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

State - Constraints - errors in OCL and inconsistencies

Key: UML22-1221
Legacy Issue Number: 7046
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
State - Constraints - errors in OCL and inconsistencies

"[1] There have to be at least two regions in an orthogonal composite state (self.isOrthogonal) implies (self.region->size >= 2)"

Delete this constraint. It is equal to Constraint [7] .

"[2] Only submachine states can have connection point references." Add the following formulation in OCL:

not(self.connection->isEmpty()) implies isSubmachineState = true

"[5] A simple state is a state without any regions. isSimple = content.isEmpty()"

OCL should be isSimple = region->isEmpty()

"[6] Acomposite state is a state with at least one region. isComposite = content.notEmpty()"

OCL should be isComposite = region->notEmpty()

"[7] An orthogonal state is a composite state with at least 2 regions isOrthogonal = (context.size() >= 2)"

OCL should be: isOrthogonal = (region->size() >= 2)

"[8] Only submachine states can have a reference statemachine. isSubmachineState = submachine.notEmpty()"

OCL should be: isSubmachineState = submachine->notEmpty()

"[9] A Protocol state (state belonging to a protocol state machine) has no entry or exit or do activity actions. entry->isEmpty() and exit->isEmpty() and doActivity->isEmpty()"

OCL should be:

let parentStateMachine = self.containingStateMachine() in if parentStateMachine->notEmpty() then if parentStateMachine->at(1).oclIsTypeOf(ProtocolStateMachine) then self.entry->isEmpty() and self.exit->isEmpty() and self.doActivity->isEmpty() endif endif

"[10] Protocol states cannot be deep or shallow history pseudo states. if oclIsTypeOf(Pseudostate) then (kind <> #deepHistory) and (kind <> #shallowHistory)"

OCL should be:

let parentStateMachine = self.containingStateMachine() in if parentStateMachine->notEmpty() then if parentStateMachine->at(1).oclIsTypeOf(ProtocolStateMachine) then (self.kind <> #deepHistory) and (self.kind <> #shallowHistory) end if end if

Furthermore, this constraint should be moved to 15.3.8, because it is a constraint for PseudoState, not for State.
Reported: UML 2.0 — Sun, 29 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Change Constraint [1] to

Key: UML22-1223
Legacy Issue Number: 7048
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Change Constraint [1] to

[1] A fork segment must not have guards or triggers.

(self.source.oclIsKindOf(Pseudostate) and self.source.oclAsType(Pseudostate).kind = #fork) implies (self.guard->isEmpty() and self.trigger->isEmpty())

Change Constraint [2] to

[2] A join segment must not have guards or triggers.

(self.source.oclIsKindOf(Pseudostate) and self.source.oclAsType(Pseudostate).kind = #join) implies (self.guard->isEmpty() and self.trigger->isEmpty())

Change Constraint [3] to

[3] A fork segment must always target a state.

(self.source.oclIsKindOf(Pseudostate) and self.source.oclAsType(Pseudostate).kind = #fork) implies (self.target.oclIsKindOf(State))

Change Constraint [4] to

[4] A join segment must always originate from a state. (self.target.oclIsKindOf(Pseudostate) and self.target.oclAsType(Pseudostate).kind = #join) implies (self.source.oclIsKindOf(State))

Change Constraint [5] to

[5] Transitions outgoing pseudostates may not have a trigger. self.source.oclIsKindOf(Pseudostate) implies self.trigger->isEmpty()
Reported: UML 2.0 — Sun, 29 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Non-existent property isFinal referenced

Key: UML22-1222
Legacy Issue Number: 7047
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Section "State redefinition", first sentence: "A state may be redefined, provided that the value of isFinal is False."

State does not have a property "isFinal".
Reported: UML 2.0 — Fri, 4 Feb 2000 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

ownedStateMachine not described correctly

Key: UML22-1224
Legacy Issue Number: 7049
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
In section "Changes from previous UML" the spec says:

"The association ownedStateMachine is introduced in order for StateMachines to have locally defined StateMachines that can be referenced from SubmachineStates."

This is not correct, because according to Figure 355 ownedStateMachine is an association between StateMachine and BehavioredClassifier and not between StateMachine and StateMachine.
Reported: UML 2.0 — Sun, 29 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Define containingStateMachine() for Vertex

Key: UML22-1220
Legacy Issue Number: 7045
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Define containingStateMachine() for Vertex

Add a section "Additional Queries" and define the query containingStateMachine as follows:

[1] containingStateMachine() replies an OrderedSet consisting of the state machine this vertex belongs to, if any.

context Vertex::containingStateMachine(): OrderedSet(StateMachine) containingStateMachine= if self.container->isEmpty() then OrderedSet{} else if self.container.StateMachine->isEmpty() then OrderedSet{} else OrderedSet
{self.container.StateMachine}
endif endif

Remove Additional Constraint [3] for StateMachine on page 491.
Reported: UML 2.0 — Sun, 29 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

State - Inconsistency

Key: UML22-1219
Legacy Issue Number: 7044
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
State - Inconsistency

In order to be consistent with Figure 354 (p. 457), the multiplicity of association "connection" should be "*"

==> connection: ConnectionPointReference[*] The entry and exit connection points used in conjunction with this (submachine)

dito for deferrableTrigger ==> deferrableTrigger: Trigger[*] A list of triggers that are candidates to be retained by the state machine if they trigger
Reported: UML 2.0 — Sun, 29 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

p.461, first sentence:

Key: UML22-1218
Legacy Issue Number: 7043
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
p.461, first sentence: "A connection point reference to an entry point can also be visualized using a rectangular symbol as shown in Figure 362."

Should refer to Figure 360, not 362

Furthermore, in Figure 360 the example should be "via again", not "via aborted".
Reported: UML 2.0 — Mon, 1 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

AssociationClass - Additional Operation [1] should be deleted

Key: UML22-1216
Legacy Issue Number: 7041
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"[1] The operation allConnections results in the set of all AssociationEnds of the Association. allConnections : Set ( AssociationEnd ); allConnections = self.end->union ( self.allParents ().end )"

AssociationEnd does not exist anymore in UML 2.0. This constraint should be deleted.
Reported: UML 2.0 — Mon, 1 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

AssociationClass Constraint [1] should be reformulated

Key: UML22-1215
Legacy Issue Number: 7040
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Constraint [1] should be reformulated as:

self.endType->excludes(self) and self.endType->collect(c | c.allParents ())~~>excludes(self) and self.endType~~>collect(c | c.allChildren())->excludes(self)

This uses the a query "allChildren" which is not yet defined on Classifier. The following to additional queries should be added to the section "Additional Operations" on page 62:

[9] children gives the direct specialisations of this classifier

context Classifier::children():Set(Classifier) result = generalization.specific

[9] allChildren gives all the directly and indirectly specialized classifiers context Classifier::allChildren():Set(Classifier) result = children->union(children->collect(c | c.allChildren))
Reported: UML 2.0 — Mon, 1 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Association - endType should be of type Classifier

Key: UML22-1214
Legacy Issue Number: 7039
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Association - endType should be of type Classifier

The association endType should be of type classifier, perhaps it should even be renamed to "endClassifier"

/ endType: Classifier [1..*] References the classifiers that are used as types of the ends of the association.

Constraint[3] should be changed accordingly to:

[3] endType is derived from the types of the member ends. self.endType = self.memberEnd->collect(p | p.classifier)
Reported: UML 2.0 — Mon, 1 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

Constraints of ConnectionPointReference - OCL not correct

Key: UML22-1217
Legacy Issue Number: 7042
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"[1] The entry Pseudostates must be Pseudostates with kind entryPoint. entry->notEmpty() implies entry.kind = #entryPoint"

should be

"[1] The entry Pseudostates must be Pseudostates with kind entryPoint. entry->notEmpty() implies entry->forAll(e | e.kind = #entryPoint)"

"[2] The exit Pseudostates must be Pseudostates with kind exitPoint exit->notEmpty() implies exit.kind = #exitPoint"

should be

"[2] The exit Pseudostates must be Pseudostates with kind exitPoint exit->notEmpty() implies exit->forAll(e | e.kind = #exitPoint)"
Reported: UML 2.0 — Mon, 1 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Stereotype «buildComponent» defined twice, description not clear

Key: UML22-1213
Legacy Issue Number: 7021
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Table 25 on p. 593 includes the stereotype «buildComponent», so does table 27 on page 597. «buildComponent» is not used anywhere else in the spec, it has not been used in UML 1.5, and from the description in table 25 it is not clear what this stereotype should be used for.

Suggestion => remove it from table 25 and from table 27.
Reported: UML 2.0 — Mon, 23 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo p 589

Key: UML22-1212
Legacy Issue Number: 7020
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Typo

"UML diagrams may have the following kinds of frame names as part of the heading_._:"
Reported: UML 2.0 — Mon, 23 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

ExtensionPoint should be a specialization of Feature (from Kernel)

Key: UML22-1210
Legacy Issue Number: 7018
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
ExtensionPoint should be a direct specialization of Feature (from Kernel), rather than RefinableElement (from Kernel). Since Feature (from Kernel) also specializes RefinableElement, ExtensionPoint would still be a specialization of RefinableElement.

This would make the classifier based notation of Figure 408 more obvious. And it would fit better with the constraint
{subsets feature}
on +extensionPoint (see Figure 401).
Reported: UML 2.0 — Mon, 23 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo p 587

Key: UML22-1211
Legacy Issue Number: 7019
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Typo

"UML diagrams contain_s_ graphical elements (nodes connected by ..."
Reported: UML 2.0 — Mon, 23 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Multiplicity of extensionLocation should be 1..1 instead of 1..*

Key: UML22-1209
Legacy Issue Number: 7017
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
The association extensionLocation is defined as follows (page 515):

"extensionLocation: ExtensionPoint [ 1..* ] An ordered list of extension points belonging to the extended use case, specifying where the respective behavioral fragments of the extending use case are to be inserted. The first fragment in the extending use case is associated with the first extension point in the list, the second fragment with the second point, and so on. (Note that, in most practical cases, the extending use case has just a single behavior fragment, so that the list of extension points is trivial.)"

It is not clear, what is meant by "behavioral fragments" (or "behavior fragments"). Neither term appears anywhere else in the spec. UseCase is a specialization of BehavioredClassifier and it can therefore have an optional classifier behavior (classifierBehavior) and own 0..* other behaviors (ownedBehavior). If "behavorial fragments" corresponded to "classifierBehavior", then the multiplicity of extensionLocation would have to be 1. If, however, it corresponded with "ownedBehavior", then it would be impossible to identify "the first fragment" because "ownedBehavior" is not ordered. In addition, it would be difficult to identify "the first extension point" because extensionLocation is not ordered either.

As stated above, "in most practical cases, the extending use case has just a single behevavior fragment". I therefore suggest to change the multiplicity of extensionLocation to 1..1
Reported: UML 2.0 — Mon, 23 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Constraint not precise enough

Key: UML22-1207
Legacy Issue Number: 7015
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Constraint [1] should be extended s follows (see also second paragraph in the section Notation on page 321)

[1] A decision node has one incoming edge and at least one outgoing ege. self.incoming->size() = 1 and self.outgoing->size() >= 1
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Duplicate with issue 7009.
Updated: Fri, 6 Mar 2015 22:54 GMT

Unnecessary sentence p 339

Key: UML22-1206
Legacy Issue Number: 7014
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Remove the following sentence from section Semantics:

"No joining of tokens is necessary if there is only one incoming edge, but it is not a useful case."
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

Imprecise sentence p 334

Key: UML22-1208
Legacy Issue Number: 7016
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"Flow final nodes are introduced to model termination or merging of a flow in an activity." should be "Flow final nodes are introduced to model termination of a flow in an activity." since merging of a flow is handled by Merge Nodes.
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
In FlowFinalNode, Rationale section, remove "or merging".
Updated: Fri, 6 Mar 2015 22:54 GMT

"Joining of tokens" not clear

Key: UML22-1205
Legacy Issue Number: 7013
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
It is not clear, how different data tokens arriving at a join node are "joined" before they are passed along the outgoing edge. Are they wrapped in an "envelope token" ? Or are they serialized (in arbitrary order ?) and then passed along the outgoing edge ?
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo p 339

Key: UML22-1204
Legacy Issue Number: 7012
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Typo

"Other rules for when tokens may be passed along the outgoing edge depend on the characteristics of the edge and its target."
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo - Missing colon p 302

Key: UML22-1203
Legacy Issue Number: 7011
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
outgoing ActivityEdge [0..*] Edges that have the node as source.

should be

outgoing: ActivityEdge [0..*] Edges that have the node as source.
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Constraint not precise enough

Key: UML22-1201
Legacy Issue Number: 7009
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Constraint [1] should be extended s follows (see also first sentence in the section Notation on page 339)

[1] A join node has one outgoing edge and at least one incoming ege. self.incoming->size() >= 1 and self.outgoing->size() = 1
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo p 320

Key: UML22-1200
Legacy Issue Number: 7008
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Typo

"A decision input behavior has one input parameter and one output parameter. The input parameter must be the same as or a supertype of the type of object token coming along the incoming edge. The behavior cannot have side effects. "
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
In Decision Node class, in constraint [2], insert "of" after supertype.
Updated: Fri, 6 Mar 2015 22:54 GMT

No Activity Edges from with equal source and target

Key: UML22-1202
Legacy Issue Number: 7010
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
The Constraints section of Activity Edge should be extended with:

[3] Source and target of an activity edge must not be equal source <> target
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This is duplicate with 7007.
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo p 161

Key: UML22-1197
Legacy Issue Number: 7005
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Typo

".. of two occurrences of the Sale collaboration, indicated b_e_ the dashed ellipses." => ".. of two occurrences of the Sale collaboration, indicated by the dashed ellipses."
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Another Inconsistency with Figure 100

Key: UML22-1196
Legacy Issue Number: 7004
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
According to Figure 100, the multiplicity of "roleBinding" is "*". Thus, the second paragraph of section "Associations" should be changed to

roleBinding: Dependency[*] A mapping between features of the collaboration type and features of the classifier or operation. This mapping indicates which connectable element of the classifier or operation plays which role(s) in the collaboration. A connectable element may be bound to multiple roles in the same collaboration occurrence (that is, it may play multiple roles).
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Multiple activity edges between a given pair of activity nodes possible ?

Key: UML22-1199
Legacy Issue Number: 7007
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Multiple activity edges between a given pair of activity nodes possible ?

Currently, there is no constraint which would forbid two Activity Edges with the same source/target pair, i.e.

--------- -------- | A1 | --------> | A1 | | | | | | | --------> | | -------- ---------

The following constraint should be added to the Constraints section of Activity Edge on page 293:

Constraints

[3] There is at most one ActivityEdge given a source and a target Activity Node. source.outgoing->select(ae | ae.source = source and ae.target = target)~~>size() = 1 and target.incoming~~>select(ae | ae.source = source and ae.target = target)->size() = 1
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

Inconsistency between constraint of ControlNode and Semantics of JoinNode

Key: UML22-1198
Legacy Issue Number: 7006
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Constraint on ControlNode (p. 317):

"[1] The edges coming into and out of a control node must be either all object flows or all control flows."

Semantics of JoinNode (p. 339):

"If there is a token offered on all incoming edges, then tokens are offered on the outgoing edge according to the following join rules: 1. If all the tokens offered on the incoming edges are control tokens, then one control token is offered on the outgoing edge. 2. If some of the tokens offered on the incoming edges are control tokens and other are data tokens, then only the data tokens are offered on the outgoing edge."

Item 2.) should be: "2. If all the tokens offered on the incoming edges are data tokens, then only the data tokens are offered on the outgoing edge."
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

Inconsistency with Figure 100

Key: UML22-1195
Legacy Issue Number: 7003
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
According to Figure 100, the multiplicity of "collaborationRole" is "*". Thus, the first paragraph of section "Associations" should be changed to

collaborationRole: ConnectableElement[*] References connectable elements (possibly owned by other classifiers) which represent roles that instances may play in this collaboration. (Subsets StructuredClassifier.role.)
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Figure 103 at the wrong place

Key: UML22-1194
Legacy Issue Number: 7002
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
The section "Presentation Option" including Figure 103 does not fit in the context of section 9.3.1. This section deals with the specialized Class meta-class for Structured Classes, whereas the "Presentation Option" and Figure 103 explain something about relating instance specifications to constructors. This section should either be deleted or moved be moved to another place, i.e. section 7.11, Kernel - the Classes Diagram, or section 7.7, Kernel - the Instance Diagrams.
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

Connector - default value für "kind"

Key: UML22-1193
Legacy Issue Number: 7001
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
On page 143, the spec says: kind : ConnectorKind =
{assembly, delegation}
Indicates the kind of connector.

This doesn't make sense. "kind" is either "assembly" or "delegation" but not a set consisting of both values. "kind" should either have no default value, or it should be "assembly" or "delegation". kind : ConnectorKind or kind : ConnectorKind = assembly or kind : ConnectorKind = delegation
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo p 137

Key: UML22-1192
Legacy Issue Number: 7000
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Typo

"A component is a substitutable unit that can be replaced at design time or run-time by a component that offers that offers equivalent functionality based on compatibility of its interfaces."
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Missing multiplicities

Key: UML22-1191
Legacy Issue Number: 6999
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
The multiplicities for the four following associations are missing in section Associations:

provided: Interface[*] required: Interface[*] realization: Realization[*] ownedMember: PackageableElement[*]
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo p. 595, Table 25, row 6, column 3

Key: UML22-1190
Legacy Issue Number: 6998
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Typo

p. 595, Table 25, row 6, column 3

Artif_i_act
Reported: UML 2.0 — Sun, 22 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
On page 595 in the entry for “script” of Table 25, replace “Artifiact” with “Artifact”
Updated: Fri, 6 Mar 2015 22:54 GMT

Additional Operations specification of NamedElement::allNamespaces()

Key: UML22-1189
Legacy Issue Number: 6997
Status: closed
Source: Unisys ( Terry L. Cowart)
Summary:
The Additional Operations specification of NamedElement::allNamespaces() appears incorrect. The else clause states:

else self.name.allNamespaces()->prepend(self.namespace)

The problem is that self.name is a String attribute, and does not have a allNamespaces query. It appears that the intent is to state:

else self.namespace.allNamespaces()->prepend(self.namespace)

which would provide access to the query, as well as providing the (apparently intended) recursion.
Reported: UML 2.0 — Thu, 19 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Second row of table 22, column "Notation", labels switched

Key: UML22-1186
Legacy Issue Number: 6964
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Second row of table 22, column "Notation", labels switched.

The use case "Withdraw" should be the including use case. "Card identification" should be the included use case.
Reported: UML 2.0 — Sat, 31 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Same issue as 6643
Updated: Fri, 6 Mar 2015 22:54 GMT

UseCase - Inconsistencies with Figure 401

Key: UML22-1185
Legacy Issue Number: 6963
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
UseCase - Inconsistencies with Figure 401

According to Figure 401, the mulitiplicy of association end +subject is "*".

On page 519 it is "subject : Classifier References the subjects to which this use case applies. The subject ..."

and should be

"subject : Classifier[*] References the subjects to which this use case applies. The subject ..."

dito for "include" and "extend"
Reported: UML 2.0 — Fri, 31 Jan 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

typo

Key: UML22-1188
Legacy Issue Number: 6968
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Last sentence on page:

"..., it is typically defined in the some classifier or package ..."
Reported: UML 2.0 — Sat, 31 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Typo in OCL

Key: UML22-1187
Legacy Issue Number: 6966
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Typo in OCL

extensionLocation->forAll (xp | extendedCase.extensionPoint->include(xp))

should be ("includes" instead of "include")

extensionLocation->forAll (xp | extendedCase.extensionPoint->includes(xp))
Reported: UML 2.0 — Sat, 31 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

UseCase - Extend is not a Namespace

Key: UML22-1184
Legacy Issue Number: 6962
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
UseCase - Extend is not a Namespace

See association end +condition of the association between Extend and Constraint: +condition
{subsets ownedMember}

Extend is not a Namespace, however. Therefore +condition cannot subset ownedMember.

Extend should either specialize Namespace or the property string of +condition should be changed to
{subsets ownedElement}: +condition {subsets ownedElement}
Reported: UML 2.0 — Sat, 31 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Inconsistent multiplicity

Key: UML22-1183
Legacy Issue Number: 6961
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Inconsistent multiplicity

" ownedUseCase: UseCase References the use cases owned by this classifier. (Specializes Namespace.ownedMember.)"

According to Figure 401 the multiplicity should be [*]. ==>

" ownedUseCase: UseCase[*] References the use cases owned by this classifier. (Specializes Namespace.ownedMember.)"
Reported: UML 2.0 — Sat, 31 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Inconsistency betw. Figure 328 and associations listed in s. Associations

Key: UML22-1182
Legacy Issue Number: 6960
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Inconsistency between Figure 328 and the associations listed in section "Associations".

If there is an association between MessageEnd and Interaction according to

interaction: Interaction[1] The enclosing Interaction owning the MessageEnd

then it is missing in Figure 328.
Reported: UML 2.0 — Fri, 31 Jan 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Wrong association name

Key: UML22-1180
Legacy Issue Number: 6943
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
lifeline: Lifeline[1] References the Lifeline on which the StateInvariant appears. Specializes InteractionFragment. covered"

should be

"covered: Lifeline[1] References the Lifeline on which the StateInvariant appears. Specializes InteractionFragment. covered"
Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Constraint [2] - Missing parenthesis in OCL

Key: UML22-1179
Legacy Issue Number: 6942
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"(self.selector->isEmpty implies not self.represents.isMultivalued()) or (not self.selector->isEmpty implies self.represents.isMultivalued())"

should be

"(self.selector->isEmpty() implies not self.represents.isMultivalued()) or (not self.selector->isEmpty() implies self.represents.isMultivalued())"

Furthermore, I don't understand why this constraint is necessary, since the multiplicy of 'represents' is exactly 1.
Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

type p 419

Key: UML22-1181
Legacy Issue Number: 6944
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
A GeneralOrdering is shown by a dotted line connected the two Eventoccurrences."

should be

"A GeneralOrdering is shown by a dotted line connecting the two Eventoccurrences."
Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Inconsistency between section "Associations" and Figure 327

Key: UML22-1178
Legacy Issue Number: 6941
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
In Figure 327, the association end of the association between Lifeline and Expression is called "discriminator", whereas the respective association belonging to Lifeline is called "selector":

"selector : Expression[0..1] If the referenced ConnectableElement is multivalued, then this specifies the specific individual part within that set."
Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

typo p 340

Key: UML22-1177
Legacy Issue Number: 6940
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
This case maps to a model containing a a join node with all the incoming ..."

should be

"This case maps to a model containing a join node with all the incoming ..."
Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

object edges" should be replaced by "object flows

Key: UML22-1176
Legacy Issue Number: 6938
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Output pins are object nodes and deliver values to other actions through object edges."

==> "object edges" should be replaced by "object flows".

"Output pins are object nodes and deliver values to other actions through object flows."
Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

graphic nodes

Key: UML22-1172
Legacy Issue Number: 6934
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"The graphic nodes that can be included in structural diagrams are shown in Table 14."

This is refering to Table 14 which lists nodes in secuence diagrams, not in structural diagrams. Probably, the correct sentence would be:

"The graphic nodes that can be included in sequence diagrams are shown in Table 14."
Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

typo p 421

Key: UML22-1171
Legacy Issue Number: 6933
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"The local attriburte PIN of UserAccepted is declared near the diagram top."

should be

"The local attribute PIN of UserAccepted is declared near the diagram top."
Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

object edges" sould be replaced by "object flows

Key: UML22-1175
Legacy Issue Number: 6937
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
They are object nodes and receive values from other actions through object edges."

==> "object edges" sould be replaced by "object flows".

"They are object nodes and receive values from other actions through object flows."
Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
In InputPin class, top section, second sentence, replace the last word with "flows".
Updated: Fri, 6 Mar 2015 22:54 GMT

typo p 356

Key: UML22-1174
Legacy Issue Number: 6936
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"The name is not restricted, but it is often just shows the type of object or data that flows through the pin."

should be

"The name is not restricted, but it often just shows the type of object or data that flows through the pin."
Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

typo p 240

Key: UML22-1173
Legacy Issue Number: 6935
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
"Other rules for when tokens may be passed along the edge depend the kind of edge and characteristics of its source and target."

should be

"Other rules for when tokens may be passed along the edge depend on the kind of edge and characteristics of its source and target."
Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Duplicate with 7012.
Updated: Fri, 6 Mar 2015 22:54 GMT

typo p 420

Key: UML22-1170
Legacy Issue Number: 6932
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
These attribute definitions may appear near the top of the diagram frame or within note symbols other places in the diagram."

should be

"These attribute definitions may appear near the top of the diagram frame or within note symbols at other places in the diagram."
Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

typo p 403

Key: UML22-1169
Legacy Issue Number: 6931
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
We are aware that other parts of the UML languatge definition the term “trace” is used also for other purposes."

should be

"We are aware that in other parts of the UML language definition the term “trace” is used also for other purposes."
Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Inconsistencies between Figure 43 and the detailled description of Package

Key: UML22-1168
Legacy Issue Number: 6919
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Figure 43 includes an association between Package and Type, whose endpoints are "package" and "/ownedClassifier" respectively.

On p. 100, section "Associations", the following association is listed: ownedType: Type[*]

The name of the endpoint in Figure 43 should be "/ownedType", not "/ownedClassifier".
Reported: UML 2.0 — Mon, 19 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Duplicate of issue 6184.
Updated: Fri, 6 Mar 2015 22:54 GMT

The section "Associations (BasicActivities)" is not complete

Key: UML22-1165
Legacy Issue Number: 6915
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
The section "Associations (BasicActivities)" is not complete because the association between Activity and Action (depicted in Figure 176) is not described.

The following item should be added to the description:
- action: Action[0..*] The Actions the Activity is composed of.
Reported: UML 2.0 — Mon, 19 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See resolution of 7319. This association is replaced with SequenceNode.
Updated: Fri, 6 Mar 2015 22:54 GMT

The query 'hostElement' has some errors

Key: UML22-1164
Legacy Issue Number: 6914
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
See the comment lines starting with – !! in the following listing:

– !! on the next line, ModelElement should probably be changed – !! to Element. hostElement() : ModelElement; hostElement = if self.Method->size() > 0 then self.Method else if self.State->size() > 0 then self.State else if self.Transition->size() > 0 then self.Transition else if self.Message->size()>0 then self.Message – !! size should be size() on the next line else if self.Stimulus->size>0 then self.Stimulus endif endif endif – !! should be endif on the next line endi – !! missing endif on this line – !! remove the closing bracket on the next line ]
Reported: UML 2.0 — Mon, 19 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Inconsistencies between Figure 3 and the detailled description of package

Key: UML22-1167
Legacy Issue Number: 6918
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
" package: Package [0..1] References the owning package of a package. Subsets NamedElement::namespace."

should be

" package: Package [0..1] References the owning package of a type. Subsets NamedElement::namespace."

Furthermore, the following description for an association depicted in Figure 43 is missing:

nestingPackage: Package [0..1] References the owning package of a package. Subsets NamedElement::namespace.
Reported: UML 2.0 — Mon, 19 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

/context : Classifier [0..1]

Key: UML22-1166
Legacy Issue Number: 6917
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
" /context : Classifier [1] The classifier that owns the behavior of which this action is a part."

The multiplicity should be [0..1] in order to be consistent with the multiplicity in Figure 176.

" /context : Classifier [0..1] The classifier that owns the behavior of which this action is a part."
Reported: UML 2.0 — Mon, 19 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
In Action class, Attributes, change multiplicity of /context to [0..1]
Updated: Fri, 6 Mar 2015 22:54 GMT

See CommonBehavior for a description of Event specifications

Key: UML22-1163
Legacy Issue Number: 6682
Status: closed
Source: XTG, LLC ( Joaquin Miller)
Summary:
The text says "See CommonBehavior for a description of Event specifications."

Under the heading,Basic Behaviors, on page 370, Section 13 mentions call behavior event, trigger event, start event and termination event; the next page mentions send invocation event, send event, invocation event, call invocation event, signal event, receive event, receiving event; there may be others.

But we aren't told there or anywhere how to specify an event nor how to specify a type of event.
Reported: UML 2.0 — Mon, 8 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above THEN below
Updated: Fri, 6 Mar 2015 22:54 GMT

page 95 diagram

Key: UML22-1162
Legacy Issue Number: 6596
Status: closed
Source: no ( Jens Muehlenhoff)
Summary:
On page 95 the diagram shows an assoziation between the class DataType and Property (with name ownedAttribute). This assoziation is'l listet in the assoziation section of the class DataTypes on page 95. Ther is an assoziation with the same name (ownedAttribute) but with a wrong type (Attribute).
Reported: UML 2.0 — Mon, 10 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

On templateableElment - additonal features

Key: UML22-1161
Legacy Issue Number: 6277
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
Summary:
The query getParameterableElements() returns the set of elements that may be used as the parametered element for a template parameter if this templateable element ???."

I think the previous sentence is not complete?
Reported: UML 2.0 — Mon, 29 Sep 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Figure 346 needs updating

Key: UML22-1160
Legacy Issue Number: 6087
Status: closed
Source: Ostfold University College ( Dr. Oystein Haugen)
Summary:
The Figure 346 on page 443 needs some updating: 1. The collaboration W should be shown as an oval 2. The text inside the right lifeline of sd Q should read “y:superB” (the colon is missing)
Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Incorrect mentioning of General Order On p 412

Key: UML22-1157
Legacy Issue Number: 6081
Status: closed
Source: Ostfold University College ( Dr. Oystein Haugen)
Summary:
Incorrect mentioning of General Order On p 412: The only purpose of gates is to define the source and the target of Messages or General Order relations.

" or General Order relations” should be removed. This is a reminiscence of an earlier version
Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Omission of non-terminal arguments (p. 424)

Key: UML22-1159
Legacy Issue Number: 6085
Status: closed
Source: Ostfold University College ( Dr. Oystein Haugen)
Summary:
In top of p. 424 there is a small textual grammar for a name in an interaction occurrence. There should be one more production defining the non-terminal ‘arguments’ as shown below here: arguments ::= argument [ , arguments]
Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Remove occurrences of TBD

Key: UML22-1158
Legacy Issue Number: 6084
Status: closed
Source: Ostfold University College ( Dr. Oystein Haugen)
Summary:
There are a couple of places where the flag “TBD” is still in the document. They should be removed.

pp. 423, 427,
Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Message notation. Incorrect notation in Figure 333 p.414

Key: UML22-1153
Legacy Issue Number: 6077
Status: closed
Source: Ostfold University College ( Dr. Oystein Haugen)
Summary:
Firstly not even the original (which is in Visio) has the appropriate dashed line of creation (I thought the pdf just had not quite got it right which happens often, but now I checked the original). Secondly the reply messages should have filled arrowheads (again judging from the description of the message notation).

The FTF should reconsider the concrete syntax for create and reply and update the figures accordingly.

Originally reported by David Fado through Jim Odell.
Reported: UML 2.0 — Thu, 28 Aug 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This is a subset of the issue described in 6463. - duplicate
Updated: Fri, 6 Mar 2015 22:54 GMT

Message End association to Interaction should be removed

Key: UML22-1155
Legacy Issue Number: 6079
Status: closed
Source: Ostfold University College ( Dr. Oystein Haugen)
Summary:
There is an association in MessageEnd to Interaction (p. 431). This association should have been removed long time ago. It is a reminiscence of an earlier version.
Reported: UML 2.0 — Thu, 28 Aug 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

Strict ordering in Inline Part Decomposition

Key: UML22-1154
Legacy Issue Number: 6078
Status: closed
Source: Ostfold University College ( Dr. Oystein Haugen)
Summary:
Inline Part Decomposition as shown in Figure 341 p. 433 are practical, but often it is necessary to describe the individual ordering between the events on the different inner lifelines. Often the user will want this ordering to be strict rather than weak.

There should be a way to denote that the ordering within an inline part decomposition should be strict.

Originally reported by Ericsson engineer Peter Cigehn.
Reported: UML 2.0 — Thu, 28 Aug 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 22:54 GMT

EventOccurrence, multiplicities incorrect in metamodel diagram

Key: UML22-1156
Legacy Issue Number: 6080
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
The metamodel shown in Figure 328, p. 407 presents the associations from EventOccurrence to ExecutionOccurrence with multiplicity ‘*’. This should be [0..1] as given in the text.
Reported: UML 2.0 — Thu, 28 Aug 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

On page 140, the title for Parameter is "Parameter (Collaboration, as speci

Key: UML22-1152
Legacy Issue Number: 6023
Status: closed
Source: self ( Steve Hickman)
Summary:
On page 140, the title for Parameter is "Parameter (Collaboration, as specialized)". This doesn't seem correct. The only prior definition of Parameter is on p 50, which is in the Kernel. The only way to "specialize" something appears to be when you want to add relationships to a concept that has been defined in a different package. I believe the more correct label should be "Parameter (from Kernel, as specialized)". Further, the abstract syntax diagram on page 128 should indicate that Parameter comes from the definition in the the Kernel. This may require deriving a new Parameter metaclass from the Kernel Parameter metaclass just so it can also be derived from ConnectableElement.
Reported: UML 2.0 — Sun, 27 Jul 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

The title of the Property description on page 144

Key: UML22-1151
Legacy Issue Number: 6022
Status: closed
Source: self ( Steve Hickman)
Summary:
The title of the Property description on page 144 says: "Property (from InternalStructures, as specialized)". I believe this should say: "Property (from Kernel, as specialized)".

Here's why: there is as yet no indication of any kind of relationship between Property as defined as part of the Superstructure Kernel and Property as described in InternalStructures. There are some hints that such a relationship exists, but it isn't clear. Either the relationship should be explicitly stated (ir a relationship exists), or it should be explicitly stated that no such relationship exists.
Reported: UML 2.0 — Sun, 27 Jul 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

labels for ExecutionOccurrence

Key: UML22-1150
Legacy Issue Number: 6021
Status: closed
Source: self ( Steve Hickman)
Summary:
The labels for ExecutionOccurrence in the diagrams on p 367 & 368 are both in italics, implying that this is an abstract class. However, the description of EventOccurrence on p. 378 doesn't mention anything about being abstract nor are there any classes derived from it anywhere in the spec.
Reported: UML 2.0 — Sun, 27 Jul 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
resolved, see above
Updated: Fri, 6 Mar 2015 22:54 GMT

duration observation" vs DurationObservationAction etc

Key: UML22-1149
Legacy Issue Number: 6020
Status: closed
Source: self ( Steve Hickman)
Summary:
There is some inconsistency in the use of the terms "duration observation" vs. DurationObservationAction and "time observation" vs. TimeObservationAction in the diagrams on the above listed pages. In particular, figure 8-158 states that the visual elements in a Sequence Diagram are "DurationObservation" and "TimeObservation", when in fact they should be "DurationObservationAction" and "DurationObservationAction". The observations only occur when the action is taken - but the representation on the sequence diagram must be the action to be taken, not the effect of it. Compare this to figures on pp 351 & 360.
Reported: UML 2.0 — Fri, 25 Jul 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above, resolved
Updated: Fri, 6 Mar 2015 22:54 GMT

Missing sections for for enumeration MessageKind or MessageSor

Key: UML22-1148
Legacy Issue Number: 6019
Status: closed
Source: self ( Steve Hickman)
Summary:
In Chapter 8, you have a section in 8.3 describing the enumeration InteractionOperator. You do not have similar sections for enumeration MessageKind or MessageSort.
Reported: UML 2.0 — Thu, 24 Jul 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
duplicate
Updated: Fri, 6 Mar 2015 22:54 GMT

figure 8-137 and 8-139

Key: UML22-1147
Legacy Issue Number: 6018
Status: closed
Source: self ( Steve Hickman)
Summary:
In figure 8-137, EventOccurrence inherits from InteractionFragment which inherits from NamedElement. In figure 8-139, EventOccurrence inherits directly from NamedElement.

The two figures should be consistent with each other (yes, I know that inheritance is transitive, but it does raise unnecessary questions)
Reported: UML 2.0 — Thu, 24 Jul 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

CommonBehaviors describes "Operation (from Communications, as specialized)

Key: UML22-1146
Legacy Issue Number: 6017
Status: closed
Source: self ( Steve Hickman)
Summary:
CommonBehaviors describes "Operation (from Communications, as specialized)" on page 354. However, the only other reference to "Operation" in the CommonBehaviors section appears on p 339, where the reference is to "Operation (from Kernel)".

There's something wrong here.
Reported: UML 2.0 — Thu, 24 Jul 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

inconsistency between figure 5.1 on page 179 and figure 7-122 on page 337.

Key: UML22-1144
Legacy Issue Number: 6015
Status: closed
Source: self ( Steve Hickman)
Summary:
There appears to be an inconsistency between figure 5.1 on page 179 and figure 7-122 on page 337.

In figure 5.1, the IntermediateActions pacakge is dependent on the Communications package.

In figure 7.122 IntermediateActions depends only on BasicBehaviors. Although Communications is present in the diagram, there is no indication of a dependency.
Reported: UML 2.0 — Thu, 24 Jul 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

OpaqueExpression in CommonBehaviors

Key: UML22-1143
Legacy Issue Number: 6014
Status: closed
Source: Honeywell ( Steven Hickman)
Summary:
OpaqueExpression in CommonBehaviors is titled "OpaqueExpression (from BasicBehaviors, specialized)". What does "specialized" mean in this context? There is no indication of inheritance from any other definition of OpaqueExpression.

NOTE: the word "specialized" is used in the title of a number of concepts - in some cases the concepts are derived from other concepts of the same name from other package. This isn't always the case though.
Reported: UML 2.0 — Thu, 24 Jul 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:54 GMT

CommonBehaviors

Key: UML22-1145
Legacy Issue Number: 6016
Status: closed
Source: self ( Steve Hickman)
Summary:
CommonBehaviors has a package named "Time" that is referenced in numerous parts of the document.

The class diagram on page 342 is labelled "SimpleTime". it appears that this should be labelled "Time" to be consistent with the package name.
Reported: UML 2.0 — Thu, 24 Jul 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above,. resolved
Updated: Fri, 6 Mar 2015 22:54 GMT

Output tokens

Key: UML22-1142
Legacy Issue Number: 8675
Status: closed
Source: FUNDP ( Pierre Yves Schobbens)
Summary:
In: [4] The output tokens are now available Replace ``available'' by ``offered''
Reported: UML 2.1 — Tue, 5 Apr 2005 04:00 GMT
Disposition: Duplicate or Merged — UML 2.1.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 22:25 GMT

Section: Activities: Modifications to the approved resolution of 10815

Key: UML22-1141
Legacy Issue Number: 12433
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Modifications to the approved resolution of 10815. It should use a different keyword for decision input flows than the existing one for decision input behaviors. It should include an update to the notation figure, and to the keyword index.
Reported: SysML 1.0 — Fri, 9 May 2008 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Revise the resolution to 10815 as suggested
Updated: Fri, 6 Mar 2015 20:58 GMT

Diagram metaclass shall be introduced and shall be subclass of Element

Key: UML22-1122
Legacy Issue Number: 10819
Status: closed
Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
Summary:
Diagram metaclass shall be introduced and shall be subclass of Element, because every tool need to add Diagrams into packages (and uses hacks to do that) , Dependencies between diagrams is usable also. Stereotypes for diagrams are also used and even represented in DiagramFrame notation
Reported: UML 2.1 — Fri, 23 Feb 2007 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This is definitely outside the scope of an RTF. However, it is also very much against one of the fundamental architectural principles of UML, that the abstract and concrete syntaxes are to be kept distinct. For instance, it should be possible to provide a UML concrete syntax that is completely textual and, hence, has no notion of diagram. Finally, the question of defining concrete syntaxes for MOF-based modeling languages and the issue of how these relate to the models themselves is being addressed by a separate RFP (the “Diagram Definition RFP”). Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Setting structural features of a data type

Key: UML22-1121
Legacy Issue Number: 10816
Status: closed
Source: Model Driven Solutions ( Mr. Ed Seidewitz)
Summary:
Document: Unified Modeling Language: Superstructure, Version 2.1.1 (formal/2007-02-03)
Sections: 11.3.12 (ClearStructuralFeatureAction) and 11.3.53 (WriteStructuralFeatureAction)

(This issue surfaced during work on the Semantics of a Foundational Subset for Executable UML Models submission.)

Background:

Use the term "structured" data type to refer to a data type that is not a primitive type or an enumeration. Such a data type may have attributes, which can be read and written by the read and write structural feature actions (for the purposes of this discussion, consider clear structural feature action to be a kind of write structural feature action).

Semantically, the main difference between a data value that is an instance of a structured data type and an object that is an instance of a class is that a data value is passed "by value" while an object is passed "by reference". That is, a data value is itself a true value that can be passed as a parameter value to behavior and can flow on "object" flow edges ("object flow" really isn't a better name than "data flow", but the way...). On the other hand, an object exists with its own identity in the extent of their class at a specific locus, and only references to an object can be passed as values.

Thus, there may be many references all to the same object. As a result of this, any change to the attributes of an object via one reference will be reflected in future reads of that attribute via different references to that object.

In the case of a structured data value, however, a change to one of its attributes will only be reflected in the value actually being acted on. If that value is not then itself passed on, this change will not be visible in any other data value. Unfortunately, write structural feature actions do not have output pins. The assumption seems to be that such writes always happen "in place". This works for objects that have their own identity, but there is no clear "place" for which the change can happen for structured data values.

Note that this would still be an issue even if variables were allowed in fUML (and so it is an issue in full UML 2 with variables, too). To change a value in a variable, one needs to use a read variable action. If the value in the variable is a structured data value, then the read variable action will place a "by value" copy of the data value on the output pin of the action (since data values don't have identity or references, it can't really do anything else...). Therefore, a write structural value action acting on the output of a read variable action will make a change to this copy, not the value in the variable. But then, since the write structural value action has no output pin, there is no way to get the changed copy back into the variable (or use it in any other way, for that matter.)

Proposed resolution:

Add an output pin to write structural feature actions. If the "object" being acted on is really an object (that is, an instance of a class), then the input reference to that object is just place on the output pin. But if the "object" being acted on is a data value (that is, an instance of a structured data type), then the value placed on the output pin is a copy of the input data value, but with the given structural feature value appropriately updated.

(Note that the output pin is not strictly necessary for a true object update, but it seems simpler to always have the output pin. In the case of a write to an object, the output pin can simply be ignored – though it might sometimes be convenient even in this case for "chaining" actions on an object.)
Reported: UML 2.1 — Fri, 9 Mar 2007 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 7.14: "Type" does not show its inheritance from "PackageableElement"

Key: UML22-1124
Legacy Issue Number: 10828
Status: closed
Source: International Business Machines ( Andreas Maier)
Summary:
In the Superstructure spec 2.1.1, in figure 7.14, the "Type"
metaclass is shown right below the "PackageableElement" metaclass,
but without any inheritance arrow between them. This is not wrong,
since a class diagram is not obliged to show all existing
relaitonships.

However, it would ease the understanding and be consistent if in this
case, the inheritance arrow between these two metaclasses was shown
in that figure.
Reported: UML 2.1 — Sat, 17 Mar 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This strikes me as a matter of taste; someone else might object to the generalization being shown in this diagram since it would clutter the diagram. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

ConnectorEnd shall have references to provided or required interfaces

Key: UML22-1123
Legacy Issue Number: 10820
Status: closed
Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
Summary:
ConnectorEnd shall have references to provided or required interfaces. It helps to use assembly connectors in composite structure diagrams between parts and ports, connector will be able to display two compatible interfaces using "ball in socket" notation.
Now it is impossible to implement that, because there are no references to interfaces.
Reported: UML 2.1 — Fri, 23 Feb 2007 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Resolution: There are two problems with this issue: (a) The ball-and-socket notation is unique to the components chapter, so this issue cannot be resolved in general for ConnectorEnd, but would have to be addressed specifically in the components chapter by introducing a subtype of ConnectorEnd. More importantly, though, (b) connectors do not have a semantic relation to interfaces. They connect ports or parts based on their compatability. The compatability between interfaces is a derived notation, and does not require metamodel support. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

constraining Classifiers

Key: UML22-1134
Legacy Issue Number: 11243
Status: closed
Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
Summary:
It should be possible to specify multiple constraining classifiers for ClassifierTemplateParameter.
For example, Java programming language allows to specify multiple interfaces as constraining types of template parameter, I see no reasons why UML can't allow several constraining types.

Resolution:

17.5.8
Change multiplicity of "constrainingClassifier" from [0..1] to [0..*].
Reported: UML 2.1.1 — Mon, 6 Aug 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

defaultClassifier of ClassifierTemplateParameter

Key: UML22-1133
Legacy Issue Number: 11240
Status: closed
Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
Summary:
Problem:

"defaultClassifier" of ClassifierTemplateParameter shall redefine "default" of TemplateParameter and restrict type to Classifier.

"default" shall be not accessible in ClassifierTemplateParameter.

Resolution:

Add
{redefines default} to end of "defaultClassifier"property description in chapter 17.5.8 ClassifierTemplateParameter

Add {redefines default}
in metamodel association. Unfortunately diagram of abstract syntax of ClassifierTemplateParameter is not included into 17.5 Templates chapter.

It should be added also.
Reported: SysML 1.0 — Wed, 1 Aug 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Remove this redundant association
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.11 p 182

Key: UML22-1129
Legacy Issue Number: 11087
Status: closed
Source: UPM ( Juan Pedro Silva)
Summary:
All rolenames in non-navigable associations in the UML metamodel should be stated, to allow reaching from one element of the association to the other using OCL. Currently, this is limited to un-ambigous type names if the rolename is not stated. For example, in section "9.3.11 Port (from Ports)", Port has required and provided interfaces, and has no rolename on both associations. There is no current way, using OCL, of getting from one Interface to a Port that provides or requires it, as "self.port" is ambigous because it doesn't specify if the programmer is looking for Ports providing or requiring such Interface. The situation repeats in many other associations.
Reported: UML 2.1.1 — Thu, 31 May 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: It is not required for the specification to name such associations. Navigation is not that hard if this is really desired: find all ports and select the subset that has the appropriate interface. Also, OCL is not constrained by navigability. Discussion: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong notation description

Key: UML22-1128
Legacy Issue Number: 11007
Status: closed
Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
Summary:
"A component realization is notated in the same way as the realization dependency (i.e., as a general dashed line with an open arrow-head). ", BUT
A Realization dependency is shown as a dashed line with a triangular arrowhead at the end that corresponds to the realized element
Reported: SysML 1.0 — Wed, 16 May 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
agreed
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.8

Key: UML22-1127
Legacy Issue Number: 11004
Status: closed
Source: NIST ( Mr. Peter Denno)
Summary:
In UML 2.1.1 L3 metamodel (and the UML 2.1.1 Superstructure spec) EncapsulatedClassifier.ownedPort is declared to be derived. No derivation is provided and it seems unlikely that one was intended. For a list of other properties declared derived for which there is no derivation, see the 2006-12-09 entry here: http://syseng.nist.gov/se-interop/plugfest/tools/changelog
Reported: UML 2.1.1 — Mon, 14 May 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This derivation is given: EncapsulatedClassifier.ownedPort is all ownedAttributes that are of type Port. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

page 449 chapter 13.3.24 (Signal (from Communications)

Key: UML22-1126
Legacy Issue Number: 11003
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
there is a mistake in document formal/07-02-03 (UML Superstructure,
v2.1.1) on page 449 chapter 13.3.24 (Signal (from Communications)). A
Signal does not have an association to a signal of type Signal. It is
probably a mix-up with SignalEvent
Reported: SysML 1.0 — Mon, 14 May 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: Duplicate of issue 10960 Revised Text: N/A Disposition: Duplicate
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 superstructure -- figure 9.4 is duplicate of figure 9.3

Key: UML22-1125
Legacy Issue Number: 10992
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
Figure 9.4 in formal/07-02-05 is a duplicate of figure 9-3. There should be a different diagram in place of figure 9-4 that shows the ports metamodel.
Reported: SysML 1.0 — Tue, 8 May 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: Fixed in 2.1.2 Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Change multiplicity of ClassifierTemplateParameter role

Key: UML22-1136
Legacy Issue Number: 11400
Status: closed
Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
Summary:
Problem:
The same Classifier could be used only in one template parameter as "constrainingClassifier", it brokes usage of ClassifierTemplateParameters.

Solution:
Change multiplicity of ClassifierTemplateParameter role from "1" to "*" on association between ClassifierTemplateParameter and Classifier in Figure 17.18 - Classifier templates
Reported: UML 2.1.1 — Thu, 13 Sep 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Any ownedBehavior should be able to have AcceptEventAction

Key: UML22-1135
Legacy Issue Number: 11265
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
Section 13.3.31, Trigger indicates the receipt of an event by and active object can either directly cause the occurrence of a behavior, or is delivered to the classifier behavior. This is insufficient. An Event should be able to be handled by any active AcceptEventAction in any thread of control in any running method Activity that is an ownedBehavior of the receiving object. This is how events are commonly handled in business process models and BPEL. It allows an active object to indicate when it is able to accept a call or signal event at a specific point in an already running method activity. If there are more than one such AcceptEventAction, then the AcceptEventAction that handles the event is arbitrary.
Reported: UML 2.1.1 — Thu, 9 Aug 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

composite values

Key: UML22-1132
Legacy Issue Number: 11239
Status: closed
Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
Summary:
UML 2.1.1

Problem:

Duration value and TimeExpression value can't be owned by Duration or TimeExpression.

Solution:

Make Duration "expr" and TimeExpression "expr" properties composite.
Change Figure 13.13 SimpleTime to reflect these ownerships.
Reported: SysML 1.0 — Wed, 1 Aug 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9 composite structures

Key: UML22-1131
Legacy Issue Number: 11164
Status: closed
Source: Student at IFI UIO Norway ( Tormod Vaksvik Håvaldsrud)
Summary:
Figure 9.3 : Is it riht that a connector can hold more than 2 ConnectorEnds? It is stated that it can hold: 2..*
Reported: SysML 1.0 — Fri, 20 Jul 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: Yes, it is possible that a connector have more than 2 ends, in case it is an n-way connector. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

"representation"

Key: UML22-1130
Legacy Issue Number: 11089
Status: closed
Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
Summary:
Classifier from Kernel packages has "representation" property of type InformationItem.
Classifier from Collaborations package has "representation" property of type CollaborationUse.

After package merge these properties conflict, one of them shall be renamed.
Reported: SysML 1.0 — Tue, 5 Jun 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

TimeEvent

Key: UML22-1138
Legacy Issue Number: 11409
Status: closed
Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
Summary:
TimeEvent has "when" property for time value.

13.3.27 TimeEvent

when: TimeExpression [1] Specifies the corresponding time deadline.

However in Figure 13.13 - SimpleTime Time Event has association with ValueSpecification.

Model shall correspond to text, so Figure 13.13 shall be fixed.
Reported: UML 2.1.1 — Fri, 14 Sep 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 14.5 - Messages.

Key: UML22-1137
Legacy Issue Number: 11401
Status: closed
Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
Summary:
Problem:
Only one MessageEnd could have the same Message as "message", because of multiplicity [0..1] near MessageEnd on association between Message and MessageEnd in Figure 14.5 - Messages.

Solution:
Change multiplicity [0..1] near MessageEnd on association between Message and MessageEnd to [0..2] in Figure 14.5 - Messages.
Reported: UML 2.1.1 — Thu, 13 Sep 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.7

Key: UML22-1140
Legacy Issue Number: 11625
Status: closed
Source: Volvo Technology Corporation ( Hans Blom)
Summary:
nestedClassifier should subset Namespace::ownedMember. There is no ownedMember in Element, i.e. Element::ownedMember is incorrect.
Reported: UML 2.1.1 — Mon, 22 Oct 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
This is a subset of the problem raised in issue 10829 Revised Text: N/A Disposition: Duplicate
Updated: Fri, 6 Mar 2015 20:58 GMT

Figures 9.4 identical to figure 9.3

Key: UML22-1139
Legacy Issue Number: 11524
Status: closed
Source: Anonymous
Summary:
Figures 9.4 should show the Port metaclass, but it is identical to Figure 9.3, Connectors
Reported: UML 2.1.1 — Fri, 28 Sep 2007 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: Fixed in an earlier release Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Flowing data into decision input behaviors

Key: UML22-1120
Legacy Issue Number: 10815
Status: closed
Source: Model Driven Solutions ( Mr. Ed Seidewitz)
Summary:
Document: Unified Modeling Language: Superstructure, Version 2.1.1 (formal/2007-02-03)
Sections: 12.3.22, DecisionNode

(This issue surfaced during work on the Semantics of a Foundational Subset for Executable UML Models submission.)

Background

There is no direct way to flow a supporting value into the decision input behavior of a decision node.

Suppose one wants to set up a decision node with a decision input behavior that, say, takes an object as an input and tests whether an attribute of that object has a certain value. Further, suppose that value is given by an input parameter of the enclosing activity. The value of the parameter is provided via an activity parameter node, but there is no direct way to connect an object flow from the activity parameter node to the test for the decision node.

Currently, a decision input behavior can only have a single input parameter, which will get the object flowing into the decision node that is to be tested. And, since it is a separate behavior from the enclosing activity, a flow from the enclosing activity can't be connected into the decision behavior. Of course, it would be possible to save the parameter value into an attribute of the enclosing activity, and then read that attribute in the decision behavior – but this seems awfully round about!

Note that there is no problem using a Conditional Node since, in that case, the test is not a separate behavior, and data can flow from the enclosing action into the test. It is just with (the supposedly simpler) Decision Node that there is a problem.

Proposal

Decision nodes may optionally have one additional incoming edge identified as the "decision input". If there is no decision input behavior, tokens offered on the decision input edge are made available to the guards on outgoing edges to determine whether the offer on the other incoming edge is passed along that edge. If there is a decision input behavior and a decision input edge, the token offered on the decision input edge is passed to the behavior (as the only argument if the regular incoming edge is control flow, as the second argument if it is object flow). Decision nodes with the additional decision input edge will offer tokens to outgoing edges only when one token is offered on each incoming edge.
Reported: UML 2.1 — Fri, 9 Mar 2007 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Adopt as proposed
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Composite Structures

Key: UML22-1119
Legacy Issue Number: 10814
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Figure 9.4 duplicates 9.3
Reported: UML 2.1.1 — Sat, 10 Mar 2007 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: Fixed in 2.1.2 Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

issue regarding required and provided interfaces

Key: UML22-1107
Legacy Issue Number: 10354
Status: closed
Source: International Business Machines ( James Bruck)
Summary:
There appears to be an issue with required and provided interfaces of Components in the UML2 Super Structure specification 2006-04-02 section 8.3.1., p.151 .

In the OCL and the paragraph discussing required and provided interfaces there is no mention of inheriting provided or required interfaces from the supertypes of the component.
Should we also consider required or provided interfaces of inherited ports?
Should we also consider supertypes of realizing classifiers?

The fact that Components don't consider supertypes is contrary to how Ports get required and provided interfaces on p187. Ports consider supertypes of the classifiers that type them when collecting required and provided interfaces.
Reported: UML 2.1 — Tue, 19 Sep 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2: Semantics of isOrdered need to be clarified

Key: UML22-1106
Legacy Issue Number: 10151
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
Text should read something like:

isOrdered : Boolean For a multivalued multiplicity, this
attribute specifies whether the values in an instantiation of this
element are maintained in the order that they where insertedsequentially
ordered. Default is false.
Reported: UML 2.1 — Fri, 1 Sep 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Actually, the original description is more general, since the ordering can be based on different ordering criteria, not just based on the order of insertion. Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Ptc/06-04-02/Pg 188

Key: UML22-1118
Legacy Issue Number: 10788
Status: closed
Source: The MathWorks ( Mr. Alan Moore)
Summary:
Where the spec currently says:

“If the port was typed by a class, the interaction point object will be an instance of that class. The latter case allows elaborate specification of the communication over a port. For example, it may describe that communication is filtered, modified in some way, or routed to other parts depending on its contents as specified by the classifier that types the port.”

Consider whether this should in fact be defined as a semantic variation point.
Reported: UML 2.1 — Tue, 27 Feb 2007 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Resolution: The dynamic semantics of a port, when it is typed by a class, is already a semantic variation point. Most of the text above is an example, rather than a definition of behavior. The only normative text above is that the interaction point object will be an instance of the type of the port, if the port is typed by a class. That aspect is currently used by tools to give dynamic semantics to ports in a domain-specific manner. If such is not desired, the modeler can always close the semantic variation point as to the meaning of this construct to behave as desired, e.g., to reduce to the case where the type of the port is an interface. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.32

Key: UML22-1117
Legacy Issue Number: 10783
Status: closed
Source: Airbus Group ( Mr. Yves Bernard)
Summary:
It should be possible to set the upperBound of a MultiplicityElement to 0 (it's currently forbidden by the constraint [1]). Example : if a class A is associated to a class B with a multiplicity of "0..*" (on the role of B). It should be possible to derive from the class A a class C of which the multiplicity of the role of B is always "0".
Reported: UML 2.1.1 — Wed, 21 Feb 2007 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

A notation for Trigger

Key: UML22-1116
Legacy Issue Number: 10777
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
Summary:
My new question is about the notation for Trigger. In on ehand, I understand the notation as described in section 13.3.31 (p. 475) for specifyng the trigger of a transition in a statemachine (even if it is not so clear because the notation for Trigger refers in fact to the notation of event (p475) ?). But how is it possible to describe the Trigger owned by a classifier? What is the notation for a class to specify which Trigger a class is owning?
In previous version of UML, it was clear in my head (it does no harm just this once that the description of the behavioral features (either Operations, or Receptions) of a class was implicitly the description of what kind of events a class may reponse to. But now, one hand a class specify its behavioral features, but what happen with its Triggers? Is the description of the behavioral features of a class the implicit description of its Triggers? But in this case, as Trigger are linked to Events, what is the need this intermediate concept of Triggers?
Reported: UML 2.1 — Thu, 15 Feb 2007 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: There is no notation for trigger independent of its specific notation in a behavioral feature. (Note that this notation reduces to the specific notation for the associated event.) For example, in state machines, a notation is defined for representing triggers on states or transitions. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Action semantic clarification

Key: UML22-1102
Legacy Issue Number: 9875
Status: closed
Source: Model Driven Solutions ( Mr. Ed Seidewitz)
Summary:
Action semantic clarification. In Activities, Action, Semantics, bullet [1], third sentence, after "offered", insert "all necessary".
Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
accepted
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities -StartClassifeirBehaviorAction and classifier behaviors

Key: UML22-1101
Legacy Issue Number: 9872
Status: closed
Source: Model Driven Solutions ( Mr. Ed Seidewitz)
Summary:
StartClassifeirBehaviorAction and classifier behaviors. StartClassifeirBehaviorAction should support passing values to the classifier behavior.
Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - isSingleExecution default

Key: UML22-1100
Legacy Issue Number: 9871
Status: closed
Source: Model Driven Solutions ( Mr. Ed Seidewitz)
Summary:
isSingleExecution default. Default of isSingleExecution is in text, but not in metamodel diagram.
Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
This is already resolved in UML 2.1.1 (formal/2007-02-03). Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Profile Structure Diagrams are missing from Annex A

Key: UML22-1105
Legacy Issue Number: 10044
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
Section 18.4 describes what are called "Structure Diagrams" for depicting profiles, stereotypes and their associated metaclasses.
However such diagrams are not included in the Normative Appendix A (Figure A.5 does show 'Structure Diagram' but only as an abstract diagram type).

Proposed resolution:
For clarity use the term 'Profile Diagram in section 18.4
Add Profile Diagram to Annex A as a 14th UML2 Diagram Type.
Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Missing inheritance in 9.3.12

Key: UML22-1104
Legacy Issue Number: 10000
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
Figure 9.2 shows that Property inherits from ConnectableElement - which is not included in the Generalizations section of 9.3.12 (though it is in the metamodel
Reported: SysML 1.0b1 — Wed, 26 Jul 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
The submitter is correct; see revised text.
Updated: Fri, 6 Mar 2015 20:58 GMT

No default value specified for Generalization::isSubstitutable

Key: UML22-1103
Legacy Issue Number: 9963
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
No default value specified for Generalization::isSubstitutable.
This is the only Boolean attribute in the whole specification without a default value
Reported: SysML 1.0b1 — Tue, 25 Jul 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
For consistency and correctness, add a default value as the summary mentions.
Updated: Fri, 6 Mar 2015 20:58 GMT

consistent descriptions of semantics of event consumption needed

Key: UML22-1115
Legacy Issue Number: 10776
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Pr. Dr. François Terrier)
Summary:
make consistent the descriptions of semantics of event consumption in section 13.3.4 and in section 13.3.2
Reported: UML 2.1 — Thu, 15 Feb 2007 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Section 13.3.2 is generic and does not define details of the semantics of event consumption. In fact it states that this is handled by BehavioredClassifier, section 13.3.4. I do not see any inconsistency between these two sections. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

section 13.3.2 doc ptc/2006-04-02, v.2.1

Key: UML22-1114
Legacy Issue Number: 10775
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Pr. Dr. François Terrier)
Summary:
Issue a: ) in behaviour description (section 13.3.2 doc ptc/2006-04-02, v.2.1) precise more formally and explicitely which elements can have behaviors, and how the behavior context is defined.

Typically clarification should say something like:
- [A] Any subclasses of BehavioredClassifier (that is: Collaboration, Class, Actor, UseCase) can have a Behavior and its context is defined through the “context” association
- [B] Any subclasses of BehavioralFeature (that is: xxx to be listed xxx) can have a Behavior and its context is defined through the “specification” association
- [C] Additionally, Transitions and States can have a Behavior and its context is defined by the first BehavioredClassifier reached through their “owned” relation
- [D] A Behavior can stand alone and be its own context (e.g. as equivalent to a C/C++ program)
è Is it here necessary to add a context association from the Behavior to itself? or should we consider that in this case it is always owned by a modelling element (eg a package) that defines its context and should we explicitly define to which kind of element this can be considered and add these elements to the list of the [C] situation ?
Reported: UML 2.1 — Thu, 15 Feb 2007 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: The issue is somewhat confusing in its wording when it asks what “elements can have behaviors”. In one reading, only BehavioredClassifier can have behaviors. Probably the issue means to ask what “elements can own behaviors”. It would be not in the style of the UML specification to summarize in a central location such information, as this would conflict with the object-oriented style of the specification, or it would cause a maintenance difficulty. Behavior::context clearly defines how the context object is determined, independent of the type of behavior or its owner. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Uses notation "Subsets Element::ownedElement" and similar

Key: UML22-1113
Legacy Issue Number: 10731
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
Uses notation "Subsets Element::ownedElement" and similar. I believe this should be "Element.ownedElement", as :: is a separator for path. Please check the document throughout.
Reported: UML 2.1.1 — Wed, 14 Feb 2007 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: In one of the earlier revisions, the decision was made to use the “::” operator as a qualifier and not the “.” operator. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

UML2: Behavior without a specification should not be a classifier behavior

Key: UML22-1112
Legacy Issue Number: 10655
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
Section 13.3.3, in the description of Behavior::specification says: "If a behavior does not have a specification, it is directly associated with a classifier (i.t., it is the behavior of the classifier as a whole."

This appears to be incorrect. Assuming the "associated classifier" is the context Classifier: a Behavior might not be an ownedBehavior of any Classifier and has no context. For example, and Activity in a Package. Such a Behavior could not have a specification, but is not the behavior of any associated classifier.

An ownedBehavior of a context Classifier can be explicitly designated as the behavior of the classifier using the BehavioredClassifier::classifierBehavior property. So there should be no need to define implicit classifier behaviors.

Finally, a BehavioredClassifier might contain any number of ownedBehaviors that factor out reusable, private functions that are used in the implementations of other ownedBehaviors. These behaviors could be invoked using CallBehaviorActions and do not need specification operations. These behaviors would need a parameter for self if they need to refer to information in the context classifier.
Reported: UML 2.1 — Fri, 9 Feb 2007 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
The issue correctly points to that the text in Behavior::specification is misleading
Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 13.8 shows the wrong diagram

Key: UML22-1109
Legacy Issue Number: 10469
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
diagrams for UML 2.1.1 - Figure 13.8 shows the wrong diagram
Reported: UML 2.1 — Wed, 22 Nov 2006 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This was fixed in an earlier release. Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.25

Key: UML22-1108
Legacy Issue Number: 10383
Status: closed
Source: Bergson Technology ( Marc Hamilton)
Summary:
SignalEvent notation interpretes Signal as an Operation. Details: A SignalEvent is associated to a Signal. The notation of SignalEvent contains an <assignment-specification> that consists of a list of <attr-name>. Quote: "<attr-name> is an implicit assignment of the corresponding parameter of the signal to...". Signal is however a Classifier and has no parameters. Either Signal should be an Operation or the notation of SignalEvent must utilize the explicit assignment of "corresponding attributes of the signal". In the latter case, this assignment should include the attribute name of the signal since the attributes of a Classifier are not ordered.
Reported: UML 2.1 — Fri, 6 Oct 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
The issue is correct. What is meant was the attributes of the signal
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13 SimpleTime

Key: UML22-1111
Legacy Issue Number: 10643
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
What the time model needs is the concept of an optional time reference that can be attached to a time observation (e.g. to model a spacecraft/ground station situation). The MARTE profile has done some excellent work on this and it should be taken into account when resolving the issue
Reported: UML 2.1.1 — Mon, 5 Feb 2007 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Resolution: The simple time model is just that: a very simple model to attach time specifications to observations, for example. When a more sophisticated handling of time is required, profiles such as the MARTE profile should be used. The proposal is not to attempt to enhance the simple time model but only fix problems with that model. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.2

Key: UML22-1110
Legacy Issue Number: 10513
Status: closed
Source: UFRJ (Federal Uniersity of Rio de Janeiro) ( Felipe Gomes Dias)
Summary:
In the UML Superstructure 2.1 available in the download section, the picture 13.8 is the same as the picture 13.7, in the page 463 of the document. The picture 13.8 should be explaining about the classes "Behavior" and "Constraint", as shown in the UML Superstructure 2.0 version.
Reported: UML 2.1 — Fri, 15 Dec 2006 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: Fixed in an earlier release; also duplicate of10469 Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

UML2: No notation for BehavioredClassifier::ownedTrigger

Key: UML22-1084
Legacy Issue Number: 9407
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
UML2 provides a number of different ways to initiatiate execution of some behavior, and for specifying what behaviors are offered for invocation. Behaviors provide a realization of these specifications.

The simplest is a BehavioredClassifier can respond to invocations of its ownedBehaviors through a CallOperationAction. The ownedBehavior is a method of a specification Operation which defines the client interface, external view, signature, contract (whatever one likes to call it) of the behavior.

If the ownedBehavior is an Activity, then the activity may contain any number of AcceptEventAction or AcceptCallAction/ReplyAction actions to enable the activity to control when and how additional behavior may be invoked by clients in the context of some broader, perhaps long-running activity. Both AcceptEventAction and AcceptCallAction have trigger: Triger properties whose event: Event could be a SignalEvent or CallEvent respectively. A BehavioredClassifier should indicate to clients its ability to receive the corresponding SignalEvent or CallEvent by including an ownedTrigger designating the event it is prepared to receive.

However, there is no notation specified for BehavioredClassifier::ownedTrigger. In addition, there are other ways to specify the ability to receive signal and/or call events that may make ownedTrigger redundant. The ability to receive a SignalEvent can be denoted by an ownedReception: Reception in a Class. The notation for an ownedReception is a <<signal>> Operation where the operation name is the Signal name, and the in parameters provide the values for the signal's ownedAttributes. There can be no inout, out, or return parameters, and no raisedExceptions. An ownedOperation is all that is needed to indicate the ability to receive a CallEvent.

The metamodel for ownedTrigger needs to be reconciled with ownedOperation and ownedReception. Perhaps the notation should provide a way to distinguish operations that invoke behaviors and operations that indicate the ability to respond to call events as <<trigger>> operations.
Reported: UML 2.0 — Wed, 1 Mar 2006 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: A classifier declares its “willingness” to handle events by its behavioral features. Currently there are two such features: Operations and Receptions. The former declares that the classifier will handle call events, the latter that the classifier handles signal events. These are the only kinds of events that can be caused by other objects. The issue requests another mechanism to accomplish the same thing without explaining why a second mechanism is required to accomplish what behavioral features already accomplishing. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2/Templates -- single argument?

Key: UML22-1083
Legacy Issue Number: 9398
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
A TemplateParameterSubstitution corresponds to exactly one template parameter, but the metamodel allows multiple actual arguments to be supplied for the parameter. There does not seem to be any compelling reason for multiple arguments to be provided for a single template parameter in a substitution (nor are the semantics of this clearl). Therefore, the multiplicity of TemplateParameterSubstitution::actual and Template ParameterSubstitution::ownedActual should be restricted to [1].
Reported: UML 2.0 — Fri, 24 Feb 2006 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Use the new 'dot' notation in examples

Key: UML22-1082
Legacy Issue Number: 9373
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
Currently there is only one example of its use. However most of the examples have taken an unadorned line to indicate that both ends are owned by the respective classes: now the same diagram indicates both ends are owned by the association. Though tools may be at liberty to hid the adornments the spec itself should be extremely precise in the examples and show the adornments explicitly since otherwise the diagrams are ambiguous.
Note that the conventions in 6.5.2 explicitly apply only to the diagrams for the metamodel itself (see line 1 of 6.5.2).
Reported: UML 2.0 — Thu, 23 Feb 2006 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
This is a duplicate of issue 9372
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Join node edge constraint

Key: UML22-1099
Legacy Issue Number: 9867
Status: closed
Source: Model Driven Solutions ( Mr. Ed Seidewitz)
Summary:
Join node edge constraint. Join node should have a constraint between the incoming and outgoing flow kinds (control vs data).
Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Constraint [2] in Section 12.3.34 (JoinNode) of formal/2007-02-03 already says “If a join node has an incoming object flow, it must have an outgoing object flow, otherwise, it must have an outgoing control flow.” Since the intent is to allow a join node to have both incoming control and object flows, it is not clear what other constraint might be needed. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Offer ordering on joins

Key: UML22-1098
Legacy Issue Number: 9866
Status: closed
Source: Model Driven Solutions ( Mr. Ed Seidewitz)
Summary:
Offer ordering on joins. Is the ordering of offers from joins the same as they were offered to the join?
Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
According to the Semantics in Section 12.3.34 (JoinNode) of formal/2007-02-03: “Tokens are offered on the outgoing edge in the same order they were offered to the join.” Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Multiple activity parameters nodes for a single inout

Key: UML22-1097
Legacy Issue Number: 9865
Status: closed
Source: Model Driven Solutions ( Mr. Ed Seidewitz)
Summary:
Multiple activity parameters nodes for a single inout. Can there be multiple activity parameters nodes for a single inout parameter? If not, the node will have both incoming and outgoing edges, which violates constraint [3] of ActivityParameterNode.
Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
There is nothing that prevents a single inout parameter having multiple activity parameter nodes, one with outgoing flows and one with incoming flows. Further, the semantics for activity parameter nodes deals with this case consistently. However, there are actually no limits on the number of activity parameter nodes for a parameter at all, without clear semantics for the general case.
Updated: Fri, 6 Mar 2015 20:58 GMT

A notation for Trigger

Key: UML22-1088
Legacy Issue Number: 9750
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
Summary:
My new question is about the notation for Trigger. In on ehand, I understand the notation as described in section 13.3.31 (p. 475) for specifyng the trigger of a transition in a statemachine (even if it is not so clear because the notation for Trigger refers in fact to the notation of event (p475) ?). But how is it possible to describe the Trigger owned by a classifier? What is the notation for a class to specify which Trigger a class is owning?
In previous version of UML, it was clear in my head (it does no harm just this once that the description of the behavioral features (either Operations, or Receptions) of a class was implicitly the description of what kind of events a class may reponse to. But now, one hand a class specify its behavioral features, but what happen with its Triggers? Is the description of the behavioral features of a class the implicit description of its Triggers? But in this case, as Trigger are linked to Events, what is the need this intermediate concept of Triggers?
Reported: SysML 1.0b1 — Thu, 18 May 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
This issue is an identical duplicate, submitted by the same author, as issue 10777
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.13 - connectors

Key: UML22-1087
Legacy Issue Number: 9619
Status: closed
Source: Unisys ( Paul Koerber)
Summary:
Connectors cannot be properly represented in a UML model using only constructs available in Compliance Level 1. The Connector class is part of the InternalStructures package which is in Level 1. The class that can own Connectors is StructuredClassifier through the ownedConnector association. This class is also in Level 1 but is abstract. All non-abstract subclasses of StructuredClassifer (such as Collaboration and EncapsulatedClassifier) are in Level 2. Because of this there is no class that can own Connector instances in a model that uses only Level 1 constructs. Therefore Connectors can’t be used in a Level 1 compliant model
Reported: UML 2.1 — Mon, 8 May 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Resolution: This was a decision made in the design of UML 2. A tool that wants to offer internal structure with only compliance level 1 would have to at least define a profile that introduces a concrete subtype of StructuredClassifier. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Semantics of fork node wording

Key: UML22-1096
Legacy Issue Number: 9864
Status: closed
Source: Model Driven Solutions ( Mr. Ed Seidewitz)
Summary:
Semantics of fork node wording. The semantics for fork node should say it copies the tokens onto outgoing edges. The wording currently used is the same as initial node and decision node, which do not copy tokens ("offered to all outgoing edges")
Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
The Semantics for ForkNode (formal/2007-02-03, Section 12.3.30) begins: “Tokens arriving at a fork are duplicated across the outgoing edges.” The fact that tokens are duplicated by a fork node is emphasized several times in the subsequent text. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

ReadLinkAction

Key: UML22-1095
Legacy Issue Number: 9859
Status: closed
Source: Model Driven Solutions ( Mr. Ed Seidewitz)
Summary:
ReadLinkAction. In Actions, ReadLinkAction, Semantics, second paragraph, before the fourth sentence (the one starting "The multiplicity of"), add the sentence "The order of the retrieved values in the output pin is the same as the ordering of the values of the links." This aligns with the text added to ReadStructuralFeatureAction and ReadVariableAction by issue 8036 in the UML 2.1 RTF.
Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
accepted
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Weight notation

Key: UML22-1094
Legacy Issue Number: 9857
Status: closed
Source: Model Driven Solutions ( Mr. Ed Seidewitz)
Summary:
Weight notation. In Activities, ActivityEdge, Notation, Package CompleteActivities subheading, the text in the first paragraph about weight notation is inconsistent with the figure below it.
Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Correct text as below
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Weight description

Key: UML22-1093
Legacy Issue Number: 9856
Status: closed
Source: Model Driven Solutions ( Mr. Ed Seidewitz)
Summary:
Weight description. In Activities, Attribute and Semantics sections, the description of weight in these are not the same. Should be as in the Semantic section.
Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Fix the Associations and Semantics headings under Section 12.3.5, ActivityEdge
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

Key: UML22-1092
Legacy Issue Number: 9855
Status: closed
Source: Model Driven Solutions ( Mr. Ed Seidewitz)
Summary:
StructuredActivityNode. In Activities, StructuredActivityNode, Semantics, Package CompleteStructuredActivities subheading, first sentence, replace "An object node attached to" with "The contents of an input pin of".
Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
The remainder of the paragraph discusses both input and output pins on structured activity nodes. Both input and output pins are “accessible” within the structured activity node, in the sense that data can flow out of the input pin and into the output pin. Thus, the sentence should refer to all pins, not just input pins.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.11

Key: UML22-1091
Legacy Issue Number: 9821
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
Summary:
Semantics of ports needs to be define with regard to interfaces having attributes and associations
Reported: UML 2.1.1 — Mon, 12 Jun 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Attributes and associations of interfaces do not affect the semantics of ports, and thus, no further definition is required. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.11

Key: UML22-1090
Legacy Issue Number: 9814
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
Summary:
Could you clarify the semantics of port according to its visibility property, i.e. clarify the following sentence: "A port by default has public visibility. However, a behavior port may be hidden but does not have to be."
Reported: UML 2.1.1 — Fri, 9 Jun 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
The last sentence was added to clarify that a port is not necessarily public, and to highlight that often behavior ports are hidden. However, as the issue submitter points out, that “clarification” is probably more confusing than it is worth. It would be better placed in the description section, but that would require explaining behavior port there. Best to drop.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.2

Key: UML22-1089
Legacy Issue Number: 9813
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
Summary:
In Figure 9.4, the role name "required" of the association between Port and Interface is not at the right place.
Reported: UML 2.1.1 — Fri, 9 Jun 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Resolution: In the current version of the spec, the name is at the correct place. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.24 Signal (from Communications)

Key: UML22-1086
Legacy Issue Number: 9576
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Replace signal: Signal [1] The signal that is associated with this event. with * ownedAttribute: Property[*] The owned attributes of the signal
Reported: UML 2.1.1 — Sun, 16 Apr 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

page 467, Section 13.3.24

Key: UML22-1085
Legacy Issue Number: 9514
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
On page 467, Section 13.3.24, a Signal is said to have one association:

signal : Signal[1] The signal that is associated with this event.

I don't understand this. A signal is associated with another signal?
Which one? Why? Could that be incorrect?

Perhaps a cut-and-paste error, because on the same page, Section 13.3.25,
a SignalEvent is said to have one association:

signal : Signal[1] The specific signal that is associated with
this event.
Reported: UML 2.0 — Wed, 5 Apr 2006 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Duplicate of issue 9576
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Superstructure / CommonBehaviors / Incorrect types in text

Key: UML22-1081
Legacy Issue Number: 9352
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
TimeConstraint::specification and DurationConstraint::specification properties are shown as having the wrong type in the text (the diagrams are OK). They should be TimeInterval and DurationInterval respectively.
Reported: UML 2.0 — Thu, 2 Feb 2006 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Resolution: This issue has been resolved in an earlier version of the specification. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

7.3.41 Parameter (from Kernel, AssociationClasses)"

Key: UML22-1080
Legacy Issue Number: 9337
Status: closed
Source: Anonymous
Summary:
Please note however, that (as far as I can see) Parameter only occurs in Kernel, NOT in AssociationClasses. So the correct statement would be "Parameter (from Kernel). This might bear a relation to the already existing FTF issue 8117.
Reported: UML 2.0 — Mon, 30 Jan 2006 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 issue: ownedMember xsi:type="uml:Stereotype" should be used

Key: UML22-1063
Legacy Issue Number: 9185
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
ownedMember xsi:type="uml:Stereotype" should be used in XMI instance documents instead of ownedStereotype xsi:type="uml:Stereotype" (especially if it becomes a derived subset).
Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0: CMOF/UML mixup for profiles

Key: UML22-1062
Legacy Issue Number: 9184
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
The end of the semantics section for Profiles informally describes a CMOF model equivalent to a Profile. This discussion in the spec about profiles and equivalent MOF metamodels could be confusing and potentially misleading. A profile is an instance of a UML2 model which is not a CMOF model. Therefore the MOF to XMI mapping rules do not apply for instances of a profile. The equivalent CMOF model is a means to explain and formalize how profiles are serialized and exchanged as XMI. The spec should make it clear that the equivalent MOF model is a model-to-model mapping being introduced as a means for describing how a profile is serialized and exchanged using XMI and how an XSD schema for validating instances of a profile is defined.

The mapping from a profile to a CMOF model is incomplete. For example, there is no statement that an instance of a stereotype maps to an instance of a CMOF::Class. This mapping needs to be completed; e.g., by direct reference

The Profile to CMOF mapping also needs to specify the XMI tags for persisting and exchanging profiles. According to the UML2 metamodel, instances of a Profile can't have Tags because an instance of a Profile is not a CMOF::Element, UML2 is not reflective. Tools will have to provide tag support for instances of stereotypes some other way. These properties can be left undefined and tools can provide values as needed. Another possible solution would be to specify how the XMI tag values and options for profile exchange would be defined, perhaps derived from other information in the profile. For example:
nsURI = http://<profilePackagePath>/schemas/<profileName>.xmi
nsPrefix = <profileName>
all others use the XMI defaults
Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Required attributes

Key: UML22-1069
Legacy Issue Number: 9191
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
Required attributes (i.e. those with a lower bound greater than 0) without a specified default must either be assigned a default or made non-required (see below). There should also be a statement in the specification to the effect that attributes whose values are set to their default need not be serialized.

uml::Artifact::fileName is required, default is <unspecified>

uml::Behavior::isReentrant is required, default is <unspecified>

uml::BehavioralFeature::concurrency is required, default is <unspecified>
uml::BehavioralFeature::isAbstract is required, default is <unspecified>

uml::Class::isActive is required, default is <unspecified>

uml::CombinedFragment::interactionOperator is required, default is <unspecified>

uml::Comment::body is required, default is <unspecified>

uml::ConditionalNode::isAssured is required, default is <unspecified>
uml::ConditionalNode::isDeterminate is required, default is <unspecified>

uml::DeploymentSpecification::deploymentLocation is required, default is <unspecified>
uml::DeploymentSpecification::executionLocation is required, default is <unspecified>

uml::ElementImport::visibility is required, default is <unspecified>

uml::ExpansionRegion::mode is required, default is <unspecified>

uml::Expression::symbol is required, default is <unspecified>

uml::GeneralizationSet::isCovering is required, default is <unspecified>
uml::GeneralizationSet::isDisjoint is required, default is <unspecified>

uml::LiteralBoolean::value is required, default is <unspecified>

uml::LiteralInteger::value is required, default is <unspecified>

uml::LiteralString::value is required, default is <unspecified>

uml::LiteralUnlimitedNatural::value is required, default is <unspecified>

uml::LoopNode::isTestedFirst is required, default is <unspecified>

uml::Message::messageKind is required, default is <unspecified>
uml::Message::messageSort is required, default is <unspecified>

uml::Model::viewpoint is required, default is <unspecified>

uml::OpaqueAction::body is required, default is <unspecified>

uml::OpaqueBehavior::body is required, default is <unspecified>

uml::OpaqueExpression::body is required, default is <unspecified>

uml::PackageableElement::visibility is required, default is <unspecified>

uml::PackageImport::visibility is required, default is <unspecified>

uml::Pseudostate::kind is required, default is <unspecified>

uml::State::isComposite is required, default is <unspecified>
uml::State::isOrthogonal is required, default is <unspecified>
uml::State::isSimple is required, default is <unspecified>
uml::State::isSubmachineState is required, default is <unspecified>

uml::StructuredActivityNode::mustIsolate is required, default is <unspecified>

uml::TimeEvent::isRelative is required, default is <unspecified>

uml::Transition::kind is required, default is <unspecified>
Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter::effect

Key: UML22-1068
Legacy Issue Number: 9190
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
Parameter::effect is documented in the specification as having multiplicity 0..* (instead of 0..1 - this should have been addressed as part of Issue 8261).
Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.1 XMI Issue

Key: UML22-1065
Legacy Issue Number: 9187
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
uml::EncapsulatedClassifier::ownedPort should be derived (from the owned attributes that are instances of Port) so as to be consistent with Package::ownedType, Package::nestedPackage, and Profile::ownedStereotype (see issue 9181).
Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0: Inconsistencies in profile example XMI

Key: UML22-1064
Legacy Issue Number: 9186
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
In the Home Example for Profiles in chapter 18, the body of the text and the examples use different conventions for naming ExtensionEnds "base$Interface", "base_Interface", and "baseInterface" all appear in various places. The spec says it should be base$Interface (although this is not a valid identifier in many common programming languages including Java).
Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

parameter of operation isRedefinitionContextValid() is inconistently named

Key: UML22-1073
Legacy Issue Number: 9195
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
The parameter of operation isRedefinitionContextValid() is inconistently named in the specification, which in turn cause package merge problems (parameters do not match). The parameter should be consitently named 'redefined', and the OCL for the associated constraints updated accordingly.
Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Compliance package L2 does not merge StructuredActions in the metamodel

Key: UML22-1072
Legacy Issue Number: 9194
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
Compliance package L2 does not merge StructuredActions in the metamodel. Also, CompleteActions (merged by L3) does not currently merge StructuredActions.

In general, higher compliance levels should merge lower compliance levels; the merge relationships in the specification should be reorganized to reflect this.
Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Resolved by the solution to issue 9182
Updated: Fri, 6 Mar 2015 20:58 GMT

The following properties should not subset DirectedRelationship::target

Key: UML22-1071
Legacy Issue Number: 9193
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
The following properties should not subset DirectedRelationship::target since they subset Dependency::supplier, which already subsets DirectedRelationship::target:

ComponentRealization::realizingClassifier
Deployment::deployedArtifact
InterfaceRealization::contract
Manifestation::utilizedElement
Substitution::contract
Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

The following properties should not subset DirectedRelationship::source

Key: UML22-1070
Legacy Issue Number: 9192
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
The following properties should not subset DirectedRelationship::source since they subset Dependency::client, which already subsets DirectedRelationship::source:

ComponentRealization::abstraction
Deployment::location
InterfaceRealization::implementingClassifier
Substitution::substitutingClassifier
Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Artifact::fileName

Key: UML22-1067
Legacy Issue Number: 9189
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
Artifact::fileName appears in the metamodel but is not documented in the specification.
Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

uml::Extension::ownedEnd should not subset uml::Association::ownedEnd

Key: UML22-1066
Legacy Issue Number: 9188
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
uml::Extension::ownedEnd should not subset uml::Association::ownedEnd since it already (implicitly) redefines it.

There should be a constraint that states that it is invalid for a property to subset a property with the same name.
Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 12.18: Small typo: "subsets ownedMember" not "ownedmember"

Key: UML22-1079
Legacy Issue Number: 9235
Status: closed
Source: LIANTIS GmbH ( Constantin Szallies)
Summary:
Figure 12.18: Small typo: "subsets ownedMember" not "ownedmember"
Reported: UML 2.0 — Mon, 12 Dec 2005 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This was resolved in some previous revision. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 161

Key: UML22-1078
Legacy Issue Number: 9232
Status: closed
Source: LIANTIS GmbH ( Constantin Szallies)
Summary:
Figure 9.7: property "representation" subsets "collaborationUse" not "occurrence"? "Classifier" has no property named "occurrence"!
Reported: UML 2.0 — Mon, 12 Dec 2005 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This issue has already been fixed in the current version of the specification. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Issue regarding "Action::effect : String"

Key: UML22-1075
Legacy Issue Number: 9197
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
What has become of the dropped property : "Action::effect : String" ? ( referenced in Ballot 7319 )
Reported: UML 1.3 — Thu, 30 Nov 2000 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Transition guards cannot currently be evaluated because they have no contex

Key: UML22-1074
Legacy Issue Number: 9196
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
Transition guards cannot currently be evaluated because they have no context. Transition should be made a specialization of Namespace and Transition::guard should subset Namespace::ownedRule
Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

StateMachine::extendedStateMachine should have a multiplicity of 0..*.

Key: UML22-1077
Legacy Issue Number: 9224
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
StateMachine::extendedStateMachine should have a multiplicity of 0..*. It currently does in the text, but it is shown with a multiplicity of 0..1 in Figure 15.3.
Reported: UML 2.0 — Thu, 8 Dec 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Behavior::context

Key: UML22-1076
Legacy Issue Number: 9198
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
Behavior::context is derived (ensure that this is indicated in the diagram and the text); it should also be read-only.
Reported: UML 2.0 — Thu, 1 Dec 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 issue: Package Primitive Types not merged

Key: UML22-1058
Legacy Issue Number: 9180
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
Package PrimitiveTypes is not merged into UML2 and there is no nsURI for InfrastructureLibrary. So there's no way to reference UML primitive types in any UML2 model including profiles. Resolve by merging PrimitiveType into L0.
Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix A: Diagrams

Key: UML22-1057
Legacy Issue Number: 9179
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
There's no diagram kind for deployment diagrams
Reported: UML 2.0 — Sat, 26 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.1 of ptc/04-10-14

Key: UML22-1056
Legacy Issue Number: 9146
Status: closed
Source: Red Hat ( John Verhaeg)
Summary:
Page 13 of section 7.2.1 of the "Unified Modeling Language (UML) Specification: Infrastructure" (ptc/04-10-14) states:

"There are minor differences in the design rationale for the other two packages."

There are actually 4 packages being discussed, with the first being PrimitiveTypes. So, either "two" should be changed to "three" when referring to the "other" packages, or the two packages (amongst the "other" three being discussed) containing the "minor differences in design rationale" should be identified.
Reported: UML 2.0 — Thu, 10 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.36 Operation

Key: UML22-1055
Legacy Issue Number: 9143
Status: closed
Source: Paranor AG ( Earl Waldin)
Summary:
The BNF for the textual specification of an operation does not allow one to specify the multiplicity of an operation's return type. The current BNF is [<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’ [‘:’ [<return-type>] ‘
{‘ <oper-property> [‘,’ <oper-property>]* ‘}’] It should allow the multiplicity to be specified in a manner similar to that for a property. For example: [<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’ [‘:’ [<return-type>] [‘[‘ <multiplicity> ‘]’] ‘{‘ <oper-property> [‘,’ <oper-property>]* ‘}
’]
Reported: UML 2.0 — Tue, 8 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8 Issue - Component Realization-Classifier multiplicity

Key: UML22-1054
Legacy Issue Number: 9142
Status: closed
Source: Cutter Information ( Oliver Sims)
Summary:
Issue: The multiplicity on the relationship from Realization to Classifier is 1. This seems wrong - it should be 1 or more.

Rationale:
A component realization consisting of only a single classifier would be very odd - although not impossible for a Hello World component perhaps.
Reported: UML 2.0 — Sat, 10 Sep 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions, Figure 156

Key: UML22-1053
Legacy Issue Number: 9123
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Figure 156, I think LinkEndCreationData and QualifierValue aren't supposed to be on this diagram: - The associations to/from these aren't in the entries for CreateLinkObjectAction of LinkEndCreationData, - endData is inherited from CreateLinkAction and isn't changed. - The qualifier association would clash with the one inherited fromn LinkEndData in CompleteActivities. There is nothing in the spec on why qualifier is specialized this way. - The multiplicity on qualifier would require qualifiers, even when there aren't any.
Reported: UML 2.0 — Thu, 27 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.1 Regressions

Key: UML22-1052
Legacy Issue Number: 9122
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
The following regressions were introduced in ballot 10:

Issue 8134

DeployedArtifact should NOT specialize Kernel::NamedElement since it already specializes Dependencies::NamedElement, and adding a redundant generalization violates the uniqueness constraint on Classifier::general (in the merged result).

Issue 8136

DeploymentSpecification should NOT specialize Artifacts::Artifact since it already specializes Nodes::Artifact, and adding a redundant generalization violates the uniqueness constraint on Classifier::general (in the merged result).

Issue 8457

The proposed new Figure 124 introduces an undesired (generalization) dependency between Kernel and Dependencies. The preferred resolution would be for Artifact (not Kernel::Namespace) to specialize Dependencies::NamedElement. Figure 124 should be:

The proposed new Figure 77 introduces an undesired (generalization) dependency between Kernel and Dependencies. The preferred resolution would be for Component (not Kernel::Namespace) to specialize Dependencies::NamedElement. Figure 77 should be:

Issue 8468

UseCase::extend must NOT subset Classifier::feature because Extend is not a specialization of Feature. Likewise, UseCase::include must NOT subset Classifier::feature because Include is not a specialization of Feature.
Reported: UML 2.0 — Thu, 27 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
agreed
Updated: Fri, 6 Mar 2015 20:58 GMT

Realization classifier

Key: UML22-1051
Legacy Issue Number: 9119
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
The Realization classifier should not be redefined in UML::Components::BasicComponents. In a component realization, the direction of the dependency is reversed, i.e. the client (source) of the dependency is the component abstraction and the supplier (target) of the dependency is the realizing classifier; this conflicts with other specializations of Realization (e.g. InterfaceRealization).

-> A new specialization ('ComponentRealization') should be introduced instead, upon which the 'abstraction' and 'realizingClassifier' properties would be defined. This could be achieved by simply renaming Realization to 'ComponentRealization' in UML::Components::BasicComponents and adding a generalization from it to UML::Classes::Dependencies::Realization.
Reported: UML 2.0 — Wed, 26 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 issue: redefining isComposite on association ends

Key: UML22-1050
Legacy Issue Number: 9117
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
The association ends IntervalConstraint::specification, TimeConstraint::specification, and DurationConstraint::specification should be composite, since, redefining an isComposite = true property with one where isComposite = false causes problems in the XMI generation. More on isComposite redefinition : 1) LinkEndCreationData::qualifier should be composite.

2) It should be considered inconsistent for a non-composite property to redefine a composite property. The body expression for Property::isConsistentWith(RedefinableElement) should be updated as follows:
This should probably be disallowed in general.
Reported: UML 2.0 — Thu, 27 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Classifier::parameter, Operation::parameter, and ConnectableElement::parame

Key: UML22-1049
Legacy Issue Number: 9110
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
Classifier::parameter, Operation::parameter, and ConnectableElement::parameter should be renamed to templateParameter (they redefine ParameterableElement::templateParameter) to make it clear that these are template parameters (in fact not related to the Parameter metaclass). ParameterableElement::owningParameter should also be renamed to owningTemplateParameter, for consistency.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
agreed
Updated: Fri, 6 Mar 2015 20:58 GMT

Component::realization should NOT be derived

Key: UML22-1048
Legacy Issue Number: 9109
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
Component::realization should NOT be derived
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Rename ActivityGroup::activity to containingActivity

Key: UML22-1047
Legacy Issue Number: 9108
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
StructuredActivityNode inherits two properties with the same name, ActivityNode::activity and ActivityGroup::activity.

-> Rename ActivityGroup::activity to containingActivity.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Rename OpaqueAction::output to outputPin.

Key: UML22-1046
Legacy Issue Number: 9107
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
OpaqueAction::output (non-derived) invalidly redefines Action::output (derived union).

-> Rename OpaqueAction::output to outputPin.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Make ActivityGroup::containedNode a derived union

Key: UML22-1045
Legacy Issue Number: 9106
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
ActivityNode::inGroup is a derived union but its opposite, ActivityGroup::containedNode, is not.

-> Make ActivityGroup::containedNode a derived union. As a result, ActivityPartition::containedNode, StructuredActivityNode::containedNode, and InterruptibleActivityRegion::containedNode will invalidly redefine ActivityGroup::containedNode, so rename ActivityPartition::containedNode to node, rename StructuredActivityNode::containedNode to ownedNode, rename InterruptibleActivityRegion::containedNode to node, and replace
{redefines containedNode}
with
{subsets containedNode}
on all three.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Make ActivityGroup::containedEdge a derived union

Key: UML22-1044
Legacy Issue Number: 9105
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
ActivityEdge::inGroup is a derived union but its opposite, ActivityGroup::containedEdge, is not.

-> Make ActivityGroup::containedEdge a derived union. As a result, ActivityPartition::containedEdge and StructuredActivityNode::containedEdge will invalidly redefine ActivityGroup::containedEdge, so rename ActivityPartition::containedEdge to edge, rename StructuredActivityNode::containedEdge to ownedEdge, and replace
{redefines containedEdge}
with
{subsets containedEdge}
on both.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

compliance levels L2 and L3

Key: UML22-1039
Legacy Issue Number: 9098
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
In (merged) compliance levels L2 and L3, ExtensionEnd::lower (non-derived) invalidly redefines feature MultiplicityElement::lower (derived).

-> Either remove this redefinition (of the default value) or add a Profiles package to UML and redefine ExtensionEnd::lower to be derived.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Change type of WriteStructuralFeatureAction::value to ValueSpecification

Key: UML22-1038
Legacy Issue Number: 9097
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
TimeObservationAction::now (type TimeExpression) invalidly redefines WriteStructuralFeatureAction::value (type InputPin) because TimeExpression is not a specialization of InputPin.

-> Change type of WriteStructuralFeatureAction::value to ValueSpecification?
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Change type of WriteStructuralFeatureAction::value

Key: UML22-1037
Legacy Issue Number: 9096
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
DurationObservationAction::duration (type Duration) invalidly redefines WriteStructuralFeatureAction::value (type InputPin) because Duration is not a specialization of InputPin.

-> Change type of WriteStructuralFeatureAction::value to ValueSpecification?
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0: separate profile application from profile importing

Key: UML22-1061
Legacy Issue Number: 9183
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
Package::appliedProfile should not subset packageImport. Why not? A profile can be imported without being applied, but any applied profile is also implicitly imported in order to make the namespace visible. (The current assumption that a package import implies a profile application does not allow importing of profiles without application – which might be required just for namespace purposes.)

The simplest solution is to define ProfileApplication to be a subclass of DirectedRelationship with a meta-association (Profile::appliedProfile : Profile) indicating the applied profile
Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0: invalid package merge diagrams for compliance points

Key: UML22-1060
Legacy Issue Number: 9182
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
The diagrams in section 2 describing the compliance levels of UML 2, should show:

(1) have a separate package for each level (instead of the "UML" package); e.g., L2 for level 2.

(2) each package except L0 should also merge the package belonging to the immediately preceding level (e.g., L2 should merge package L1).
Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 issue: Profile::ownedStereotype should be derived

Key: UML22-1059
Legacy Issue Number: 9181
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
Profile::ownedStereotype should be derived (just like Package::/ownedType) from those ownedMembers which are Stereotypes.
Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Rename LinkAction::input to inputPin

Key: UML22-1043
Legacy Issue Number: 9104
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
LinkAction::input (non-derived) invalidly redefines Action::input (derived union).

-> Rename LinkAction::input to inputPin.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Rename OpaqueAction::input to inputPin

Key: UML22-1042
Legacy Issue Number: 9103
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
OpaqueAction::input (non-derived) invalidly redefines Action::input (derived union).

-> Rename OpaqueAction::input to inputPin.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Rename InformationFlow::source

Key: UML22-1041
Legacy Issue Number: 9100
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
InformationFlow::source (non-derived) invalidly redefines DirectedRelationship::source (derived union).

-> Rename InformationFlow::source to informationSource and remove
{redefines source}
.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Rename InformationFlow::target

Key: UML22-1040
Legacy Issue Number: 9099
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
InformationFlow::target (non-derived) invalidly redefines DirectedRelationship::target (derived union).

-> Rename InformationFlow::target to informationTarget and remove
{redefines target}
.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Rename ActivityPartition::subgroup to subpartition

Key: UML22-1036
Legacy Issue Number: 9095
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
ActivityPartition::subgroup (non-derived) invalidly redefines ActivityGroup::subgroup (derived union).

-> Rename ActivityPartition::subgroup to subpartition, replace
{redefines subgroup}
with
{subsets subgroup}
.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Replace {redefines redefinedElement}

Key: UML22-1035
Legacy Issue Number: 9094
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
State::redefinedState (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

-> Replace
{redefines redefinedElement}
with
{subsets redefinedElement}
.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Replace {redefines redefinedElement}

Key: UML22-1034
Legacy Issue Number: 9093
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
Transition::redefinedTransition (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

-> Replace
{redefines redefinedElement}
with
{subsets redefinedElement}
.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Replace {redefines redefinedElement}

Key: UML22-1033
Legacy Issue Number: 9092
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
Region::extendedRegion (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

-> Replace
{redefines redefinedElement}
with
{subsets redefinedElement}
.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

body expression for Property::isConsistentWith(RedefinableElement)

Key: UML22-1026
Legacy Issue Number: 9085
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
The body expression for Property::isConsistentWith(RedefinableElement) is incorrect; it should be:

result = redefinee.oclIsKindOf(Property) and
let prop : Property = redefinee.oclAsType(Property) in
(prop.type.conformsTo(self.type) and
((prop.lowerBound()~~>notEmpty() and self.lowerBound()~~>notEmpty()) implies prop.lowerBound() >= self.lowerBound()) and
((prop.upperBound()~~>notEmpty() and self.upperBound()~~>notEmpty()) implies prop.lowerBound() <= self.lowerBound()) and
(self.isDerived implies prop.isDerived))
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

following imports from merged packages to unmerged packages should be remov

Key: UML22-1025
Legacy Issue Number: 9084
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
UML::Deployments::ComponentDeployments -> UML::CommonBehaviors
UML::StateMachines::ProtocolStateMachines -> UML::CommonBehaviors
UML::UseCases -> UML::CommonBehaviors

UML::AuxiliaryConstructs::InformationFlows -> UML::CompositeStructures
UML::AuxiliaryConstructs::Models -> UML::CompositeStructures
UML::Classes::AssociationClasses -> UML::CompositeStructures
UML::CommonBehaviors::Communications -> UML::CompositeStructures
UML::Interactions::Fragments -> UML::CompositeStructures
UML::StateMachines::BehaviorStateMachines -> UML::CompositeStructures
UML::StateMachines::ProtocolStateMachines -> UML::CompositeStructures
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Superstructure Fig 2.2 Incomplete

Key: UML22-1024
Legacy Issue Number: 9080
Status: closed
Source: Thematix Partners LLC ( Dr. Doug Tolbert)
Summary:
The current version of the UML 2 Superstructure specification
(formal/05-07-04) has a diagram for the (top-level) package merges
comprising L1 (Figure 2.2). The packages that are shown as merged in
the diagram are: BasicActivities, BasicInteractions, Interfaces and
UseCases. The definitional XML file for L1, however, actually merges
BasicActivities, BasicInteractions, UseCases, Communicatiions and
InternalStructures
Reported: UML 2.0 — Fri, 14 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This is resolved by the resolutions to issues 9180 and 8459 (ballot 12).
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.4

Key: UML22-1023
Legacy Issue Number: 9077
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
The statement "Interaction Overview Diagrams are specialization of Activity Diagrams that represent Interactions." is misleading. An Interaction Overview Diagram is not a special activity diagram. It just re-uses the activity notation.
Reported: UML 2.0 — Wed, 12 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Common Behaviors

Key: UML22-1020
Legacy Issue Number: 9007
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
In Description section of Common Behaviors, CallConcurrencyKind, how can "Multiple invocations of a behavioral feature" occuring simultaneously have a "first behavioral feature". Full text: "Multiple invocations of a behavioral feature may occur simultaneously to one instance, but only one is allowed to commence. The others are blocked until the performance of the first behavioral feature is complete. It is the responsibility of the system designer to ensure that deadlocks do not occur due to simultaneous blocks."
Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
While nit-picking, the issue submitter is correct
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions

Key: UML22-1019
Legacy Issue Number: 9006
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Figure 143 should show MultiplicityElement as being from Kernel (the MDL file accidentally used a copy).
Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This issue was fixed in a previous revision. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

7.3.22 InstanceSpecification

Key: UML22-1022
Legacy Issue Number: 9023
Status: closed
Source: Anonymous
Summary:
on reading UML Superstructure I found a little mistake regarding chapter
>7.3.22 InstanceSpecification. This inconsistency seems although to be
>corrected within UML Infrasturcture.
>UML Superstructure, page 79, InstanceSepcification - Associations
>classifier : Classifier [0..*] ...
>
>UML Infrastructure, page 66, InstanceSpecification - Associations
>classifier : Classifier [1..*]
>
>I guess the specification within UML Infrasturcture is true. However I
>hope to get some kind of confirmation from you (as I want to be sure).
Reported: UML 2.0 — Wed, 28 Sep 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see page 504 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

Key: UML22-1021
Legacy Issue Number: 9010
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Clarify that multiple arrows coming out of an object-node-in-the-middle notation has the semantics of multiple edges coming out of an output pin.
Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

Key: UML22-1018
Legacy Issue Number: 9003
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Association.memberEnd should specialize Relationship:relatedElement. Programs accessing the repository with RelatedElement should get the elements being associated
Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

Key: UML22-1017
Legacy Issue Number: 9000
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
In Figure 195, subsetting opposite Variable should be of namespace, rather than owner
Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Invalid stereotype in StandardProfile

Key: UML22-1016
Legacy Issue Number: 8996
Status: closed
Source: The MathWorks ( Mr. Alan Moore)
Summary:
Page 671 (ormal/05-07-04),<< script>> is in StandardProfileL1, but its base element, Deployments::Artifact isn’t in L1.
Reported: UML 2.0 — Thu, 22 Sep 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8459 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / miscellaneous figure-text discrepancies

Key: UML22-1015
Legacy Issue Number: 8993
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
There are a few discrepancies between the figures and the latest Superstructure text (formal/05-07-04) that need to be fixed:

(1) figure 15.2 contains State::doAcvity – it should be State::doActivity (the textual description of this item uses correct spelling)

(2) resolutions to issues 6185 and 7342 indicate that Behavior::context should be derived and that it should subset "redefinitionContext". This needs to be fixed in figure 13.6. Also, the description in the text for this item on page 417 should be updated to show that "context" is derived ("/context").

(3) the association end Pseudostate::state shown in figure 15.2 is not documented. It should be.
Reported: UML 2.0 — Thu, 22 Sep 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 500 -501 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Rename Package::ownedMember

Key: UML22-1028
Legacy Issue Number: 9087
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
Package::ownedMember (non-derived) invalidly redefines Namespace::ownedMember (derived union).

-> Rename Package::ownedMember to packagedElement and replace
{redefines ownedMember}
with
{subsets ownedMember}
. Update all references to ownedMember (e.g. in sample profiles XMI) as appropriate.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Rename Constraint::namespace

Key: UML22-1027
Legacy Issue Number: 9086
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
Constraint::namespace (non-derived) invalidly redefines NamedElement::namespace (derived union).

-> Rename Constraint::namespace to context, replace
{redefines namespace, subsets context}
with
{subsets namespace}
on it, and remove Constraint::context.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 510 - 512 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Rename ActivityEdge::redefinedElement

Key: UML22-1030
Legacy Issue Number: 9089
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
ActivityEdge::redefinedElement (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

-> Rename ActivityEdge::redefinedElement to redefinedEdge, replace
{redefines redefinedElement}
with
{subsets redefinedElement}
.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Rename Component::ownedMember

Key: UML22-1029
Legacy Issue Number: 9088
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
Component::ownedMember (non-derived) invalidly redefines Namespace::ownedMember (derived union).

-> Rename Component::ownedMember to packagedElement and replace
{redefines ownedMember}
with
{subsets ownedMember}
. Update any references to ownedMember as appropriate.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Replace {redefines redefinedElement}

Key: UML22-1032
Legacy Issue Number: 9091
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
StateMachine::extendedStateMachine (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

-> Replace
{redefines redefinedElement}
with
{subsets redefinedElement}
.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Rename ActivityNode::redefinedElement

Key: UML22-1031
Legacy Issue Number: 9090
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
ActivityNode::redefinedElement (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

-> Rename ActivityNode::redefinedElement to redefinedNode, replace
{redefines redefinedElement}
with
{subsets redefinedElement}
.
Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 6.5

Key: UML22-1012
Legacy Issue Number: 8987
Status: closed
Source: Vtron ( Minghua Liu)
Summary:
"“Part I. Structure” defines the static, structural constructs (e.g., classes, components, nodes artifacts) used in various structural diagrams, such as class diagrams, component diagrams, and deployment diagrams. Part II - “Behavior” specifies the dynamic, behavioral constructs (e.g., activities, interactions, state machines) used in various behavioral diagrams, such as activity diagrams, sequence diagrams, and state machine diagrams. “Part ~~~~ I. Structure” defines auxiliary constructs ~~~~~~~~~~~~~~ (e.g., information flows, models, templates, primitive types) and the profiles used to customize UML for various domains, platforms, and methods" The words underlined shoude be "Part III - Supplement.
Reported: UML 2.0 — Wed, 7 Sep 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 should specify default property ownership for association ends

Key: UML22-1011
Legacy Issue Number: 8978
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
UML2 should define the defaults for property ownership and the explicit meaning of navigation notation. It should also provide notation for overriding these defaults in order to specify explicity the classifier that owns a property without relying on navigability. This recognizes a common notation practice and will result in predictable metamodel interchange. I general, the UML2 spec should attempt to avoid situations like the pair EF and IJ in figure 21, and instead use sensible defaults. If the default isn't what the model wants, then there should be notation to explicitly say what is needed. This will limit semantic variation points or unspecified notation meaning that may result in interchange and interoperability issues.

The diagram conventions used in Superstructure section 6.5.2 tie navigability and property ownership together in a manner that is consistent with the notaiton used in Basic and EMOF. However section 7.3.1 Notation for Association says:

Various options may be chosen for showing navigation arrows on a diagram. In practice, it is often convenient to suppress
some of the arrows and crosses and just show exceptional situations:
Show all arrows and x’s. Navigation and its absence are made completely explicit.
Suppress all arrows and x’s. No inference can be drawn about navigation. This is similar to any situation in which
information is suppressed from a view.
Suppress arrows for associations with navigability in both directions, and show arrows only for associations with oneway
navigability. In this case, the two-way navigability cannot be distinguished from situations where there is no navigation
at all; however, the latter case occurs rarely in practice.

This is fine, but given a UML2 diagram what are we to assume if all navigations are not explicit as in the first bullet? Wouldn't such such a model be ambiguous? Should UML2 specify which one of these conventions are implied by the notation? The last bullet represents common practice as well as the conventsions used in the UML2 specification. Perhaps the UML2 spec should to be specific about what the notation means and not leave this up to the reader.

Later in the spec (page 42) under Issue 6243, Figure 22 shows a class containing a property with non-primitive type and indicates this is an ownedAttribute of the class, and can be shown as an association too as described in Basic and EMOF. What it doesn't say is what the notation

by itself means. We know ClassA can navigate to b, but we don't know anything about who owns the properties and therefore where the ends go in an instance of the metamodel. Are they both ownedEnds of the Association? Is b an ownedAttribute of ClassA and a is an ownedEnd? Since there is currently no notation for specifying which classifier owns the properties, the notation should specify the default owners. Otherwise different tools may produce different XMI as it is not clear when a property on an association end is an ownedEnd of the association or an ownedAttribute of one of the associated classes.

The conventions in 6.5.2 should be the definitive notation for navigation arrows (with x on the ends options to make non-navigable explicit), and also specifies the default for property ownership. That is, the bullet lists in 7.3.1 should be replaced with those in 6.5.2 for association navigability and property ownership.

Then a notation should be specified for explicitly stating property ownership when the default is not appropriate.
Reported: UML 2.0 — Fri, 26 Aug 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 430 references invalid metaclass

Key: UML22-1002
Legacy Issue Number: 8947
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
Figure 430 references an 'IntegerExpression' metaclass that doesn't exist. Either such a metaclass (and others for other kinds of expressions?) should be added, or the example should be changed to use a different type of expression.
Reported: UML 2.0 — Tue, 2 Aug 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.5

Key: UML22-1001
Legacy Issue Number: 8946
Status: closed
Source: Bergson TA ( Marc Hamilton)
Summary:
A Property is a ConnectableElement, which currently is (should be?) a TypedElement. The Description in 9.3.5 however states: "A ConnectableElement is an abstract metaclass representing a set of instances that play roles of a classifier. Connectable elements may be joined by attached connectors and specify configurations of linked instances to be created within an instance of the containing classifier. Note on p.84 states: "When used to specify the existence of an entity in a modelled system, an instance specification represents part of that system." In 9.3.12. it says:"When an instance of the containing classifier is created, a set of instances corresponding to its properties may be created either immediately or at some later time. These instances are instances of the classifier typing the property. A property specifies that a set of instances may exist; this set of instances is a subset of the total set of instances specified by the classifier typing the property. A part declares that an instance of this classifier may contain a set of instances by composition." So, the concepts must be related. I propose that a ConnectableElement is a specialization of InstanceSpecification, not just a TypedElement. Current problems in practise: A TypedElement is not a PackageableElement and it thus cannot be imported in some other namespace. This makes is hard to create orthogonal views of architectures (e.g. logical vs. execution) in which 'roles' (parts!) are shared. On the other hand, using InstanceSpecifications instead of "Parts" makes it impossible to refer them in interactions. Besides, the meaning of an InstanceSpecification in the context of a classifier is unclear in contrast to the Property.
Reported: UML 2.0 — Tue, 2 Aug 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: The concept of connectable element is not an instance specification, so it would be a mistake to make it a specialization of InstanceSpecification. As the issue also points out, doing so would cause problems with interactions (where connectable elements are heavily used) as well as with their meaning. The issue really at hand appears to be that ConnectableElements are not packageable elements. The reason is that they have really no meaning outside of the context of the classifier they are owned by and thus would not be packaged separately. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Navigability Impact on Tools

Key: UML22-1006
Legacy Issue Number: 8963
Status: closed
Source: Thematix Partners LLC ( Dr. Doug Tolbert)
Summary:
The notion of navigability for association ends may be interpreted as
limiting the ability of UML tools to traverse associations with
non-navigable ends. However, discussion among RTF members indicates
that UML tools need not be specifically limited in their ability to
traverse non-navigable ends. To prevent confusion about the impact of
non-navigable ends among tool developers studying the specification, the
ability of UML repositories and other tooling to ignore navigability
limitations should be explicitly stated.
Reported: UML 2.0 — Thu, 11 Aug 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 XMI DTD requirement

Key: UML22-1005
Legacy Issue Number: 8957
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
In section 6.5.1 of both the RFP for the UML 2 Superstructure and the RFP for the UML 2 Infrastructure it is required that

Proposals shall specify an XMI DTD for the UML metamodel.

This was based on the assumption that such schemas carry sufficient information for tool vendors to construct facilities for meaningful interchange of models. Unfortunately, due to the introduction of certain more complex features such as package merge in UML 2.0, these schemas are not sufficient. On the other hand, the XMI for the individual compliance levels (Lm, L0, L1, L2, and L3) is sufficient for the interchange objective. Therefore, instead of the XMI schemas, it is proposed to make the latter normative for the UML 2 Superstructure and Infrastructure specs.
Reported: UML 2.0 — Wed, 10 Aug 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This is resolved by the resolution to 3898 and the explanatory text for 8678.
Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 issue: {unrestricted} described in text but not BNF

Key: UML22-998
Legacy Issue Number: 8935
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
In section 7.3.49 of Super, and 9.2.2 of Infra,
{unrestricted} is given as a notation option: "A modifiable structural feature is shown using {unrestricted}
as part of the notation for the structural feature."
However unrestricted is is not included in the BNF for Property (in 7.3.44).
It does not seem useful as a keyword since it is the default; nor is 'unrestricted' a very suggestive term for the meaning.

Proposed Resolution:
Delete the above sentence from 7.3.49 of Super, and 9.2.2 of Infra.
Reported: UML 2.0 — Tue, 19 Jul 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML Superstructure / Actions / Missing package heading

Key: UML22-997
Legacy Issue Number: 8933
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
In section 11.3.21, (Actions, LinkAction), the second constraitns section should include the phrase (CompleteActions) at the end
Reported: UML 2.0 — Mon, 18 Jul 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Undocumented properties

Key: UML22-1010
Legacy Issue Number: 8976
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
The following properties appear in the metamodel diagrams but are not documented in the spec:

UML::Classes::Kernel::Property::class
UML::Components::BasicComponents::Connector::contract
UML::Components::BasicComponents::Realization::abstraction
UML::Components::BasicComponents::Realization::realizingClassifier
UML::Interactions::BasicInteractions::Lifeline::coveredBy
Reported: UML 2.0 — Thu, 25 Aug 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 494 - 495 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 591,592

Key: UML22-1009
Legacy Issue Number: 8968
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Constraint 9 and 10 state that entry and exit points are only allowed in the topmost region of a statemachine. On page 592 the entry/exit point semantic describes that these points are also allowed on composite states (see also issue 6075). I think the constraints don't take into account that composite states are also allowed.
Reported: UML 2.0 — Wed, 17 Aug 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Core::Constructs::Operation

Key: UML22-1008
Legacy Issue Number: 8966
Status: closed
Source: Vienna University of Technology ( Lorenz Froihofer)
Summary:
This is a question or an issue for the UML 2.0 Superstructure and Infrastructure Revision Task Force (http://www.omg.org/issues/uml2-rtf.html An operation, e.g. Core::Constructs::Operation does no longer contain the isAbstract attribute (compared to UML version 1.5). I could not find a note in any of the classes within the inheritance hierarchy stating that this is a change to the 1.x versions. Was this attribute intentionally dropped for version 2.0? If yes, what is the suggested replacement?
Reported: UML 2.0 — Tue, 9 Aug 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This ability is still there, since the attribute isAbstract is inherited from BehavioralFeature (which is a superclass of Operation) as defined in CommonBehaviors. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Interaction::lifeline should be ordered

Key: UML22-1007
Legacy Issue Number: 8964
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
Interaction::lifeline should be ordered so as to dictate the ordering of lifelines (in a diagram for example).
Reported: UML 2.0 — Fri, 12 Aug 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Classes Notation for association end ownership

Key: UML22-1004
Legacy Issue Number: 8956
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
UML 2.0 has separated the concepts of navigability from association end ownership. However there is as yet no explicit notation for specifying who owns an association end. An explicit notation is required and, possibly, a set of default notational conventions for the most frequent cases.
Reported: UML 2.0 — Wed, 10 Aug 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 489 - 490 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

connection point reference

Key: UML22-1003
Legacy Issue Number: 8955
Status: closed
Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
Summary:
Is this known issue, that just one ConnectionPointReference can point into same connection point?
It's not possible to create two SubMachineStates with ConnectionPointReferences assigned with same StateMachine, because meta Association between PseudoState (connection point) and ConnectionPointReference has multiplicity [0..1].

This destructs all concept of reusable StateMachines
Reported: UML 2.0 — Wed, 10 Aug 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Collaboration use issues (02)

Key: UML22-1014
Legacy Issue Number: 8990
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
2) The caption of Figure 106 still refers to "collaboration occurrence" (should be "collaboration use")
Reported: UML 2.0 — Thu, 22 Sep 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Collaboration use issues (01)

Key: UML22-1013
Legacy Issue Number: 8989
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
(1) All the dependencies in Figure 109 of ptc/04-10-02 are pointing in the wrong direction. Note that constraint [1] of CollaborationUse says:
"All the client elements of a roleBinding are in one classifier and all supplier elements of a roleBinding are in one collaboration..."

which implies that the supplier elements (the ends with the arrow, according to the notation subsection of Dependency) are the roles in the collaboration and the client elements are the parts that are playing specific roles of that collaboration. The figure actually shows the inverse of that.
Reported: UML 2.0 — Thu, 22 Sep 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see page 498 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.18 and 12.3.35

Key: UML22-1000
Legacy Issue Number: 8939
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Add constraint to conditional and loop node that the result output pins have no outgoing edges
Reported: UML 2.0 — Mon, 25 Jul 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.14

Key: UML22-999
Legacy Issue Number: 8938
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
BNF for transition specifies that a trigger is mandatory. That's not the case, e.g. for the initial state transition.
Reported: UML 2.0 — Fri, 22 Jul 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

p. 732: Show examples of new stereotype notation

Key: UML22-987
Legacy Issue Number: 8852
Status: closed
Source: Pivot Point ( Cris Kobryn)
Summary:
Recommended Changes to UML 2.0 Profiles to Support SysML

Source: SysML Partners (Partners@SysML.org)
Nature: Revision
Severity: Significant
Summary:
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

Recommended changes:
8) p. 732: Show examples of new stereotype notation. Add the following including new Figure 463:
"Finally, the two alternate notational forms are shown.
- Other notational forms for showing values
  AlarmClock is valid for OS version 1.1, is POSIX-compliant and it has a starting operation called Start. The compartment form of notation is shown on the left and the in-symbol form on the right (note that not all properties of Clock are shown on the right."
Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 468 - 469 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

p. 732: Change example to be consistent with new definition of Clock

Key: UML22-986
Legacy Issue Number: 8851
Status: closed
Source: Pivot Point ( Cris Kobryn)
Summary:
Recommended Changes to UML 2.0 Profiles to Support SysML

Source: SysML Partners (Partners@SysML.org)
Nature: Revision
Severity: Significant
Summary:
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

Recommended changes:
7) p. 732: Change example to be consistent with new definition of Clock. Replace figure 462 with:
Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 466 -467 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.5

Key: UML22-994
Legacy Issue Number: 8919
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Description
Section Associations (CompleteActivities): weight specifies the number of tokens instead of objects consumed from the source node on each traversal. It's a common property for object flow as well as for control flows.
Reported: UML 2.0 — Wed, 6 Jul 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 163

Key: UML22-993
Legacy Issue Number: 8901
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Fig. 93: The only message of the notation abstraction is that some components offer and some components require an interface. That the same as in a component diagram. Fig. 93 shows an internal view of a component. A composite structure diagram must show how the components are wired together. For examples that :BackOrder uses :Customer and NOT :Organization or vice versa. I propose to not use the notation abstraction.
Reported: UML 2.0 — Thu, 30 Jun 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Introducing a minimalist resolution, to just fix the incorrectly used terminology.
Updated: Fri, 6 Mar 2015 20:58 GMT

Make instance model consistent with new definition of Clock

Key: UML22-983
Legacy Issue Number: 8848
Status: closed
Source: Pivot Point ( Cris Kobryn)
Summary:
Recommended Changes to UML 2.0 Profiles to Support SysML

Source: SysML Partners (Partners@SysML.org)
Nature: Revision
Severity: Significant
Summary:
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

Recommended changes:
4) p. 730: Make instance model consistent with new definition of Clock. Replace Figure 458 with:
Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see page 463 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

p. 729: Extend the Clock example to show metaclass property

Key: UML22-982
Legacy Issue Number: 8847
Status: closed
Source: Pivot Point ( Cris Kobryn)
Summary:
Recommended Changes to UML 2.0 Profiles to Support SysML

Source: SysML Partners (Partners@SysML.org)
Nature: Revision
Severity: Significant
Summary:
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)3) p. 729: Extend the Clock example to show metaclass property and the use of Boolean. Replace Figure 456 with:
Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 462 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

p. 731: Make example consistent with new definition of Clock.

Key: UML22-985
Legacy Issue Number: 8850
Status: closed
Source: Pivot Point ( Cris Kobryn)
Summary:
Recommended Changes to UML 2.0 Profiles to Support SysML

Source: SysML Partners (Partners@SysML.org)
Nature: Revision
Severity: Significant
Summary:
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

Recommended changes:
6) p. 731: Make example consistent with new definition of Clock. Replace Figure 461 with:
Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8849 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

p. 731: Make this example consistent with the new definition of Clock

Key: UML22-984
Legacy Issue Number: 8849
Status: closed
Source: Pivot Point ( Cris Kobryn)
Summary:
Recommended Changes to UML 2.0 Profiles to Support SysML

Source: SysML Partners (Partners@SysML.org)
Nature: Revision
Severity: Significant
Summary:
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

Recommended changes:
5) p. 731: Make this example consistent with the new definition of Clock. Replace Figure 459 with:
Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 464 - 465 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.37 ObjectFlow

Key: UML22-989
Legacy Issue Number: 8859
Status: closed
Source: Sapiens Deutschland GmbH ( Helmut Barthel)
Summary:
On page 418, Constraints (BasicActivities), you write: "[1] Object flows may not have actions at either end." In contrast, on page 420, Notation, the description of the upper right part of figure 281 is: "Two object flow edges linking object nodes and actions(!!)." After many cycles of re-reading the Activities chapter I got convinced that the constraint is really meant as-is. So, the notation mentioned above likely means the "standalone pin notation" from page 433. If so, you should make it very clear, that this notation maps to two Pin instances (one at either action) and ONE ObjectFlow instance in-between, in the model (just like the alternative notation in the same figure shows). In addition, you should add this clarification throughout the Activities chapter. In addition, on page 433, regarding the explanation of the standalone pin notation, you should add, that it maps to ONE object flow edge in-between the two pins, in the model.
Reported: UML 2.0 — Tue, 7 Jun 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML Superstructure / Actions / incorrect form for subsetting

Key: UML22-996
Legacy Issue Number: 8932
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
The Actions chapter uses the convention "Specialized from" in describing properties that are specialized in a metaclass, instead of the "Subsets " convention used throughout the rest of the document. The former should all be changed to follow the conventional form.
Reported: UML 2.0 — Mon, 18 Jul 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.9

Key: UML22-995
Legacy Issue Number: 8930
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Semantics section, last sentence: Recursive reference to semantics section of ActivityParameterNode.
Reported: UML 2.0 — Mon, 18 Jul 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

pp. 733-734: Add association as valid graphic path

Key: UML22-988
Legacy Issue Number: 8853
Status: closed
Source: Pivot Point ( Cris Kobryn)
Summary:
Recommended Changes to UML 2.0 Profiles to Support SysML

Source: SysML Partners (Partners@SysML.org)
Nature: Revision
Severity: Significant
Summary:
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

Recommended changes:
9) pp. 733-734: Add association as valid graphic path. Add the following row to Table 24:

Unidirectional Association See "Profile (from Profiles)" on page 720
Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

TimeExpression

Key: UML22-991
Legacy Issue Number: 8894
Status: closed
Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
Summary:
TimeExpression should hold time value, but there is no attribute for that. Maybe TimeExpression should be inherited from OpaqueExpression and hold value in "body"?
Reported: RAS 2.2 — Mon, 20 Jun 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 472 - 478 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

OpaqueAction

Key: UML22-990
Legacy Issue Number: 8867
Status: closed
Source: Eclipse Foundation ( Mr. Kenneth Hussey)
Summary:
should specialize input and output, so opaque actions can have pins.
Reported: UML 2.0 — Tue, 14 Jun 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see page 471 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

abstract Action in Activity diagram

Key: UML22-992
Legacy Issue Number: 8896
Status: closed
Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
Summary:
4. The same situation is with abstract Action in Activity diagram. OpaqueAction also can't be used, because can't have Pins.
How to draw "human friendly" action (activity)? The only way is to use CallBehaviorAction?
Reported: RAS 2.2 — Mon, 20 Jun 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8867 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

p. 728: New presentation options. Replace the following paragraph

Key: UML22-981
Legacy Issue Number: 8846
Status: closed
Source: Pivot Point ( Cris Kobryn)
Summary:
Recommended Changes to UML 2.0 Profiles to Support SysML

Source: SysML Partners (Partners@SysML.org)
Nature: Revision
Severity: Significant
Summary:
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

2) p. 728: New presentation options. Replace the following paragraph:
"The values of a stereotype that has been applied to a model element can be shown as part of a comment symbol tied to the model element. The values from a specific stereotype are optionally preceded with the name of the applied stereotype within a pair of guillemets, which is useful if values of more than one applied stereotype should be shown."
with the following text:
"The values of a stereotype that has been applied to a model element can be shown in one of three ways:
·As part of a comment symbol tied to the symbol representing the model element
·In compartments of a graphic node representing the model element.
·Above the name string within a graphic node or before the name string otherwise
In the case where a compartment or comment symbol is used, the user may elect to show the stereotype name in guillemets before the name string in addition to in the compartment or comment.
They are displayed as name/value pairs, thus:
<namestring>'='<valuestring>
If a stereotype property is multi-valued then the valuestring is displayed as a comma-separated list:
<valuestring>::=<value>
{','<value>}
Certain values have special display rules:
·As an alternative to a name/value pair, when displaying the values of boolean properties diagrams may use the convention that if the namestring is displayed then the value is True, otherwise the value is False;
·If the value is the name of a NamedElement then optionally its qualifiedName can be used.
If compartments are used to display stereotype values then an additional compartment is required for each applied stereotype whose values are to be displayed. Each such compartment is headed by the name of the applied stereotype in guillemets. Any graphic node may have these compartments.
Within a comment symbol, or if displayed before/above the symbols's namestring, the values from a specific stereotype are optionally preceded with the name of the applied stereotype within a pair of guillemets, which is useful if values of more than one applied stereotype should be shown.
When displayed in compartments or comment symbol at most one name/value pair can appear on a single line. When displayed above/before a namestring the name/value pairs are separated by semicolons and all pairs for a given stereotype are enclosed in braces."
Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 460 - 461 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

p. 721: Allow stereotypes to have properties that are typed by metaclasses

Key: UML22-980
Legacy Issue Number: 8845
Status: closed
Source: Pivot Point ( Cris Kobryn)
Summary:
SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)
. Change paragraph 4 to:
"As part of a profile, it is not possible to have an association between two stereotypes or from a metaclass in the reference metamodel to a stereotype, although a unidirectional association from a stereotype to a metaclass, or equivalently typing a stereotype property by a metaclass, is allowed. The effect of new (meta) associations between stereotypes can be achieved in limited ways either by:"
Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 7756 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Can't specify mutator semantics for derived properties

Key: UML22-968
Legacy Issue Number: 8769
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
It is currently not possible to specify the effect of setting derived properties that are not read-only. As a result, derived properties are under-specified in the model because the semantics of updating them cannot be modeled or stated formally.
Reported: RAS 2.2 — Fri, 6 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.37

Key: UML22-967
Legacy Issue Number: 8766
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
It's a common modeling scenario that an object flow with an outpin pin at the source must target an action directly (without a pin). For example a decision node with an incoming object flow - the object is necessary for the guard condition -, but one or more of the target actions don't need that object. Due to the constraint that object flows don't have actions at either end I must model an input pin. For example in case of a CallOperationAction an operation with an additional parameter must be defined even if I don't use it. It's just for modeling purposes. I've assumed before reading the constraint in the specification that an object flow can target an action directly. In that case it's semantic is the same as for the control flow. That works perfect for me. I would propose to weaken the constraint for object flows that actions as targets are allowed. The object token enables the action and gets lost. Any other solution with the same semantic is also acceptable.
Reported: RAS 2.2 — Thu, 5 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
closed no change
Updated: Fri, 6 Mar 2015 20:58 GMT

MessageEnd

Key: UML22-976
Legacy Issue Number: 8784
Status: closed
Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
Summary:
MessageEnd is MessageOccurrenceSpecification that redefines "event" as MessageEvent.
DestructionEvent and CreationEvent are not subclasses of MessageEvent, so can't be on message end, so how to map "create message" and "destroy message"?
Reported: RAS 2.2 — Wed, 18 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

ExecutableNode should be abstract in Figure 195. It is in Figure 197.

Key: UML22-975
Legacy Issue Number: 8782
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
ExecutableNode should be abstract in Figure 195. It is in Figure 197.
Reported: UML 2.0 — Sun, 15 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8239 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12 and 13

Key: UML22-979
Legacy Issue Number: 8826
Status: closed
Source: Ostfold University College ( Dr. Oystein Haugen)
Summary:
Figure numbers 306,307,308,309 appear in both the Activities chapter (12) and the Common Behavior chapter (13)
Reported: UML 2.0 — Thu, 26 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect Communication Domain Model

Key: UML22-978
Legacy Issue Number: 8825
Status: closed
Source: Thematix Partners LLC ( Mr. James J. Odell)
Summary:
Fig. 308 does not contain the correct domain model. The current model that
appears in Fig. 308 is a duplicate of Fig. 307.
Reported: RAS 2.2 — Thu, 26 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8292 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Obsolete term EventOccurrence still used in multiple places

Key: UML22-977
Legacy Issue Number: 8824
Status: closed
Source: Thematix Partners LLC ( Mr. James J. Odell)
Summary:
1) 14.3.25 OccurrenceSpecification, the change in class name was from EventOccurrence to OccurrenceSpecification. This change needs to be noted in this document. Also, the reason why the change was made.
2) EventOccurrence is still being use in the toBefore and toAfter association descriptions of OccurrenceSpecification.
3) EventOccurrence is still be referenced in other areas:
a) in the last word of the Example text on page 476,
b) In the Notation text on Page 489,
c) In the fifth paragraph of the overview on Page 497
d) Multiple times on Page 509 and 510
e) First paragraph on Page 528
f) Multiple times on Page 531
g) Multiple times on Fig. 347
Reported: RAS 2.2 — Thu, 26 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 453 - 457 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Notation of Attributes and Associations subsections

Key: UML22-972
Legacy Issue Number: 8774
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Notation of Attributes and Associations subsections in the whole specification should be consistently follow the rules: Every entry must include * attribute/association end name * its type * its multiplicity: you should NOT omit this even if it maps to the default value of *. Also, both upper and lower multiplicities should be provided; i.e., NOT "[*]" but "[0..*]") * ALL modifiers such as subsets and redefines. When referencing other association ends, use the following convention: "<metaclass-name>::<association-end-name> (do NOT use the "." notation for this) * if something is derived, the explanation should be given how it is derived and an OCL formula might have to be provided.
Reported: RAS 2.2 — Tue, 10 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: Most of these issues have been resolved through numerous editorial changes that were intended to ensure consistency. The exceptions are:
h the use of * instead of 0..* – simply not worth the effort given that the two are equivalent. It will take a lot of effort to do this with no real value; chances are that this will NEVER get done. There is no point in keeping the issue open.
h The derivation specification already has another open issue.
Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 330

Key: UML22-971
Legacy Issue Number: 8773
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Typo in fig. 192: Association from BehavioralFeature to Parameterset: should be ownedMember instead of ownedmember (uppercase).
Reported: UML 2.0 — Tue, 10 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This issue refers to an older version of the specification. It is fixed in the meantime. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.48

Key: UML22-970
Legacy Issue Number: 8772
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Semantic sections mentions the order of structural features of the specified classifier. The list of structural features is ordered for a class, but unordered for a classifier.
Reported: UML 2.0 — Mon, 9 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions

Key: UML22-969
Legacy Issue Number: 8770
Status: closed
Source: Object Management Group ( Stephen Mellor)
Summary:
The third sentence of the Actions chapter implies that most of the actions are specialization of the one that supports implementation-dependent semantics. Should be reworded.
Reported: UML 2.0 — Fri, 6 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Actions should be able to overlap partitions, to support multiple participa

Key: UML22-974
Legacy Issue Number: 8781
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Actions should be able to overlap partitions, to support multiple participants
Reported: UML 2.0 — Sun, 15 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1 Page: 156 ff

Key: UML22-973
Legacy Issue Number: 8778
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Fig. 86, 87, and 89 have no dividing line between name compartment and internal view compartment
Reported: UML 2.0 — Thu, 12 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This dividing line is optional. Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

OpaqueAction

Key: UML22-966
Legacy Issue Number: 8759
Status: closed
Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
Summary:
In chapter 11.3.26 OpaqueAction is described as subclass of Pin. It
> should be subclass of Action.

That's a bug. Please raise an issue.

> Can OpaqueAction be used as default Action type in Activity diagrams
> and be as replacement of old-style user defined ActionStates in UML 1.4?

It sounds like you are asking for a new feature. I don't see that the RTF will accept this default. You can always do this woth a profile.
Reported: RAS 2.2 — Tue, 3 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 591

Key: UML22-965
Legacy Issue Number: 8753
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
The semantics section describes that the transition from an initial pseudostate may have an action. There should be a constraint in the constraints section that actions are allowed, but no triggers and guards. Instead of action it should be named behavior.
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see page 442 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify caption of Figure 56

Key: UML22-961
Legacy Issue Number: 8746
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Clarify caption of Figure 56. The wording of caption of Figure 56 gives the impression that it is a general notation to provided/required interfaces, especially because it is in the Presentation Option section. Discussion during FTF was that this is only an example, rather than a general notation.
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Interactions

Key: UML22-960
Legacy Issue Number: 8745
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Messages to self. Are curved arrows in interactions (sending to self) still supported in UML 2? See Figure 3-56 in UML 1.5 (doc.omg/org/formal/03-03-01). If not, how are messages to self shown?
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify first constraint on InputPin and OutputPin, move "only" to before "

Key: UML22-953
Legacy Issue Number: 8734
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Clarify first constraint on InputPin and OutputPin, move "only" to before "when".
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

LoopNode should move rather than copy values to/from loop variables

Key: UML22-952
Legacy Issue Number: 8733
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
LoopNode should move rather than copy values to/from loop variables. Otherwise, tokens will be dangling tokens. Same for ConditionalNode bodyOutput, etc.
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

In Figure 210, put merge before Use Part to merge the incoming flows

Key: UML22-951
Legacy Issue Number: 8732
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
In Figure 210, put merge before Use Part to merge the incoming flows
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see page 431 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Exceptions thrown across synchronous invocations

Key: UML22-950
Legacy Issue Number: 8730
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Exceptions thrown across synchronous invocations. Clarify that exceptions are thrown across synchronous invocations, not asynchronous ones. Or introduce an attribute to tell whether it is thrown across call boundaries.
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Multiple exception handlers

Key: UML22-949
Legacy Issue Number: 8729
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Multiple exception handlers. Clarify that one exception handler is executed if multiple match, and it is undefined which
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Actions, CallBehaviorAction, third sentence,

Key: UML22-955
Legacy Issue Number: 8736
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Actions, CallBehaviorAction, third sentence, should be limited to synchronous calls
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

The Syle Guidelines for Stereotype

Key: UML22-954
Legacy Issue Number: 8735
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
The Syle Guidelines for Stereotype says "The values of an applied stereotype are normally not shown." This is application-dependent. Sentence should be removed
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

CollaborationUse: Constraint 1,

Key: UML22-959
Legacy Issue Number: 8744
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
CollaborationUse: Constraint 1, allows parameters from different operations to be coordinated. Is that intended?
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This issue appears to refer to an earlier version of the specification. It is impossible to identify in the current version what this issue concerns. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

ConditionalNode and LoopNode test and bodies should be ExecutableNodes

Key: UML22-958
Legacy Issue Number: 8740
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
ConditionalNode and LoopNode test and bodies should be ExecutableNodes
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

ExpansionRegion

Key: UML22-957
Legacy Issue Number: 8739
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
ExpansionRegion, clarify that tokens in input pins and expansion nodes are destroyed when the expansion node completes
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

ControlFlow

Key: UML22-956
Legacy Issue Number: 8737
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
ControlFlow should say that if it targets an action, or control pin of action, then the action requires a control token to start executing
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Last element in transition BNF

Key: UML22-964
Legacy Issue Number: 8752
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Last element in transition BNF should be <behavior-expression> instead of <activity-expression>. The term is used on the next side.
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Update as suggested.
Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for connector end multiplicities.

Key: UML22-962
Legacy Issue Number: 8747
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Notation for connector end multiplicities. Notation of ConnectorEnd, first paragraph says the multiplicities shown are the association multiplicities. What about the connector end multiplicities?
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This issue has been fixed in the current version of the specification. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

ParameterSet, first line: "inputs or outputs".

Key: UML22-963
Legacy Issue Number: 8749
Status: closed
Source: International Business Machines ( Dr. Tracy Gardner)
Summary:
ParameterSet, first line: "inputs or outputs".
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

In Activities, Figure 176, Action should be abstract

Key: UML22-942
Legacy Issue Number: 8718
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
In Activities, Figure 176, Action should be abstract
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Profile Semantics, pag 723

Key: UML22-941
Legacy Issue Number: 8706
Status: closed
Source: The MathWorks ( Mr. Alan Moore)
Summary:
"A reference metamodel typically consists of metaclasses that are either
imported or locally owned. All metaclasses that
are extended by a profile have to be members of the same reference
metamodel. A tool can make use of the information
about which metaclasses are extended in different ways, for example to
filter or hide elements when a profile is applied, ..."

The specification must be explicit about the mechanism used to hide/filter
reference metamodel elements. The SysML Partners are trying to do exactly
this with SysML but it's not clear from the above paragraph or any other
part of the Profiles section how to do it.
Reported: RAS 2.2 — Thu, 28 Apr 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12

Key: UML22-935
Legacy Issue Number: 8680
Status: closed
Source: FUNDP ( Pierre Yves Schobbens)
Summary:
"Any object nodes declared as outputs are passed out of the containing activity." Only tokens can be passed, not nodes. I suggest: "The last token from each output Activity Parameter Node is offered on the corresponding output of the calling action."
Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

token

Key: UML22-934
Legacy Issue Number: 8679
Status: closed
Source: FUNDP ( Pierre Yves Schobbens)
Summary:
"All tokens offered on the incoming edges are accepted." 1- The edges of of the terminated Activity or of the Activity Final Node? 2- In general, it is not possible to accept all tokens offered. For instance, a same token in an ObjectNode could cause two token offers throughtwo forks. Yet, only one of these offered tokens can be accepted, causing the other to be no longer offered. I suggest to delete this sentence.
Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

String is primitive but has structure.

Key: UML22-944
Legacy Issue Number: 8720
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
String is primitive but has structure. Section 17.4 (PrimitiveTypes) has String, even though the definition of primitive type in Section 7.3.43 excludes any structure: "A primitive type defines a predefined data type, without any relevant substructure (i.e. it has no parts). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically."
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

``conditional node or conditional node'' delete one.

Key: UML22-937
Legacy Issue Number: 8683
Status: closed
Source: FUNDP ( Pierre Yves Schobbens)
Summary:
``conditional node or conditional node'' delete one.
Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

add the rule of ``natural termination''

Key: UML22-936
Legacy Issue Number: 8681
Status: closed
Source: FUNDP ( Pierre Yves Schobbens)
Summary:
I suggest to add the rule of ``natural termination'': An activity terminates when it has a token in each of its output Activity Parameter Nodes. This removes the need for Activity Final Nodes in most cases, and makes UML less error-prone, since it is an error to terminate without a token in each output Activity Parameter Node. It also makes the languages more consistent, since this rule is used for loops.
Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Solid triange notation for Association

Key: UML22-948
Legacy Issue Number: 8728
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Solid triange notation for Association. Association, Examples, shows a solid triangle notation that is not mentioned in the notation section. It says it indicates the order of reading, but association generally don't have an order or reading, the end names express the order of reading. I thought it showed the order of the association ends (Association.memberEnd is ordered), because there's no other notation for that.
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

The create stereotype on Usage dependency

Key: UML22-947
Legacy Issue Number: 8727
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
The create stereotype on Usage dependency. The create stereotype on Usage dependency is defined in standard stereotypes (Table 25) and in retired stereotypes (Table 28). It is used in Figures 103 and 121.
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This issue was resolved in an earlier revision. The “create” stereotype is now defined in the table in appendix C section C.1. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.2

Key: UML22-939
Legacy Issue Number: 8690
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
Summary:
In figure 195, p332, StructuredActivityNode and Action inherit from ExecutableNode. In figure 196, p333, StructuredActivityNode inherits from Action. => StructuredActivityNode inherits two times of Action. A priori, you could delte the inheritance link between StructuredActivityNode and ExeutableNode in figure 195
Reported: UML 2.0 — Thu, 7 Apr 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Delete sentence

Key: UML22-938
Legacy Issue Number: 8685
Status: closed
Source: FUNDP ( Pierre Yves Schobbens)
Summary:
" One frequent case is a total ordering of clauses, in which case the result is determinate." The clauses themselves can be nondeterministic, making this sentence false (although the idea is clear). Delete.
Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Element to Constraint navigation

Key: UML22-946
Legacy Issue Number: 8726
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Element to Constraint navigation. The "constrainedElement" association between Constraint and Element is unidirectional from Constraint to Element. That means implementations are not required to provide efficient navigation from an element to the constraints on it. Can't see how an API could do without this.
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
This is a duplicate of issue 8020 Revised Text: N/A Disposition: Duplicate
Updated: Fri, 6 Mar 2015 20:58 GMT

Disjointness should be independent of generalization

Key: UML22-945
Legacy Issue Number: 8723
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Disjointness is applicable to classes that are not specializations of the same class. It should be independent of generalization
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Same as issue 8014 Revised Text: N/A Disposition: Duplicate
Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics for instances applies to InstanceSpecification?

Key: UML22-943
Legacy Issue Number: 8719
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Semantics for instances applies to InstanceSpecification? Clarify whether the semantics for instances specified in other chapters applies to InstanceSpecification. For example, will deleting an InstanceSpecification delete other instances it owns by association composition?
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

policy to describe the Associations sub section of a meta class description

Key: UML22-940
Legacy Issue Number: 8696
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
Summary:
what is the official policy to describe the Associations sub section of a meta class description (using EBNF style):

/?<end-name> : <associated-class-name> : <cardinality> (= <DefaultValue>)? <FeaturesList>? <tab> <Description>

where:

<end-name> ::= String

<associated-class-name> ::= String

<cardinality> ::= [<n>, <m>]

<DefaultValue> ::= String

<FeaturesList> ::=
{<Features>}
<Features> ::= <FeatureKind>} | {<FeatureKind>, <Features>

<FeatureKind> ::= subsets <property-name> | redefined <end-name> | union | ordered | bag | sequence | readOnly | unrestricted

<property-name> ::= String

<n> ::= Integer

<m> ::= Integer | * and m >= n

<tab> is a tabulation

ps: ? means it is optional part.
Reported: RAS 2.2 — Tue, 12 Apr 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 -- Need explanations of XMI structure and usage

Key: UML22-933
Legacy Issue Number: 8678
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
Appendix G is intended to contain the XMI for UML. However, there is no explanation of the meaning of its various parts, or its structure, or how it is to be used. This information should be included in the introduction to the XMI appendix in both the Infrastructure (Appendix A) and the Superstructure (Appendix G).
Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

token movement

Key: UML22-932
Legacy Issue Number: 8677
Status: closed
Source: FUNDP ( Pierre Yves Schobbens)
Summary:
The verbs ``flow'', ``pass'', ``traverse'' seem used interchangeably to describe token movement. I suggest to reserve ``flow'' for a complex path (So e.g. p.309 should be: ``Activity edges are directed connections, that is, they have a source and a target, along which tokens may
{\bf pass}
). , ``pass'' for an elementary move, and to replace ``traverse'' by ``pass''. (p.303, 304, 309, 310, etc.)
Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

output tokens (02)

Key: UML22-931
Legacy Issue Number: 8676
Status: closed
Source: FUNDP ( Pierre Yves Schobbens)
Summary:
In, e.g.: [4] The output tokens are now available Replace ``available'' by ``offered''. Also p.310, p.330, p.342, etc.
Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12

Key: UML22-927
Legacy Issue Number: 8670
Status: closed
Source: FUNDP ( Pierre Yves Schobbens)
Summary:
there should be a consistent convention as whether unused Paragraphs must be omitted or filled with ``None''. We suggest the first, and thus to delete the Paragraphs pp.110, 163, 216, 217, 220-262, 280, 285, 298, 301, 304, 311-320, 323, 331, etc.
Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8155 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix F

Key: UML22-926
Legacy Issue Number: 8619
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The following classifiers show no inheritance hierarchy because the link (inheritance arrow) is missing: Classifier (from Templates), Classifier (from PowerTypes), Interface (from Communications), BehavioredClassifier (from Interfaces), Behavior (from CompleteActivities), Activity (from BasicActivities), Activity (from StructuredActivities), and Activity (from CompleteActivity). In addition, Classifier (from UseCases) and Classifier (from Dependencies) are just kind of sitting there without showing any inheritance. It is strange to see classifiers on a diagram with no relationships expressed.
Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: E.1

Key: UML22-925
Legacy Issue Number: 8617
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typos - Remove the extra space beginning the paragraphs of #4, 6, 9, 10, 11, 12, and 14. There is also an extra space in #10 in "sequence /communication."
Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see page 412 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

text p.297

Key: UML22-930
Legacy Issue Number: 8674
Status: closed
Source: FUNDP ( Pierre Yves Schobbens)
Summary:
The text p.297: [1] An action execution is created when all its object flow and control flow prerequisites have been satisfied (implicit join). Exceptions to this are listed below. The flow prerequisite is satisfied when all of the input pins are offered tokens and accept them all at once, precluding them from being consumed by any other actions. contains, I believe, the problems: 1. Flows need not be connected by input pins, so ``inputs'' must replace ``input pins''. 2. The current text implies that all offered tokens are consumed when an action starts, which is not intended, we believe (specially if two offers are incompatible). 3. ``precluding them from being consumed by any other actions'' does not belong here. We suggest: To start, the action must have at least one token per input. When starting, it accepts simultaneously exactly one token per input, then creates an action execution.
Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section 12 (03)

Key: UML22-929
Legacy Issue Number: 8672
Status: closed
Source: FUNDP ( Pierre Yves Schobbens)
Summary:
``Result pin'', ``Output pin'' or even ``Result output pin'' seem used interchangeably throughout the text. Replace by ``Output pin''.
Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section 12 (02)

Key: UML22-928
Legacy Issue Number: 8671
Status: closed
Source: FUNDP ( Pierre Yves Schobbens)
Summary:
A section ``Use'' containing methodological indications about the use of the construct should be added. Currently, such remarks are randomly spread into ``Description'', ``Semantics'', etc.
Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: UML is methodology independent; there should not be any methodological advice in the spec at all. Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix C Table 27

Key: UML22-920
Legacy Issue Number: 8610
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typo - Description column for <<systemModel>> Capitalize SystemModel when using the stereotype name. Is the description for <<metamodel>> worded correctly?
Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
agreed - fix
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix C Table 26

Key: UML22-919
Legacy Issue Number: 8609
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typos - Column Description for <<realization>> Change spelling to <<implementationClass>> to agree with the spelling in <<type>>. It's unfortunate that the column Name breaks the stereotype label so that one can't tell if the stereotype lable is one or two words. - Description for <<specification>> change to "...such as attributes and methods which are useful..." Place column headings on all pages.
Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: D.1

Key: UML22-922
Legacy Issue Number: 8613
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
EJBService has incorrect stereotype name shown inside guillemets. In description for EJBBusiness, change "level methods" to "level method."
Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
agreed - fix
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.8

Key: UML22-921
Legacy Issue Number: 8611
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Constraints 9 and 10 exclude composite states from using entry or exit points. Entry/exit points are allowed on composite states as mentioned on page 592 (see Issue 6075).
Reported: UML 2.0 — Sat, 19 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Remove constraints [9] and [10] as entry/exit point are essentially allowed on any region.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: D.3

Key: UML22-924
Legacy Issue Number: 8615
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Correct spelling of "oferred" to "offered" in Description of NETProperty. The Description of NETAssembly is an incomplete sentence that doesn't make a lot of sense. Rewrite
Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
agreed- fix
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: D.2

Key: UML22-923
Legacy Issue Number: 8614
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Correct spelling of "oferred" in Description of COMInterface. Complete cells (Parent, Tage, and Constraints) for COMTLB
Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
agreed - fix
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18

Key: UML22-915
Legacy Issue Number: 8605
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
General comments - The format of the Generalizations statement is not the same as previous chapters. For sub-sections that are empty either delete them or change the wording to "None."
Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue N/A for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.4

Key: UML22-914
Legacy Issue Number: 8604
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typos - Place a "." in the Reference cell for row Metaclass of table 23 and ProfileApplication of table 24
Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.3.8

Key: UML22-913
Legacy Issue Number: 8603
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation or a note that OCL notation is not available to Constraint [2]. Typo - Change "stereotypes is shown" to "stereotypes are shown" in 3rd line of 2nd para of Notation. - Change 3rd sent of 1st para below bullets under Icon presentation to "Some tools may use different images for the icon replacing the box." In fig. 447 lower case stereotypes "clock" and "creator, clock" to agree with naming convention and figs. 461 & 462. In para immediately following fig. 457, I believe the statement should be: "Note that the extensionEnd must be composite, and that the derived "isRequired" attribute in this case is false. Fig. 458 needs the derived slash infront of the isRequired attribute for :Extension. Typos - Lower case the stereostype name "clock" in sentence immediately fololowing fig. 458, immediately preceding fig. 460 and sentences preceding and following fig. 462. Lower case the stereotype name "creator" in the sentence following fig. 461.
Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix C Table 25

Key: UML22-918
Legacy Issue Number: 8608
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Suggest that the column headings are found on each page of the table. Typos - In the description of <<focus>> capitalize the first "Auxiliary." - In the description of <<implementationClass>> capitalize the word "Class" when used following "Implementation" as indicated by the statement "The actual name of the stereotype is the same as the stereotype label except that the first letter of each is capitalized." (Assuming you meant the first letter of each word of each stereotype label.) - Ditto with "Model Library." - Ditto with "Type." - In the description of <<modelLibrary>> correct spelling of "inteded" to "intended."
Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see page 405 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix B (02)

Key: UML22-917
Legacy Issue Number: 8607
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Table number does not fit with other tables in this Supersturcture and Appendixes. (Appendix C starts with Table 25.)
Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix B

Key: UML22-916
Legacy Issue Number: 8606
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typos - 2nd sent. of last para pg 745, rewrite as "...to indacate that it is a constructor..." - 3) under Notation Placement, delete the word "to." Check capitalization of keyword "buildcomponent" because pgs 771 and 777 spell it "buildComponent."
Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.3.7

Key: UML22-912
Legacy Issue Number: 8602
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typo - under Associations change "is" to "are."
Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.3.3

Key: UML22-911
Legacy Issue Number: 8600
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typo - 3rd sent, 2nd para under Description, change "changed" to "change." Association type:Stereotype[1] does not show the redefines statement in fig. 446. Additional Operations [1] "which was 1" statement does not agree with the last statement under Description. Fig. 446 shows a directional arrow from ExtensionEnd to Stereotype. This disagrees with first sentence of paragraph 2 of Description.
Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
There is no disagreement with first sentence of paragraph 2 of Description.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.3.2

Key: UML22-910
Legacy Issue Number: 8599
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The derived attribute isRequired default multiplicity is not supported by fig. 446. Please verify all mutliplicities between fig 446 and text for this concept agree. The association ownedEnd:ExtensionEnd[1] does not show that it redefines ownedEnd in the fig.446. Statement under attributes implies that the lower and upper bound must = 1 but Additional Operations [3] does not suppport this. Fig. 448 notation does not agree with text. If MOF notation is different, then clarify.
Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8453 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.2

Key: UML22-909
Legacy Issue Number: 8598
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typo - remove the extra slash below line between Class and Extension in fig. 446
Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.3.2

Key: UML22-908
Legacy Issue Number: 8596
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The definition of the attribute indicated that multiplicity may be [0..1], yet this is not supported by fig. 446 no by the association ownedEnd:ExtensionEnd[1]. Further, fig 446 does not indicate that the association ownedEnd:ExtensionEnd[1] redefines Association::ownedEnd. Additional Operations [3] says that a lower bound of 1 makes isRequired true, but the statement discussing attributes implies that the lower bound = upper bound. Shouldn't the Additional Operation [3] also indicate this? Notation in fig. 448 does not agree with the text description of the proper notation unless the notation for a MOF model is different than for UML in which case the text should explain that fig. 448 is not a UML notated diagram.
Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.6

Key: UML22-893
Legacy Issue Number: 8517
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete sub-section Attributes or change wording to "None." Change definition of association parameter:TemplateParameter to "The complete set of ordered formal template parameters for this template signature." This is indicated by fig. 427. I believe Constraint [2] should say "parameters are the owned parameter." Change wording of 2nd sent. of 2nd para of Semantics to "Either the parameter that owns the parametered element, or the element that is owned, directly or indirectly, but the template subclasses of TemplateSignature can add additional rules constraining what a parameter can reference in the context of a particular kind of template." I see no subclasses for TemplateSignature in the diagrams--just composite parts. The paragraph under ClassifierTemplates needs enhancement. What figure is being referenced? If it is fig. 429, that diagram does not support the text paragraph.
Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 379 - 380 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.5

Key: UML22-892
Legacy Issue Number: 8516
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delelte sub-section Attributes or change wording to "None." Change association name from "binding":Tto "templateBinding" to agree with fig. 428 or change fig. 428 association name from "templateBinding" to "binding."
Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.4

Key: UML22-891
Legacy Issue Number: 8515
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Under sub-section Notation, the last sentence says to see "ParameterableElement (from Templates)" on page 679 (and its subclasses)." What subclasses? I find none listed or diagrammmed in any figure. Delete sub-section Attributes or change wording to "None." Typo - Delete the second word ("the") of the second para of Semantics.
Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.7

Key: UML22-895
Legacy Issue Number: 8527
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The classifier for the association parameter:ParameterableElement[0..1] does not agree with fig. 429. The classifier is titled ClassifierTemplateParameter in the figure. In addition, the figure does not support that this association redefines ParameterableElement::parameter Fig. 413 shows an additional association: representation:InformationItem[*]. Please add this to the sub-section Typos - 2nd line, 1st para under Section, rewrite as "parameterable element so that a classifier can be exposed as a formal template paramenter, and provided as ...." - 1st line, under sub-section Description, put a comma after Kernal::Classifier. - 3rd line, 3rd para under sub-section Semantics insert the word "of" between "specialization" and "this anonymous." - Last sent., para 2 of Collaboration under sub-section Semantics, change the word "used" to something "identified" or "defined" or "decided." "We have used that..." is not very understandable. - Last para. of Collaboration under sub-section Semantics: change "produce" to "producer" and "NrokeredSale" to "BrokeredSale." Delete "And anyway," and change "Parameters, by the very nature..." to "Parameters, by their very nature..."
Reported: UML 2.0 — Wed, 9 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 382 - 383 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.1

Key: UML22-894
Legacy Issue Number: 8518
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
In fig. 412 the PrimitiveTypes package is sitting alone with no dependencies or navigation lines yet it is on the same level as Kernal, BasicActivities, BasicInteractions, and InternalStructures. If all of the other packages don't import elements from PrimitiveTypes, I would suggest offsetting the PrimitiveTypes package or putting it in a separate figure. Question - Why not develop PrimitiveTypes as an enumeration with Boolean, Integer, String, UnlimitedNatural, and UserDefinedKind or UserDefinedList as the elements of the enumeration?
Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.15

Key: UML22-901
Legacy Issue Number: 8588
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
It is very confusing to have two very similar concepts with the same name (17.5.14 and 17.5.15). Could the two concepts be combined into one, combining figure 440 with 441 and the text? If not, consider changing the name of one of the concepts. Association parameter:ParameterableElement is not what is diagrammed in fig. 441. Instead fig. 441 shows parameter:OperationTemplateParameter[0..1] with no redefinition mentioned.
Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.14

Key: UML22-900
Legacy Issue Number: 8587
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typo - Be consistent with the capitalization of "Operation" in sub-section Semantics
Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Indeed. Change the first case to lower case initial letter.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.12

Key: UML22-897
Legacy Issue Number: 8529
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The classifier name for the association nameExpression: in fig. 438 is StringExpression not Expression as indicated by text. In addition, the figure indicates that nameExpression:StringExpression[0..1] subsets ownedElement. Typo - under sub-section Notation in para "With alias:" change "is" in the first sent. to "are."
Reported: UML 2.0 — Wed, 9 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Indeed. These errors must be fixed.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.8

Key: UML22-896
Legacy Issue Number: 8528
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The redefines statement of association parameteredElement:Classifier[1] is not supported in fig. 429. Delete sub-section Constraints or change wording to "None." Change spelling of alloswSubstitutable to allowSubstitutable in 2nd sent. of last para of sub-section Notation.
Reported: UML 2.0 — Wed, 9 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see page 384 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.1.2

Key: UML22-907
Legacy Issue Number: 8595
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typos - Requirement 4 - delete the "of" immediately preceding the word "specializations." - Requirement 9 - Change the word "constraint" to "constrain."
Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.20

Key: UML22-906
Legacy Issue Number: 8593
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This seems to be a leftover from a previous edit. Remove the association item.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12 Activities

Key: UML22-899
Legacy Issue Number: 8544
Status: closed
Source: Universidad Peruana de Ciencias Aplicadas (UPC) ( ILVER ANACHE PUPO)
Summary:
In Figure 178 and 183 there is two different inheritance relationships. In 178 the class ControlNode is a direct parent for classes ActivityFinalNode and InitialNode. These two classes are a direct descendant from FinalNode in figure 183. These introduce two different inheritance taxonomy with different meaning.
Reported: UML 2.0 — Fri, 11 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8237 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.13

Key: UML22-898
Legacy Issue Number: 8530
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig. 438 shows an additional associaton: owningExpression:StringExpression[0..1] that subsets owner
Reported: UML 2.0 — Wed, 9 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Indeed. This item needs to be added.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.17

Key: UML22-903
Legacy Issue Number: 8590
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig. 442 does not show that the association parameter:ConnectableElementTemplateParameter redefines anything.
Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See the discussion to issue 8528. We will add a clarification to the diagram.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.16

Key: UML22-902
Legacy Issue Number: 8589
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig 441 for the association parameteredElement:Operation[1] does not mention that the association redefines TemplateParameter::parameteredElement.
Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see page 389 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.19

Key: UML22-905
Legacy Issue Number: 8592
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation to the constraint or a note that OCL notation is not available
Reported: UML 2.0 — Wed, 3 May 2000 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see page 392 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.18

Key: UML22-904
Legacy Issue Number: 8591
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig. 442 does not show that association parameteredElement:ConnectableElement redefines anything
Reported: UML 2.0 — Tue, 9 May 2000 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See the discussion on issue 8590.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.2.2

Key: UML22-883
Legacy Issue Number: 8507
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Not all of the sub-package names given in the sub-section Generalizations are shown in fig. 413. Add them or ellipses. Change capitalization of "information Item" and "Information Items" in sub-section Description to agree. If Information Item is an abstraction shouldn't the name appear in italics in fig. 413? Change last sent. of para 1, sub-section Description to "...for representing information in a very abstract way, one which cannot be instantiated." Change "taken" to "made" in first sent. of para 2 of Descriptions. Delete sub-section Attributes or change wording to "None." Add OCL notation to constraints [1] and [2] or a note that OCL notation is not available. Constraint [1] contains an enumeration list but this is not diagrammed as part of fig. 413. The constraint reads like a guard whose condition is that the InformationItem can only be of the enumerationKind listed in the constraint. Why not diagram it that way? Typos - 1st sent., Para 2 of sub-section Semantics, change "item" to "items." - 2nd sent., Para 3 of sub-section Semantics, reword to "specifying this detailed information belongs to the represented classifier." Question - Why is the multiplicity in fig. 418 0..1? Suggest removing all multiplicities from diag. 418 as they add nothing to it.
Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.2.1

Key: UML22-882
Legacy Issue Number: 8506
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typo - Change first sent. under sub-section Description to "...one or more information items circulates from its sources to its targets." Subject of phrase is singular (one or more) and needs the singular verb. Add OCL notation to the constraints or state that OCL notation is not available. Constraint [1] reads like an enumeration. Why is it not diagrammed showing an enumeration. Reword the except clause to "...and InstanceSpecification except when the classifier of the InstanceSpecification is a relationship (i.e., it represents a link)." Constraint [2] change "target" to "targets" and delete the prepositional phrase "if any." (Or explain how information can flow if there isn't at least one source and one target.)
Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Expansion region description

Key: UML22-872
Legacy Issue Number: 8488
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Expansion region description: "The number of output collections at runtime can differ from the number of input collections." Drop "at runtime".
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
The sentence is supposed to be about modeling time, rather than runtime.
Updated: Fri, 6 Mar 2015 20:58 GMT

ExpansionRegioin example, Figure 261: concurrent => parallel

Key: UML22-871
Legacy Issue Number: 8487
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
ExpansionRegioin example, Figure 261: concurrent => parallel
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, ExpansionRegion (05)

Key: UML22-870
Legacy Issue Number: 8486
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
<pre> In ExpansionRegion, clarify the interaction of elements from multiple input collections (ie, there is none). Clarify that the region operates on each collection in the specified mode. From Jim R: If there are N input collections (note there may also be plain scalar inputs, whose value remains constant in each of the executions), then one value from the same position in each of them represents a "slice". The slice is not actually formed into an object or a single value. The body of the region is executed once for each slice. Each of its pins gets the value from the given position in the corresponding input collection. Each execution is independent and concurrent, therefore the values from different positions do not interact. If the body interacts with an outside object, then there is a high possibility of conflict among the concurrent executions, so that is not usually recommened, although it is not forbidden by the UML2 rules. If it does happen, you can't assume any particular order of execution or even that two executions won't hit the same slot at the same time (in this, it is the same as all other uses of concurrency in UML). If each execution keeps to its own subset of values (for example, by indexing into a collection using the input position for that execution), then things might be OK; otherwise it's probably a real bad idea to use this construct. It works best when the computations are purely internal, in that case the concurrency poses no problems at all and permits total freedom in implementation; those kinds of computations are pretty common in practice. </pre>
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

mustIsolate:

Key: UML22-879
Legacy Issue Number: 8500
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
mustIsolate: The wording of UML 2 for StructuredActivityNode.mustIsolate refers to individual nodes instead of all the nodes in the group: If the mustIsolate flag is true for an activity node, then any access to an object by an action within the node must not conflict with access to the object by an action outside the node. A conflict is defined as an attempt to write to the object by one or both of the actions. If such a conflict potentially exists, then no such access by an action outside the node may be interleaved with the execution of any action inside the node. The UML 1.5 wording was better: Because of the concurrent nature of the execution of actions within and across procedures, it can be difficult to guarantee the consistent access and modification of object memory. [Examples snipped] In order to avoid these problems, it is necessary to isolate the effects of a group of actions from the effects of actions outside the group. This is indicated by setting the mustIsolate attribute to "true" on a group action. If a group action is isolated, then any object used by an action within the group cannot be accessed by any action outside the group until the group action as a whole completes. Any concurrent actions that would result in accessing such objects are required to have their execution deferred until the completion of the group action. In the first example above, if the read actions on the temperature and pressure attributes are wrapped in a group action with mustIsolate set to "true", then the temperature and pressure values read are assured to be consistent, since no changes can intervene between the two reads. Similarly, if an isolated group is used for the second action, then the update is assured to be consistent, since no action outside the group can change the list until the update is complete. Note" The term "isolation" is used here in the sense used in traditional transaction terminology. An execution engine may achieve any required isolation using locking mechanisms, or it may simply sequentialize execution to avoid concurrency conflicts. Isolation is different than the property of "atomicity", which is the guarantee that a group of actions either all complete successfully or have no effect at all. Atomicity generally requires a rollback mechanism to prevent committing partial results. This is beyond the scope of what can be guaranteed by the basic action semantics.
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

No notation

Key: UML22-878
Legacy Issue Number: 8499
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
In ConditionalNode: "A notational gloss is provided for this frequent situation." There is no notation
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of isAssured/isDeterminant in conditional node

Key: UML22-875
Legacy Issue Number: 8493
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Semantics of isAssured/isDeterminant in conditional node, the phrase "concurrently yield a value" sounds it is referring to tests that complete at the same instant in time. Would be clearer to drop "concurrently", since it isn't the concurrency that isAssured/isDeterminant is concerned with, it's the results.
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Add constraint in LoopNode

Key: UML22-874
Legacy Issue Number: 8491
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Add constraint in LoopNode that loop variable inputs should not have edges coming out of them. Otherwise, the value could leave the pin in the middle of the loop.
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

Key: UML22-873
Legacy Issue Number: 8490
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Loop node owns output pins as loop input variables, but pins must be owned by actions under the input/output associations in UML 2 (not in UML 1.5).
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
The filer is referring to the loop variable pins.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.3

Key: UML22-890
Legacy Issue Number: 8514
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Under sub-section Notation, the last sentence says to see "ParameterableElement (from Templates)" on page 679 (and its subclasses)." What subclasses? I find none listed or diagrammmed in any figure.
Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.3

Key: UML22-889
Legacy Issue Number: 8513
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete sub-section Attributes or change wording to "None." Add that the association boundElement also subsets Element::owner as shown in fig. 428. Change the association name from "template":TemplateSignature to "signature" in the text or change fig. 428 association name from "signature" to "template." The Examples sub-section makes no sense. ClassifierTemplate and PackageTemplate are not to be found in this document. Do you mean Classifier (pg 689) and Package (pg 696)? This section is TemplateBinding but no specializations are listed or referenced. Clarify this sub-section, in particular provide page numbers for the sections to which the reader is referred. Or change the name of Classifier to ClassifierTemplate and Package to PackageTemplate. If name change is made then change the names in all figures that contain these template names
Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see page 376 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.1

Key: UML22-888
Legacy Issue Number: 8512
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add associaton owningSubstitution:TemplateParameterSubstitution[0..1] that subsets Element:owner as shown in fig. 428.
Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.4

Key: UML22-885
Legacy Issue Number: 8509
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
PprimitiveTypes strike me more as an enumeration or list than a package. Consider changing them to an enumeration or list. Boolean is derived from George Boole and is generally capitalized whenever used. Please be consistent in capitalization of "Boolean" when using the word as an adjective. Sometimes on page 673 it is capitalized ("The Boolean condition") but other times it is not ("boolean type," "boolean attribute," and "boolean expression"). Delete sub-sections Attributes, Associations, and Constraints or change the wording to "None.
Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.3.1

Key: UML22-884
Legacy Issue Number: 8508
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
If model is an abstraction of the physical system shouldn't the name in fig. 419 be in italics? Attribute viewpoint:String[*] does not have the same multiplicity as shown in fig. 419 which is the default multiplicity of [0..*] as indicated on page 14 of this document. Delete sub-sections Associations and Constraints or change the wording to "None." Add the word "open" between small and triangle in 1st sent. of Notation. Typo - 2nd sent of sub-section Notation, change "is" to "are."
Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see page 371 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.2

Key: UML22-887
Legacy Issue Number: 8511
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete the sub-sections Attributes and Constraints or change the wording to "None." Association templateBinding:TemplateBinding[*] subsets Element::ownedElement according to fig. 428. Change wording in para 3, sent. 2 of sub-section Semantics to "...by expanding the templates to which it binds, since..." The Examples sub-section makes no sense. ClassifierTemplate and PackageTemplate are not to be found in this document. Do you mean Classifier (pg 689) and Package (pg 696)? This section is TemplateableElement but no specializations are listed or referenced. Clarify this sub-section, in particular provide page numbers for the sections to which the reader is referred.
Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see page 374 0f ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.1

Key: UML22-886
Legacy Issue Number: 8510
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete sub-sections Attributes and Constraints or change wording to "None." Add the association owningDefault:TemplateParamenter[0..1] that subsets owner. Fig. 427 shows this.
Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the semantics of minimum multiplicity > 0 for streaming parameters

Key: UML22-881
Legacy Issue Number: 8503
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Clarify that the semantics of minimum multiplicity > 0 for streaming parameters that it is required sometime during execution
Reported: UML 2.0 — Mon, 7 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 209 of Activites

Key: UML22-880
Legacy Issue Number: 8502
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Figure 209 of Activites, and entry in index: <<singleCopy>> should be replaced with <<singleExecution>>.
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
In Activities, Activity, Figure 209, replace "singleCopy" with "singleExecution".
Updated: Fri, 6 Mar 2015 20:58 GMT

Add constraints on conditional and loop nodes (02)

Key: UML22-877
Legacy Issue Number: 8497
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Add constraints on conditional and loop nodes that body outputs are pins on action contained in the body part of the clauses
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see page 361 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Add constraints on conditional and loop nodes

Key: UML22-876
Legacy Issue Number: 8496
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Add constraints on conditional and loop nodes that decider is an output pin of an action in the test body, and that its type is boolean
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Conformance / inconsistencies

Key: UML22-853
Legacy Issue Number: 8459
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
Summary:

There are two fundamental inconsistencies in the way that conformance is defined:
· BasicActions and BasicInteractions, which are defined at L1, both reference Signal and Event, defined in CommonBehaviors::Communications, which is defined at L2.
· Profiles are defined as L2 but Appendix C defines a profile for level L1. Clearly, if L1 is to support profiles, the definition of profiles needs to be defined at that level as well or a lower level.

Recommendation:

For the first item, move CommonBehaviors::Communications from L2 to L1

For the second item, a minimal impact resolution is to retain the L1 system as such, but to include it as part of compliance level L2. In general, the standard profiles should be specified explicitly as belonging to the appropriate compliance levels in section 2.4
Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 335 - 336 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / missing merges

Key: UML22-852
Legacy Issue Number: 8458
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
Compliance level L3 references, but does not merge:

Superstructure::Logical View::UML::CommonBehaviors

Superstructure::Logical View::UML::CompositeStructures

There are a number of diagrams in the UML2 Rose model that contain unlabeled dependencies between packages. In particular, Activities, Interactions, StateMachines, and UseCases have dependencies to CommonBehaviors that are unlabeled. See diagram UML/Behavior Packages and UML/UML Top-Level Packages.

Since CommonBehaviors does not contain any classes, it does not necessarily need to be merged into any compliance level. Instead, the packages it contains are merged as needed.

Recommendation:

Remove all unlabeled dependencies between packages, or mark them as either package imports or package merges as needed.
Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / improper subsetting

Key: UML22-851
Legacy Issue Number: 8457
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
The following properties (in the subsets constraints) are unresolved in their unmerged, containing package. The problem is that the properties in these subsets constraints are not defined in the unmerged package. They will be defined in the various compliance levels once the packages have been merged. However, the package merge rules (and the desire to be able to check OCL constraints on unmerged packages) require all references to be resolved before the merge.

Superstructure::LogicalView::UML::CompositeStructures::InternalStructures::Property::_structuredClassifier
{subsets classifier}

Superstructure::LogicalView::UML::Components::BasicComponents::Component::realization
{subsets clientDependency}

Superstructure::Logical View::UML::Deployments::Artifacts::Artifact::manifestation {subsets clientDependency}

Recommendation:

These are either resolved by including the proper superclass in the unmerged package so that the properties are visible, or copying the associations from another merged package in order to make the properties visible.
Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 330 - 333 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / invalid subset rule too strict

Key: UML22-855
Legacy Issue Number: 8462
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
The redefinition rule [4] of Property on page 127 of ptc/04-10-02 restricts a navigable property from being redefined by a non-navigable property. Unfortunately, this rule is violated in many parts of the model.

Recommendation:

As a practical resolution for this problem, it is suggested that this constraint be removed since it does not seem to provide any benefits and yet prevents the realization of the agreed design intent
Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Kernel / excessive restriction on redefinition

Key: UML22-854
Legacy Issue Number: 8461
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
In section 7.3.44 on pg. 130 of ptc/04-10-02 there is a constraint that states: “All redefinitions shall be made explicit with the use of a
{redefines <x>}
property string.” Unfortunately, this is violated in numerous places in the metamodel. This results in numerous inconsistencies in the metamodel.

Recommendation:

As a practical resolution with minimal impact, it is recommended that this restriction be removed. This means that the use of the same association end name for a given association end implies a redefinition of the corresponding association end in an ancestor class.
Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.3

Key: UML22-861
Legacy Issue Number: 8469
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Typo: Constraint 3 contains the word "IntectionFragment". Should be InteractionFragment
Reported: UML 2.0 — Sat, 5 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.6

Key: UML22-860
Legacy Issue Number: 8468
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete sub-section Attributes or change wording to "None." For the associations include:Include[*] and extend:Extend[*], the "Specialized Classifier.feature" is not shown in fig. 401. Add OCL notation to constraints [2] and [3] or indicate the OCL notation is not available. Add an ending ")" to Additional Operation OCL notation--one missing. Typo - 1st sent. of para 3 of Semantics, change "describe" to "Describes." There is no association or navigable link between UseCase and Actor shown in fig. 401. Add appropriate link(s).
Reported: UML 2.0 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, ExpansionRegion (04)

Key: UML22-869
Legacy Issue Number: 8485
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
In ExpansionRegion, clarify that that input pins on expansion regions (introduced by merge with CompleteStructuredActivities) provide values that are constant across the execution of the region, and that output pins are not allowed.
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, ExpansionRegion (03)

Key: UML22-868
Legacy Issue Number: 8484
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
ExpansionRegion: require that all input collections have the same number of elements at runtime.
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, ExpansionRegion (02)

Key: UML22-867
Legacy Issue Number: 8483
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
ExpansionRegion: remove "If an expansion region has outputs, they must be collections of the same kind and must contain elements of the same type as the corresponding inputs." Inputs and outputs of expansion regions do not need to correspond, this was intended to refer to the pins that flows to the output. Add general constraints on types of source and targets of object flows rather than have the a special case for expansion nodes.
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.5

Key: UML22-859
Legacy Issue Number: 8467
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add the generalization "NamedElement (from Kernal)" on page xxx (page 100 I believe). This generalization is shown in fig. 401 and mentioned in the Description sub-section. Delete sub-sections Attributes and Constraints or change wording to "None." In sub-section Semantics, I'm not certain that the following statement is reflected in fig. 401 "Since the primary use of the include relationship is for reuse of common parts, what is left in a base use case is usually not complete in iteself by dependent on the included parts to be meaningful. This is relfected in the direction of the relationship, indicating that the base use case depends on the addition but not vice versa." Reword 2nd sent of para 2, Semantics, to "All of the behavior of the included use case is executed...." or "The included use case behavior is executed at a single..."
Reported: UML 2.0 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.4

Key: UML22-858
Legacy Issue Number: 8466
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig. 401 shows 2 associations: extend:Extend{*] and useCase:UseCase[1]. Define these in the sub-section Associations. Delete sub-section Attributes or change the wording to "None."
Reported: UML 2.0 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see page 342 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.3

Key: UML22-857
Legacy Issue Number: 8465
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Under sub-section Generalizations add the generalization "NamedElement (from Kernal)" on page xxx" (page 100 I believe). This generalization is diagrammed in fig. 401. Delete sub-section Attributes or change wording to "None."
Reported: UML 2.0 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Indeed. This was a missed generalization.
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Common Behaviors / missing multiplicites

Key: UML22-856
Legacy Issue Number: 8463
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
In figure 318 on page 463, the multiplicities of DurationObservationAction::duration and TimeObservationAction::now are not specified. This results in violations of the redefinition rules for these association ends.

Recommendation:

Set the multiplicities for these association ends to 1, to conform to the multiplicity of WriteStructuralfeatureAction::value association end that they redefine
Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, ExpansionRegion

Key: UML22-866
Legacy Issue Number: 8482
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
ExpansionRegion, clarify wording in description: expansion nodes are not input pins.
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

Key: UML22-865
Legacy Issue Number: 8481
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
<pre> ExceptionHandler, clarify working of constraint [1]: "[1] The exception body may not have any explicit input or output edges." It should say the exception handler and its input object node are not the source or target of any edge. </pre>
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

ValueSpecificationAction, Attribute section, is missing the return pin

Key: UML22-864
Legacy Issue Number: 8478
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
ValueSpecificationAction, Attribute section, is missing the return pin
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions

Key: UML22-863
Legacy Issue Number: 8477
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Figure 141, remove import from IntermediateActions to Communications. Add an import from BasicActions to Communications
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Common Behavior

Key: UML22-862
Legacy Issue Number: 8476
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Common Behavior: why does Figure 326 refer to Signal from Communications, but not Operation form Communications? (it looks like Communications can refer to Kernel:Operations rather than defining its own).
Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.14

Key: UML22-841
Legacy Issue Number: 8443
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Association guard:Constraint[0..1] subsets ownedElement. Need to add this to the definition. Association replacedTransition:Transition[0..1] redefined redefinedElement. Need to add this to the definition. Association /redefinitionContext:Classifier[1] subsets redefinitionContext. Need to add this to the definition. Also need to add OCL notation. Constraint [2] - delete last paranthesis. Add OCL notation or a note that OCL cannot express constraint [7]. Add OCL notation or a note that OCL cannot express Additional operation [1]. Typos - pg. 626, para 4, sent 2, add "s" to transition. - pg. 627, 1st bullet under sub-section Example, first sent, delete the final "s" in "states." Why aren't he bulleted statements under sub-section Enabled (compound) transitions constraints? The activities named in fig. 396 ("MinorReq = ID;" and "MajorReq = ID:") are not the same format as indicated in Table 20 ("MinorReq := Id;") - the colon is missing before the equal sign in the figure.
Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix A

Key: UML22-840
Legacy Issue Number: 8440
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
A use case diagram is a structural diagram. Similar to operations in classes in shows the structure of the system services. Therefore a use case is a specialized Classifier and not Behavior like model elements of all other behavior diagrams (interaction, activity, and state machine).
Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.11

Key: UML22-837
Legacy Issue Number: 8416
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Attributes are derived and need this noted. Also add OCL notation to the derived attributes as per the "How to Read this Specification" (page 14)indicates will be done. isComposit=(region>1) - modified from page 14. isOrthogonal=(region>=2) ??? isSimple=((region=0) and (submachineState=0)) ??? isSubmachineState=(SubmachineState>0) I question the multiplicity of the association connection:ConnectionPointReference[*]. Shouldn't it be [0..*] because the association wouldn't exist if the state was simple or compound. Ths association also subsets ownedMember and that needs to be added to the definition. According to fig. 354, the multiplicity for connectionPoint:Pseudostate is 0..8 and this association subsets ownedElement. I question the multipliticy of the association deferrableTrigger:Trigger[*]. Do all state have MULTIPLE deferrable triggers? First paragraph on page 605 says "a state may specify a set or event types that may be deferred in that state." Associations doActivity:Behavior[0..1], entry:Behavior[0..1], and exit:Behavior[0..1] all subset ownedElement according to fig. 354. Association redefinedState:State[0..1] redefines redefinedElement. This needs stating in the definition. I question the multiplicity of region:Region[*]. If the state is a simple state it has no regions (page 600). Change the multiplicity to [0..*] here and in fig. 354. Association /redefinitionContext:Classifier[1] subsets redefinitionContext and needs mentioning in the definition. Add OCL notation to constraint [3]. OCL font format doesn't appear correct for constraint [4]. Constraint [7] repeats constraint [1] but is just worded and expressed slightly differently. Should bulleted statements on page 605 immediately above Entering a non-orthogonal state be added as constraints? Should an exit point be added to the ATM state machine in fig. 391?
Reported: UML 2.0 — Tue, 1 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.11

Key: UML22-836
Legacy Issue Number: 8415
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
No mention of figures 387 and 390 are made in the text. Reference figure 387 on pages 600 (Composite state) and page 606 (Entering an orthogonal composite state). Reference figure 390 at end of paragraph 2 on page 613. Typos - In sentence under Exiting an orthogonal state, change "is" in last sentence to "are." - Under Composite state (pg 609) Upper case Decomposition compartment. - Page 606, Under Exiting non-orthogonal state, change "from a composite state..." to "from a simple composite state..." to agree with the line just above Simple state in sub-section Description on page 600. - Page 606, first paragraph, change "il defined" to "ill defined." - Page 612, under Examples, change "sub state machine" to "submachine state." - Page 614, first line, change "In Figure 391 this state machine" to "In Figure 391 the state machine of figure 389 an figure 390." - Page 614, first line of Rational change "Submachine states...has been..." to "State machines...have been...."
Reported: UML 2.0 — Tue, 1 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Minor typos and consistency with figures.
Updated: Fri, 6 Mar 2015 20:58 GMT

Action Semantics Section: 9.5

Key: UML22-835
Legacy Issue Number: 8413
Status: closed
Source: Codesic Consulting, Inc. ( Jeff Barnes)
Summary:
The JumpAction->Inputs section documents jumpOccurrence:RuntimeInstance[1..1]. The second sentence of the documentation contains a typo that makes the meaning of the documentation unclear. Please re-write the second sentence.
Reported: UML 1.4.2 — Tue, 1 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Appendix C.1

Key: UML22-839
Legacy Issue Number: 8439
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
script is an artifact stereotype on compliance level L1. Artifact is an element on level L2. That's a mismatch.
Reported: UML 2.0 — Wed, 2 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Indeed. The entry should be moved to compliance level L2.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.12

Key: UML22-838
Legacy Issue Number: 8433
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete sub-section Attributes or change line to "None." Association connectionPoint:Pseudostate[*] subsets ownedMember. According to fig. 354, there is an association submachineState:State[*] that needs to be added and defined in the text. Association extendedStateMachine:StateMachine[*] redefines:redefinableElement I think. Figure 355 is overwritten by fig. 356 and this association is hard to read. In fig. 355, classifier StateMachine is not generalized or connected to any other classifier in the figure. Draw appropriate connections or make the StateMachine classifier a separate figure. Correct spelling of "conectionPoint" in OCL notation for constraint [3]. Add OCL notation to Additional Operations [1], [3], and [4] or otherwise note that OCL notation is not available for these operations. Typos - Para immediately above Run-to-completion and concurrency (pg. 671), change "... the invoked object complete..." to "...the invoked object completes..." - Page 619, 7th para. change "is" to "are." - Page 612, 1st para, last sent., does the capitalization of "verifyTransaction" need changing? - Personal preference for easier understanding place commas in "for, e.g., classes" on page 623 in sub-section Rational (second such labeled sub-section). Complete the sentence/paragraph for the last paragraph under StateMachine extension.
Reported: UML 2.0 — Tue, 1 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Specification: Action Semantics Section: 9.5

Key: UML22-834
Legacy Issue Number: 8412
Status: closed
Source: Codesic Consulting, Inc. ( Jeff Barnes)
Summary:
Figure 27 illustrates a directed association from JumpHandler to HandlerAction. Yet the documentation on page 115 says there is a reference from HandlerAction to JumpHandler (jumpHandler 1..1). Where is the association from HandlerAction to JumpHandler? The multiplicity at the (non-navigable) JumpHandler end of A_HandlerAction_JumpHandler is 0..*.
Reported: UML 1.4.2 — Tue, 1 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.10

Key: UML22-833
Legacy Issue Number: 8411
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete sub-section Attributes or change line to "None." Fig. 354 shows that association transition:Transition[*] subsets ownedMember as does association subvertex:Vertex[*]. Fig. 355 shows that association extendedRegion:Region[0..1] redefines redefinedElement and that association /redefinitionContext:Classifier[1] subsets redefinitionContext. Within subsections Additional constraints and Additional operations stateMachine often appears with a lower case "m." Typo - delete the apostrophy starting the sentence in Additional constraing [2].
Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.9

Key: UML22-832
Legacy Issue Number: 8410
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Font style is not consistent in the list of literal values for PseudoStateKind. Delete sub-sections Attributes and Associations or change line to "None."
Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Minor editorial follow suggestions
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.16

Key: UML22-843
Legacy Issue Number: 8445
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The multiplicities for the association definitions do not agree with those shown in fig. 354. Typo - Additional operation [1], change "sate" to "state." Question - Are the "?" and "-- no other valid cases possible" legal OCL notation?
Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 319/320 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.15

Key: UML22-842
Legacy Issue Number: 8444
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation to the constraints or a note that OCL notation is unavailable for these constraints. Typos - first bullet of sub-section Semantics, change "occur" to "occurs." - second bullet of sub-section Semantics, cange "stat" to "state." If a transition of kind external leaves the border of the composite state, how can it end at the composite state itself? Please provide a figure to illustrate this.
Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Collaborations / improper subset

Key: UML22-850
Legacy Issue Number: 8456
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
In figure 100 of ptc/04-10-02, the association end Classifier::representation subsets “Classifier::occurrence” and should subset “Classifier::collaborationUse”. The fix should also be applied to the Associations specification for Classifier in the Composite Structures chapter on page 175.

Recommendation:

Change figure 100 as specified above.

In the entry for Associations of Classifier on page 175, replace the parenthesized expression:

Subsets Classifier.occurrence

By the expression:

Subsets Classifier.collaborationUse
Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Profiles::ObjectNode has wrong default multiplicity

Key: UML22-849
Legacy Issue Number: 8454
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
ObjectNode::upper should have default multiplicity unbounded (“*”) in order of object nodes to be multi-valued by default.

Recommendation:

Redefine inherited MultiplicityElement::upper to have default “*” in ObjectNode.
Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Profiles::ExtensionEnd has wrong default multiplicity

Key: UML22-848
Legacy Issue Number: 8453
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
ExtensionEnd should have a default multiplicity of 0..1 which differs from the inherited MultiplicityElements::lower which defaults to 1. I think therefore that there needs to be an override by ExtensionEnd redefining lower with a different default.

Recommendation:

Redefine inherited MultiplicityElement::lower to have default 0 in ExtensionEnd.
Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
OK, that is a more accurate specification.
Updated: Fri, 6 Mar 2015 20:58 GMT

Should Profiles::Image be an Element?

Key: UML22-845
Legacy Issue Number: 8449
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
Should Image a subclass of Element? Image and diagram interchange may benefit from reflective capabilities inherited from MOF. Having Image, and all UML metaclasses be a subclass of Element may make it easier for MOF based tools to reflectively navigate the visual notation.

Recommendation:

Make Profiles::Image a subclass of Element
Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 323/324 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.7

Key: UML22-844
Legacy Issue Number: 8446
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Inconsistent in the spelling of pre- and post-condition vs pre condition and post condition. Other sections use pre- and post-condition. Association postCondition:Constraint[0..1] subsets ownedElement and preCondition:Constraint[0..1] subsets guard according to fig 357. Question: Why doesn't association postCondition:Constraint subset guard instead or inaddition to ownedElement? For other concepts where pre- and post-conditions exist, they both subset guard
Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Remove redundant superclass for Element

Key: UML22-847
Legacy Issue Number: 8452
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
Abstractions::Comments::Comment is a subclass of Abstractions::Comments::Element which is a subclass of Abstractions::Ownerships::Element. The resolution to issue 6279 redefines package merges such that the Element superclass of Element should be removed.

Recommendation:

Delete Abstractions::Comments::Element, and make Comment a subclass of Ownerships::Element. Move the associations from Comments::Element to Ownerships::Element
Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

OCL for Property::opposite() is incorrect:

Key: UML22-846
Legacy Issue Number: 8451
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
OCL for InfrastructureLibrary::Core::Constructs::Property::opposite() should it be:

opposite =

if owningAssociation->empty() and association.memberEnd->size() = 2 then

let otherEnd = (association.memberEnd - self)->any() in

if otherEnd.owningAssociation->empty() then otherEnd else Set{} endif

else Set {}

endif

Recommendation:

Fix the operation definition.
Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.8

Key: UML22-831
Legacy Issue Number: 8409
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typo - Change "Pseudostate are" to "Pseudostates are" in sub-section Description. Fig. 354 says that the association stateMachine:Statemachine[0..1] subsets namespace. Also correct "Statemachine" to S"tateMachine." Fig 354 also shows an association state:State[0..1] that subsets owner. Correct the number of parantheses for constraints [1], [4], and [6]. Bold the word "and" in constraint [3.
Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Minor editorials change following suggestions
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.7

Key: UML22-830
Legacy Issue Number: 8408
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typos - "In a protocol state machine, several transitions can refer to the same operation as illustrated below." Change below to "Figure 366" as the figure is above the text in the current version. Para. above Unreferred Operations, change "stat" to "state." Association "\referred:Operation[0..*]" needs the slash direction changed to "/" and the multiplicity of fig. 357 doesn't agree with that listed in the text. Change "No additional attributes" to "None."
Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Minor editorials
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.26

Key: UML22-817
Legacy Issue Number: 8350
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typos - Place a period "." at the ent of i) and iii); In first line of Style guidelines sub-section, change "are" to "is."
Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.25

Key: UML22-816
Legacy Issue Number: 8349
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The associations toBefore:GeneralOrdering and toAfter:GeneralOrdering use "EventOccurrence" in the definition. OccurrenceSpecification appears to be the renamed "EventOccurrence." The class EventOccurrence is not defined as a concept in this document. However, the name is still used in many places. EventOccurrence occurs in the following places: figures 307, 308, and 347; pages 509 (weak sequencing # 3), 544, 549, and 794; and in the Frame row, Notation column of tables 14, 16, 18, and 19. Either change the class name or define the concept
Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.1

Key: UML22-823
Legacy Issue Number: 8401
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typo - Delete the word "of" from the first sent. of sub-section Descriptions. Delete sub-section Attributes or state "None" instead of "No additional attributes." The multiplicities for the associations entry:Pseudostate[1..*] and exit:Pseudostate[1..*] don't agree with figure 354. Change the word "refreshens" to "references" in association definition for state:State[0..1]. In sub-section Semantics, last words of para 2, change "pseudo states" to "pseudostates." Under sub-section Presentation Options change Figure "362" to "361" in the para talking about entry point and change Figure "361" to "362" in the para talking about exit point. Just thought I'd mention that when I printed a hardcopy (PDF using Adobe Acrobat Reader 6.0), the submachine state symbol in fig. 359 had a bold outline and the entry circle is normal weight whereas the submachine state symbol line weight in figs. 360-362 are normal weight as is the example on pg, 638. The exit circle in fig. 360 and on pg. 638 is in bold line weight. There also appears to be a difference in the line weights in the softcopy version.
Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1

Key: UML22-822
Legacy Issue Number: 8387
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Fig. 87 on page 157 shows a composite structure diagram. Therefore the horizontal line below the component name is missing (see 9.3.13 for composite structure notation).
Reported: UML 2.0 — Sun, 27 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This line is optional. Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.6

Key: UML22-829
Legacy Issue Number: 8407
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Change "No additional attributes" to "None." The association conformance:ProtocolConformance[*] subsets ownedElement. Please add a specialization statement to the definition. Fig. 357 shows another association: interface:Interface[0..1] that subsets namespace. Add to associations or delete from fig. Constraint [3] is missing two ending parantheses but they may be found in constraint [4] as it has two extra. Delete the very small dot in front of the list of specifications in sub-section Semantics. "Depending on the context" is confusing in light of constraint [1] and "or they can be different" needs further explanation. Totally reword and redefine this paragraph. I, unfortunately, don't know enough to help you further. Typos - Reword to "Protocol state machine interpretation can be: Change "sub-statemachines" to "sub-state machines" in first line of next to last para in sub-section Semantics. In last para of sub-section Semantics, last word of second sent. should be "machines."
Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.42

Key: UML22-828
Legacy Issue Number: 8406
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
Summary:
In the ReplyAction specification, the association replyValue is specified as an OutputPin which is inconsistant with the specification of this association on Figure 152 (p 241) where it is specified as an InputPin to ReplyAction. The specification page 300 should be changed to InputPin instead of OutputPin.
Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8197 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.20

Key: UML22-812
Legacy Issue Number: 8345
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
According to fig. 329 the association interaction:Interaction[1] subsets namespace and the association argument:ValueSpecification[*] is ordered and subsets ownedElement. Correct text to reflect fig. Constraint [3] change the last word from "Parameter" to "Argument." In sub-section Semantics, para. 4, delete the dash . Typo - First para., pg 540, put a space between "as" and "well" In sub-section Notation, begin a new paragraph with the second sent. of the current 3rd paragraph
Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.19

Key: UML22-811
Legacy Issue Number: 8343
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Change class name for the association selector to OpaqueExpression (as per fig. 328) or change class name on fig. 328. Interaction:Interaction[1] subsets namespace according to the fig. Mention the specialization in the text definition. Typo - First sent. of Semantics change "OccurrenceSpecification" to "OccurrenceSpecifications."
Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.24

Key: UML22-815
Legacy Issue Number: 8348
Status: closed
Source: Anonymous
Summary:
Change the name of the enumeration list to MessageSortKind on fig. 329, as the section heading, and in sub-section Description
Reported: UML 1.4.2 — Thu, 24 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.21

Key: UML22-814
Legacy Issue Number: 8347
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
In sub-section Description, change enumerator name from MessageSort to MessageKind
Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Notice that the Issue refers the wrong section. The correct section number is 14.3.22.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.21

Key: UML22-813
Legacy Issue Number: 8346
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Since the description say that a MessageEnd represents what can and not what must occur at the end of a message and fig. 329 shows the multiplicity of the association to be 0..1, change the multiplicity of messate:Message from [1] to [0..1].
Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.5

Key: UML22-827
Legacy Issue Number: 8405
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typos - For consistency, spell as "pre- and post-conditions" in the Semantics sub-section
Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.5

Key: UML22-826
Legacy Issue Number: 8404
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typo - In sub-section Description, change "abide" to "abides." Under sub-section Attributes, change "No additonal attributes" to "None." According to fig. 357, associations specificMachine:ProtocolStateMachine[1] subsets source, subsets owner and generalMachine:ProtocolStateMachine[1] subsets target. Mention these specializations in the definitions. Change sent. under sub-section Constraints to "None."
Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.4

Key: UML22-819
Legacy Issue Number: 8352
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Be consistent in the use of the period (.) ending the statement in the reference column of the tables. Place a period at the end of the sentence under sub-section Graphic Paths, pages 554 and 561. First line, page 556 shange shows to show.
Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.29

Key: UML22-818
Legacy Issue Number: 8351
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Association invariant:Constraint[1] subsets ownedElement and association covered:Lifekube[1] redefines (not subsets/specializes) covered according to fig. 328. Typos - Last sentence of sub-section Semantics, change has to have and is to are.
Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.4

Key: UML22-821
Legacy Issue Number: 8357
Status: closed
Source: CEA ( Gerard Sebastien)
Summary:
p 346, keyword «singleExecution» is used for activities that execute as a single shared execution. p 347, keyword «singleCopy» is used in figure is used to specify single execution. Anyway use an uppercase for the first letter of the keyword, as done for Precondition and Postcondition.
Reported: UML 2.0 — Fri, 25 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Pre and postconditions use lowercase first letter like all keywords, see Figure 207.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.5

Key: UML22-820
Legacy Issue Number: 8356
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
Summary:
The specification says: "If isReplaceAll is false and the structural feature is unordered and nonunique, then adding an existing value has no effect." This should be replaced by: "If isReplaceAll is false and the structural feature is unordered and UNIQUE, then adding an existing value has no effect."
Reported: UML 2.0 — Fri, 25 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.3

Key: UML22-825
Legacy Issue Number: 8403
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Change "No additonal attributes." to "None."
Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.2

Key: UML22-824
Legacy Issue Number: 8402
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig. 354 shows the association owningState:State[*]. Please add this to the sub-section or delete it from the diagram. Also, explain how a state can have multiple final states as indicated by the multiplicity in the figure. In the sub-section Semantics, the first sentence seems to contradict constraint number [4]. Please clarify more fully how a final state may be entered if there can be no entry behavior.
Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.17

Key: UML22-810
Legacy Issue Number: 8341
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Change the name of this enumeration to InteractionOperatorKind and add "break" to the list of Literals in the text
Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.16

Key: UML22-809
Legacy Issue Number: 8340
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typo - 2nd sent. under sub-section Description change represent to represents. Add specialization notes to definitions for associations. Association fragment:InteractionFragment subsets ownedMember according to fig. 331 and is ordered. Typo - End the 2nd paragraph under sub-section Semantics with a period. Association guard:InteractionConstraint subsets ownedElement.
Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.15

Key: UML22-808
Legacy Issue Number: 8339
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Separate the associations into packages. Add the specialization for subsets namespace to enclosingOperand:InteractionOperand[0..1] and subets ownedElement for enclosingInteraction:Interaction[0..1] as shown in the appropriate figures.
Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.2

Key: UML22-797
Legacy Issue Number: 8323
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Multiplicity of the association does not agree with fig. 330. Change fig. to agree with text definition
Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13

Key: UML22-796
Legacy Issue Number: 8322
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
General comments: Add OCL notation to the constraints where possible. If not possible state that OCL notation is not available for the constraint. Either delete sub-section headings where there is no data for the sub-section or add the word "None." Make certain that the multiplicities for the associations agree between the text and the associated figures. There is inconsistency in representation of 0..* on figures, sometimes the figures use * to mean 0..* (according to the text definitions) and then sometimes 0..* is used. Several times the figures will note that an association is a redefinition of or subsets a class but the text does not mention this. Be certain to add the appropriate statement to the text definition.
Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue N/A for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.30

Key: UML22-795
Legacy Issue Number: 8320
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The generalization "Dependencies" is not listed in fig. 316 under NamedElement. Add this to the figure. The association port:Port[*] is not diagrammed anywhere. Either remove this association from the text or add it to a figure. The sub-section Changes from UML 1.x indicates that the corresponding metaclass was changed from Event but names listed in the BNF definition are all children or grandchildren of the metaclass Event in fig. 317. I believe something needs to change or be clarified but I don't know what.
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.13

Key: UML22-807
Legacy Issue Number: 8338
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Separate the associations into appropriate packages which are identified. Multiplicity of association lifeline:LifeLine[0..*] is not diagrammed as 0..*. The association is diagrammed as subsets ownedMember. The association event:MessageEnd is not diagrammed anywhere. If such an association exists, it should probably be diagrammed in fig. 329. Association message:Message[*] subsets ownedMember in fig. 329. Association action:Action[*] subsets ownedElement in fig. 330. Typos - 2nd paragraph, pg 527, 2nd sent. should be "Similarly the deteailed actions...are often omited in Interactions,..." Delete the word "are" from 1st sent. of 3rd para under Notation
Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.14

Key: UML22-806
Legacy Issue Number: 8337
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Both associations are shown in fig. 331 as "subsets ownedElement" so please add this specialization to the definition text or remove notes from the figure.
Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.4

Key: UML22-799
Legacy Issue Number: 8325
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Attribute sub-section heading needs to be changed to Associations. Fig. 331 shows message:NamedElement[0..*] as an association
Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.3

Key: UML22-798
Legacy Issue Number: 8324
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Association operand:InteractionOperand[1..*] subsets ownedElement according to fig. 332. Please add appropriate specializes comment to text. Typo - In the last sentence of sub-section Semantics for Loop change wording from "The loop construct represent..." to "The loop construct represents..."
Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.10

Key: UML22-803
Legacy Issue Number: 8329
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typos - Under sub-section Notation, start 3rd paragraph with "For ExecutionSpecification..." In the last sentence of paragraph 3 of Notation write " "(and start and finish associations refer to the very same OccurrenceSpecification)."
Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.8

Key: UML22-802
Legacy Issue Number: 8328
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typos - Correct Semantics sub-section sentence to "An execution event represents the start or finish of the execution of an action or a behavior."
Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.6

Key: UML22-801
Legacy Issue Number: 8327
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
If DescriptionEvent has a constraint that no other OccurrenceSpecification may appear below the OccurrenceSpecification that references the DescructionEvent on a given Lifeline in an InteractionOperand then a similar constraint should be added to the CreationEvent. "No other OccurrenceSpecification may appear above an OccurrenceSpecification which references a CreaationEvent on a given Lifeline in an InteractionOperand."
Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.5

Key: UML22-800
Legacy Issue Number: 8326
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig. 331 does not show package name for the generalization InteractionFragment. Typo - Change paragraph 3 of Notation to "A Continuation that is alone in an InteractionFragment is considered to be at the end of the enclosing InteractionFragment."
Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.29

Key: UML22-794
Legacy Issue Number: 8319
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
To be consistent with other multiplicities in fig. 318, add the association multiplicity to the figure. Mention that the association redefines value as shown in the figure. I am not familiar with BNF notation but should "<timeobservation>" be spelled "<timeObservation>?"
Reported: UML 2.0 — Sat, 26 Feb 2000 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.28

Key: UML22-793
Legacy Issue Number: 8318
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
To be consistent with other multiplicities on the figure, add the multiplicities for the associations. Also mention that each association redefines minimum or maximum
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see ptc/2006-04-01 p 261
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.27

Key: UML22-792
Legacy Issue Number: 8317
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Under sub-section Description change "represent" to "represents." Under sub-section Notation, reword "Often a TimeExpression is a non-negative integer" to "Often a TimeExpression is an UnlimitedNatural number." Saying that often a TimeExpression is a non-negative integer implies that it may, at times, be a negative integer
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see ptc/2006-04-01 p 260
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.12

Key: UML22-805
Legacy Issue Number: 8331
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Change wording of definitions for associations to: "The OccurrenceSpecification referenced that comes before the OccurrenceSpecification referenced by after" and "The OccurrenceSpecification referenced that comes after the OccurrenceSpecification referenced by before"
Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.3 & 14.3.11

Key: UML22-804
Legacy Issue Number: 8330
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The Description for the concept Gate identifies the different roles gates play as formal, actual, and expression. Fig. 332 uses the terms formal and actual in the association names but not expression. I think expression is very descriptive and suggest changing the name of the association from cfragmentGateGate to expressionGate:Gate. This would require changing figure 332 and the text for CombinedFragment.
Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.26

Key: UML22-791
Legacy Issue Number: 8316
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add package name SimpleTime to association when:TimeExpression[1]. Fig. 318 shows that this association redefines when. Add the association for the package Communications as shown in fig. 317. This is when:ValueSpecification[1] that subsets ownedElement.
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Resolved by resolution to issue 8894.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.24

Key: UML22-790
Legacy Issue Number: 8315
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig. 317 shows signal:Signal[1] as an association of SignalEvent, not an attribute. Either correct text or figure. Delete the "." leading the first paragraph under the sub-section Notation
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.3

Key: UML22-776
Legacy Issue Number: 8297
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Multiplicities for the associations need to be added to the text for raisedException:Classifier[0..*], and changed in the associated diagrams to reflect the correct multiplicity (1 for method:Behavior (according to the text) and not * as shown in fig. 311 and 0..* for fig. 315). Unless "specializes" means the same thing as "redefines" change either the text for raisedException:Classifier from specializes to redefines or change fig 315. from redefines to specializes. Regardless, less confusion would occur if the text and the figure used the same word.
Reported: UML 2.0 — Fri, 18 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.2

Key: UML22-775
Legacy Issue Number: 8295
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Specialization mentioned for the association context:BehavioredClassifier[0..1] is not shown on figure 311. Multiplicities for ownedParameter:Parameter in the text do not agree with fig. 311. According to the text the ownedParameter:Parameter references a list of parameters "that can be given" which implies that no parameters may be given and therefore the multiplicity should be [0..*]. This is not what is shown in fig. 311. Multiplicities for remaining associations listed do not agree between the text and the diagrams (fig. 311 & 313). Multiplicities should probably be [0..*] which are not what are shown in figs. 311 & 313. Add the specialization for the association redefinedBehavior:Behavior in the text to agree with fig. 311. Specializations listed for the associations precondition:Constraint and postcondition:Constraint do not agree with fig. 313. Figure 313 shows that these associations subset ownedRule. Add OCL notation to the constraints where possible or indicate that OCL notation is not available.
Reported: UML 2.0 — Thu, 17 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
In the recent version of the specification, the specialization for context:BehavioredClassifier has already been added. The multiplicities mentioned above are all “” which is equivalent to “0..”. To correct the remaining mismatch between text and diagram:
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.14

Key: UML22-784
Legacy Issue Number: 8308
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation or a note that OCL is unable define a notation for the constraints.
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.12

Key: UML22-783
Legacy Issue Number: 8307
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
To be consistent, add the multiplicity for duration:Duration[1] to figure 318. Also, fig. 318 indicates that the association redefines value. Please indicate this in the text. I am not familiar with BFN but should "<urationobservation>" be "<durationObservation>"?
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.4

Key: UML22-778
Legacy Issue Number: 8301
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Under sub-section Generalizations change "Class" to "Classifier." Figures use italics for displaying the concept name so you need to mention that BehavioredClassifier is an abstract class. Under sub-section Associations add package name BasicBehaviors before the first two associations. Add the multiplicity which should probably be [0..*] and if this is correct then change fig. 311 to agree with [0..*] or 1 as is currently indicated by the text. If the multiplicity is as indicated in fig. 311 , then change the text to agree. For the association ownedTrigger:Trigger[0..*], fig. 316 does not indicate this multiplicity. Make the two agree. Add OCL notation or a note that OCL can not supply notation. The sub-section Semantics describes two BehavioredClassifiers - an immediate event and an input event pool. Possibly consider making these children of BehavioredClassifiers or of Event (fig. 316), i.e. ImmediateEventOccurrence and InputEventPool, instead of just Event. If this is done then two additional concepts would need to be added.
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.8

Key: UML22-780
Legacy Issue Number: 8303
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Under sub-section Description change "each of its instance" to "each of its instances." The multiplicity for the association ownedReception:Reception in the text does not agree with fig. 314. If it is [0..*} both text and fig. 314 need changing. Specializes Classifier.feature is not shown in fig. 314 as a specialization of Class but rather as a subset of Interface. Correct either the fig. 314 or text.
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.7

Key: UML22-779
Legacy Issue Number: 8302
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add the specializes or subsets comment to the association to agree with fig. 317. Question: If the default value of a Boolean expression is true and its value changes to false would there be a corresponding changeExpression? To me the description and semantics imply that the default value for all Boolean expressions is set at false and this isn't true (e.g., MutliplicityElement attribute isUnique; Port attribute isService). Therefore, what happens when those values change?
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.23

Key: UML22-789
Legacy Issue Number: 8314
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Under sub-section Description change wording to the following: "A signal is a specification of a type of send request instances that communicated..." and "The data...are representedas attributes..."
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.22

Key: UML22-788
Legacy Issue Number: 8313
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation to constraint [2] or the note that ICL notation is not definable
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.9

Key: UML22-782
Legacy Issue Number: 8305
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Reword the last sentence under sub-section Semantics. Assuming is not good. State clearly that the ending point in time and the starting point in time would swap. Change "assuming" to "because." Under sub-section Notation, change "Often a Duration is a non-negative integer expression..." to "Often a Duration is an UnlimitedNatural number..." Use of the word "often" implies that the notation could be expresses as a negative integer which, for Duration is an impossibility (at least in our universe
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.10

Key: UML22-781
Legacy Issue Number: 8304
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Figure 318 shows an association of specification:DurationInterval[1] that redefines specification. Add this to the text or delete the association from the figure. Delete the "." after "DurationConstaint in Figure 320 caption.
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.19

Key: UML22-786
Legacy Issue Number: 8311
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The multiplicity of the attribute language:String[*] in the text does not agree with that shown in fig. 311. Change fig. 311 to agree with the text. Delete the sub-section heading Examples are there none.
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.15

Key: UML22-785
Legacy Issue Number: 8309
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The association multiplicity in the text does not agree with fig. 314. If multiplicity is [0..*], both text and figure need to be changed
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.20

Key: UML22-787
Legacy Issue Number: 8312
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation to or a note that OCL can not define the constraints
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.36

Key: UML22-777
Legacy Issue Number: 8298
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
BNF of a operation defines name and type of a parameter as mandatory fields. But both are optional
Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.35

Key: UML22-755
Legacy Issue Number: 8255
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
I forgot to mention that "ordered" needs to be added to the following associations: results:OutputPin[0..*], loopVariable:OutputPin[0..*], and loopVariableInput:InputPin[0..*] as shown in fig. 196.
Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Also added subsets statements to results, loopVariable, and loopVariableInput.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3

Key: UML22-754
Legacy Issue Number: 8254
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add sections for front end node and back end node as mentioned in LoopNode
Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.35

Key: UML22-753
Legacy Issue Number: 8253
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Correct multiplicities of associations so that the figures (195 and 196) agree with text. Add subsets statments to descriptions as shown in fig. 96. Typo - 5th para, 1st sent of Semantic sub-section change "body sections has" to "body section has." Delete sub-sections Notation and Examples as there are none.
Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Multiplicities are in consistent format. Headers issue is duplicate with 8155.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.48

Key: UML22-767
Legacy Issue Number: 8273
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Under sub-section Notation, say see fig. 307
Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.48

Key: UML22-766
Legacy Issue Number: 8272
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
In sub-section Description, structured activity node is noted as possibly having pins in CompleteStructuredActivities but no pins show any relationship to StructuredActivityNode in fig. 196. The association variable:Variable[0..1] is diagrammed (fig. 195) as belonging to the StructuredActivities package which does not agree in multiplicity and which does indicate that ownedMember is subsetted. A third association is also diagrammed in fig. 195. The association activity:Activity[o..1]. The figure also shows that this association redefines Activity. Figure 196 shows an association of containedEdge:ActivityEdge[?..*]. The figure shows multiplicity as * but in too many cases this should be shown as 0..* In addition, fig. 196 indicates that this association redefined contaniedEdge. Add OCL notation to constraints. In 3rd para of sub-section Semantics, last sentence add the verb "are" between tokens and left. Under the sub-section notation change the word enclosed to enclosing and add the appropriate notation symbology as it is not found in the descriptions of the children of StructuredActivityNode (conditionalNode, loopNode, or sequenceNode as shown in fig. 195) or in section 12.4.
Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12

Key: UML22-771
Legacy Issue Number: 8280
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
General comments. Change the multiplicities on the figures to reflect 0..* instead of only . Some of the figures show it the 0.. way but most do not. If the text lists associations as [0..*] the associated figures should agree. Add OCL notation where possible and where there is no OCL notation available so note it. Delete sub-section headings where there is nothing under them or state None. For specialized concepts, if there is no new information to impart change the word from none to the phrase no new if there was some information in the original concept description sub-section. Generalizations are often not diagrammed in the appropriate Abstract Syntax package diagrams. For instance, the concept ControlNode generalized ActivityNode (from BasicActivities. Even though ActivityNode (the parent) is found in other packages, ControlNode (the child) is not. Should mention be made that ControlNode generalizes ActivityNode from the StructuredActivities package when ContronNode isn't in this package? If so, explain more fully in the How to Read This Specification Section (6.5) about the direct generalizations of a concept being generalized to all packages to which the parent belongs. Where a generalization is diagrammed not all of the "from" packages are listed as indicated in the concept text. Add all package names to the parent namespace or use ellipses to indicate that the list is longer than the namespace allows.
Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.4

Key: UML22-770
Legacy Issue Number: 8279
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typos - remove the dash from between page and the number when referencing. ActivityNode Notation cell delete ExecutableNode and ControlNode as they just refer the reader elsewhere. ControlNode Notation cell delete FinalNode as it just refers reader elsewhere. Add ActivityNode and FlowNode. ExeceptionHandler Notation cell does not exactly agree with fig. 253. In fig. 253 the small square sits across the HandlerBodyNode instead of abutting it.
Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.38

Key: UML22-758
Legacy Issue Number: 8258
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The multiplicity of association (CompleteActivities) inState:State[0..*] does not agree with fig. 189. Add OCL notation to constraint (BasicActivities) [1]. Add OCL notation to contraints (CompleteActivities. Add "(BasicActivities)" to the 1st Semantics sub-section
Reported: UML 2.0 — Tue, 8 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.37

Key: UML22-757
Legacy Issue Number: 8257
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation to constraints. In the Semantics (CompleteActivities) sub-section, third para change receiving to multireceiving and is to are. In Examples sub-section, the example describing fig. 286, last line indicates that the selection specifies that a query operatiion that takes an Order evaluates the customer object via the Order.customer:Party association. This is not what is diagrammed in the right side of fig. 286.
Reported: UML 2.0 — Tue, 8 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
OCL is duplicate with 6346.
Updated: Fri, 6 Mar 2015 20:58 GMT

Profiles:Extension End

Key: UML22-756
Legacy Issue Number: 8256
Status: closed
Source: The MathWorks ( Mr. Alan Moore)
Summary:
Profiles:Extension End - the spec needs to be clear on the behaviour of the
{required}
property of an extension if the extending stereotype in question
has subclasses. Are those sub-stereotypes also required?
Reported: UML 1.4.2 — Tue, 8 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.2

Key: UML22-765
Legacy Issue Number: 8271
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig. 196 shows no relationship between concepts immediately under Action (StructuredActivityNode and ActivityEdge) and any of the other concepts in the diagram. There are no connecting lines. If this is truly the case, break this single diagram into two or, as I think (after reading section 12.3.47) there should be some relationship shown between the concepts on the right side of the diagram and those on the extreme left, add lines to show the appropriate relationships.
Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.47

Key: UML22-764
Legacy Issue Number: 8270
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fo the association executableNode:ExecutableNode[*] mention that it redefines containedNode as shown in diagram 195
Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Also added ordered to the property string.
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 super/templates/

Key: UML22-763
Legacy Issue Number: 8265
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
The definition of Classifier and ClassifierTemplateParameter indicates that there may be additional constraint placed on the parameter. Examples and notation also indicate that. However, there is no defined way to express that constraint in the metamodel (at the very least it is not obvious and is very open for interpretation). The metamodel must provide a meta-association from ClassifierTemplateParameter to Classifier to represent the constraining classifier.
Reported: UML 1.4.2 — Thu, 10 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 232/233 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.43

Key: UML22-760
Legacy Issue Number: 8262
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The association condition:Constraint[0..*] does not have the same multiplicity as fig. 192. Also the fig. indicates that the association subsets ownedElement. Add OCL notation to constraints
Reported: UML 2.0 — Tue, 8 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.41

Key: UML22-759
Legacy Issue Number: 8261
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The attribute effect:ParameterEffectKind[0..1] does not display this multiplicity in fig. 192. Reword the definition of attribute isStream:Boolean[1..1]=false to "Tells whether an input parameter may accept valuses or an output parameter post values while the behavior is executing." parameterSet:ParameterSet[0..*] listed as an attribute is an association. Please move it to the Association sub-section. The multiplicity for parameterSet:ParameterSet[0..*] does not agree with fig. 192. Add OCL notation to the constraints. Under sub-section Notation the last sent. says to "See notation for Operations." but gives no reference location. Is this supposed to be at page 105?
Reported: UML 2.0 — Tue, 8 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.49

Key: UML22-774
Legacy Issue Number: 8294
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Under sub-section Associations and Constraints change None to No new
Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8232 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.46

Key: UML22-773
Legacy Issue Number: 8293
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
For sub-sections Associations and Constraints change the None to No new.
Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8231 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.1

Key: UML22-772
Legacy Issue Number: 8292
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Figures 307 and 308 are identical. Fig. 308 does not show what the text is describing as the Communication Domain Model(especially the paragraph on pg 457 starting with "As shown in Figure 308..."). Fig. 307 (and current 308) multiplicity for the association execution:BehaviorExecution is diagrammed as * but I wonder if it shouldn't be 0..* since the text indicates that an object may or may not cause the execution of a behavior. In the paragraph immediately following fig. 309, I believe that "The execution of a send action results in a send request, which results in a signal event occurrence (not a call event occurrence as stated). Minor editing call - In the first line on page 457, change synchronously and asynchronously to synchronous and asynchronous.
Reported: UML 2.0 — Wed, 16 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 240/241 of ptc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/templates/inexplicable constraint on defaults

Key: UML22-762
Legacy Issue Number: 8264
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
The definition of TemplateParameter states that the parameter cannot own at the same time its parametered element and default element. The ownership of those two elements is mutually exclusive. It is also expressed as an OCL constraint. However, there is no justification offered in the spec for this constraint and one is not obvious. The constraint should be removed.
Reported: UML 1.4.2 — Thu, 10 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Indeed, cannot see any justification for this. Remove the constraint.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.44

Key: UML22-761
Legacy Issue Number: 8263
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add package name to first Constraint sub-section. Left fig of fig. 295 needs an "s" on end. Shouldn't exception handler edges also be used in figures 296 and 303? If not, please clarify that the execption pin notation takes the place of the notation for the exception handler notation.
Reported: UML 2.0 — Wed, 9 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.51

Key: UML22-769
Legacy Issue Number: 8276
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Under sub-sections Associations and Constraints change none to no new
Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8232 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.50

Key: UML22-768
Legacy Issue Number: 8275
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add "See "ValuePin (from BasicAQctions)" on page 309." immediately under concept heading. Change None to No new under the sub-section Associations. Delete the word "these" in the 3rd sentence of sub-section Semantics. Delete sub-section Examples as there are none.
Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Empty section issue is duplicate with 8231. Headers issue is duplicate with 8155.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.34

Key: UML22-752
Legacy Issue Number: 8252
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add the package name IntermediateActivities to the first Associations sub-section. Add the subsets ownedElement statement (as shown in fig 193) to the association joinSpec:ValueSpecification[1..1]. Typo - remove the second a between containing and join in the 4th sent of the Notation sub-section 1st para. Change AcceptOrder behavior to SendInvoice behavior (as shown in fig 277) in the 1st sentence in the Examples sub-section. Add OCL notation to the constraints
Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.33

Key: UML22-751
Legacy Issue Number: 8250
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The order cancellation request example lends itself to enhancement. Fig. 274 could be enhanced if there was drawn a fork from invoice providing multiple edges of "no payment needed" or "make payment" with the "no payment needed" edge directly entering the join. Another fork could also be added after the AcceptPayment activity with one outgoing edge labeled "refund payment" with an edge to an activity "IssueRefund" then an edge going to the join. The explanation would reiterate that a token transfer, once initiated (SendInvoice activity), that is outside of the region is not interruptable. That since the SendInvoice activity is outside the region, no matter when the CancelOrder interrupt activity is issued, the SendInvoice activity is issued. However, corrective activities are needed to be performed before the CloseOrder actvity can be accomplished. This would be to either issue the invoice stating no payment is due or to issue a refund once payment is received. Additionally, wouldn't the CancelOrder activity more likely go to the merge before the CloseOrder activity instead of directly to the Activity Final? Otherwise, logically thinking, some order is out there not closed (just canceled). But then maybe (probably??) I'm missing the point of the example in which case a better explanation of the example needs to be provided.
Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.17

Key: UML22-738
Legacy Issue Number: 8234
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Multiplicity for StructuredActivities associations test:ActivityNode[0..*] and body:ActivityNode[0..*] and for CompleteStructuredActivities association bodyOutput:outputPin[0..*] do not agree with figures 195 and 196 respectively. Remove the second set of parantheses from the sub-section heading Associations ((CompleteStructuredActivities)).
Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.16

Key: UML22-737
Legacy Issue Number: 8233
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Package CompleteActivities is not supported by fig. 182 as a generalization for this concept. Change Figure 293 reference in sub-section Notation to either figure 294 or, more likely, figure 301.
Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.15

Key: UML22-736
Legacy Issue Number: 8232
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Change "None" to "No new" for sub-sections Attributes, Associations, and Constraints
Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8670 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.14

Key: UML22-735
Legacy Issue Number: 8231
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
For the Attributes, Associations, and Constraints sub-sections change "None" to "No new." This would be a good policy to follow for all "(as Specialized)" concepts where no new information is presented in the 'as Specialized" concept.
Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This was fixed as part of an editorial pass in a previous release. Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

MultiplicityElement BNF too restrictive

Key: UML22-731
Legacy Issue Number: 8226
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
The BNF for Notation in 9.12 of Infra and 7.3.32 of Super does not allow specification of uniqueness-designator without preceding order-designator.
This seems too restrictive and is in fact inconsistent with the example in Fig 59 of Super which just shows
{unique}
.
Reported: UML 1.4.2 — Thu, 3 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.13

Key: UML22-730
Legacy Issue Number: 8225
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig. 192 spells the association as ownedParameterSet (no "s"), does not express the same multiplitity as the text, and indicates that the association subsets ownedmember (need to capitalize the "M" in the figure). Make text and figure agree.
Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.6 & 12.3.19

Key: UML22-741
Legacy Issue Number: 8237
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
I'm confused. Fig. 178 shows ActivityFinalNode as a child of ControlNode in the BasicActivities sub-package, but in fig. 183 it is a "grandchild" of ControlNode and a child of FinalNod in the IntermediateActivities sub-package. Can a concept be both a child and a grandchild of the same higher-level concept, in this case ControlNode?
Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.19

Key: UML22-740
Legacy Issue Number: 8236
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig. 179 does not support generalizations of CompleteActivities, CompleteStructuredActivities, or IntermediateActivities packages. Add OCL notation
Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.18

Key: UML22-739
Legacy Issue Number: 8235
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The generalization from CompleteStructuredActivities is not supported by the figures. Typo - add a space before last sentence in para 2 of sub-section Description. (Before Note that... .) Change wording of definition of attribute isDeterminate:Boolean to "If true, the modeler asserts that at most only one of concurrent tests will succeed and therefore the choice of the clause is deterministic." The multiplicity of the CompleteStructuredActivities association result:OutputPin[0..*] is not what is shown on fig 196. Also change the definition to reflect that the association is ordered and subsets output. Delete sub-section headers Notation, Presentation Option, and Examples are there are none. Suggest changing wording in sent 5 para 4 of sub-section semantics to "If the isDeterminate attribute has a true value, the modeler asserts that at most only one of concurrent test sections will yeild a test value (the predecessor relationship may be used to enforce this assertion)."
Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.28

Key: UML22-746
Legacy Issue Number: 8242
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation to the constraint
Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 6425 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.27

Key: UML22-745
Legacy Issue Number: 8241
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation to the constraint. In sub-section Semantics, last sent. of para 1 change "concurrency" to "mode." Typo - In sub-section Presentation Option, put a space after Figure 259. On Page 399, change figure reference number to 261. In fig. 261, chane <<concurrent>> to <<parallel>>.
Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Missing OCL issue is a duplicate of 6452. Empty section issues are duplicates of 8155.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.23

Key: UML22-744
Legacy Issue Number: 8240
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add subsets note to association protectedNode:ExecutableNode[1..1] as shown on fig. 197. Add OCL notation to constraints. Under sub-section Presentation Option change "interrupting edge is a zig-zag adornment..." to "exception handler is a zig-zag adornment..." Delete sub-section heading Rationale as there is none. Typo - Under sub-section Changes from previous UML in para 2 put a space between first and second sentences.
Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
OCL is duplicate with 6346. Headers issue is duplicate with 8155.
Updated: Fri, 6 Mar 2015 20:58 GMT

Used of "Redefines ...from Abstractions" in descriptions is misleading

Key: UML22-734
Legacy Issue Number: 8229
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
For example 11.7.2 of Infra: the name property states
Redefines the corresponding attributes from Basic::NamedElement and Abstractions::Visibilities::NamedElement.

However there is no redefinition occurring; nor would it make sense.
Reported: UML 1.4.2 — Thu, 3 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

BNF Notation for Operation is too restrictive

Key: UML22-733
Legacy Issue Number: 8228
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
In 11.8.2 (Infra) and 7.3.36 (Super) the notation BNF requires a
{<oper-property}
any time there is a ':' after the operation name
Reported: UML 1.4.2 — Thu, 3 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Incomplete BNF for Property

Key: UML22-732
Legacy Issue Number: 8227
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
In BNF Notation for Property (11.3.4 of Infra, 7.3.44 of Super), <prop-modifier> is defined but never refered to
Reported: UML 1.4.2 — Thu, 3 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.24

Key: UML22-743
Legacy Issue Number: 8239
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Change type font to italics on fig. 195. Change association handler:ExceptionHandler [0..1] so that fig. 197 and text agree. Add the subsets ownedElement note as shown in fig 197.
Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.22

Key: UML22-742
Legacy Issue Number: 8238
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL Notation to constraints. Typo - remove 2nd "a" from sent3 of para 2 of sub-section Notation. Delete sub-section headers Presentation Option and Style Guidelines as there are none.
Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Missing OCL issue is a duplicate of 6452. Empty section issues are duplicates of 8155.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.38

Key: UML22-748
Legacy Issue Number: 8245
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
I may be all wet (after all it is a Monday morning and raining here) but I think fig. 265 needs to be redrawn. The notation between the BuildComponent and InstallComponent activites is different than the notation between the InstallComponent and DeliverApplication activities yet the flow is basically the same. To agree with the left side of the flow between BuildComponent and InstallComponent activities, there should be a fork after the InstallComponent activity with an edge going to DeliverApplication activity and an edge going to a decisionNode. The decisionNode should have two edges exiting it. One labeled [more components to be installed] and going back to the InstallComponent activity; a second labeled [no more components to be installed] going to a Flow final node. The edge and the [no more components to be installed] label need to be removed from the edge going from the decisionNode to the DeliverApplication activity. Out of curiosity, why was a fork notation used and not the decisionNode with three control flow edges leading from it?
Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.30

Key: UML22-747
Legacy Issue Number: 8243
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation to the constraints
Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 6425 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.32

Key: UML22-750
Legacy Issue Number: 8248
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation
Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 6425 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.31

Key: UML22-749
Legacy Issue Number: 8247
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation to constraints. Reword last sentence in last paragraph of sub-section Semantics. The entire sentence is confusing and unclear
Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
The missing OCL issue is a duplicate of 6425.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.1

Key: UML22-729
Legacy Issue Number: 8224
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typo - Capitalize the "M" in ownedMember of the subsets not for the BehavioralFeature association ownedParameterSet:ParameterSet
Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.12

Key: UML22-728
Legacy Issue Number: 8223
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Associated fig. 192 spells association name as ownedParameterSet (no "s"), does not show the same multiplicity, and shows that this association subsets ownedMember. Make fig and text agree.
Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Multiplicity in fig. 192 is “*” and in associations section “[0..*]”. Both are the same.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.10

Key: UML22-727
Legacy Issue Number: 8222
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Associated fig. 184 does not show generalizations from FundamentalActivities for ActivityGroup or from Dependencies for NamedElement. The association activity:Activity[0..1] is not diagrammed in fig. 184. The description for the association represents:Element[0..1] needs rewording. Does it mean "An element constraining the behaviors invoked by the nodes in the partition" (constraining used as a verb) or "The element constraining behaviors that are invoked by the nodes in the partition (constraining used as the noun "constraining behaviors")? Fig. 184 shows additional associations: ContainedEdge:ActivityEdge[1..1] and containedNode:ActivityNode[1..1]. These need to be added to text. Add OCL notation to constraints.
Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12

Key: UML22-726
Legacy Issue Number: 8220
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Use of the term edge(s)is confusing without the appropriate qualifier - "Control" or "Object." Suggest changing edge or edges to ControlEdge(s) and/or ObjectEdge(s) as appropriate
Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.9

Key: UML22-725
Legacy Issue Number: 8219
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add the multiplicity [1..] to the association. Reword the description of the association parameter:Parameter. It could be interpreted as "the same object node will accept as well as provide parameter values." If that's not the case, i.e., one node accepts and another not provides (which I think is what is meant) then change the "and" to "or." Add OCL notation to the constraints. Constraint [3] needs rewording to something like "Activity parameter nodes must have neither incoming nor outgoing edges" or "Activity parameter nodes must have only incoming or outgoing edges but not both." Wording depends on meaning of constraint. Please clarify semantics to address the following questions. Are input values placed as tokens on input activity parameter nodes at the beginning of flows? Since this node is at the beginning of the flow is that why it has no incoming edges? If it has no incomind edges, how are the values placed on the node? Para 1 of semantics says to see semantics at ObjectNode, Action, and ActivityParamenterNode. This is the semantics section for ActivityParameterNode. Delete that phrase or correct it to the proper reference semantics section. The package CompleteActivities does not show any diagrams with ActivityParameterNode. Delete those package references on pg. 366 or explain why that package is referenced.
Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see pages 200/201 of prc/2006-04-01
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.4

Key: UML22-716
Legacy Issue Number: 8208
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
None of the multiplicities listed with the associations agree with the multiplicities diagrammed. Please correct either figures (probable) or the text. Associations in the text do not mention any subsets that are illustrated in the associated figures. There is no figure given for Activity in the IntermediateActivity Package but several references to that package (pg 343, 345. Please add a figure for that package for Activity or add Activity to one of the IntermediateActivity figures. Figure 211 is not discussed and appears to give no added value to the section unless figure 210 should contain an action to create a Trouble Ticket.
Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
The multiplicities only differ in format.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.2

Key: UML22-715
Legacy Issue Number: 8207
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
According to fig. 187 the associations localPrecondition:Constraint[0..*] and localPostcondition:Constraint[0..*] are subsets of ownedElement. In addition, the multiplicity shown in the fig does not agree with the multiplicity of the text for either association. Para 1, pg 338, sentence 3 appears to have an extra word - tokens - before control tokens. If this isn't extra, then rewrite sentence to make it more clear. The Rationale is a very good description of what an Action is and I suggest placing that paragraph in the Description section. The paragraph for the rationale is not really a rationale or justification--it is a description.
Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.2

Key: UML22-714
Legacy Issue Number: 8206
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Remove duplicate redefines activity statement for association activity between StructuredActivityNode and Activity.
Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 7099 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.8

Key: UML22-721
Legacy Issue Number: 8215
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete the package name "(CompleteStructuredActivities)" after Attributes because ActivityNode is not part of that package according to the figures. Add subsets notations to the associations as shown in the figures. Change the multiplicities of the associations so that the figures and the text agree. Add OCL notation to the constraints
Reported: UML 2.0 — Wed, 2 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.7

Key: UML22-720
Legacy Issue Number: 8214
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add IntermediateActivities to the section header list of packages. Typo - remove "that" from the first sentence. Add appropriate subsets information to the associations as shown in the diagrams. Make the text and diagram multiplicities agree for the associations. Add OCL notation to the constraints
Reported: UML 2.0 — Wed, 2 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.6

Key: UML22-719
Legacy Issue Number: 8213
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete the headers Presentation Option and Style Guidelines as there are none. "In Figure 222, two ways to reach an activity final exist;..." the figure number needs to be changed to 223
Reported: UML 2.0 — Wed, 2 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.25

Key: UML22-683
Legacy Issue Number: 8170
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add the superclass pointer "(from Kernal)" to fig. 143. No operations are indicated in fig 143. Constraint [2] appears to have an operation name missing or misspelled
Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.24

Key: UML22-682
Legacy Issue Number: 8169
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
If this is not an action why is it discussed in Actions? Move to appropriate Chapter. Wouldn't the action be more like writing to LinkEndDestroyData? If it stays in this chapter please clarify the introduction and description especially explaining how this is different from LinkEndData. Also need to clarify/explain statement "Qualifer values are used in CompleteActions." I don't see a fit with that statement in this section. Attribute in fig 150 is isRemoveDuplicates:Boolean = false so change either the figure or the attribute name in the text. Add OCL notation to Constraints. Constraint [1] typo in "DestroyLinkActiuon" Constraint [2] needs to emphasize that the type UnlimitedNatural is >0. Delete the header Examples as there are none. Typo in Rationale - "LinkeEndDestructionData"
Reported: UML 2.0 — Sun, 2 Jan 2000 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.35

Key: UML22-629
Legacy Issue Number: 8100
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The modifications made for multiple languages (Issue 3391) could often be taken by the reader to mean that multiple languages may exist simultaneously in a single opaque expression. An example is the attribute "language:String[0..*] specifies the languages in which the expression is stated" could be interpreted to mean that the expression could be stated in mixed languages. Additionally plurality of verbs and modifying expressions often do not agree with the plurality of the sentence subject. An example of this is "The languages of an opaque expression, is specified, is often..." Subject is the sentence is "languages" so verb should be "are." Furthermore, this statement implies that a single ("an") opaque expression may have more than one language ("languages").
Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1 - typo

Key: UML22-631
Legacy Issue Number: 8104
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typo - Change "Components" to Component in ownedMember:PackageableElement[*] 1st sentence
Reported: UML 2.0 — Fri, 21 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1

Key: UML22-630
Legacy Issue Number: 8103
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add ending guillemets to specification in isIndirectlyInstantiated. Verify that OCL for /provided:Interface[*] is correct. 3rd and 4th lines don't look right to me
Reported: UML 2.0 — Fri, 21 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.34

Key: UML22-628
Legacy Issue Number: 8099
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The sentence "The contraint does not apply to the namespace itself, but may also apply to elements in the namespace." would be better if "also" was replaced with "instead."
Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.33

Key: UML22-627
Legacy Issue Number: 8098
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
I am not an OCL expert (barely a novice) but it seems to me that Constraint [2] is incorrect in stating "~~>select(ns|ns.name~~>isEmpty())". Shouldn't that be ~~>select(ns|ns.name~~>notEmpty()) because the constraint is saying that there is a name and all of the containing namespaces have a names (in other words, all of the containing namespaces are notEmpty).
Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.5

Key: UML22-637
Legacy Issue Number: 8112
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add Generalization TypedElement (from Kernal) to fig. 96.
Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.3

Key: UML22-636
Legacy Issue Number: 8110
Status: closed
Source: Anonymous
Summary:
Incorrect page number for reference for "Property" under Description
Reported: UML 1.4.2 — Mon, 24 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.2

Key: UML22-635
Legacy Issue Number: 8109
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Better choice of word in Changes from UML 1.x would be to change the "of" in last sentence to "that."
Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1

Key: UML22-632
Legacy Issue Number: 8105
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add component icon to fig. 90 <<component>> :ShoppingCart to be consistent with others in diagram
Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.20.2

Key: UML22-633
Legacy Issue Number: 8107
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Either delete Issue 7240 note from page, make the correction, or explain why the correction was not made.
Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.1

Key: UML22-634
Legacy Issue Number: 8108
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Page references are incorrect for "Property" and "StructuredClassifier".
Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.9

Key: UML22-638
Legacy Issue Number: 8115
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add generalization for InvocationAction to fig 101 to agree with text on 187
Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

InfrastructureLibrary defines, but should not use package merge

Key: UML22-561
Legacy Issue Number: 7956
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
The resolution to 7623 said to replace all «import» by «merge» in Infrastructure Figure 70. These changes should be reversed because they result in InfrastructureLibrary both defining and being defined by package merge making it very difficult to implement UML2.

Any implementation would have to do these merges by hand in order to have an implementation of Constructs that could be used to implement package merge, EMOF CMOF, or any other UML2 compliance level.
Reported: UML 1.4.2 — Wed, 1 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
closed no change
Updated: Fri, 6 Mar 2015 20:58 GMT

section 2.10.4.1 detailed semantics of collaborations

Key: UML22-557
Legacy Issue Number: 7948
Status: closed
Source: Anonymous
Summary:
My question concerns section 2.10.4.1 (detailed semantics of collaborations). The last part of the 4th paragraph starts as follows:

"However, instances of different classifiers can play the role defined by the classifier role, as long as they have all the required properties."

Allow me to illustrate my interpretation of this section by means of an example.

Suppose there is a class A with 5 operations, o1, o2, o3, o4 and o5, and there is a class B with 3 operations, identical to o2, o3 and o4.
Suppose there is a classifier role R in a collaboration, which has A as its base. The role can then specify a subset of the features of A. These features are then required by instances which play the role. Suppose this subset consists of o2 and o3. Then the quote from the spec above claims that instances of B are allowed to play role R. Is this correct so far?

Then, the spec goes on:

"Several classifier roles may have the same base classifier, even in the same collaboration, but their features and contained elements may be different subsets of the features and contained elements of the classifier. These classifier roles specify different roles played by (possibly different) instances of the same classifier."

So, considering again role R from my example, suppose there is now a different classifier role Q, which also has A as its base. Suppose Q specifies o3 and o4 as the required subset of A's features.

Now the last sentence from the spec quote seems to say that only (possibly different) instances of A can play roles R and Q. This would mean that an instance of B is NOT allowed to play either R or Q, which would contradict my example above.
Reported: UML 1.4.2 — Wed, 24 Nov 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.43

Key: UML22-554
Legacy Issue Number: 7942
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Notation for a primitive type should be <<primitiveType>> instead of <<primitive>>. That's more consistent to the general usage of keywords that they are identical to the metaclass name
Reported: UML 2.0 — Mon, 22 Nov 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Interactions

Key: UML22-559
Legacy Issue Number: 7950
Status: closed
Source: The MathWorks ( Mr. Alan Moore)
Summary:
In the description of the Graphic Paths for a Communication Diagram I can
find no mention of what the lines between the Lifelines correspond to -
although I did find this in the description of Message: "On Communication
Diagrams, the Messages are decorated by a small arrow along the connector
close to the Message
name and sequence number in the direction of the Message." I assume this
means that the lines correspond to a Connector model element.

The Graphic Paths section should be updated to include this information and
justification added as to why a Connector is needed in order for Messages to
be shown between two lifelines on a Communication Diagram (this seems an
overly tight constraint to me).
Reported: UML 1.4.2 — Fri, 26 Nov 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.44 - OCL incorrect

Key: UML22-558
Legacy Issue Number: 7949
Status: closed
Source: Paranor AG ( Earl Waldin)
Summary:
The OCL for the derivation of association /opposite for Property in section 7.3.44, page 126 is incorrect. It's derivation in section "Constraints" on page 126 as given as follows: [1] If this property is owned by a class, associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end. opposite = if owningAssociation->notEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)~~>any() in if otherEnd.owningAssociation~~>notEmpty() then otherEnd else Set{} endif else Set {} endif I think that the prose "this property is owned by a class" should translate into "class" and not "owningAssociation" in the above OCL. In other words, the prose does not agree with the OCL. So contraint [1] for opposite should read opposite = if class->notEmpty() and ... let ... in if otherEnd.class -> notEmpty() then ... else Set {} endif
Reported: UML 1.4.2 — Fri, 26 Nov 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 6201 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.2.8

Key: UML22-555
Legacy Issue Number: 7946
Status: closed
Source: INSA ( Jean Louis Sourrouille)
Summary:
In my opinion, the sentence "When a language is reflective, there is no need to define another language to specify its semantics." is false. Any natural language is reflective. However, just take a dictionary of a language that you don't know, you will not understand anything. In fact, the semantics of UML is described in english, not in UML, which explains that you can understand the metamodel.
Reported: UML 1.4.2 — Tue, 23 Nov 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super Basic Interactions

Key: UML22-560
Legacy Issue Number: 7951
Status: closed
Source: The MathWorks ( Mr. Alan Moore)
Summary:
Basic Interactions includes SendOperationEvent whose superclass is
MessageEvent, which is in CommonBehaviors::Communications.

The problem is that the Basic Interactions package is in Level 1, but
CommonBehaviors::Communications is in Level 2.

The same is true for SendSignalEvent. In fact Event itself is also in
Communications so there's a problem with the whole set of Event subtypes
defined in BasicInteractions.

Also BasicActions::SendSignalAction references Communications::Signal
Reported: UML 1.4.2 — Fri, 26 Nov 2004 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This issue was fixed in release 2.1.. Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

An observed time value must be written into a structural feature

Key: UML22-562
Legacy Issue Number: 7967
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
TimeObservationAction is a specialized WriteStructuralFeatureAction. An observed time value must be written into a structural feature. If modeling activities with that kind of action it would be useful to be able to write the time value to a variable instead of a structural feature. The time value is often used temporarily
Reported: UML 2.0 — Fri, 3 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: These actions were removed as part of an earlier fix. Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Classes

Key: UML22-556
Legacy Issue Number: 7947
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
I see a problem in the definition of the InstanceSpecification of a new primitive like Real. The value is specified by a ValueSpecification. The UML metamodel of ValueSpecifications reflects the predefined primitive types of UML: LiteralInteger, LiteralString, and so on. This is an indirect dependency from the Kernel package to the AuxiliaryConstructs package. That dependency direction shouldn't be allowed. How to specify a value specification for a primitive type Real? I think that we need LiteralReal to do that.
Reported: UML 1.4.2 — Wed, 24 Nov 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8069 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.34

Key: UML22-691
Legacy Issue Number: 8178
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Association result:OutputPin[1..1] is Specialized from Action:output according to fig. 155. Rewrite Constraint [4] as "The type of the object input pin is the type of the association class that owns the association end." Complete the Semantics section. Delete the header Examples as there are none
Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.33

Key: UML22-690
Legacy Issue Number: 8177
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete Examples header as there are none
Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue N/A for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.31

Key: UML22-689
Legacy Issue Number: 8176
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig 153 shows that the association result:OutputPin[1..1] is subsetted. Add OCL notation for constraint [1]. I believe the wording of constraint [1] might be better as: "The type of the result output pin is the type of the classifier."
Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.26

Key: UML22-684
Legacy Issue Number: 8171
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The generalization in figure 142 doesn't agree with that mentioned in the section. Attributes are both ordered. Delete header Examples as there are none
Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Example header is duplicate of 8155.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.27

Key: UML22-694
Legacy Issue Number: 8182
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete the Examples header as there are none
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8155 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.36

Key: UML22-693
Legacy Issue Number: 8181
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation to constraint [2]. Delete Examples header as there are none
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 6452, 8155 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.28

Key: UML22-686
Legacy Issue Number: 8173
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typos - In description delete provide and change accept to accepts. Add OCL notation to Constraints. Delete header Examples as there are none.
Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
OCL issue is a duplicate of 6452. Header issue is a duplicate of 8155.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.29

Key: UML22-687
Legacy Issue Number: 8174
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Please clarify the relationship and differences between QualifierValue, LinkEndCreationData, LinkEndData, and LinkEndDestructionData especially since QualifierValue, LinkEndData, and LinkEndCreationData are all in the CompleteActions package. Constraint [2] change "are" to "is" Delete Examples header as there are none.
Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.35

Key: UML22-692
Legacy Issue Number: 8180
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add the specialized statement needed for the association result"OutputPin[1..1] as shown in fig. 155. Add semantics or delete the header. Delete the Examples header as there are none.
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8155 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.30

Key: UML22-688
Legacy Issue Number: 8175
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Association exception:InputPin[1..1] is subsetted according to fig 158. Delete Examples heading as there are none
Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Headers issue is duplicate with 8155.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.27

Key: UML22-685
Legacy Issue Number: 8172
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Description should mention the multiplicity expressed in fig. 143. Delete the header Examples as there are none
Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Optional inputs

Key: UML22-588
Legacy Issue Number: 8037
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
When does an action start when all its inputs are optional?
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Preserve order in result of read actions

Key: UML22-587
Legacy Issue Number: 8036
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
The semantics of the various read actions (ReadStructuralFeatureAction, etc) should specify that the order of the retrieved collections is preserved in the values of the output pin.
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Interactions chapter refers to ActivityInvocations

Key: UML22-582
Legacy Issue Number: 8030
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Interactions chapter refers to ActivityInvocations The Interactions chapter still refers to ActivityInvocations, which was only in an intermediate draft of the original submission. I think it should be CallBehaviorAction or CallOperationAction, not sure.
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
The term ActivityInvocations only appears once, on page 563 of ptc/04-10-02.
Updated: Fri, 6 Mar 2015 20:58 GMT

Destruction semantics in StructuredClassifier

Key: UML22-583
Legacy Issue Number: 8031
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Destruction semantics in StructuredClassifier The destruction semantics in StructuredClassifier should include destruction of links created due to connectors between noncomposite properties
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 119 missing multiplicity

Key: UML22-585
Legacy Issue Number: 8033
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Figure 119 missing multiplicity. Figure 119 (Connectors and parts in a structure diagram) is missing a multiplicity on the right side of the connetor
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Link maintenance in StructuredClassifier

Key: UML22-584
Legacy Issue Number: 8032
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Link maintenance in StructuredClassifier The semantics of StructuredClassifier should indicate that links are created/destroyed according to connectors when objects are added/removed from the connected properties. Extend Create/Destroy/ClearLinkAction and Add/Remove/ClearStructuralFeature with boolean properties that "turn on" this semantics.
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see ptc/2006-04-01 p 94
Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectNode, constraint 1 In ObjectNode

Key: UML22-591
Legacy Issue Number: 8040
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
ObjectNode, constraint 1 In ObjectNode, Constraints (Complete Activities), the first constraint regarding upperbound should be removed. The size of the object node buffers can be any size.
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

DestroyObjectAction semantics

Key: UML22-590
Legacy Issue Number: 8039
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Clarify the "owns" language in DestroyObjectAction to mean the objects related by composite associations
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

IsReadOnly constriant

Key: UML22-589
Legacy Issue Number: 8038
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
done) IsReadOnly constriant Constraint on StructuralFeature::isReadOnly: if true and there is no intialization value, then the lower multiplicity must be zero.
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for method

Key: UML22-586
Legacy Issue Number: 8035
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Need a notation for instances of the specification/method metaassociation (Figure 311).
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 6150 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.1

Key: UML22-659
Legacy Issue Number: 8145
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add that retureInformation:OutputPin[1..1] is a specialization or subsets output as shown in fig. 152. Add OCL expression for constraint 1 or that the constraint cannot be expressed in OCL. Constraint [3] contains a typo in the 1st line "isUnmrashall" should be "isUnmarshall"
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Missing OCL is a duplicate of 6452.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.1

Key: UML22-658
Legacy Issue Number: 8144
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typos and rewording requests Basic Concepts para 2 - Change "Behavior" to "Behaviors" Basic Concepts para 3 - Change "Operations" to "Operation calls" Intermediate Concepts para 1 sentence 1 - change "various action primitive actions" to "various primitive actions" Intermediate Concepts para 1 sentence 3 - rewrite to something like: S"pecifically, a single primitive action is defined so that it either carries out a computation or accesses object memory, but never both." Intermediate Concepts para 6 sentence 4 - Add verb in "multiplicity bound ignored" to "multiplicity bound is ignored" Intermediate Concepts para 6 last sentence - replace the pronoun "these" with the appropriate noun - I don't know if "these" refers to the points where the lower multiplicity bound is ignored or the points where the modeler has determined that the lower multiplicity bound is enforced. Intermediate Actions, Read Write Actions (page 230) para 3 sentence 1 - needs rewording: "ranging from" implies a "to" something which is not listed; "implementation-dependent" is a modifiying phrase but I don't know what it is modifying (the following comma may not be needed). My interpretation of the sentence meaning is: "Value specificationc cover various expressions ranging from implementation-dependent constants to complex expressions with possible side-effects."
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.15

Key: UML22-621
Legacy Issue Number: 8092
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
I am confused by the statements that say "the name of the imported element must be qualified in order to to used and is not added to the importing namespace." Add a statement to clarify that if the name is qualified, how the element is referenced by another element.
Reported: UML 2.0 — Wed, 19 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.12

Key: UML22-620
Legacy Issue Number: 8091
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Issues 6164 and 6159 still have not been addressed. Figure 36 reads that the client CarFactory is dependent upon the supplier Car which is not what the text states.
Reported: UML 2.0 — Wed, 19 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
The fix was not completed. Instead of VehicleType the text should refer to CarFactory.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.32 Page: 96-99

Key: UML22-626
Legacy Issue Number: 8097
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The document defines multiplicity as an "inclusive interval of non-negative integers" which is the same thing as Unlimited Naturals, but in several other places the "non-negative" qualifier for integer is left off leaving only integer as the definition of the lower bound and integers may be negative. Examples are Additional Operations [4]and in the second paragraph of semantics. Additional Operations [2] OCL is incorrect if the type for includesCardinality(c:Integer) is Integer because the third line says that includesCardinality = (lowerBound() <= C) and (UpperBound () >= C). Everywhere else it is stated that the upperBound is UnlimitedNatural NOT an integer. Remove the word "is" following specification in the second sentence of the first paragraph under Notation.
Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.32

Key: UML22-625
Legacy Issue Number: 8096
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Since the lower bound of multiplicity can not be negative by definition, shouldn't the type of /lower MultiplicityElement be UnlimitedNatural? Also, /upper is missing from the list of attributes
Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.22

Key: UML22-624
Legacy Issue Number: 8095
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Figures 50 and 51 cause me confusion because Fig. 50 uses as the classifier name a type (String). Yet Fig. 51 shows "Other properties of the feature, such as type" on the second line of the slot streetNumber:Integer = 381. Should the classifier name in Fig. 50 be a type or something more like myAddress. Please clarify, especially that there is a difference, as indicated by the naming convertion, between the instance specification and the feature shown in the slot.
Reported: UML 2.0 — Wed, 19 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 6.5.1: Error in example

Key: UML22-616
Legacy Issue Number: 8086
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Error in example. Text for /isComposite : Boolean A state with isComposite = True is said to be a composite state. A composite state is a state that contains at leas one region> BUT the OCL says IsComposite = (region >1) which translates to is greater than one. Use the is equal to or greater than symbol or change the number to 0.
Reported: UML 2.0 — Fri, 14 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.10

Key: UML22-619
Legacy Issue Number: 8090
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
If constraind elements are those elements required to evaluate the constraint spedividation, why is the multiplicity for the specification: ValueSpecification[0..1]? Shouldn't the multiplicity be 1? If not, please clarify.
Reported: UML 2.0 — Tue, 18 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.20

Key: UML22-622
Legacy Issue Number: 8093
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Text says that Manager constitutes one GeneralizationSet but Figure 42 uses the word Employee. Please correct
Reported: UML 2.0 — Wed, 19 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
The submitter is correct. This is a bug.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.8

Key: UML22-618
Legacy Issue Number: 8089
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The association package:Package[0..1] is listed as being an association of Classifier. However, the only figure to diagram this association is Figure 14 and the association is from Type not Classifier.
Reported: UML 2.0 — Fri, 14 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Stereotypes applying in UML 2.0

Key: UML22-623
Legacy Issue Number: 8094
Status: closed
Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
Summary:
I have some questions regarding stereotypes using in UML 2.0.

1. How to declare user defined stereotype in the model? Should class with stereotype <<metaclass>> and metaclass name be created in the model? How to declare stereotype <<metaclass>>?

2. Is some relationship between stereotyped model element and stereotype instance exist? Where stereotype instance should be created (contained) and how model element can collect all applied stereotypes?
Reported: UML 1.4.2 — Mon, 17 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.3

Key: UML22-617
Legacy Issue Number: 8088
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Clarification of subsetting is still confusing to me. The Note has an incomplete sentence for the last "sentence." I believe you need to remove the starting word "If."
Reported: UML 2.0 — Fri, 14 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.20

Key: UML22-678
Legacy Issue Number: 8164
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Superclass generalization is not written on fig. 144. Association argument:InputPin[0..*] multiplicity does not agree with fig. 144. Association argument:InputPin[0..*]in fig. 144 says it is ordered and subsets input. Add statements to the definition of the association. Under Constraints say none.
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.19

Key: UML22-677
Legacy Issue Number: 8163
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Bold the heading Associations. Delete the heading Examples as there are none. Constraint [2] of 11.3.18 says that input pin has no type but there is no such constraint mentioned for 11.3.19 (which is the section describing inputPin.
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.22 -- significant revision?

Key: UML22-680
Legacy Issue Number: 8166
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
If LinkEndCreationData is not an action, should it be in this part? Wouldn't the action be to read data from this element or write data to this element? LinkEndCreationData is found in two packages but the discussion/text only addresses its use from the IntermediateActions with no mention of its use in CompleteActions. If this section is to stay in this part then rewrite introduction, description, associations, constraints and semantics to address its use/application in CompleteActions. OCL notation for Constraint[2] does not say that the UnlimitedNatural must be >0 as is stated in the definition of the association insertAt:InputPin. Too many closing ")" for the number of opening "(" in Constraint [2] OCL notation Delete the Examples header as there are none.
Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.21

Key: UML22-679
Legacy Issue Number: 8165
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Associated figures 148 & 150 do not diagram an direct association between LinkAction and InputPin. Please clarify, add to figures, or delete the association from the section. Constraint [2] OCL notation has an extra ending ) Semantics need to be rewritten clarifying how LinkAction and inputPin are associated. None of the figures containing the classifier LinkAction show an association with a multiplicity of 1..1. Delete heading Examples as there are none.
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.40

Key: UML22-696
Legacy Issue Number: 8185
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typo - removeAt:InputPin [0..1] Unlimitednatural needs correcting. Add specialization to association removeAt:InputPin [0..1] as shown in fig. 147. Constraint [1] needs OCL notation. Add that the Unlimited Natural number must be >0 to the constraint definition. Delete Examples header as there are none. Last statement in the Changes from previous UML is not supported by fig. 147. There is no other mention of RemoveAttributeValusAction in this version of the Superstructure
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Example header is duplicate of 8155. OCL is duplicate of 6346.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.38

Key: UML22-695
Legacy Issue Number: 8183
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete the Examples header as there are none
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8155 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.23 -- significant revision?

Key: UML22-681
Legacy Issue Number: 8167
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
I read and understand little difference between LinkEndData and LinkEndCreationData or LinkEndDestructionData. If none of these elements are actions what are they doing in Actions? Wouldn't the action be to read to or write from these elements? Add the package CompleteActions name to the Description and mention that LinkEndData identifies one end of a link to be destroyed. Add "(IntermediateActions)" to the first Constraint header. I'm not certain that constraint (IntermediateActions) [3] multiplicity agrees with the association value:InputPin[0..1] mulitplicity The instruction under semantics to see LinkAction and its children needs to be rewritten. Through following all of the instructions to see different sections, I finally found semantics information in ReadLinkAction, CreateLinkAction, and DestroyLinkAction. Delete header Examples as there are none.
Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.14

Key: UML22-672
Legacy Issue Number: 8158
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
In description, change "positive integer" to "unlimitedNumber greater than 0" Delete Examples hearder as there are none
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Example header is duplicate of 8155.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.18

Key: UML22-676
Legacy Issue Number: 8162
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
I am confused by the request of issue 7179 to replace 'input' by 'target' in both constraints and then seeing 'input' replaced by 'target' only in the OCL notation. Please clarify. I am also confused by constraint [2] since part 11.3.19 InputPin says nothing about the type of inputPin. Delete the header Examples as there are none.
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.16

Key: UML22-674
Legacy Issue Number: 8160
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Constraint 1 says that the classifier cannot be abstract but fig. 146 shows the Classifier name in italics. Delete header Examples as there are none
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.17

Key: UML22-675
Legacy Issue Number: 8161
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Change "positive integer" in the Description section to "unlimitedNatural >0" Delete the header Example as there are none
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.15

Key: UML22-673
Legacy Issue Number: 8159
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete the header Examples as there are non
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8155 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.53

Key: UML22-709
Legacy Issue Number: 8198
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Put a line feed before Notation header. Delete Examples header as there are none
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.42

Key: UML22-708
Legacy Issue Number: 8197
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The text does not agree with fig. 152. Correct either the figure or the text. Fig shows that ReplyAction generalizes Actions (from BasicActions), that the association replyToCall is to CallEvent not Trigger, that the association replyValue is to InputPin not OutputPin and that this association subsets input from Actions, that the association returnInformation:InputPin subsets input from Actions. Constraint [1] uses the word "trigger" but figure would indicate that "call event" would be more correct. This constraint needs OCL notation. Semantics really don't agree with figure. [2] needs the word "to" added after meaning and the word trigger is still used when the figure would indicate call even is mor appropriate.
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
OCL is duplicate with 6346. Figure 152 should use Trigger instead of CallEvent.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.43

Key: UML22-698
Legacy Issue Number: 8187
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Association target:inputPin[1] subsets input from BasicActions according to figure 145
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.41

Key: UML22-697
Legacy Issue Number: 8186
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The association removeAt:InputPin[0..1] is subsets input from Actions according to fig. 157. Correct typo in Constraint [1] "removaeAt". Add OCL notation for the constraint. Constraint also needs to mention that the Unlimited Natural must be >0. Typo - Last line of para 1 of semantics - change "support" to "supports" Delete header Examples as there are none
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.2

Key: UML22-660
Legacy Issue Number: 8146
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add the specialization (subsets) statement to result:OutputPin[0..*] as shown in fig. 152. Add OCL statements to Constraints. Constraint [2] needs clarification. Last part of sentence is confusing. Typo - Semantics, para 2, sentence 1 - Change "unmarshall" it "isUnmarshall"
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Missing OCL is a duplicate of 6452.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.9

Key: UML22-667
Legacy Issue Number: 8153
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation to Constraints. Delete Examples heading as there are none
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issues 8155 and 6346 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.8

Key: UML22-666
Legacy Issue Number: 8152
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig. 144 shows a default for isSynchronous:Boolean = true but this is not indicated in the Attributes section. Associations result:OutputPin[0..*] multiplicity does not match fig. 144; change the description to: "An ordered list of output pins..." and add a statement about the specialization or subsets. Add OCL notation to Constraints.
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Multiplicity is in proper format. Lists are always ordered. OCL is duplicate with 6346.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.12

Key: UML22-670
Legacy Issue Number: 8156
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete Examples header as there are none
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8155 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.11

Key: UML22-669
Legacy Issue Number: 8155
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete Examples header as there are none
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: Fixed as part of a previous copy-edit pass of the spec. Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.10

Key: UML22-668
Legacy Issue Number: 8154
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation to Constraints. Typo - place a period at the end of the definition of the operation:Operation[1] association Add a subsets or specialization statement to the association target:InputPin[1] as is shown in fig. 144
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
OCL is duplicate with 6346
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.6

Key: UML22-664
Legacy Issue Number: 8150
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
It seems to me that the OCL statement does not specify that the UnlimitedNatural needs to be >0. Add "The insertion point is ignored when replacing all values." as last sentence in para 2 of Semantics. Remove the header Examples as there are none.
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.7

Key: UML22-665
Legacy Issue Number: 8151
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL statements as appropriate for Constraints. Typo - Need a couple of line feeds before the header Notation
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Missing OCL is a duplicate of 6452.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.5

Key: UML22-663
Legacy Issue Number: 8149
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
It seems to me that the OCL statement does not specify that the UnlimitedNatural needs to be >0. Remove the header Examples as there are none
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.13

Key: UML22-671
Legacy Issue Number: 8157
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete Examples header as there are none.
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8155 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Connector multiplicity notation

Key: UML22-579
Legacy Issue Number: 8027
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Connector multiplicity notation The notation section of ConnectorEnd says multiplicities shown on connector lines represent the multiplicities of both the association and the connector: These adornments specify properties of the association typing the connector. The multiplicity indicates the number of instances that may be connected to each instance of the role on the other end. But these multiplicity can be different, and have separate elements in the metamodel.
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Associations between interfaces

Key: UML22-578
Legacy Issue Number: 8025
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Associations between interfaces The wording of the caption in Figure 56 implies that association between interfaces have implication on required and provided interfaces. My udisjoinnderstanding from mailing list discussion is that this is only an example, not a semantics. Should be clarified in the caption that this is an example of applying associations to interfaces.
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

create dependency Figures 103 and 121

Key: UML22-580
Legacy Issue Number: 8028
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
create dependency Figures 103 and 121 use create dependencies, which do not apply to the example. Standard stereotypes defines create for BehavioralFeature as: "Specifies that the designated feature creates an instance of the classifier to which the feature is attached. May be promoted to the Classifier containing the feature."
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Transitivity in composition

Key: UML22-573
Legacy Issue Number: 8015
Status: closed
Source: NIST ( Mr. Evan K. Wallace)
Summary:
Transitivity in composition: The semantics of Association say composite associations are transitive. Transitivity violates the single-owner rule for composition mentioned in the same paragraph. It also requires that the association have the same class on both ends.
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

underlined association name

Key: UML22-581
Legacy Issue Number: 8029
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
underlined association name Figures 120 and 121 underline the association names, which doesn't seem consistent with the notation for instances in Figure 21.
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
The notation for instance specification seems clear that if an association name is shown on an instance specification, that this name would be underlined, see p.84: “It is not necessary to show an underlined name where it is clear from its connection to instance specifications that it represents a link and not an association.” (The diagram example in that section does not show the name.) Therefore, the above two figures are consistent with the notation defined for instance specifications. One could eliminate the association name, if so desired. Revised Text: Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

Key: UML22-577
Legacy Issue Number: 8021
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Specializing one association end Suppose we have a class diagram like this: <pre>
aend bend
A ----------------------------- B
^ ^

subbend

{subsets bend}

SubA -------------------------- SubB

</pre>
What metarelation is used between the lower left end and the upper left end (aend)? It is not redefined or subsetted.
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Add concept "StateInvariant"

Key: UML22-572
Legacy Issue Number: 7996
Status: closed
Source: SINTEF ICT ( Richard Torbjørn Sanders)
Summary:
Add concept "StateInvariant" in figure, with arrows to "mystate" and "
{Y.p == 15}
"
Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Pin/parameter matching constraints

Key: UML22-574
Legacy Issue Number: 8017
Status: closed
Source: International Business Machines ( Mr. Jim Amsden)
Summary:
Pin/parameter matching constraints: The wording for CallAction, constraints 2 and 3 should be consistent with the wording of constraint 3 for CallBehaviorAction and CallOperationAction
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

Key: UML22-576
Legacy Issue Number: 8019
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
Dependency should specialize source/target On Dependency, client and supplier should specialize source and target from DirectedRelationship. Source/target are derived unions, so can't be used otherwise
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: CB/ACT

Key: UML22-575
Legacy Issue Number: 8018
Status: closed
Source: MEGA International ( Mr. Antoine Lonjon)
Summary:
Matching by order difficult to implement Matching by order of the parameters of methods and operations and pins and parameters is difficult to implement in relation database implementations.
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.9

Key: UML22-723
Legacy Issue Number: 8217
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add the multiplicity [1..] to the association. Reword the description of the association parameter:Parameter. It could be interpreted as "the same object node will accept as well as provide parameter values." If that's not the case, i.e., one node accepts and another not provides (which I think is what is meant) then change the "and" to "or." Add OCL notation to the constraints. Constraint [3] needs rewording to something like "Activity parameter nodes must have neither incoming nor outgoing edges" or "Activity parameter nodes must have only incoming or outgoing edges but not both." Wording depends on meaning of constraint. Please clarify semantics to address the following questions. Are input values placed as tokens on input activity parameter nodes at the beginning of flows? Since this node is at the beginning of the flow is that why it has no incoming edges? If it has no incomind edges, how are the values placed on the node? Para 1 of semantics says to see semantics at ObjectNode, Action, and ActivityParamenterNode. This is the semantics section for ActivityParameterNode. Delete that phrase or correct it to the proper reference semantics section. The package CompleteActivities does not show any diagrams with ActivityParameterNode. Delete those package references on pg. 366 or explain why that package is referenced.
Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.1

Key: UML22-722
Legacy Issue Number: 8216
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
If BasicActivities and StructuralActivities are orthogonal, why does the structural level require the basic level? This concept is not supported by fig. 175. Please forgive me if I've already sent this one in, but I hadn't marked my comment as submitted.
Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8202 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.4

Key: UML22-641
Legacy Issue Number: 8120
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Correct statement under Constraints to read "No additional constraints."
Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.10

Key: UML22-640
Legacy Issue Number: 8117
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
I can't find appropriate figure for the generalization "Parameter (from Kernel, AssociationClasses)". Add appropriate OCL notation to Constraints
Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.1

Key: UML22-647
Legacy Issue Number: 8132
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Figure 124 does not show what the Generalizations "Classifier (from Kernel, Dependencies, PowerTypes)" indicates, or the association ownedProperty:Property, or the multiplicity listed for attribute filename:String[0..1]
Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.1

Key: UML22-648
Legacy Issue Number: 8133
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Typo in 1st line of Notation. In Semantics, clarify which Appendix to see
Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Both matters raised by this issue represent valid editorial clarifications to the text.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.13

Key: UML22-644
Legacy Issue Number: 8129
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Under Notation change "name of the part" to rolename to differentiate it from the name of the part (as in composition).
Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.13

Key: UML22-645
Legacy Issue Number: 8130
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig 121 uses the word "make" for the constructor. Unfortunately, this word could be misconstrued to be a noun and refer to the make of the car (Volvo, Audie, Ford) instead of the verb it is intend to be. Suggest changing "make" to "assemble."
Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.13

Key: UML22-643
Legacy Issue Number: 8128
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Associations need derived symbol added to role:ConnectableElement and /part:Property (as shown in fig. 95), a statement that role is derived, and multiplicities added to all associations (as shown in fig. 95).
Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see ptc/2006-04-01 page 140
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.9

Key: UML22-639
Legacy Issue Number: 8116
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation to Constraints. Notation says to see "CallOperationAction" for an example, but no examples are given in that section
Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.2

Key: UML22-646
Legacy Issue Number: 8131
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
There is no explanation in the chapter or the section on StrucutredActivities as to why two StructuredActivities packages are drawn, both <<merge>> in fig. 94. Please clarify somewhere
Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.12

Key: UML22-642
Legacy Issue Number: 8127
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
In Examples, the reference page number to SturcturedClassifier is incorrect
Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.4.1

Key: UML22-615
Legacy Issue Number: 8085
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Multiplicity is non-negative so shouldn't the lower bound be typed as an unlimited natural (a non-negative number) instead of an integer which can be negative? The upper bound is typed as an unlimited natural. This question also applies to Infrastructure (ptc/03-09-15, sections 9.11 and 9.12).
Reported: UML 2.0 — Wed, 12 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.6

Key: UML22-614
Legacy Issue Number: 8084
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
There appears to be a conflict between the Superstructure VisibilityKind and the Infrastructure VisibilityKind (ptc/03-09-15, section 9.20.2, pg 93). Superstructure lists the four found in vers 1.5 of UML but Infrastructure lists only public and private. What is the correct enumeration for VisibilityKind? Has the Superstructure refined the Infrastructure? If so, a clarification that Superstructure VisibilityKind is refining that from Infrastructure would be helpful.
Reported: UML 2.0 — Wed, 12 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.8.3

Key: UML22-610
Legacy Issue Number: 8080
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Figure 98 shows an merged package P::A in the source package S. I do not see how P::A got merged when Figure 97 shows no merge between target P and source S or between source R and source S. The text says that packages P and Q are being merged by package R while package S merges on package Q (with the open ended arrow indicating Q as the target but the keyword <<merge>> at the end nearest S. The statement above Figure 98 says the transformed packages R and Q are shown but the figure has the packages labeled R and S. There appears to be no merge connection between P and S but a subpackage from P appears in S. The text and figures are very confusing and need clarification
Reported: UML 2.0 — Fri, 7 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.6.1

Key: UML22-609
Legacy Issue Number: 8079
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The each sentence in the third paragraph under semantics appears to have an incorrect "and" in them. I believe the and should be replaced by the word "or" in each sentence. The second paragraph seems to have a couple of misplaced hyphens.
Reported: UML 2.0 — Thu, 6 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.3

Key: UML22-613
Legacy Issue Number: 8083
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Second sentence in second paragraph under description is somewhat confusing. "The constraint does not necessilarily apply to the namespace itself, but may also apply to the elements in the namespace." The use of the word "also" bothers me. Do you mean "instead" rather than also. Wouldn't it make more sense, in the context of the first part of the sentence, that the constraint could instead apply to the elements in the namespace rather than the namespace. If you mean that a constraint could apply to both or the namespace or the element in the namespace then the statement needs to be reworded
Reported: UML 2.0 — Wed, 12 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
The text does need to be reworded to eliminate such confusion.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.1.5

Key: UML22-612
Legacy Issue Number: 8082
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Figure 115 shows the <<enumeration>> Color, but shouldn't that be labeled as ColorKind as shown in Figure 88 and specified in Conventions and Typography in 8.5?
Reported: UML 2.0 — Mon, 10 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.5

Key: UML22-607
Legacy Issue Number: 8076
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The phrase that starts "These constructs that are used..." is not a complete sentence and confusing. I believe that the word "that" needs to be deleted
Reported: UML 2.0 — Wed, 5 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

search for referenced item -- Section: 11.3.4

Key: UML22-606
Legacy Issue Number: 8075
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
A reference is made to the Operations Diagram in the Description section but no figure number (93) or page number (146) is given. It would save time and greatly decrease the frustration factor for this reader if I didn't have to search for the referenced item.
Reported: UML 2.0 — Wed, 5 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 68

Key: UML22-603
Legacy Issue Number: 8072
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Figure 68 does not show the
{composite}
notation for the attribute ownedType: Type
Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

methods not defined under attributes

Key: UML22-602
Legacy Issue Number: 8070
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
In all previous sections when a diagram shows a named association, the text defines these under the heading Associations. All of a sudden you've changed methods and are not defining these under attributes. A clarification as to why this is done would help those of us who are not UML experts.
Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.1.2

Key: UML22-611
Legacy Issue Number: 8081
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Additional option [1] says that the query lowerBound () returns the lower bound of the multiplicity as an Integer. Why is the type Interger used instead of the type UnlimitedNatural? An integer can be a negative number but not so with naturals. My understanding is that multipliticity is not allowed to be less than 0.
Reported: UML 2.0 — Mon, 10 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.3

Key: UML22-605
Legacy Issue Number: 8074
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The description refers to the Classifiers Diagram but no figure number (Figure 84) or page number (page 127) is given. It would greatly facilitate the reading if the user did not have to search for this. In section 6.3 on How to Read this Specification, it is stated that extensive cross-references are given. This specification would be better if more cross-references were given, especially when a figure or section that is found elsewhere in the document is referenced. I sent in a request to clarify Chapter/Section 10.2. I have since found that an excellent clarification exists in Chapter 11.3. If this had be referenced in Chapter 10.2 it would have saved this reader several hours of confusion and frustration
Reported: UML 2.0 — Wed, 5 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.1

Key: UML22-604
Legacy Issue Number: 8073
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The last phrase in the sixth paragraph from the top which starts with "For n-ary associations..." is an incomplete prepositional phrase and the meaning is unclear
Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Actor is a specialized Classifier and not BehavioredClassifier

Key: UML22-608
Legacy Issue Number: 8078
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Actor is a specialized Classifier and not BehavioredClassifier. Therefore an actor is not allowed to realize an interface. I propose to inherit Actor from BehavioredClassifier. It is useful to model actors with interfaces. The actor/subject communication requires the definition of signals/messages that can be sent from the subject to an actor.
Reported: UML 2.0 — Thu, 6 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see ptc/2006-04-01 p 108/109
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.1

Key: UML22-711
Legacy Issue Number: 8202
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Italicize activity as well as execution in sent 2 of para 1 under Actions and activities. Basic Activities describes basic and structured levels as orthogonal where either can be used without the other or both can be used to support modeling... . Yet StructuredActivities says that this level requires the basic level. Fig. 175 does not support this statement. Please clarify and fix.
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.54

Key: UML22-710
Legacy Issue Number: 8199
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete header Examples as there are none
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8155 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

{redefined } should be named {redefines }

Key: UML22-713
Legacy Issue Number: 8204
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary: {redefined <end-name>}
should be named
{redefines <end-name>}
Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Typo in the Superstructure spec; it does not occur in the Infrastructure.
Updated: Fri, 6 Mar 2015 20:58 GMT

Property string {bag} is redundant

Key: UML22-712
Legacy Issue Number: 8203
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Property string
{bag}
is redundant. Use property string
{nonunique}
defined for MultiplicityElement instead
Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.5

Key: UML22-718
Legacy Issue Number: 8210
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add subsets (or specializes) or redefines statements to associations as indicated by the associated figures. Correct either the association multiplicity or the associated diagram multiplicity so that they agree. Italicize ActivityEdge in fig. 196. Add OCL notation to constraints. In Semantics (CompleteActivities) change "Edges" beginning paragraphs 3 and 4 to "ActivityEdges". In notation change stick-arrowhead to open arrowhead
Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.4

Key: UML22-717
Legacy Issue Number: 8209
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation to constraints
Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 6452 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.48

Key: UML22-703
Legacy Issue Number: 8192
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig. 241 shows the generalization of UnmarshallAction to be Actions (from Basic). Correct either figure or text. Association object:inputPin[1..1] subsets nput from Input and association result:OutputPin[1..1] subsets output from Output according to fig 241. Add OCL notation to constraints
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
OCL is duplicate with 6346.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.46

Key: UML22-701
Legacy Issue Number: 8190
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation to constraint [2]. My guess would be self.object.type=self.classifier.type (That's pure guess since I know very little OCL.) Delete header Examples as there are none
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 6452, 8155 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.45

Key: UML22-700
Legacy Issue Number: 8189
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL Notation to Constraints
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 6452 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.52

Key: UML22-707
Legacy Issue Number: 8196
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete Examples header as there are none
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8155 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.51

Key: UML22-706
Legacy Issue Number: 8195
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete Examples header as there are none
Reported: UML 2.0 — Sun, 9 Jan 2000 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8155 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.50

Key: UML22-705
Legacy Issue Number: 8194
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Association value:ValueSpecification[1] does not express a specialization in the figure. Please correct either text or figure. Add OCL notation to constraints
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
OCL request is duplicate of 6346.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.44

Key: UML22-699
Legacy Issue Number: 8188
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Association target:inputPin[1] subsets input from Input according to fig 144. Add OCL notation to the constraints. Semantics [1] change "his" to "the".
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
OCL is duplicate with 6346.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.49

Key: UML22-704
Legacy Issue Number: 8193
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Add OCL notation to constraints. Delete Examples header as there are none
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 6452, 8155 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.47

Key: UML22-702
Legacy Issue Number: 8191
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Delete header Example as there are none
Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8155 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

unclear statement

Key: UML22-596
Legacy Issue Number: 8064
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The last part of the following statement makes no sense to me: "Understandability. While increasing the precision and conciseness, the specification techniques should also improve the readability of the specification. For this reason a less than strict formalism is applied, since a strict formalism formal technigues" It appears that part of the sentence got left out as there is no period
Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
There is a word missing in this text.
Updated: Fri, 6 Mar 2015 20:58 GMT

Text references Figure 8 and the correct figure number is 6

Key: UML22-595
Legacy Issue Number: 8063
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Text references Figure 8 and the correct figure number is 6
Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
This is indeed an incorrect figure reference.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section is badly worded and does not make a lot of sense

Key: UML22-599
Legacy Issue Number: 8067
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Section is badly worded and does not make a lot of sense. I interpreted it as "Often an informal convention is used to show (a part of) a construct, e.g., the name of a class should be centered and in bold."
Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

clarify what a directed association is

Key: UML22-598
Legacy Issue Number: 8066
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
am not an expert on UML and am reading this to learn about it. Could you please clarify what a directed association is. A search of the document does not yield any other reference to this term.
Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Terminology Issue

Key: UML22-593
Legacy Issue Number: 8042
Status: closed
Source: Object Management Group ( Stephen Mellor)
Summary:
When we build a state machine (nee State chart diagram) to define the behavior of a Dog, say, each dog instance has its own state.

In other words, each copy of the state machine diagram has it's own state. What is the official term for each-copy-of-the-state-machine, the entity that has state. We need to be able to say "The <state machine thing> for Fido is in the state 'Barking'" and "The <state machine thing> for Rover is in the state Sleeping".
Reported: UML 1.4.2 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Resolution: The submitter does not raise an issue against the specification, but asks a question for clarification. Such terminology might be useful in explaining the semantics, but is not required for the specification. Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

typing error in the statement :unrestricted ?

Key: UML22-600
Legacy Issue Number: 8068
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
believe there is a typing error in the statement :unrestricted: Indicated that there is no restriction no [should be to?] adding new values, changing a value, or removing values to an occurrence of a StructuralFeature
Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

extra word in the last sentence of the paragraph under Attributes

Key: UML22-597
Legacy Issue Number: 8065
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
believe that there is an extra word in the last sentence of the paragraph under Attributes. "If the mulitplicity of the attribute is supressed if it is '1' (default in UML)." I believe the sentence should read "The multipliticy of the attribute is supressed if is is '1' (default in UML)."
Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

section 9.20.2 VisibilityKind lists two types of visibility

Key: UML22-594
Legacy Issue Number: 8062
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
In section 9.20.2 VisibilityKind lists two types of visibility-~~Public and Private. Yet the glossary (page 19) and Figure 80 on page 119 (and many other figures) list threePublic, Private, and Protected. Version 1.5 also defined a fourth type of visibility~~-Package. Please clarify and or enhance the definition of VisibilityKind in 9.20.2 to explain the differences between the glossary and the Figure.
Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

StructuredActivityNode specialized multiplicity

Key: UML22-592
Legacy Issue Number: 8041
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
The semantics of StructuredActivityNode still says "This constraint is modeled as a specialized multiplicity from ActivityNode and ActivityEdge to StructuredActivityNode". The FTF changed the metamodel for this to not use specialized multiplicity.
Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

What happened to real numbers

Key: UML22-601
Legacy Issue Number: 8069
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The elements for numbers you define in the Literals package are LiteralInteger and LiteralUnlimitedNatural. What happened to real numbers? Natural numbers do no include decimals.
Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12

Key: UML22-724
Legacy Issue Number: 8218
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Use of the term edge(s)is confusing without the appropriate qualifier - "Control" or "Object." Suggest changing edge or edges to ControlEdge(s) and/or ObjectEdge(s) as appropriate
Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.4

Key: UML22-662
Legacy Issue Number: 8148
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Association fromAction:Action[1] missing the specialization or subsets statement shown in fig. 159. Add OCL statements to constraints. Fig. 161 shows the association +action between i2:ActionInputPin and s1:ReadSetAction and between i4:ActionInputPin and s2:ReadSetAction but this is not an association defined for ActionInputPin in the text or shown on fig. 159. Either correct +action association to +fromAction or add +action as an association of ActionInputPin. I may be totally incorrect but shouldn't there be some link or association from the classifier bar:Signal?
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See revised text. The rest is duplicate with 6452.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.3

Key: UML22-661
Legacy Issue Number: 8147
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig. 142 does not list Dependencies as a generalization. Associations /input:InputPin[*] and /output:OutputPin[*] need the specialization or subset statement as shown in fig. 143 Association /context:Classifier[1] does not agree with multiplicity in fig. 142 Delete headers Examples and Rationale as these sections are blank
Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.10

Key: UML22-655
Legacy Issue Number: 8140
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig 124 shows that the Association utilizedElement:PackageableElement also subsets target
Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.9

Key: UML22-654
Legacy Issue Number: 8139
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Constraints are not shown on fig 126 as other constraints have been shown on other figures. Under Notation, should "instance" be "instance specification?"
Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.4

Key: UML22-657
Legacy Issue Number: 8143
Status: closed
Source: Anonymous
Summary:
Table 8 Node Reference says Node has keyword options <<device>> and <<execution environment>> but these are not mentioned in the Node section nor are they diagrammed anywhere.
Reported: UML 1.4.2 — Wed, 26 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.6

Key: UML22-652
Legacy Issue Number: 8137
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Fig 126 does not show all generalizations listed; text for the Association deployment:Deployment[*] does not mention that the association specializes ownedElement as shown in the figure
Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.11

Key: UML22-656
Legacy Issue Number: 8141
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The specialization of the association nestedNode:Node is not shown in fig. 125
Reported: UML 2.0 — Wed, 26 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
There is no nestedClassifier association end that applies to this case.
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.4

Key: UML22-650
Legacy Issue Number: 8135
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
The Associations for the Nodes Package text do not agree with Fig. 126.
Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.8

Key: UML22-653
Legacy Issue Number: 8138
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
I don't believe that fig 125 shows the composite association between nodes and ExecutionEnvironment as expressed in Semantics. Typo - add ending guillemets to <<J2EE container.
Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.3

Key: UML22-649
Legacy Issue Number: 8134
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Kernel generalization is not shown in fig. 126
Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.5

Key: UML22-651
Legacy Issue Number: 8136
Status: closed
Source: U. S. Geological Survey ( Jane Messenger)
Summary:
Generalization, Association, and Constraints in text don't agree with fig. 127
Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see ptc/2006-04-01 page148/149
Updated: Fri, 6 Mar 2015 20:58 GMT

ReduceAction

Key: UML22-565
Legacy Issue Number: 7977
Status: closed
Source: Object Management Group ( Stephen Mellor)
Summary:
It has come to my attention that the removal of the ReduceAction (fair
enough) requires the use of a variable (a very bad idea) to construct an
alternative specification.

To do something like Reduce(<data expression>, Add) in UML 1.5, you
would have to say:
- An activity/structure node with variable Sum.
- The expansion region takes the collection as input and has no
  output. In this case, the output collection will have only one
  element in it.
- In the region, edges coming from/going to the inputs/outputs take
  elements from the input collections and put elements in the output
  collections.
- The region uses CallOperationAction with operation timeofLastCall to
  get the time and CallBehaviorAction on the (primitive)
  FunctionBehavior for addition and updates the variable.
- After the region is complete, the variable has the sum in it.
The 1.5 Action Model included variables so that those who "needed" them
could have them. However, the introduction of variables changes the
static-single-assignemnt nature of the language and would now require
data-flow analysis of a developer model to work out what is happening.
Before all we had to do was scan for Variable Actions and reject the
developer model so proposed.

In other words, those of us in the translation business did not need
variables, and we could ignore those models that used them. Now we're
stuck.

Topic: ReduceAction

UML 1.5 had ReduceAction, which repeatedly applied a function pairwise
to elements of a collection until only only element is left. It did not
constrain order or concurrency of application. It was replaced with
ExpansionRegion UML 2, which requires commitment to order and
concurrency.
Reported: UML 1.4.2 — Tue, 14 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Corrections to issue description:
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Incorrect statement on port visibility

Key: UML22-564
Legacy Issue Number: 7973
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
The updated UML spec p162 states:

"UML Superstructure 2.0 Draft Adopted Specification

A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. If the port
symbol is placed overlapping the boundary of the rectangle symbol denoting that classifier this port is exposed (i.e., its
visibility is public). If the port is shown inside the rectangle symbol, then the port is hidden and its visibility is as specified (it
is protected by default)."

This text was supposed to be removed by the FTF – the placement of the port is independent of its visibility. Port placement is merely a question of graphical convenience. Their visibility is indicated by the usual means as for all other properties (+, -, and #).
Reported: UML 1.4.2 — Fri, 10 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.7

Key: UML22-566
Legacy Issue Number: 7986
Status: closed
Source: SINTEF ( Richard Sanders)
Summary:
... of an object. (missing period) ... destruction of the instance -> of the object ... that this instanceowns -> instance owns
Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Minor error in BNF of an message argument

Key: UML22-563
Legacy Issue Number: 7970
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
Minor error in BNF of an message argument: Instead <argument> ::= (<[parameter-name> ‘=’] write <argument> ::= ([<parameter-name> ‘=’]
Reported: UML 2.0 — Tue, 7 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.14

Key: UML22-568
Legacy Issue Number: 7988
Status: closed
Source: SINTEF ( Richard Sanders)
Summary:
... <interactionconstraint> -> <InteractionConstraint> ... in Figure 335 -> Figure 335 or 352
Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.16

Key: UML22-569
Legacy Issue Number: 7989
Status: closed
Source: SINTEF ( Richard Sanders)
Summary:
... and InteractionOperand represent -> represents
Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

StateInvariants/Continuations

Key: UML22-571
Legacy Issue Number: 7995
Status: closed
Source: SINTEF ICT ( Richard Torbjørn Sanders)
Summary:
StateInvariants/Continuations: add to figure a Continuation (e.g. Idle) that spans :Y and an additional lifeline :X
Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Table 14

Key: UML22-570
Legacy Issue Number: 7990
Status: closed
Source: SINTEF ( Richard Sanders)
Summary:
Bottom of page: Node type "Stop" should be "Destruction event"
Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.13

Key: UML22-567
Legacy Issue Number: 7987
Status: closed
Source: SINTEF ( Richard Sanders)
Summary:
... needs not be the whole -> need not be
Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

DataType attributes UML 2 Super (ptc/04-10-02)

Key: UML22-553
Legacy Issue Number: 7939
Status: closed
Source: The MathWorks ( Mr. Alan Moore)
Summary:
On Figure 13, DataType::ownedAttribute is specified as ordered but in the
associations section on page 59, it is not specified as ordered.
Reported: UML 1.4.2 — Fri, 19 Nov 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

In normative XMI file for the metamodel, no Associations have a name.

Key: UML22-534
Legacy Issue Number: 7105
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
In the normative XMI file for the metamodel, no Associations have a
name.
The name is needed for generating APIs and (in some cases) XMI elements;
and their absence actually makes UML2 an invalid MOF2 metamodel: MOF2
Core has the following constraint for CMOF:
[6] Names are required for all classifiers and features (though there is
nothing to prevent these names being automatically generated by a tool).

(Association is a classifier)

We could get by with not having a name in the MDL and auto-generating a
name into the XMI. This is in fact what the Unisys XMI plug-in did when
no Association name was provided - and this was hence reflected in the
normative XMI for UML 1.x (the names were of the form A_<end1>_<end2>).
Reported: XMI 2.0 — Mon, 8 Mar 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/Constraints for create messages

Key: UML22-533
Legacy Issue Number: 6989
Status: closed
Source: KDM Analytics ( Dr. Nikolai Mansourov)
Summary:
page 429 Constraints for message need to include "no EventOccurences before receiving the create message". In the graphic notation this is handled by defining the create graphic path as flowing into the Lifeline head symbol, but since we do not want to introduce the concept of a Lifeline head in the meta-model, we need an additional constraint.

Constraints need to be updated as new sorts of messages are added.
Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Infra/11.5.1/Invalid reference to Attribute class

Key: UML22-536
Legacy Issue Number: 7274
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
In section 11.5.1 (DataType) the first association is specified as:

ownedAttribute: Attribute[*] The Attributes owned by the DataType.

This is out of date: the class Attribute has been replaced by Property,
though the association name is OK referring to 'Attribute'. This is
reflected in the diagram above that text (Fig 86).

Proposed resolution:
Replace the above text with:
ownedAttribute: Property[*] The Properties owned by the DataType.
Reported: XMI 2.0 — Wed, 28 Apr 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 78

Key: UML22-535
Legacy Issue Number: 7246
Status: closed
Source: PostFinance ( Karl Guggisberg)
Summary:
Figure 78 - inconsistencies with Class Descriptions Figure 78 shows an enumeration ConnectorKind which is not defined in this chapter, however (see also Issue #7001). Suggestion: define ConnectorKind in section 8.3 - Class Descriptions. Figure 78 shows an association between Connector and Behavior with association end "+contract". This association is not defined in Section 8.3.2 - Connector, however.
Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: Fixed by the resolution to issue 8976 in UML 2.1. Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Class InfrastructureLibrary::Core::Basic::Property

Key: UML22-532
Legacy Issue Number: 6923
Status: closed
Source: Fraunhofer FOKUS, Germany ( Michael Soden)
Summary:
Class InfrastructureLibrary::Core::Basic::Property contains an attribute named 'default' of type 'String'. If initial values should be provided for a Property instance, then there is no possibility to evaluate the string without a schema. I'm not sure about the intension of this default property, especially for MOF (it seems to be useable only for visualization in UML).

Proposed resolution: If evaluation should be processable by tools (e.g. code generators), then the type of 'default' must be changed to class "Type" or a schema for evaluation should be provided.
Reported: UML 2.0 — Mon, 19 Jan 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

In 2.13.3, the first sub-section about ActivityGraph is not numbered

Key: UML22-531
Legacy Issue Number: 6727
Status: closed
Source: Condris Technologies ( Valentin Crettaz)
Summary:
In 2.13.3, the first sub-section about ActivityGraph is not numbered, it should be 2.13.3.1. Subsequent sub-sections should be renumbered
Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

missing closing parenthesis

Key: UML22-529
Legacy Issue Number: 6725
Status: closed
Source: Condris Technologies ( Valentin Crettaz)
Summary:
In the second additional operation of the model element StateMachine, there is a missing closing parenthesis in the last else branch, i.e. the last else branch should read
Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Indeed so.
Updated: Fri, 6 Mar 2015 20:58 GMT

The Composition section does not follow the usual conventions

Key: UML22-528
Legacy Issue Number: 6724
Status: closed
Source: Condris Technologies ( Valentin Crettaz)
Summary:
The Composition section does not follow the usual conventions of first presenting the attributes and then the associations of the model element.
Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

In "2.9.3.5 Instance", numbering of different well-formedness rules wrong

Key: UML22-526
Legacy Issue Number: 6703
Status: closed
Source: Condris Technologies ( Valentin Crettaz)
Summary:
In "2.9.3.5 Instance", the numbering of the different well-formedness rules is wrong. Below rule [2], there are two rule [3], one of which is not left-aligned properly.
Reported: UML 1.5 — Wed, 17 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

The numbering of the sub-sections in 2.7.2 is wrong

Key: UML22-525
Legacy Issue Number: 6702
Status: closed
Source: Condris Technologies ( Valentin Crettaz)
Summary:
The numbering of the sub-sections in 2.7.2 is wrong. In "2.7 Data Types", we have "2.7.1 Overview" and "2.7.2 Abstract Syntax". Below that, the numbering starts with "2.7.3.1 AggregationKind" instead of "2.7.2.1 AggregationKind".
Reported: UML 1.5 — Wed, 17 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Associations section of element JumpHandler

Key: UML22-523
Legacy Issue Number: 6697
Status: closed
Source: Condris Technologies ( Valentin Crettaz)
Summary:
In the Associations section of element JumpHandler, the protectedAction association misses appropriate type information.

The line should read:

protectedAction: Action [0..*]
Reported: UML 1.5 — Mon, 15 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Remove one of the dots between protectedAction and availableOutput

Key: UML22-522
Legacy Issue Number: 6696
Status: closed
Source: Condris Technologies ( Valentin Crettaz)
Summary:
In the Outputs listing, "self.jumpHandler.protectedAction..availableOutput.type" should read "self.jumpHandler.protectedAction.availableOutput.type"

Remove one of the dots between protectedAction and availableOutput
Reported: UML 1.5 — Mon, 15 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 infra and super Constraints Diagram of the Kernel

Key: UML22-524
Legacy Issue Number: 6699
Status: closed
Source: TimeWarp Engineering Ltd. ( Steven Cramer)
Summary:
The Constraint:namespace to Namespace:ownedRule association depicted in the super structure spec on page (31) should be made navigable on both ends and the namespace property should be renamed to owningNamespace and this should subset context and subset namespace.
Reported: UML 1.5 — Tue, 16 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

The section about Procedure does not contain any well-formedness rules

Key: UML22-527
Legacy Issue Number: 6704
Status: closed
Source: Condris Technologies ( Valentin Crettaz)
Summary:
The section about Procedure does not contain any well-formedness rules. Instead, the section repeats the content (copy-paste!!) of section 2.9.2.11 about attributes and associations.
Reported: UML 1.5 — Wed, 17 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

At the bottom of the page, the characters "antics." should be removed

Key: UML22-530
Legacy Issue Number: 6726
Status: closed
Source: Condris Technologies ( Valentin Crettaz)
Summary:
At the bottom of the page, the characters "antics." should be removed
Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent use of 'Element' between MOF and UML

Key: UML22-549
Legacy Issue Number: 7889
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
UML uses Element to mean any Element in a Model, which is inherently something that has an identity separate from its value: this even includes elements such as ValueSpecification.
MOF uses Object for such a thing, and uses Element to represent any value: specifically when used to declare parameters in Reflection then Element is used to represent both 'Objects' and plain data values (such as integers or strings) used as property or parameter values. Object inherits from Element.

Proposed resolution:

MOF should swap the names of Object and Element: this makes it consistent with UML and with languages such as Java where java.lang.object can represent data values.
Reported: UML 1.4.2 — Mon, 1 Nov 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Missing XMI tags in spec and XMI rendition of metamodel

Key: UML22-548
Legacy Issue Number: 7783
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
This issue applies to Infrastructure, Superstructure and MOF

In the XMI for Superstructure for example (in OMG document ad/03-04-02),
while this does use the nsuri for MOF (using the correct form
xmlns:cmof="http:///schema.omg.org/spec/mof/2.0/cmof.xmi) it does not
contain any XMI tags to define for UML what its nsuri and prefix should
be: which are needed in order to generate the UML xsd.
Neither does the XMI for the MOF Core itself contain an XMI tag to
define that the nsuri and prefix should be as just quoted.

In any case these important values should be included in the
specification documents as well as being buried in tags in the XMI
files.
Reported: UML 1.4.2 — Fri, 24 Sep 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

ptc-03-09-15/Constructs::Class superClass property

Key: UML22-504
Legacy Issue Number: 6493
Status: closed
Source: David Frankel Consulting ( David Frankel)
Summary:
Issue: Constructs::Class has a superClass property that redefines general,
which is from Constructs::Classifier (section 11.3, figure 73, p. 111); but
Constructs::Class also inherits from Basic::Class, which has superClass as a
property (section 10.2, 66, p. 97). What does this mean? Is this a bug?
Is it something correct having to do with package merge?

Recommendation: Determine whether this is intended or an oversight. If it
is an oversight, correct it. If not, explain the meaning of having these
both of these properties.
Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

ptc-03-09-15/Non-navigable ends with no role names nor multiplicities

Key: UML22-503
Legacy Issue Number: 6492
Status: closed
Source: David Frankel Consulting ( David Frankel)
Summary:
Issue: It appears that associations with neither end names nor
multiplicities on non-navigable ends are used in parts of the UML Core that
are defined via CMOF. See, for example, section 9.9, figure 35, p. 62, for
example. I understand that for elements defined via EMOF, this signifies a
simple property. But is it appropriate for elements defined with CMOF.

Recommendation: Either correct this by adding multiplicities and end names
or explain in the specification why it is alright to omit them in these
cases
Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
The meaning of this convention should be explained in the document.
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Issue: Message notation

Key: UML22-502
Legacy Issue Number: 6463
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
PROBLEM STATEMENT
According to Superstructure, p. 430, the notation for messages in
interaction diagrams is as follows (we put assumptions between parenthesis):

asynchronous message - (solid line) open arrowhead
synchronous message - (solid line) filled arrowhead
reply message - dashed line (filled or open arrowhead?)
object creation - dashed line open arrowhead

However, the example given in Figure 333, p. 414, shows a different
notation:

asynchronous message - solid line open arrowhead (not shown in this diagram,
but in others)
synchronous message - solid line filled arrowhead
reply message - dashed line OPEN arrowhead
object creation - SOLID line open arrowhead

Another confusing aspect of the notation is that in a reply message, which
is not a true message, the message name is the name of the operation invoked
on the callee (same as in the corresponding synchronous call), but it
suggests instead that there is an operation with this name in the caller. In
Figure 333, the reply labeled as "foo(_)" visually suggests that there is an
operation named foo in class C1, which is wrong: foo is defined in C2, not
in C1. It would make more sense to label a reply message with the name of
the value returned.

PROPOSED SOLUTION
The simplest solution would be to fix Figure 333 using a dashed arrow to
represent object creation, although this would yield the same notation for
object creation and reply message. Therefore, beyond this simplest solution,
we propose something more advanced: First, state explicitly the notation for
all kinds of messages, leaving no place for assumptions. Second, use a
filled arrowhead for reply messages, since this emphasizes the conceptual
proximity to the synchronous message it is a reply from. Third, use the
notation for object creation also for object deletion, which currently is
not mentioned. That is:

asynchronous message - SOLID LINE open arrowhead
synchronous message - SOLID LINE filled arrowhead
reply message - dashed line FILLED ARROWHEAD
object creation OR DELETION - dashed line open arrowhead

Or better, simply drop object creation as an special kind of message. Object
creation (and deletion) was not considered a special kind of message in UML
1, and it is not at all clear why it should be in UML 2. Probably, an object
creation is either synchronous or asynchronous, but not "something else" in
the same meta-specialization row. In fact, the constraints and semantics of
Message (Superstructure, p. 429) do not consider object creation as
messages: "The signature must either refer an Operation (...) or a Signal",
"A Message reflects either an Operation call (...) or a sending and
reception of a Signal". Neither does the meta-attribute Message.messageSort,
which has the following permitted values: synchCall, synchSignal,
asynchCall, asynchSignal. By the way, what do synchSignal and asynchCall
mean? The "sorts" of message are not defined in the Spec. Although calls are
considered in other places to be either synchronous or asynchronous, signals
are explicitly defined to be asynchronous (Superstructure, pp. 15, 371, 394
and 395), therefore at least synchSignal is banned.

Finally, we also propose to label reply messages with the name of the value
returned by the operation call, not the operation name itself. In Figure
333, this would leave the replies foo() and doit() without label, and the
last reply would be labeled simply as "x".
Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Why not using the UML1 activity symbol for UML2 actions?

Key: UML22-508
Legacy Issue Number: 6503
Status: closed
Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
Summary:
I didn't recognize it before, but now I am surprised that the action
symbol
is not the same as the UML1 activity symbol ("shape with straight top
and bottom
and with convex arcs on the two sides").
Actions are no activities, but the semantic is similar for
the "normal" UML user.
In UML1 the user has to distinguish between the activity symbol and
the state symbol ("round-cornered rectangle"), especially if states
and activities
are shown within the same diagram.
Now you has to use the UML1 state symbol for actions. I think that
this is confusing
for the normal UML user.
Another point is that the action symbol is the same as the state
symbol. There will
be no chance for a misunderstanding, because both symbols are not
allowed within the same
diagram. But it would be much clearer if the action symbol has a
different notation and
looks like the UML1 activity symbol.

So, why not using the UML1 activity symbol for UML2 actions?
Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicity seems to be broken - UML2 Infra & Super

Key: UML22-507
Legacy Issue Number: 6502
Status: closed
Source: Daimler AG ( Mario Jeckle)
Summary:
The current Infastructure document defines it at page 54 as (line
numbers have been added by me):
(1) multiplicity ::= multiplicity_range
(2) multiplicity_range ::= [lower '..'] upper
(3) lower ::= integer
(4) upper ::= unlimited_natural | '*'

But at page 56 (also page 20 of the Superstructure document which
copies
the definition) it says:

(5) multiplicity ::= multiplicty_range [
{order_designator}
]
(6) multiplicity_range ::= [lower '..'] upper
(7) lower ::= integer | value_specification
(8) upper ::= unlimited_natural | '*' | value_specification
(9) order_designator ::= ordered | unordered
(10) uniqueness_designator ::= unique | nonunique

There are several problems arising from this definition:

(P1) (9) and (10) are never used
(P2) Defining the lower bound as "integer" (according to page 142 of
the
Infrastructure document) allows it to specify multiplicities with
lower bounds below 0 (e.g. [-5..7], [-42..0])
(P3) (4) and (8) include the asterisk symbol to denote an
infinite
upper bound. Though, this is redundant since the symbol is already
there
as part of the lexical representation of unlimited_natural (according
to
page 144 of the Infrastructure document)
(P3) (4) and (8) define the upper bound using the datatype
"unlimited_natural" which comprimises all integer numbers starting
from
zero. Thus multiplicities like [0..0] would be legal.
(P4) It should be mentioned that the lower part is lower or equal to
the
value given for the upper part (where '*' is geater than any other
element of the set named integer). Otherwise multiplicities like
[8..2]
would be considered legal.
(P5) What is the role of the value_specification mentioned at (8) and
(9) isn't it redundant there?

Or am I just misreading the spec?
Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Dependency / ownership of dependencies

Key: UML22-499
Legacy Issue Number: 6451
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
At present, a dependency is not owned by any other element except a package. It seems to make sense for a dependency to be owned by its source. For example, the client of a usage should own it, since that would mean that the usage would be deleted along whenever its client is deleted – it makes no sense to have a dependency independently of the depending (source) element.
Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification of Information Flow semantics

Key: UML22-498
Legacy Issue Number: 6446
Status: closed
Source: Pivot Point ( Cris Kobryn)
Summary:
Description: Consider the following recommendations to improve Information
Flow semantics:
b) Allow Information Flow to be specialized and decomposed using
aggregation.
c) Allow Information Flow between classifiers with ports and interfaces.
Make provisions for relating the information flow to a port, such that an
Information Flow can flow through a port.
d) Allow Information Flows between classifiers with object flows across
activity partitions.
e) Change the name from Information Flow to Item Flow (or something similar)
to allow for the flow of non-information, such as physical items specified
in systems engineering applications.
Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Activity diagram problems

Key: UML22-497
Legacy Issue Number: 6444
Status: closed
Source: Pivot Point ( Cris Kobryn)
Summary:
Description: The following are some recommendations to improve Activity
diagrams for systems engineering applications:
a) Generalize pins so that they can be applied to control as well as data.
b) Clarify how activity diagrams can be used to represent continuous
behavior (e.g., streaming input).
c) Clarify how an object node to represent a role.
Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Infra/Metamodel::Constructs/invalid OCL constraint for "opposite"

Key: UML22-490
Legacy Issue Number: 6201
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
Is OCL for InfrastructureLibrary::Core::Constructs::Property::opposite() incorrect? Should it be:
opposite =
if owningAssociation->empty() and association.memberEnd->size() = 2 then
let otherEnd = (association.memberEnd - self)->any() in
if otherEnd.owningAssociation->empty() then otherEnd else Set{} endif
else Set {}
endif
Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8451 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Kernel/missing merges

Key: UML22-489
Legacy Issue Number: 6197
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
Kernel does not merge Abstractions::Namespaces, Abstractions, Multiplicities, Ownerships, and Visibilities
Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Package merge/redefinitions issue - lost association ends

Key: UML22-488
Legacy Issue Number: 6194
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
There is a subtle problem with redefinitions resulting from package merge. Property names have to match by name or the merging property has to redefine the merged property, AND the property types have the same name. Otherwise association ends are lost. For example, consider package Communications which is merged into BehaivorStateMachines. Communications has association ownedBehavior:Behavior <--> context:BehavioredClassifier (ignoring multiplicities to keep the text simpler). BehaviorStateMachines has class StateMachine which specializes Behavior, and has association ownedStateMachine:StateMachine
{redefines ownedBehavior}
<--> context:BehavioredClassifier. After the merge, merging BehavioredClassifier must contain two properties for ownedBehavior:Behavior and ownedStatemachine:StateMachine. Otherwise the association to the superclass is lost. This is a case where a class ends up redefining one of its own properties, and where ! the redefined and redefining properties both appear in the merged result.
Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Super/missing merge

Key: UML22-487
Legacy Issue Number: 6187
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
Package Super isn't merged anywhere, so the constraints it adds to Classifier are never included in L3
Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

raisedException

Key: UML22-493
Legacy Issue Number: 6275
Status: closed
Source: TimeWarp Engineering Ltd. ( Steven Cramer)
Summary:
Reviewing of the Rose MDL file the diagram Constructs::Operations (Class Diagram) displays raisedException as a reference from both BehavioralFeature as well as Operation. Operation inherits from BehavioralFeature as well.

I believe this violates a well-formedness rule that all structural features must be distinguishable.
Reported: UML 1.5 — Thu, 18 Sep 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 8461 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Templates / TemplateParameter not named

Key: UML22-492
Legacy Issue Number: 6262
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
TemplateParameters do not appear to be namable. They inherit from Element and not NamedElement. In UML 1.5 they inherited from ModelElement (i.e. were namable). They need to be named to be referred to in the implementation of the template.
Reported: UML 1.5 — Tue, 23 Sep 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.75/kinds of changeability

Key: UML22-491
Legacy Issue Number: 6216
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
pg. 75: StructuralFeature::isReadOnly
Limits severely limits previous capabilities to define various kinds of changeability. Even if some people think that the varieties of changeablity are not right, we should make this an enumerated value to provide extensibility for profiles. Call it "changeablity" as before. Should have enum values:

Changeable (unrestricted)

readOnly (no changes after initialization)

[Note that the meaning and semantics of "initialization" are completely undefined, so this isn't all that useful.]

The following additional choices were available in UML1:

CreateOnly (add a set any time after initialization but no further changes)

addOnly (may add members to the set but not change or remove any)

Both of these occur in practice often enough.
Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

Section 9.3.4 page 161, Presentation Option

Key: UML22-496
Legacy Issue Number: 6423
Status: closed
Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
Summary:
The statement "A dashed arrow with a stick arrowhead may be used to show that a collaboration is used in a classifier, optionally labelled with
the keyword «represents»." and the accompanying example are confusing. Please clarify what this presentation option is trying to accomplish.
Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Kernel features / cannot exclude superclass properties

Key: UML22-495
Legacy Issue Number: 6398
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
In practice it is not always possible to refactor class hierarchies to ensure that all attributes are defined in the appropraite classes in that hierarchy. For example, a class hierarchy may be supplied by a third party or may be used by multiple products whereas the refactoring may only be required in a subset of them. In such cases, it is extremely useful to be able to exclude undesirable features inherited from a superclass. This einently practical technique should be supported in UML to allow those systems that use that feature to be properly modeled.
Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Syntax of names

Key: UML22-494
Legacy Issue Number: 6389
Status: closed
Source: Anonymous
Summary:
Issue: The UML infrastructure specification does not specify the syntax for names. This prevents model interchange.

Proposal: Specify the syntax for the string in Name. At least, the characters that may be used in names, and any rules about where in the name certain characters may not (or may) appear.

Include in the syntax specification a list of characters used in (or excluded from) names using (seven and) eight bit characters and a list of characters used in (or excluded from) names using sixteen bit characters.

[After a quick glance, the rules sent to the UML 2 Superstructure FTF mail list looks like it will do the job. Or, in any event, get us started.]
Reported: UML 1.5 — Wed, 22 Oct 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Issue: definition of navigability

Key: UML22-501
Legacy Issue Number: 6460
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
PROBLEM STATEMENT
There is no definition for navigability or navigation in the Spec. Other
concepts of similar importance, such as visibility, multiplicity, etc., are
defined in the Spec, so it is not clear why it should be assumed that this
concept does not require a definition.

PROPOSED SOLUTION
Add definition in Section 4 (Terms and definitions): The navigability of a
binary association specifies the ability of an instance of the source
classifier to access the instances of the target classifier by means of the
association instances (links) that connect them. Navigability is closely
related to the possibility of sending messages through associations (a
message cannot be sent through an association instance against its
navigability, that is, navigability is required for sending messages through
associations), but they remain nonetheless different concepts.
Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This issue was resolved in UML 2.1 where an explanation of navigability was provided (see page 41 top in formal/07-02/05) Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Use 'represent' for the relationship of a model

Key: UML22-500
Legacy Issue Number: 6456
Status: closed
Source: Anonymous
Summary:
"An instance specification is a model element that represents an instance in a modeled system." [7.7.1] That is, the relationship of the instanceSpecification with a class to an object of that class is the representation relationship.

At the same time, a lifeline represents a connectable element. [14.2]

This is an example of a recurrent problem in the specification: model elements that represent other model elements.

At the same time, "attributes of a class are represented by instances of Propert[ies]..."

This is an example of an occassional and quite striking problem in the specification: items in the modeled system that represent model elements.

The theory of representation needs to be settled. That done, the specification needs to be reviewed with this in mind and all improper uses of representation corrected.
Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Rose Model of UML 2.0 spec

Key: UML22-506
Legacy Issue Number: 6501
Status: closed
Source: Pivot Point ( Cris Kobryn)
Summary:
Class Diagram:Constructs/Packages in the Rose file shows the
nestedPackage/package association the spec shows
nestedPackage/nestingpackage

I believe the spec to be in error...

I am not sure where to report this and or who keeps this model up to
date. Any recommendations would be appreciated
Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

ptc-03-09-15/Relationships among Core packages

Key: UML22-505
Legacy Issue Number: 6496
Status: closed
Source: David Frankel Consulting ( David Frankel)
Summary:
Issue: The superficial impression that Core::Abstractions is the lowest
layer in the U2P Core does not stand up under close examination.
Core::Basic is closer to being the fundamental layer because it uses none of
the new association modeling constructs (such as derived unions and subsets)
to define itself; but is not entirely so because it imports two packages
from Abstractions.

Recommendation: It would be worth considering whether the two packages that
Basic imports from Abstractions can be placed in Basic, so that Basic is
unambiguously the lowest layer in Core. This would also make EMOF
unambiguously the lowest-i.e. the most fundamental-layer of MOF, since
EMOF is based on Core::Basic while CMOF is based on Core::Constructs.
Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Move Comment into Basic and add Kind

Key: UML22-547
Legacy Issue Number: 7782
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
Move Comment into Basic and add Kind
The ability to annotate and describe elements and diagrams is pretty
fundamental so should be included in Basic.
There should also be the recognition that there are different kinds of
comment: for example most tools have a dialog allowing people to enter a
Description for an Element; and separately may allow the element to be
annotated on diagrams in a particular context. At the moment there is no
way to distinguish these.
The UML Metamodel itself is an example of the need for different kinds
of Comment: each Class has a number of distinct sections (e.g.
Description, Semantics, Notation).
Hence there should be a 'kind' attribute on Comment to reflect this.
Reported: UML 1.4.2 — Fri, 24 Sep 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Unconsistent Profile extension description (02)

Key: UML22-546
Legacy Issue Number: 7757
Status: closed
Source: Softeam ( Philippe Desfray)
Summary:
18.3.5 says that "A profile by definition extends a reference metamodel or another profile."
While in theory I could see how it might be modeled, I don't see how the latter could work in practice with real tools. Let's extend the current example and define a new Profile called ClockTechnology with Stereotype AtomicClock with baseClass Clock and property radioactiveElement:String..."
—

Import between profiles is supported, and stereotype generalization is the usual way to achieve what has been called "extending a profile".

The reference to profile extension should be simply discarded. A profile extends a reference metamodel.
.

Discussion

In Profiles:Profile:semantics, change the first sentence

A profile by definition extends a reference metamodel or another profile.

Into

A profile by definition extends a reference metamodel.
Reported: UML 1.4.2 — Fri, 3 Sep 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Unconsistent association extension description

Key: UML22-545
Legacy Issue Number: 7756
Status: closed
Source: Softeam ( Philippe Desfray)
Summary:
b) More worryingly, 18.3.5 Semantics also says "As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel." I fail to see how a profile could in fact could cause an association between 2 stereotypes to subset an existing association in a reference metamodel since the stereotypes do not at all inherit from the baseClasses so do not inherit any of its properties or associations in order to be able to subset them: this is emphasized by the MOF representation shown in the new Figure 447.
—

Indeed profiles do not support association subsetting. This should be made clear in the spec to avoid any confusion while using profiles.
.

Discussion

In Profiles:Profile:semantics, change the paragraph

As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel.

Into

As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass.
Reported: UML 1.4.2 — Fri, 3 Sep 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Section 11.7

Key: UML22-538
Legacy Issue Number: 7343
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
In the manner of representing the relationship between BehavioralFeature and Parameter the infrastructure imposes either a limit on the nature of parameters on modeling languages reusing the infrastructure or forces them to duplicate this mechanism. The infrastructure decided to represent as concrete associations the kinds of parameters, and distinguishes two: returnResult and formalParameter. The parameter association is then derived as a union of these. However, there may be a large number of parameter kinds. For example, the superstructure defines four, and one can easily imagine additional ones. To be more reusable and expandable, parameter should be characterized by its kind (does it return a result, is it a formal parameter). Note that this is, in reality, a property of the parameter, not of the relation between BehavioralFeature and Parameter and thus is modeled better this way anyway. Define an attribute "direction" on Parameter of type "ParameterDirectionKind". In infrastructure give it two values: in, and returnResult. This type can be extended in other languages, e.g., the UML uses also out, and inout). Make BehavioralFeature.parameter concrete. Make the formalParameter and returnResult associations derived from the direction attribute of each parameter. The result is the identical model, but much more reusable. Note that the superstructure was forced to introduce both mechanisms, thus running into the risk of inconsistencies, if the two mechanisms do not match up. There is no negative impact on the infrastructure of relying on the more reusable option proposed here. The number of model elements stored in the repository is identical for infrastructure, and lower for superstructure.
Reported: UML 2.0 — Sun, 16 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

simple time model" in CommonBehavior

Key: UML22-537
Legacy Issue Number: 7303
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
For the "simple time model" in CommonBehavior, it is unclear when the DurationObservationAction and TimeObservationAction would be executed. For one, it is not stated when these actions are executed. I assume that when the execution of the model reaches the point of the attached model elements, then these actions are executed. Several problems: It is unclear what determines when these actions are executed. If the actions are embedded in a sequence of actions, where control flow indicates when they execute, what is the meaning of the association to a named element? If that named element is reached later in the execution, does the execution wait? If it is reached earlier, does that element have to wait until the action sequence is enabled? (ii) There should be some constraint on the "NamedElements" associated with TimeExpression that limits those to elements that can be enountered during execution, as these elements appear to determine when these actions are evaluated. There is a tension between these actions being embedded in a sequence of actions where their execution is determined by the control and data flow, and the associated "NamedElements" that would determine the observation of time also. Normally, actions are used within a sequence of actions (an activity). These two actions are different in that they seem to make no sense within an activity due to that they have very special invocation points. They seem to only make sense as stand-alone elements. Maybe it should not be an action, but some other model element, that should dictate how time and duration are observed.
Reported: UML 2.0 — Wed, 5 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: Fixed as part of the resolution to issue 8894 in UML 2.1 Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Problem with diagram references in Profiles section

Key: UML22-551
Legacy Issue Number: 7909
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
2nd paragraph in Stereotype Semantics does not have proper cross-references to the figures and hence they have not been updated as other figures have been inserted. The para currently reads:
An instance "S" of Stereotype is a kind of (meta) class. Relating it to a metaclass "C" from the reference metamodel (typically UML) using an "Extension" (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of "S" (see example Figure 454). At the model level (such as in Figure 457) instances of "S" are related to "C" model elements (instances of "C") by links (occurrences of the association/extension from "S’ to "C").

But the 2 references should be to Figure 456 and Figure 461 respectively.
Reported: UML 1.4.2 — Sun, 14 Nov 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Design principles

Key: UML22-550
Legacy Issue Number: 7908
Status: closed
Source: none ( Markus Flueckiger)
Summary:
have a general problem with the UML 2.0 specification. A graphical modelling language is essential for succesful software development. However the more I read about UML 2.0 the more I had the impression that UML 2.0 has not been developed with actual real-world software development in mind. Just to give one highlight of UML 2.0 is the merge relation between packages: The relation leads to bad designs and incomprehensible software systems, e.g. like like badly designed inheritance hierarchies etc. Especially consider the following case: a trifle change in the diagram (change the merge relationship into e.g. an access relationship) causes a tremendous amount of changes on the code and the configuration level. The only way to handle this is to forbid the merge relationship and to hope that nobody is blind enough to actually use it. Reading the manual, I stumbled over numerous similar issues. I'm sorry to say but I'm very disappointed with UML 2.0 as it is
Reported: UML 1.4.2 — Wed, 10 Nov 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

The specification is fond of using 'typically.'

Key: UML22-544
Legacy Issue Number: 7407
Status: closed
Source: X-Change Technologies ( Joaquin Miller)
Summary:
The specification is fond of using 'typically.' The term should be use with care in a specification. Typically, 'must' or 'may' are better choices. For example, at 7.4.1 p.42: The multiplicity bounds are typically shown in the format: lower-bound..upper-bound It will be better to write: The multiplicity bounds are shown in the format: lower-bound..upper-bound simply deleting 'typically.' (In this case, the syntax specification should show the case when the two bounds are equal.)
Reported: UML 2.0 — Mon, 31 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

TimeObservationAction and DurationObservationAction

Key: UML22-543
Legacy Issue Number: 7406
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
TimeObservationAction and DurationObservationAction are described as actions, but are not really actions like the actions of the action chapter. They would never be used when defining a behavior, but are part of a metalanguage to define temporal constraints and to refer to measured times and durations in formulating such constraints. However, these two elements are the only aspects of this language, everything else is left to be defined later (see TimeExpression). Putting these two mechanisms into the specifications unduly constrains any profile that would want to define a notation for expressing temporal constraints. Such a language might not see a need to use the actions described in this chapter. My recommendation is to find a different way of expressing time observations and duration observations in the metamodel. The syntax examples clearly show that they are not meant to be used within an activity as actions. Note that the only way to use these observations is to create a "fake" activity attached to the interaction (e.g., as a nestedClassifier) which contains only this action. A rather convoluted and heavy-weight means of expressing the simple concept of "NOW" (as the point in time when some model element is executed). A simpler mechanism is clearly needed.
Reported: UML 2.0 — Sat, 29 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: Fixed as part of the resolution to issue 8894 in UML 2.1 Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

add an interaction fragment

Key: UML22-541
Legacy Issue Number: 7397
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
Sequence diagrams are often used to describe abstract system behavior in the form of the interaction of the system with its environment. Experience has shown that systems have normal behavior and exceptional behavior (in response to unusual or unexpected events). UML2 has introduced a mechanism of representing exceptions. However, interactions do not give us a vehicle of showing exceptional behavior. Recommendation: add an interaction fragment indicating exceptional handling similar to the way this is done in the activity chapter.
Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Interactions model sequences of events

Key: UML22-540
Legacy Issue Number: 7392
Status: closed
Source: Missouri University of Science and Technology ( Thomas Weigert)
Summary:
Interactions model sequences of events. The metaclass EventOccurrence represents the occurrence of an event. Currently, there are the following kinds of events known: i. sending of a message ii. receiving of a message iii. start of the execution of a behavior iv. finish of the execution of a behavior v. stop First, clearly, there could be many more events that one might want to represent on a lifeline. In particular, the invocation of an action is a possible event, and should be allowed to be represented. Secondly, event occurrence is modeled poorly. It is shown as a kind of message end, which means that every event occurrence inherits the notion of being a message end point, even if the event has nothing to do with a message (such as a stop event). Clearly the inheritance hierarchy is inverted. A message end can represent an event occurrence (such as the sending or receiving of a message). But not every event occurrence is a message event.
Reported: UML 2.0 — Sat, 29 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This was fixed in UML 2.1 Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify example in figure 133

Key: UML22-539
Legacy Issue Number: 7362
Status: closed
Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
Summary:
Could you describe in details the meaning of the example described in Figure 133, because it could very useful to understand the deployment specification concept. Moreover, is there anything lacking in figure 134? It contains no model element with the <<deployment specification>> stereotype.
Reported: UML 2.0 — Wed, 19 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

XMI schema

Key: UML22-542
Legacy Issue Number: 7401
Status: closed
Source: X-Change Technologies ( Joaquin Miller)
Summary:
"[C]omplying with a package requires complying with its abstract syntax, well-formedness rules, semantics, notation and XMI schema," [2] but there is no XMI schema. "It is expected that the normative XMI for this specification will be generated by a Finalization Task Force, which will architectually align and finalize the relevant specifications." [Appendix F] That is consistent with the OMG Document Archives, which show: ad/03-04-02: XMI for U2 Partners' UML 2.0: Superstructure, 3rd. revision (Contact: Mr. Cris Kobryn) No description of this document is available. Formats: Note: Not yet available. An XMI schema should be supplied, or the requirement to comply with an XMI schema should be removed.
Reported: RAS 2.0b1 — Mon, 31 May 2004 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

DataType attributes UML 2 Super (ptc/04-10-02)

Key: UML22-552
Legacy Issue Number: 7938
Status: closed
Source: The MathWorks ( Mr. Alan Moore)
Summary:
On Figure 13, DataType::ownedAttribute is specified as ordered but in the
associations section on page 59, it is not specified as ordered.
Reported: UML 1.4.2 — Fri, 19 Nov 2004 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
See issue 7939 for disposition
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Constructs/owningComment

Key: UML22-486
Legacy Issue Number: 6176
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
Constructs association owningCommet:Element[0..1] c-~~> ownedCommet:Comment[0..*] should have been owningElement:Element[0..1] c~~-> ownedCommet:Comment[0..*] as defined in Kernel/Root.
Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see below
Updated: Fri, 6 Mar 2015 20:58 GMT

Classes diagram of the Core::Constructs package

Key: UML22-485
Legacy Issue Number: 6006
Status: closed
Source: Honeywell ( Steven Hickman)
Summary:
In the Classes diagram of the Core::Constructs package, the references to StructuralFeature, Relationship, Type, and Classifier have no cross-reference to the package where they were originally defined, whereas other concepts in this diagram do. It is clear from the fact that some of these concepts are involved in derived roles or relationships, that they MUST have been defined somewhere else.

The document needs to be fixed so that it is self consistent and so that proper cross-references are indicated.
Reported: UML 2.0 — Sat, 19 Jul 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

cross-reference missing

Key: UML22-484
Legacy Issue Number: 6005
Status: closed
Source: Honeywell ( Steven Hickman)
Summary:
The reference to TypedElement in the Expressions diagram for Core::Constructs makes no cross-reference to the definition of TypedElement in Core::Abstractions::TypedElements or Core::Basic.

Is it a reference to either of these or is it yet another definition of a concept with the same name?
Reported: UML 2.0 — Sat, 19 Jul 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Relationship and DirectedRelationship in Core::Constructs

Key: UML22-483
Legacy Issue Number: 6004
Status: closed
Source: Honeywell ( Steven Hickman)
Summary:
There doesn't seem to be any value in the specialization of Relationship and DirectedRelationship in Core::Constructs from their definitions in Core::Abstractions::Relationships. The documentation clearly states that the specializations don't add anything to the either concept. In fact, it appears that this can be said for everything in the Core::Constructs Root Diagram.

If this is the case, why do these specializations exist? The UML spec is big enough - there is no point in adding things that don't need to be there. If the goal is to merely create a single diagram that includes concepts and relationships that were previously spread across multiple diagrams, then why not simply create the diagram and have every contained concept refer to the package where it was originally defined?

If there is a compelling reason for these specializations, then that reason needs to be spelled out in the spec - because it isn't obvious to me.
Reported: UML 2.0 — Sat, 19 Jul 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

document appears to be inconsistent in how it handles concepts

Key: UML22-482
Legacy Issue Number: 6003
Status: closed
Source: Honeywell ( Steven Hickman)
Summary:
This document appears to be inconsistent in how it handles concepts with the same name. In some cases, the class diagrams make it clear that a concept is being imported from one package to another by reference. However, there are a lot of cases where the same concept name is used in separate packages but it is not clear if it is the same concept, a parallel concept, or a refinement of the concept.

In many cases the documentation of the concepts is the same (or nearly so) everywhere it appears. This tends to imply that it is, in fact, the same concept. However, if this were the case, then it should be defined in one package and imported by reference in other packages. On the other hand, since the import by reference is actually done in some cases, that tends to imply that, where the import by reference is not done, something else significant is going on. What that significant thing "is" is never made clear - at least not as far as I can tell.

I suspect the same problem exists in the UML 2.0 Superstructure submission because they were both written by the same group.

Proper understanding of the metamodel becomes impossible without this issue getting resolved. Someone needs to go through both of these documents and locate every place the same concept name is used in multiple packages and make sure it is clear how the concepts with the same name in different packages relate to each other.
Reported: UML 2.0 — Sat, 19 Jul 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Designates a Generalization

Key: UML22-477
Legacy Issue Number: 5794
Status: closed
Source: yahoo.com ( Jeff Barnes)
Summary:
The text:

Designates a Generalization whose parent GeneralizableElement is the immediate ancestor of the current GeneralizableElement.

disagrees in plurality with the * cardinality of the generalization association end between GeneralizableElement and Generalization in the Core Package - Relationships diagram (Figure 2-6) on page 2-14.
Reported: UML 1.4 — Sun, 15 Dec 2002 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
closed no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Namespace issue (UML 1.4 formal/2002-09-67, 2.5.3.26 Namespace )

Key: UML22-476
Legacy Issue Number: 5593
Status: closed
Source: blomesystem ??????? ( Michael Zavyalov)
Summary:
The Namespace has the following definition constraint (p. 2-64): [1] The operation contents results in a Set containing all ModelElements contained by the Namespace. contents : Set(ModelElement) contents = self.ownedElement -> union(self.namespace, contents)

The errors: 1. Syntax error in the union operation. According to Object Constraint Language Specification set has operation (p. 6-38) set->union(set2 : Set(T)) : Set(T) with the single parameter !

2. The functions contents and allContents are used to receive all composite and aggregate elements of namespace according to specification of these functions (Is that right ?). For example all overriden functions in the descedent elements (Package, DataType) release these functions in this manner. In this case function contents must be realized as: contents = self.ownedElement 3.The functions contents and allContents is sometimes used to receive list of «accessable» objects ! For example: definition constraint #2 for BehavioralFeature (p. 2-54): [2] The type of the Parameters should be included in the Namespace of the Classifier. self.parameter->forAll( p | self.owner.namespace.allContents->includes (p.type) ) Why parameter can't use imported DataType ? Why parameter can't use DataType located in the Namespace binded with the namespace of classifier by «friend» Permission ? Note that DataType may be included in the namespace of namespace of owner. It also may be included directly into owner ! I may send the collection of such errors («contents» instead of «acessable»).
Reported: UML 1.4 — Sun, 25 Aug 2002 04:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This is an issue raised against the UML 1 metamodel, which is no longer valid. Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Sending a signal after a delay

Key: UML22-475
Legacy Issue Number: 4937
Status: closed
Source: Object Management Group ( Stephen Mellor)
Summary:
Sending a signal after a delay
Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
The feature requested is already supported in UML 2.1: Precede an action by an AcceptEventAction, where the latter references a trigger that refers to a TimeEvent. Thus, for example, if you have a sequence of an AcceptEventAction with a TimeEvent specifyinig the desired delay and a SendSignalAction, then the signal will not be sent until the delay has passed. Note that this feature is extremely generic, probably giving the user even too much support (you can define a statemachine purely with actions, if there are not proper constraint placed on the events allowed in the AcceptEventAction).
Updated: Fri, 6 Mar 2015 20:58 GMT

Does visibility apply to creating an destroying links?

Key: UML22-474
Legacy Issue Number: 4448
Status: closed
Source: NIST ( Mr. Conrad Bock)
Summary:
It isn't clear whether visibility of association ends applies to
creating and 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?
Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

relationship should just be a cross-reference

Key: UML22-481
Legacy Issue Number: 6002
Status: closed
Source: self ( Steve Hickman)
Summary:
There is no clear relationship between NamedElement, TypedElement and Type as defined in Core::Basic and items by the same name in Core::Abstractions::Namespaces and Core::Abstractions::TypedElements. There is no reference between the two although the concepts seem identical.

It seems like the relationship should just be a cross-reference. However, is it a type-instance relationship? Or is a refinement relationship (as can be seen in other parts of the spec)? Or is it something else? What is going on here?
Reported: UML 1.5 — Sat, 19 Jul 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
closed no change
Updated: Fri, 6 Mar 2015 20:58 GMT

formal/03-03-01 : Omission of definition of Class "Action"

Key: UML22-480
Legacy Issue Number: 5907
Status: closed
Source: Anonymous
Summary:
I believe I found an omission from the UML 1.5 Specification formal/03-03-01:

p. 2-112, Fig. 2-18: Association between "Message" and "Action (from Common Behavior)"

In Sec. 2.9 Common Behavior; none of the diagrams or text specify Class "Action".

p. Index-1 cites "Action" p 2-103.

p. 2-103 has no mention of "Action".

The first item in Sec. 2.9.3 is "2.9.3.1 AttributeLink", not "2.9.3.1 Action" as would be alphabetized.

My question is what is definition of the "Action" Class in Fig. 2-18?
Reported: UML 1.5 — Mon, 21 Apr 2003 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
closed no change
Updated: Fri, 6 Mar 2015 20:58 GMT

Specify XMI parameters for the UML / XMI interchange format

Key: UML22-473
Legacy Issue Number: 3898
Status: closed
Source: DSTC ( Stephen Crawley)
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.
Reported: UML 1.3 — Fri, 22 Sep 2000 04:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

logic upperbound is the same as the lower bound.

Key: UML22-479
Legacy Issue Number: 5896
Status: closed
Source: Anonymous
Summary:
3] The operation lowerbound returns the lowest lower bound of the ranges in a multiplicity. lowerbound( ) : Integer; lowerbound = self.range->exists(r : MultiplicityRange |r.lower = result) and self.range->forall(r : MultiplicityRange |r.lower <= result) [4] The operation upperbound returns the highest upper bound of the ranges in a multiplicity. upperbound( ) : UnlimitedInteger; upperbound = self.range->exists(r : MultiplicityRange |r.upper = result) and self.range->forall(r : MultiplicityRange |r.upper <= result) =============================================

according to the logic upperbound is the same as the lower bound.

should the upperbound read as r.upper >= result instead of r.upper <= result on the last line?
Reported: UML 1.5 — Fri, 4 Apr 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
closed no change
Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2.27 ModelElement

Key: UML22-478
Legacy Issue Number: 5804
Status: closed
Source: yahoo.com ( Jeff Barnes)
Summary:
The text "deploymentLocation The set of locations may differ. Often it is more restrictive on the child." has no corresponding association in any diagram. The closest match is documented in 2.5.2.12 Component on pages 2-31 and 2-32. If this is the non-inherited feature discussed on page 2-44 is it not redundant and doesn't it cloud the meaning of the feature?
Reported: UML 1.4 — Thu, 19 Dec 2002 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
closed no change
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Classes / dependencies should be unidirectional

Key: UML22-511
Legacy Issue Number: 6630
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
In the metamodel, UML::Classes::Dependencies::NamedElement::supplierDependency should not be navigable, as it does not make sense for the supplier of a dependency to know about its dependencies
Reported: UML 1.5 — Wed, 26 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
see above
Updated: Fri, 6 Mar 2015 20:58 GMT

two classes "NamedElement

Key: UML22-510
Legacy Issue Number: 6525
Status: closed
Source: Pivot Point ( Cris Kobryn)
Summary:
Secondly, there are two classes "NamedElement" holding un-redefined
attribute "name", one is in the
package "InfrastructureLibrary.Core.Basic", and the other is in the
package "InfrastructureLibrary.Core.Abstractions.Namespaces". The
problem is that there are a lot of classes directly or indirectly
inheriting both of them e.g. class "InstanceSpecification" in package
uml.classes.kernel, and it causes problem of duplicated parameters in
class creation in the generated JMI interfaces. e.g.
"
public InstanceSpecification createInstanceSpecification
(java.lang.String name,
infrastructurelibrary.core.abstractions.visibilities.VisibilityKind
visibility, java.lang.String name, java.util.Collection classifier);
"
Similiar cases happen to attribute "type", "isAbstract" etc.
Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

well-formedness rules are not numbered correctly

Key: UML22-515
Legacy Issue Number: 6641
Status: closed
Source: Condris Technologies ( Valentin Crettaz)
Summary:
The well-formedness rules are not numbered correctly. After the note in the middle of the page, the numbering scheme starts over at [1] instead of going on to [10].
Reported: UML 1.5 — Wed, 26 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

number of the figure is wrong

Key: UML22-514
Legacy Issue Number: 6640
Status: closed
Source: Anonymous
Summary:
At the bottom of page 2-216, the paragraph "This life cycle may be depicted informally using a statechart diagram, as shown in Figure 2-39." should actually read "This life cycle may be depicted informally using a statechart diagram, as shown in Figure 2-40." The number of the figure is wrong.
Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.5 table of contents

Key: UML22-520
Legacy Issue Number: 6665
Status: closed
Source: EWSolutions ( Patrick Cross)
Summary:
The example text <Company xmi:id="Company_1" name="Acme"> <HQAddress xmi:id="Address_1" Street="Side Street" </Company>City="Hometown"/> should be <Company xmi:id="Company_1" name="Acme"> <HQAddress xmi:id="Address_1" Street="Side Street" City="Hometown"/> </Company>
Reported: XMI 2.0 — Wed, 3 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

In the last paragraph, the period after the word "collections" on the secon

Key: UML22-519
Legacy Issue Number: 6662
Status: closed
Source: Condris Technologies ( Valentin Crettaz)
Summary:
In the last paragraph, the period after the word "collections" on the second line should be removed
Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11

Key: UML22-518
Legacy Issue Number: 6661
Status: closed
Source: Condris Technologies ( Valentin Crettaz)
Summary:
In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11. That's why "...subaction Addition is the scalar 9." should read "...subaction Addition is the scalar 11."
Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

The multiplicity of association named subaction of type Action ill formed

Key: UML22-517
Legacy Issue Number: 6660
Status: closed
Source: Condris Technologies ( Valentin Crettaz)
Summary:
The multiplicity of the association named subaction of type Action is ill formed. Instead of [1..] it should read [1..1].
Reported: UML 1.5 — Mon, 1 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

Operations and derived attributes

Key: UML22-521
Legacy Issue Number: 6692
Status: closed
Source: TimeWarp Engineering Ltd. ( Steven Cramer)
Summary:
I am looking at ValueSpecification which introduces Additional Operations, such as integerValue(). My question is : What is the reasoning behind making these Operations vs. Derived attributes?

In MultiplicityElement we have a derived attribute lower which is equal to lowerBound(). What logic is used to determine whether an Operation has a corresponding Attribute?

Also the spec seems to indicate that all derived values will be implemented via some operation. Is this a requirement or an assumption of implementation?

Why can’t lower in MultiplicityElement simple be defined as if lowerValue->notEmpty() then 1 else lowerValue.integerValue() what makes the lowerBound() operation required?
Reported: UML 1.5 — Wed, 10 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

class "InfrastructureLibrary.core.constructs.Association",

Key: UML22-509
Legacy Issue Number: 6524
Status: closed
Source: Pivot Point ( Cris Kobryn)
Summary:
found something strange in the specification of UML 2.0.
First of all, in the
class "InfrastructureLibrary.core.constructs.Association", there is
an attribute "ownedEnd" with return type
of "InfrastructureLibrary.Core.Constructs.Property" and 0...*; and it
its direct subclass "infrastructurelibrary.profiles.Extension", there
is an attribute "ownedEnd" which redefines ownedEnd in
class "Association", but with return
type "infrastructurelibrary.profiles.ExtensionEnd" and multiplicity
of 1. It causes conflicts of generated JMI interface.
Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

remove paragraph

Key: UML22-513
Legacy Issue Number: 6639
Status: closed
Source: Condris Technologies ( Valentin Crettaz)
Summary:
The paragraph starting at the bottom of page 2-200 with "A user model uses instances..." and finishing at the top of page 2-201 describes figure 2-37 which has been removed from the specification 1.4 when transiting to 1.5. Thus, the paragraph should be either adapted to reflect the change or removed.
Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Infra/Metamodel/missing derivation indicators

Key: UML22-512
Legacy Issue Number: 6637
Status: closed
Source: Simula Research Laboratory ( Dr. Bran Selic)
Summary:
Package::nestedPackage and Profile::ownedStereotype should be derived, just as Package::ownedType is (all three subset Package::ownedMember). In general, if the contents of a subset are determined soley by type (and the superset property is not derived), the subset property should be derived.
Reported: UML 1.5 — Fri, 21 Nov 2003 05:00 GMT
Disposition: Resolved — UML 2.1.2
Disposition Summary:
Discussion: This was fixed in release 2.1. Revised Text: N/A Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

multiplicity of the association named "type" of type DataType

Key: UML22-516
Legacy Issue Number: 6659
Status: closed
Source: Condris Technologies ( Valentin Crettaz)
Summary:
The multiplicity of the association named "type" of type DataType is given as [1..1}. It should be [1..1], i.e. with square brackets instead of curly braces
Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
Disposition: Resolved — UML 2.1
Disposition Summary:
No Data Available
Updated: Fri, 6 Mar 2015 20:58 GMT