Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — All Issues

  • Acronym: UML
  • Issues Count: 960
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA35-265 when is a connection a "bi-directional connection"? UML 2.0 open
CORBA34-274 when is a connection a "bi-directional connection"? UML 2.0 CORBA 3.4 Deferred closed
UMLR-54 Operation calls on behavior ports UML 2.0 open
UMLR-35 Disjointness should be independent of generalization UML 2.0 open
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
UML23-151 Section: 14.3.20 UML 2.0 UML 2.3 Resolved closed
UML23-148 UML 2 Super / Components / realizingClassifier UML 2.0 UML 2.3 Resolved closed
UML22-1373 Section: 12.3.52 UML 2.0 UML 2.1 Resolved closed
UML23-149 Section: 8.3.4 UML 2.0 UML 2.3 Resolved closed
UML241-46 actions UML 2.0 open
UML241-41 Section: 9.3.12 UML 2.0 open
UML241-37 Section: 11.3.39 UML 2.0 open
UML241-33 What is a mapping that is not computable? UML 2.0 open
UML241-32 Components UML 2.0 open
UML241-35 DeploymentSpecification - notation for DeploymentSpecification on the insta UML 2.0 open
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
UML25-603 CollaborationOccurence UML 2.0 UML 2.5 Resolved closed
UML25-609 Deployment (from ComponentDeployments, Nodes) UML 2.0 UML 2.5 Resolved closed
UML25-608 Dependency associations UML 2.0 UML 2.5 Resolved closed
UML25-628 Notation of enumeration literals UML 2.0 UML 2.5 Resolved closed
UML25-624 Associations section of InteractionUse UML 2.0 UML 2.5 Resolved closed
UML25-627 Figure 307 and Figure 308 are exactly the same UML 2.0 UML 2.5 Resolved closed
UML25-562 Section: 9.3.3 UML 2.0 UML 2.5 Resolved closed
UML25-561 At «implementation Class», what does "a child of instance" mean?! UML 2.0 UML 2.5 Resolved closed
UML25-559 three possibilities for aggregation kind at 7.11.2, but only two notations UML 2.0 UML 2.5 Resolved closed
UML25-558 Section: 7.11.2 UML 2.0 UML 2.5 Resolved closed
UML25-560 It is not clear what 'related to' means UML 2.0 UML 2.5 Resolved closed
UML25-567 Concept of 'port side' not to be found in metamodel UML 2.0 UML 2.5 Resolved closed
UML25-565 Description text for CollaborationOccurrence unclear UML 2.0 UML 2.5 Resolved closed
UML25-564 Editrial error in Section: 9.3.4 ? UML 2.0 UML 2.5 Resolved closed
UML25-563 Association collaborationRole UML 2.0 UML 2.5 Resolved closed
UML25-576 There is no "precise mapping UML 2.0 UML 2.5 Resolved closed
UML25-575 Semantics section of StructuralFeature UML 2.0 UML 2.5 Resolved closed
UML25-592 "required interface" UML 2.0 UML 2.5 Resolved closed
UML25-596 UML 2 does not permit use of a state machine UML 2.0 UML 2.5 Resolved closed
UML25-600 "role binding" UML 2.0 UML 2.5 Resolved closed
UML25-599 multiplicity of the "role:ConnectableElement" UML 2.0 UML 2.5 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-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-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-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-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-990 OpaqueAction UML 2.0 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-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-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-944 String is primitive but has structure. UML 2.0 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-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-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-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-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-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-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-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-844 Section: 15.3.7 UML 2.0 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-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-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-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-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-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-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-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-554 Section: 7.3.43 UML 2.0 UML 2.1 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-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-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-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-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-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-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-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-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-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-250 Bad cross reference for InterfaceRealization Notation UML 2.0 UML 2.2 Resolved closed
UML22-249 PrimitiveTypes access by UML (M1) models UML 2.0 UML 2.2 Resolved closed
UML22-253 Unclear which Property has aggregation UML 2.0 UML 2.2 Resolved closed
UML22-252 Move Property::isId from MOF to UML UML 2.0 UML 2.2 Resolved closed
UML22-248 Notation for stereotypes on Comments and other elements UML 2.0 UML 2.2 Resolved closed
UML22-251 text-diagram out of synch in Infrastructure 11.4.1 UML 2.0 UML 2.2 Resolved closed
UML22-254 Clarify isRequired UML 2.0 UML 2.2 Resolved closed
UML22-217 General ordering cycles UML 2.0 UML 2.2 Resolved closed
UML22-215 What exactly is a state list? UML 2.0 UML 2.2 Resolved closed
UML22-214 Section: 9.14.2 UML 2.0 UML 2.2 Resolved closed
UML22-213 Section: 11.1.3 UML 2.0 UML 2.2 Resolved closed
UML22-212 Action inputs/outputs UML 2.0 UML 2.2 Resolved closed
UML22-219 Completion event modeling UML 2.0 UML 2.2 Resolved closed
UML22-216 Editorial bug in 2.1 Superstructure Convenience document UML 2.0 UML 2.2 Resolved closed
UML22-183 7.3.4 Association Class UML 2.0 UML 2.2 Resolved closed
UML22-264 Invalid mandatory compositions and associations UML 2.0 UML 2.2 Resolved closed
UML22-263 11.3.47 on StructuralFeatureAction (and related sections on subclasses) UML 2.0 UML 2.2 Resolved closed
UML22-262 Section: 9.16.1 UML 2.0 UML 2.2 Resolved closed
UML22-261 Section: 9.19.1 UML 2.0 UML 2.2 Resolved closed
UML22-258 Section: 9.12.1 UML 2.0 UML 2.2 Resolved closed
UML22-257 Merged Metam.:Property::class with redefinition of non-inherited property UML 2.0 UML 2.2 Resolved closed
UML22-256 navigating from link to link ends UML 2.0 UML 2.2 Resolved closed
UML22-255 ExtensionEnd description refers to old use of navigability UML 2.0 UML 2.2 Resolved closed
UML22-260 Section: 9.10.3 UML 2.0 UML 2.2 Resolved closed
UML22-259 Section: 9.13 UML 2.0 UML 2.2 Resolved closed
UML22-285 Section: 15 UML 2.0 UML 2.2 Resolved closed
UML22-291 Section: 14.3.10 UML 2.0 UML 2.2 Resolved closed
UML22-290 Section: 14.3.14 UML 2.0 UML 2.2 Resolved closed
UML22-296 Section: e. g. 12.2. page 287 UML 2.0 UML 2.2 Resolved closed
UML22-201 assembly connectors UML 2.0 UML 2.2 Resolved closed
UML22-200 New Issue on multiple guillemot pairs for same element UML 2.0 UML 2.2 Resolved closed
UML22-210 11.3.26 OpaqueAction UML 2.0 UML 2.2 Resolved closed
UML22-209 Definition of stereotype placement requires a name UML 2.0 UML 2.2 Resolved closed
UML22-206 the default for a Property should not be inconsistent with its type UML 2.0 UML 2.2 Resolved closed
UML22-204 packagedElement UML 2.0 UML 2.2 Resolved closed
UML22-203 ptc/06-01-02:14.3.14, Notation UML 2.0 UML 2.2 Resolved closed
UML22-207 UML's support for null values and semantics is unclear UML 2.0 UML 2.2 Resolved closed
UML22-211 UML 2/ Super / SendSignalEvent erratum UML 2.0 UML 2.2 Resolved closed
UML22-199 Question on InfrastrucutreLibrary::BehavioralFeatures::Parameter UML 2.0 UML 2.2 Resolved closed
UML22-208 "Property::lowerValue" is not a good name UML 2.0 UML 2.2 Resolved closed
UML22-202 Fig 7.14 UML 2.0 UML 2.2 Resolved closed
UML22-275 Section: 17.5 UML 2.0 UML 2.2 Resolved closed
UML22-283 Activity shape UML 2.0 UML 2.2 Resolved closed
UML22-235 text of specs and corresponding XMI specs should be clarified UML 2.0 UML 2.2 Resolved closed
UML22-234 UML 2: "isLeaf" UML 2.0 UML 2.2 Resolved closed
UML22-227 Section: 15.3.14 Transition UML 2.0 UML 2.2 Resolved closed
UML22-238 Figure 7.4 invalid redefines UML 2.0 UML 2.2 Resolved closed
UML22-237 EnumerationLiteral should constrain InstanceSpecification UML 2.0 UML 2.2 Resolved closed
UML22-233 Stereotype attributes inherited from Class UML 2.0 UML 2.2 Resolved closed
UML22-231 Section 11.4.1 "Classifier" (in Constructs) UML 2.0 UML 2.2 Resolved closed
UML22-228 Notation (p 154, formal/05-07-04 ) UML 2.0 UML 2.2 Resolved closed
UML22-230 Section 11.4.1 "Classifier" (in Constructs) UML 2.0 UML 2.2 Resolved closed
UML22-229 Section 10.2.1 "Class" (in Basic) UML 2.0 UML 2.2 Resolved closed
UML22-192 Section: 7.3.7 UML 2.0 UML 2.2 Resolved closed
UML22-191 AssociationClass is severely underspecified UML 2.0 UML 2.2 Resolved closed
UML22-190 Show an example of correct notation for the metamodel UML 2.0 UML 2.2 Resolved closed
UML22-184 Optional name attribute in NamedElement is misleading and insufficient UML 2.0 UML 2.2 Resolved closed
UML22-197 UML 2 Super / Components / connectors to interfaces UML 2.0 UML 2.2 Resolved closed
UML22-187 reference to Figure 12.87 missing UML 2.0 UML 2.2 Resolved closed
UML22-186 Section: 14.4 UML 2.0 UML 2.2 Resolved closed
UML22-194 No ObjectEvent corresponding to SendObjectAction UML 2.0 UML 2.2 Resolved closed
UML22-193 Fig 12.10 UML 2.0 UML 2.2 Resolved closed
UML22-188 UML 2.1/Superstructure/ call triggers vs signal triggers UML 2.0 UML 2.2 Resolved closed
UML22-198 UML 2.2 RTF issue - line styles for profiles UML 2.0 UML 2.2 Resolved closed
UML22-195 UML 2 Super / Composite Structure / ambiguous constraint UML 2.0 UML 2.2 Resolved closed
UML22-132 Section: 15.3.12 UML 2.0 UML 2.2 Resolved closed
UML22-131 Section: 11.5.1 DataType (as specialized) UML 2.0 UML 2.2 Resolved closed
UML22-141 event parameters UML 2.0 UML 2.2 Resolved closed
UML22-130 Section: 11.3.13 TypedElement (as specialized) UML 2.0 UML 2.2 Resolved closed
UML22-129 Section: 11.3.6 Classifiers diagram UML 2.0 UML 2.2 Resolved closed
UML22-139 Page: 62 UML 2.0 UML 2.2 Resolved closed
UML22-125 Page: 129 UML 2.0 UML 2.2 Resolved closed
UML22-124 Page: 369/370 UML 2.0 UML 2.2 Resolved closed
UML22-136 Page: 157,162,163 UML 2.0 UML 2.2 Resolved closed
UML22-127 9.1 BehavioralFeature package UML 2.0 UML 2.2 Resolved closed
UML22-126 Page: 532 UML 2.0 UML 2.2 Resolved closed
UML22-133 Page: 423 UML 2.0 UML 2.2 Resolved closed
UML22-92 Section: D.4 UML 2.0 UML 2.2 Resolved closed
UML22-91 Section: 15.3.8 (second issue) UML 2.0 UML 2.2 Resolved closed
UML22-90 Section: 18.3.6 UML 2.0 UML 2.2 Resolved closed
UML22-89 Section: 17 UML 2.0 UML 2.2 Resolved closed
UML22-102 Section: 8.3.1 UML 2.0 UML 2.2 Resolved closed
UML22-99 Section: 7.3.36 UML 2.0 UML 2.2 Resolved closed
UML22-107 Activities UML 2.0 UML 2.2 Resolved closed
UML22-106 Clarify multiple inputs to expansion regions UML 2.0 UML 2.2 Resolved closed
UML22-105 DataStoreNode has uniqueness, reverse constraint inherited from ObjectNode UML 2.0 UML 2.2 Resolved closed
UML22-87 Add constraints on conditional, loop, sequence to rule out node contents UML 2.0 UML 2.2 Resolved closed
UML22-86 Section: Activities, LoopNode UML 2.0 UML 2.2 Resolved closed
UML22-104 Misleading statement about multiplicity in AssociationClass UML 2.0 UML 2.2 Resolved closed
UML22-103 Client/supplier on dependencies UML 2.0 UML 2.2 Resolved closed
UML22-88 Constrain conditional node to have body pins if there is a result pin. UML 2.0 UML 2.2 Resolved closed
UML22-173 On page 26, Figure 7.9 UML 2.0 UML 2.2 Resolved closed
UML22-172 choice of terminolgy for TransitionKind is non-intuitive UML 2.0 UML 2.2 Resolved closed
UML22-171 Section: 15.3.15 UML 2.0 UML 2.2 Resolved closed
UML22-170 Section 8.3.2 sub-section "Notation" starting on page 149 UML 2.0 UML 2.2 Resolved closed
UML22-169 inconsistency wrt UML2 classifier behavior UML 2.0 UML 2.2 Resolved closed
UML22-168 keyword, "buildcomponent", and a stereotype, "buildComponent" UML 2.0 UML 2.2 Resolved closed
UML22-182 Element and Comment in Basic UML 2.0 UML 2.2 Resolved closed
UML22-181 Description of Element UML 2.0 UML 2.2 Resolved closed
UML22-180 Unclear relationship between the Basic and Abstractions packages UML 2.0 UML 2.2 Resolved closed
UML22-179 XMI file: Core::Constructs::Operation::bodyCondition should have upper boun UML 2.0 UML 2.2 Resolved closed
UML22-178 /qualifiedName attribute missing on Core::Constructs::NamedElement UML 2.0 UML 2.2 Resolved closed
UML22-177 Operation::ownedParameter should be ordered in XMI? UML 2.0 UML 2.2 Resolved closed
UML22-176 Section: Classes UML 2.0 UML 2.2 Resolved closed
UML22-175 constraints owned by these properties have no context UML 2.0 UML 2.2 Resolved closed
UML22-174 Operation should be a specialization of TypedElement and MultiplicityElemen UML 2.0 UML 2.2 Resolved closed
UML22-167 section, 12.3.27 ExpansionRegion(from ExtarStructureActivities UML 2.0 UML 2.2 Resolved closed
UML22-166 (merged) compliance levels L2 and L3 UML 2.0 UML 2.2 Resolved closed
UML22-165 (merged) compliance level L1 UML 2.0 UML 2.2 Resolved closed
UML22-164 Section: 14.3.20 Message (from BasicInteractions) UML 2.0 UML 2.2 Resolved closed
UML22-163 Section: Activities UML 2.0 UML 2.2 Resolved closed
UML22-33 StateMachine - Constraints UML 2.0 UML 2.2 Resolved closed
UML22-32 transtion UML 2.0 UML 2.2 Resolved closed
UML22-30 Inheritance of 'Enumerations' is not detailed UML 2.0 UML 2.2 Resolved closed
UML22-31 manage simultaneity of events UML 2.0 UML 2.2 Resolved closed
UML22-112 External exceptions. UML 2.0 UML 2.2 Resolved closed
UML22-111 Clarify which classifier or operation this is referring to UML 2.0 UML 2.2 Resolved closed
UML22-110 represents and occurrence keywords are switched UML 2.0 UML 2.2 Resolved closed
UML22-116 Section: Action/Activity UML 2.0 UML 2.2 Resolved closed
UML22-119 Input tokens to LoopNodes should be destroyed when the loop is done UML 2.0 UML 2.2 Resolved closed
UML22-118 Section: 8.3.1 UML 2.0 UML 2.2 Resolved closed
UML22-123 Section: Classes UML 2.0 UML 2.2 Resolved closed
UML22-122 Section: 12.3.2 Action UML 2.0 UML 2.2 Resolved closed
UML22-109 In Figure 12, ownedAttribute is bidirectional, in Figure 95, it is unidirec UML 2.0 UML 2.2 Resolved closed
UML22-108 StructuredActivityNode, Semantics, third paragraph, first sentence, UML 2.0 UML 2.2 Resolved closed
UML22-117 Section: 9.3.7 UML 2.0 UML 2.2 Resolved closed
UML22-76 Section: 14 UML 2.0 UML 2.2 Resolved closed
UML22-75 Section: 14.3.18 UML 2.0 UML 2.2 Resolved closed
UML22-74 RemoveStructuralFeatureValueAction specification UML 2.0 UML 2.2 Resolved closed
UML22-82 Decision node UML 2.0 UML 2.2 Resolved closed
UML22-81 Section: Actions UML 2.0 UML 2.2 Resolved closed
UML22-72 Section: 13.3.17 UML 2.0 UML 2.2 Resolved closed
UML22-71 Section: 13.3.11 UML 2.0 UML 2.2 Resolved closed
UML22-78 Section 15 UML 2.0 UML 2.2 Resolved closed
UML22-77 Section: 14 UML 2.0 UML 2.2 Resolved closed
UML22-69 Section: 12.3.40 UML 2.0 UML 2.2 Resolved closed
UML22-68 Section: 12.3.33 UML 2.0 UML 2.2 Resolved closed
UML22-84 Section: Classes UML 2.0 UML 2.2 Resolved closed
UML22-83 Section: Activities UML 2.0 UML 2.2 Resolved closed
UML22-65 Section: 10.3.11 UML 2.0 UML 2.2 Resolved closed
UML22-85 Section: Interactions UML 2.0 UML 2.2 Resolved closed
UML22-155 Section: Common Behavior UML 2.0 UML 2.2 Resolved closed
UML22-154 Section: Classes (02) UML 2.0 UML 2.2 Resolved closed
UML22-153 Section: Common Behavior (02) UML 2.0 UML 2.2 Resolved closed
UML22-152 Section: Common Behavior UML 2.0 UML 2.2 Resolved closed
UML22-151 Property ownership must be consistent across association redefinitions UML 2.0 UML 2.2 Resolved closed
UML22-150 Missing notation for association classes UML 2.0 UML 2.2 Resolved closed
UML22-149 Page: 346-347 UML 2.0 UML 2.2 Resolved closed
UML22-148 Page: 255 UML 2.0 UML 2.2 Resolved closed
UML22-147 Behavior UML 2.0 UML 2.2 Resolved closed
UML22-144 UML 2 - Invalid subsetting of composition ends UML 2.0 UML 2.2 Resolved closed
UML22-143 UML 2 Super / Actions / Compliance Levels of Actions UML 2.0 UML 2.2 Resolved closed
UML22-162 Page: 53-55 UML 2.0 UML 2.2 Resolved closed
UML22-161 "ownedType" is not a valid element UML 2.0 UML 2.2 Resolved closed
UML22-158 Section: Classes UML 2.0 UML 2.2 Resolved closed
UML22-157 Section: Classes UML 2.0 UML 2.2 Resolved closed
UML22-156 Section: Activities UML 2.0 UML 2.2 Resolved closed
UML22-146 UML SuperStructure - Inconsistency re State Machine terms UML 2.0 UML 2.2 Resolved closed
UML22-145 Section: 14.3.20 UML 2.0 UML 2.2 Resolved closed
UML22-160 Section: 16.3.3 UML 2.0 UML 2.2 Resolved closed
UML22-159 Section: Activities UML 2.0 UML 2.2 Resolved closed
UML22-142 Page: 420 UML 2.0 UML 2.2 Resolved closed
UML22-36 Connector - "provided Port" and "required Port" not defined Constraint 1 UML 2.0 UML 2.2 Resolved closed
UML22-48 Section: 9.14.1 UML 2.0 UML 2.2 Resolved closed
UML22-42 Notation sections for TimeObservation and DurationObservation UML 2.0 UML 2.2 Resolved closed
UML22-38 Connector - inconsistencies in Constraint[3] UML 2.0 UML 2.2 Resolved closed
UML22-37 Connector - inconsistencies in Constraint [2] UML 2.0 UML 2.2 Resolved closed
UML22-40 Connector - inconsistencies in Constraint[5] UML 2.0 UML 2.2 Resolved closed
UML22-39 Connector - inconsistencies in Constraint[4] UML 2.0 UML 2.2 Resolved closed
UML22-50 Presentation Options UML 2.0 UML 2.2 Resolved closed
UML22-44 useless example on p.330, Figure 247 UML 2.0 UML 2.2 Resolved closed
UML22-43 Property defines an association "datatype" which is redundant UML 2.0 UML 2.2 Resolved closed
UML22-57 Multiple typos in ptc/04-10-02 UML 2.0 UML 2.2 Resolved closed
UML22-56 Clarify the differences between redefining element and redefined element. UML 2.0 UML 2.2 Resolved closed
UML22-55 All sections UML 2.0 UML 2.2 Resolved closed
UML22-64 Section: 9.3.11 UML 2.0 UML 2.2 Resolved closed
UML22-63 Section: 8.3.2 UML 2.0 UML 2.2 Resolved closed
UML22-51 constrainedElement direction UML 2.0 UML 2.2 Resolved closed
UML22-52 Derived union notation UML 2.0 UML 2.2 Resolved closed
UML22-61 Section: 9.3.7 UML 2.0 UML 2.2 Resolved closed
UML22-60 Section: 9.3.6 UML 2.0 UML 2.2 Resolved closed
UML22-62 Section: 8.3.2 UML 2.0 UML 2.2 Resolved closed
UML22-58 Section: 8.3.2 UML 2.0 UML 2.2 Resolved closed
UML22-59 Section: 9.3.4 UML 2.0 UML 2.2 Resolved closed
MOF24-42 Relations UML 2.0 MOF 2.4 Resolved closed
UMLR-75 Page: 107 UML 2.0 open
UMLR-70 Section: Classes UML 2.0 open
UMLR-72 Section: Classes UML 2.0 open
UMLR-71 Section: Activities UML 2.0 open
UMLR-40 Properties on Association for end objects UML 2.0 open
UMLR-39 Notation for classifierBehavior UML 2.0 open
UMLR-38 Contextualized attribute values Figures 121 UML 2.0 open
UMLR-42 ReadStructuralFeatureAction UML 2.0 open
UMLR-34 Section: Classes, Behavior UML 2.0 open
UMLR-37 End objects of a link In the semantics of AssociationClass UML 2.0 open
UMLR-36 Action for retrieving activity instance UML 2.0 open
UMLR-44 Activities section UML 2.0 open
UMLR-43 Section: 16.3.1 UML 2.0 open
UMLR-48 Add constraints on ConditionalNode UML 2.0 open
UMLR-47 ExpansionRegion (behavior in the shorthand notation) UML 2.0 open
UMLR-46 Section: Activities : Why is exception type needed? UML 2.0 open
UMLR-45 Section: Activities - clarification UML 2.0 open
UMLR-103 Section: 7 UML 2.0 open
UMLR-59 Section: 14.3.3 Page: 508+ UML 2.0 open
UMLR-58 Section: 14.3.3 UML 2.0 open
UMLR-51 Section: 10.3.1 UML 2.0 open
UMLR-60 ConditionalNode inputs used by more than one test UML 2.0 open
UMLR-55 Possibility to define a Collection as default Value needed UML 2.0 open
UMLR-49 SequenceNode should have way to set output pins in CompleteStructured UML 2.0 open
UMLR-80 Section: Sequence diagrams UML 2.0 open
UMLR-32 Alternative entry and exit point notation is ambiguous UML 2.0 open
UMLR-3 More explanation needed on Figure 339 UML 2.0 open
UMLR-2 More examples UML 2.0 open
UMLR-4 Parameterization of lifelines UML 2.0 open
UMLR-19 Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class R UML 2.0 open
UMLR-27 inconsistency in the action model UML 2.0 open
UMLR-26 large overlap between structural features and variables UML 2.0 open
UMLR-28 metaattribute isReadOnly UML 2.0 open
UMLR-29 surface notation for state machines UML 2.0 open
UMLR-30 Provide exception handling for all behaviors. UML 2.0 open

Issues Descriptions

when is a connection a "bi-directional connection"?

  • Legacy Issue Number: 7356
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Dave Stringer)
  • Summary:

    The discussion on when to send BiDirIds over connections is floundering.
    In part, I think this is due to a lack of precision in our thinking (and more
    importantly in the adopted firewall spec we are working from).

    When does a GIOP connection become bi-directional? The implementation
    of the connection-initiator protocol engine must know this. Before this
    event it has to treat a GIOP Request message as a protocol error and after
    the event it has to dispatch the request.

    There seems to be an assumption (or more than one) that there is a
    relationship between an Object Reference (i.e. the programming language
    artefact representing CORBA::Object) and a GIOP connection.

    Whilst it is true that an implementation of the CORBA spec will provide a
    relationship (else an invocation cannot result in a GIOP Request message)
    the particular relationship was left to ORB implementers to provide for
    flexibility of implementation. Specifically, such a relationship is not prescribed
    in the CORBA specification (nor should it be).

    I suggest it would be dangerous to define a GIOP connection to change state
    when an Object Reference that (in some ill-defined way) "points to" a server
    that is the target of that connection, undergoes a policy change (i.e. its BiDir
    Offer policy is set to Allow).

    Instead, a GIOP connection presumably becomes bi-directional when an
    invocation on an Object Reference, with an effective Offer Policy of Allow, results
    in a Request message being sent over that connection.

    The specification must be explicit over which event causes the connection to
    become bi-directional.

    Also, can a connection cease to be bi-directional? For example if either the
    Object Reference invoked above or the POA with "Export = Allow" are destroyed.
    Again this would appear to be fraught with problems, leading to the assumption
    that the GIOP connection, once bi-directional, remains bi-directional until it is
    closed.

    Lastly, the closing of idle connections and the subsequent re-connection has
    hitherto been a matter for ORB implementers (Messaging::RebindPolicy not
    withstanding). This is unfortunate as an application won't be aware of the ORB
    having conserved resources in this way and the ORB should not be expected to
    provide session semantics that span multiple tcp connections (this is currently
    stated in the description of NegotiateSession).

  • Reported: UML 2.0 — Tue, 18 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:33 GMT

when is a connection a "bi-directional connection"?

  • Legacy Issue Number: 7356
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Dave Stringer)
  • Summary:

    The discussion on when to send BiDirIds over connections is floundering.
    In part, I think this is due to a lack of precision in our thinking (and more
    importantly in the adopted firewall spec we are working from).

    When does a GIOP connection become bi-directional? The implementation
    of the connection-initiator protocol engine must know this. Before this
    event it has to treat a GIOP Request message as a protocol error and after
    the event it has to dispatch the request.

    There seems to be an assumption (or more than one) that there is a
    relationship between an Object Reference (i.e. the programming language
    artefact representing CORBA::Object) and a GIOP connection.

    Whilst it is true that an implementation of the CORBA spec will provide a
    relationship (else an invocation cannot result in a GIOP Request message)
    the particular relationship was left to ORB implementers to provide for
    flexibility of implementation. Specifically, such a relationship is not prescribed
    in the CORBA specification (nor should it be).

    I suggest it would be dangerous to define a GIOP connection to change state
    when an Object Reference that (in some ill-defined way) "points to" a server
    that is the target of that connection, undergoes a policy change (i.e. its BiDir
    Offer policy is set to Allow).

    Instead, a GIOP connection presumably becomes bi-directional when an
    invocation on an Object Reference, with an effective Offer Policy of Allow, results
    in a Request message being sent over that connection.

    The specification must be explicit over which event causes the connection to
    become bi-directional.

    Also, can a connection cease to be bi-directional? For example if either the
    Object Reference invoked above or the POA with "Export = Allow" are destroyed.
    Again this would appear to be fraught with problems, leading to the assumption
    that the GIOP connection, once bi-directional, remains bi-directional until it is
    closed.

    Lastly, the closing of idle connections and the subsequent re-connection has
    hitherto been a matter for ORB implementers (Messaging::RebindPolicy not
    withstanding). This is unfortunate as an application won't be aware of the ORB
    having conserved resources in this way and the ORB should not be expected to
    provide session semantics that span multiple tcp connections (this is currently
    stated in the description of NegotiateSession).

  • Reported: UML 2.0 — Tue, 18 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Operation calls on behavior ports

  • Key: UMLR-54
  • Legacy Issue Number: 8748
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Operation calls on behavior ports. Per FTF discussion, clarify that an operation call can arrive at a behavior port and be handled by a method on the owning object, without going to the classifier behavior

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Updated: Fri, 20 Apr 2018 14:30 GMT

Disjointness should be independent of generalization

  • Key: UMLR-35
  • Legacy Issue Number: 8014
  • Status: open  
  • Source: NIST ( Mr. Evan K. Wallace)
  • Summary:

    Disjointness should be independent of generalization. Two classes can be disjoint, but have no common supertype. This facilitates the mapping to OWL

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Sun, 28 Feb 2016 03:57 GMT

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

Section: 14.3.20

  • Key: UML23-151
  • Legacy Issue Number: 10076
  • Status: closed  
  • Source: Thomson Transaction Services ( Tim Grunewald)
  • Summary:

    My question regards the following: Syntax for the Message name is the following: <messageident> ::= ([<attribute> ‘=’] <signal-or-operation-name> [‘(‘ [<argument> [‘,’<argument>]* ‘)’] [‘:’ <return-value>]) | ‘*’ <argument> ::= (<[parameter-name> ‘=’] <argument-value>) | (<attribute> ‘=’ <out-parameter-name> [‘:’ <argument-value>] | ‘ -’ First, I see a typo in the argument definition where the beginning of the definition should read as follows (Note the first square bracket and less than symbol): <argument> ::= ([<parameter-name> ‘=’] Second, I would like clarification on this item. From the definition it seems that I cannot specify a message by just showning the parameters. For example, if I have a class that has an operation of setFoo(int value): void, I cannot have a message of the method and its parameters, for example, "setFoo(value)". It would look like this instead "setFoo(value=)" according to the definition in the specification. To me this just doesn't seem right to have this hanging equal sign. There are other examples, pages 458 and 491 for example, that show a parameter without the equals sign. Could someone clarify this for me?

  • Reported: UML 2.0 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Discussion:
    This issue seems to have been fixed already.
    Disposition: ClosedNoChange

  • Updated: Sun, 8 Mar 2015 14:22 GMT

UML 2 Super / Components / realizingClassifier

  • Key: UML23-148
  • Legacy Issue Number: 8385
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    InterfaceRealization is a subclass of Realization that inherits the attribute Realization::realizingClassifier (defined in the Components package). This attribute has a multiplicity of 1, which means that InterfaceRealization must have a "realizingClassifier", even though this attribute only makes sense when the target is a Component and not an Interface. This is complicated further by the fact that InterfaceRealization has its own association end that serves a similar purpose called "implementingClassifier". But, this only makes sense for the case when the target of the realization is an Interface and not a Component.

    InterfaceRealization should not be forced to have a "realizingClassifier" attribute. The best way to fix this may be to define a separate subclass of Realization for the case of Components (e.g., ComponentRealization) such that the two cases are kept apart. Alternatively, the multiplicity on Realization::realizingClassifier could be set to 0..1.

  • Reported: UML 2.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This has already been resolved in 2.2.

    Revised Text:
    None.

    Disposition: Closed, no change.

  • Updated: Sun, 8 Mar 2015 14:18 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: 8.3.4

  • Key: UML23-149
  • Legacy Issue Number: 8386
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Notation of a component realization is described as the same as the realization dependency, i.e. dashed line with open arrow-head. But the realization dependency has a triangular arrow-head. Please note that all component example figures use the open arrow-head. I would prefer the triangular arrow-head.

  • Reported: UML 2.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This is a duplicate of part of 10651.

    Revised Text:
    None.

    Disposition: Duplicate.

  • Updated: Sun, 8 Mar 2015 14:18 GMT

actions

  • Key: UML241-46
  • Legacy Issue Number: 7549
  • Status: open  
  • Source: Anonymous
  • Summary:

    In the opinion of some, "at present, the spec bases actions on foundations described in the activities section." However the text says: "An action is the fundamental unit of behavior specification." Thus the text contradicts the opinion. If the opinion is correct, the text should be corrected to agree

  • Reported: UML 2.0 — Wed, 16 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Section: 9.3.12

  • Key: UML241-41
  • Legacy Issue Number: 7614
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Instance values are depicted using the same icon as for the defining classifier. However, for parts this convenient notational convention is not defined. Allow to use the same icon as for the classifier that is the type of the part, when representing the part (modulo the namestring, which is necessarily different, as is the case with instance value also). As an example, a part that derives from an active class could then optionally be shown with the vertical side bars highlighting its active nature.

  • Reported: UML 2.0 — Tue, 3 Aug 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Section: 11.3.39

  • Key: UML241-37
  • Legacy Issue Number: 8184
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Add an "s" to the first classifier in Description. The multiplicities for the associations newClassifier:Classifier[0..*] and oldClassifier:Classifer[0..*] do not agree with fig. 153. Please correct either figure or text - probably figure. Semantics need to clarify the differences/similarities between "existing," "old," and "new" classifiers

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

What is a mapping that is not computable?

  • Key: UML241-33
  • Legacy Issue Number: 7412
  • Status: open  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "It is possible to specify a mapping between the specification and implementation elements, although it is not necessarily computable." What is a mapping that is not computable?

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

Components

  • Key: UML241-32
  • Legacy Issue Number: 7442
  • Status: open  
  • Source: Cutter Information ( Oliver Sims)
  • Summary:

    The Components chapter of the UML2 Superstructure spec does not specify what component generalization/specialization means. Is it intended that this be left unspecified? If not, then I propose the semantics described in a paper I wrote on this subject prior to the spec being adopted. The paper suggested an approach that is consistent with substitutability semantics, and should also be able to be made to work with most if not all component technologies. I'd be happy to email the paper to anyone interested.

  • Reported: UML 2.0 — Thu, 3 Jun 2004 04:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 GMT

DeploymentSpecification - notation for DeploymentSpecification on the insta

  • Key: UML241-35
  • Legacy Issue Number: 7154
  • Status: open  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    DeploymentSpecification - notation for DeploymentSpecification on the instance level

    There are several examples of DeploymentSpecification on the instance level which use the notation name: value (i.e. execution: thread) instead of the default notation for slots (see InstanceSpecification on p. 59) name = value (i.e. execution = thread)

    See - Figure 132 on page 191 - Table 8, 2nd row, 2nd column on page 199

  • Reported: UML 2.0 — Sat, 13 Mar 2004 05:00 GMT
  • Updated: Sun, 8 Mar 2015 14:12 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

CollaborationOccurence

  • Key: UML25-603
  • Legacy Issue Number: 7778
  • Status: closed  
  • Source: Silogic ( Yves BERNARD)
  • Summary:

    The ability for a CollaborationOccurence to be owned by an operation is stated in the CollaborationOccurence semantics but doesn't appear in the metamodel (c.f. Figure 100). More I think that the constraints specified for a CollaborationOccurence should be clarified to to take into account that the owner may be an operation.

  • Reported: UML 2.0 — Tue, 21 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • 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: Fri, 6 Mar 2015 20:59 GMT

Deployment (from ComponentDeployments, Nodes)

  • Key: UML25-609
  • Legacy Issue Number: 7848
  • Status: closed  
  • Source: Borland corp. ( Oleg Smirnov)
  • Summary:

    Deployment (from ComponentDeployments, Nodes): Associatons: • configuration : deploymentSpecification [*] The specification of properties that parameterize the deployment and execution of one or more Artifacts. This association is specialized from the ownedMember association. There is no "ownedMember" association in inheritance hierarchy of Deployment.

  • Reported: UML 2.0 — Fri, 8 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • 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: Fri, 6 Mar 2015 20:59 GMT

Dependency associations

  • Key: UML25-608
  • Legacy Issue Number: 7847
  • Status: closed  
  • Source: Borland corp. ( Oleg Smirnov)
  • Summary:

    I think, that Dependency associations must subset (or specialize?): Dependency::client - DirectedRelationship::source Dependency::supplier - DirectedRelationship::target

  • Reported: UML 2.0 — Fri, 8 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • 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: Fri, 6 Mar 2015 20:59 GMT

Notation of enumeration literals

  • Key: UML25-628
  • Legacy Issue Number: 7426
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Notation of enumeration literals The UML Superstructure spec often writes enumeration literal in OCL expressions as a hash mark (#) followed by the name of the enumeration literal, i.e. #public (p. 20) #protected (p. 27) #composite (p.80) #false (p. 215) #unordered (p. 216) #entryPoint (p. 469) #deepHistory (p. 474) etc. Sometimes it also includes enumeration literals consisting of a (fully qualified) enumeration name followed by '::' and the enumeration literal name, i.e. Aggregation::none (p. 69) According to the OCL 2.0 spec, the second notation is correct (see Sec 7.4.2 in the OCL 2.0 spec) Suggestion: replace all occurences of enumeration literal names with a leading '#' by the notation introduced in OCL 2.0.

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Disposition: Merged with 18124

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Associations section of InteractionUse

  • Key: UML25-624
  • Legacy Issue Number: 7879
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Associations section of InteractionUse: Type of argument must be Action instead of InputPin. Add Property string

    {ordered}

    .

  • Reported: UML 2.0 — Sun, 24 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • 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: Fri, 6 Mar 2015 20:59 GMT

Figure 307 and Figure 308 are exactly the same

  • Key: UML25-627
  • Legacy Issue Number: 7884
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Figure 307 (Invocation Domain Model) and Figure 308 (Communication Domain Model) are exactly the same ("Copy&Paste error"). Communication Domain Model should be replaced

  • Reported: UML 2.0 — Wed, 27 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • 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: Fri, 6 Mar 2015 20:59 GMT

Section: 9.3.3

  • Key: UML25-562
  • Legacy Issue Number: 7415
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    A collaboration is represented as a kind of classifier and defines a set of cooperating entities to be played by instances (its roles)," Roles aren't instances, are they? Does this want to say something like: A collaboration is a kind of classifier and defines a set of roles to be played by cooperating instances, ... Well, probably not. Perhaps: A collaboration is represented as a kind of classifier and defines a set of cooperating entities (its roles) to be played by instances, ...

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • 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: Fri, 6 Mar 2015 20:59 GMT

At «implementation Class», what does "a child of instance" mean?!

  • Key: UML25-561
  • Legacy Issue Number: 7411
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    At «implementation Class», what does "a child of instance" mean?!

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Delete the offending phrase.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

three possibilities for aggregation kind at 7.11.2, but only two notations

  • Key: UML25-559
  • Legacy Issue Number: 7409
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    There are three possibilities for aggregation kind at 7.11.2, but only two notations at 7.11.3.

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • 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: Fri, 6 Mar 2015 20:59 GMT

Section: 7.11.2

  • Key: UML25-558
  • Legacy Issue Number: 7408
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "The interaction of association specialization with association end redefinition and subsetting is not defined." Is that as good as we can do?

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    The quoted text no longer appears in the spec. There is now an explanation of this interaction.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

It is not clear what 'related to' means

  • Key: UML25-560
  • Legacy Issue Number: 7410
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "When a property is an association end, the value or values are related to the instance or instances at the other end(s) of the association" It is not clear what 'related to' means. The text ought to spell out what this relationship is, exactly.

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • 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: Fri, 6 Mar 2015 20:59 GMT

Concept of 'port side' not to be found in metamodel

  • Key: UML25-567
  • Legacy Issue Number: 7435
  • Status: closed  
  • Source: Silogic ( Yves BERNARD)
  • Summary:

    the semantic variation point about port uses the concept of "port side" that I cannot find in the metamodel. May be it should be added?

  • Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • 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: Fri, 6 Mar 2015 20:59 GMT

Description text for CollaborationOccurrence unclear

  • Key: UML25-565
  • Legacy Issue Number: 7420
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    The Description text for CollaborationOccurrence seems to be unclear about roles and the instances playing roles. For example, roles aren't involved in an occurrence, instances playing roles are. For another example, in the case of multiple occurrences of a given collaboration, the roles are the same, while the instances playing those roles may (or may not) differ.

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • 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: Fri, 6 Mar 2015 20:59 GMT

Editrial error in Section: 9.3.4 ?

  • Key: UML25-564
  • Legacy Issue Number: 7419
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "Associated dependencies map features of the collaboration type to features in the classifier. These dependencies indicate which role in the classifier plays which role in the collaboration." seems to be an editorial error

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • 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: Fri, 6 Mar 2015 20:59 GMT

Association collaborationRole

  • Key: UML25-563
  • Legacy Issue Number: 7416
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "Association collaborationRole: ConnectableElement References connectable elements (possibly owned by other classifiers) which represent roles that instances may play in this collaboration." Do they represent roles, or are they roles? If they represent roles, how do we learn which role a particular element represents?

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Disposition: Merged with 18697

  • Updated: Fri, 6 Mar 2015 20:59 GMT

There is no "precise mapping

  • Key: UML25-576
  • Legacy Issue Number: 7559
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The RFP requires that "Proposals shall justify and fully specify any changes or extensions required to existing OMG specifications. ... In general, OMG favors upwards compatible proposals that minimize changes and extensions to existing OMG specifications." [5.1.6] "Since UML has a large installed user base all proposed changes should consider backward incompatibility issues." [6.2] "... gratuitous changes to the current UML specification are strongly discouraged." [6.3] "Wherever changes have adversely impacted backward compatibility with previous specifications, submissions shall provide rationales and change summaries along with their precise mappings." "Proposals shall minimize the impact on users of the current UML 1.x, XMI 1.x and MOF 1.x specifications, and shall provide a precise mapping between the current UML 1.x and the UML 2.0 metamodels." "Proposals shall identify language elements to be retired from the language ..." [6.5.1] UML 2 removes three essential elements of an existing OMG specification, the UML 1.5 action language: GroupAction, ConditionalAction and LoopAction. No reason is given. The UML 2 specification notes that "conditional nodes replace ConditionalAction from the UML 1.5 action model" but gives no rationale for this change. There is no mention of the removal of GroupAction and LoopAction. There is no "precise mapping between the current UML 1.x and the UML 2.0 metamodels" for GroupAction, ConditionalAction and LoopAction.

  • Reported: UML 2.0 — Wed, 23 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • 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: Fri, 6 Mar 2015 20:59 GMT

Semantics section of StructuralFeature

  • Key: UML25-575
  • Legacy Issue Number: 7558
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    The Semantics section of StructuralFeature says "A structural feature specifies that instances of the featuring classifier have a slot..."
    That's wrong. It is instance specifications of the classifier that have slots, not instances.

  • Reported: UML 2.0 — Fri, 2 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • 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: Fri, 6 Mar 2015 20:59 GMT

"required interface"

  • Key: UML25-592
  • Legacy Issue Number: 7652
  • Status: closed  
  • Source: Silogic ( Yves BERNARD)
  • Summary:

    The concept of "required interface" is discussed but not clearly specified. 1. Shouldn't a specialized "Usage" be derived to model those related to interfaces? 2. May Classifier have required interfaces or only BehavioredClassifier? 3. A derived role or at least an OclHelper should be provided to get the required interfaces.

  • Reported: UML 2.0 — Thu, 2 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • 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: Fri, 6 Mar 2015 20:59 GMT

UML 2 does not permit use of a state machine

  • Key: UML25-596
  • Legacy Issue Number: 7675
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    It appears UML 2 does not permit use of a state machine as a specification technique for a class. The support for use of a state machine to specify a method does not help: that state machine won't be a method. The support for use of a state machine to specify a classifier behavior does not help: since that state machine is not a specification of code that gets invoked when an object is created. Example: An architect specifies a state machine for a class. This is not the specification of a method, nor of an independent computation belonging to an object of that class, but of the overall behavior of an object of that class. That state machine responds to four events. As a refinement of that model, a tool or a designer generates four event taker method specifications, which together implement the specified state machine. Those methods are then hand coded according to that specification, or perhaps another tool generates the code for those methods. An object of this class "does nothing until it [one of its event taker methods] is invoked by some other object, then it does its thing, and then it returns and again does nothing." The behavior of that object is fully specified by this state machine. This state machine is not the specification of a method, nor is it the specification of a classifier behavior ("When an instance of a behaviored classifier is created, its classifier behavior is invoked."). But the opinion of experts, expressed in FTF discussions, is that these are the only two uses of a state machine permitted by the FAS. This state machine is not intended to "to describe or illustrate the behavior of an object." It is intended to fully specify that behavior. It is not a protocol state machine. Proposal: Specifically authorize this use of a state machine.

  • Reported: UML 2.0 — Sat, 4 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    A BehavioredClassifier in UML 2 can own any number of Behaviors via its BehavioredClassifier::Behavior link.
    These Behaviors can be of any type and can have any interpretation desired by the modeler (with the exception of
    the one designated as the “classifier Behavior”). Hence, there is nothing to prevent defining a state machine with the
    interpretation suggested by the submitter.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

"role binding"

  • Key: UML25-600
  • Legacy Issue Number: 7748
  • Status: closed  
  • Source: Silogic ( Yves BERNARD)
  • Summary:

    If a "role binding" is describe as a mapping between ConnectableElements, Collaboration::Classifier should derive from InternalStructure::StructuredClassifier rather than from Kernel::Classifier

  • Reported: UML 2.0 — Fri, 17 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • 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: Fri, 6 Mar 2015 20:59 GMT

multiplicity of the "role:ConnectableElement"

  • Key: UML25-599
  • Legacy Issue Number: 7747
  • Status: closed  
  • Source: Silogic ( Yves BERNARD)
  • Summary:

    It's not clear whether the multiplicity of the "role:ConnectableElement" role multiplicity is [1] or [0..1]. I think it should be [1], as stated in the role description but figure 96 shows "0..1" and the ConnectorEnd constraints descriptions aren't clear on that point

  • Reported: UML 2.0 — Fri, 17 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • 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: Fri, 6 Mar 2015 20:59 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.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

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

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

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

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

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.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

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

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

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

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

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.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

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

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

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

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

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

Bad cross reference for InterfaceRealization Notation

  • Key: UML22-250
  • Legacy Issue Number: 9881
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The notation part of Section 7.3.25 says "See Interface(from
    Interfaces)". However this has nothing to do with Realization. The
    cross-reference should in fact be to Realization - section 7.3.45 -
    which does have the notation needed.

  • Reported: UML 2.0 — Mon, 3 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PrimitiveTypes access by UML (M1) models

  • Key: UML22-249
  • Legacy Issue Number: 9878
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML allows M1-level models to reuse the primitive types defined in the PrimitiveTypes package in the UML Infrastructure (e.g., Integer, String, etc.). Currently, this package is merged into L0 and is not separately accessible and should have its own URI so that it can be imported by M1 models without having to import the UML metamodel.

    This may also mean that instead of merging the package PrimitiveTypes into L0, the package should be imported

  • Reported: UML 2.0 — Thu, 29 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unclear which Property has aggregation

  • Key: UML22-253
  • Legacy Issue Number: 9889
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Where a diagram has a diamond it is not clear which end has the aggregation metaproperty. This can be discovered but only with a lot of detecetive work. For example 7.3.3 states "An association with aggregationKind = shared differs in notation from binary associations in adding a hollow diamond as a terminal adornment at the aggregate end of the association line. ". Nothing makes sufficiently clear that, for an aggregate property, that the diamond is depicted at the opposite end to the multiplicity and other annotations for that property.

  • Reported: UML 2.0 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Move Property::isId from MOF to UML

  • Key: UML22-252
  • Legacy Issue Number: 9888
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    It is a general requirement to be able to indicate candidate keys in UML models. This should be in Infrastructure (s still usable by MOF) and merged into Superstructure.

  • Reported: UML 2.0 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for stereotypes on Comments and other elements

  • Key: UML22-248
  • Legacy Issue Number: 9877
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 18.3.8, Notation, states "When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element. " However several elements do not have names - for example Comment and LiteralString (the ODM Profile does define stereotypes on the latter).

    SysML contains the following.
    A comment note box may contain stereotype keywords or icons even though Comment is not a named element. UML specifies placement of a stereotype keyword relative to the name of the element. SysML makes explicit that they may appear inside a comment box as well. The stereotype keywords, if present, should appear prior to the comment text. The stereotype properties, if present, should appear after the comment text. The typical placement of stereotype icons is in the upper-right-hand corner of the containing graphical node.
    This approach should be used by UML and generalized for other non-named elements

  • Reported: UML 2.0 — Thu, 29 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Duplicate of 9706

  • Updated: Fri, 6 Mar 2015 20:58 GMT

text-diagram out of synch in Infrastructure 11.4.1

  • Key: UML22-251
  • Legacy Issue Number: 9885
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Bran at the Boston meeting remarked on the practical difficulty of keeping the Infrastructure doc up to date and in synch, text to diagrams and diagrams to underlying xmi.

    This is a report of a place where the text is out of synch with metamodel diagrams in doc.

    reference is to 06-04-03 Infrastructrue v2.1 doc.

    11.4.1 Classifier

    Associations • feature : Feature [*] Redefines the corresponding association in Abstractions. Subsets Namespace::member and is a derived union. Note that there may be members of the Classifier that are of the type Feature but are not included in this association (e.g., inherited features). Constraints No additional constraints Semantics No additional semantics

    Problem here is that Figure 11.16, the Constructs classifier diagram, shows the important general association, Classifier to Classifier, which is not mentioned in the text, needs to be documented under 11.4.1 Associations and probably also Semantics

  • Reported: UML 2.0 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify isRequired

  • Key: UML22-254
  • Legacy Issue Number: 9890
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    18.3.2 the description for isRequired, while technically correct, is somewhat terse and does not make clear that the references to 'multiplicity are to the lower and upper properties of ExtensionEnd

  • Reported: UML 2.0 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

General ordering cycles

  • Key: UML22-217
  • Legacy Issue Number: 9806
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    There should be a constraint preventing the definition of general ordering cycles (involving occurrence specifications), as there is with generalizations

  • Reported: UML 2.0 — Tue, 6 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What exactly is a state list?

  • Key: UML22-215
  • Legacy Issue Number: 9800
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The UML2.1 specification defines a state list:

    The special case of the transition from the junction having a history as
    target may optionally be presented as the target
    being the state list state symbol. See Figure 15.27 and Figure 15.28 for
    examples.

    I couldn't map that definition to the example. There is no junction and
    no history state. Can someone
    provide fig. 15.27 in another notation without state list?

    I'm not the first one who's asking this. Probably we should provide such
    an example in the spec.

  • Reported: UML 2.0 — Tue, 30 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.14.2

  • Key: UML22-214
  • Legacy Issue Number: 9760
  • Status: closed  
  • Source: Self-Employed ( Steven Coco)
  • Summary:

    The definition of Namespace lists as a generalization, Namespace. This appears to be an error: it appears this is intented to refer to NamedElement.

  • Reported: UML 2.0 — Wed, 24 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.1.3

  • Key: UML22-213
  • Legacy Issue Number: 9752
  • Status: closed  
  • Source: Watt Systems Technologies ( Kenneth Lloyd)
  • Summary:

    Element reads "Constructs::Element reuses the definition of Element from Abstractions::Comments." Since this element has been removed should this read "Constructs::Element reuses the definition of Element from Abstractions::Ownerships." as reflected in the merge?

  • Reported: UML 2.0 — Wed, 17 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Action inputs/outputs

  • Key: UML22-212
  • Legacy Issue Number: 9720
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Seeing as Action::input and Action::output are derived compositions that subset Element::ownedElement, all subsets of them should be compositions (I thought Karl had added a constraint to this effect?). In particular, OpaqueAction::inputValue, OpaqueAction::outputValue, AcceptEventAction::result, AcceptCallAction::returnInformation, UnmarshallAction::result should be composite

  • Reported: UML 2.0 — Mon, 15 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Completion event modeling

  • Key: UML22-219
  • Legacy Issue Number: 9808
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Completion events are an explicit concept in UML statecharts. However, there is no corresponding metaclass either in the Common Behavior section or in Statecharts. Since completion events trigger transitions, it may be necessary to have an explicit CompletionEvent metaclass. For instance, we may want to model an interaction in which execution occurrences are initiated by completion events.

  • Reported: UML 2.0 — Wed, 7 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Requires the addition of a new meta class. This needs to be postponed to a later revision when we will have more time to investigate this proposal and its impacts.

    Revised Text:
    N/A
    Disposition: Closed, out of scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial bug in 2.1 Superstructure Convenience document

  • Key: UML22-216
  • Legacy Issue Number: 9803
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The Convenience document is inconsistent with the resolution with 9087 and itself: the spec shows Package::packagedElement as derived in the Associations section of 7.3.37 whereas it's clearly not in the resolution. Figure 7.14 is actually OK as is the metamodel.

  • Reported: UML 2.0 — Mon, 5 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.3.4 Association Class

  • Key: UML22-183
  • Legacy Issue Number: 9249
  • Status: closed  
  • Source: Paranor AG ( Earl Waldin)
  • Summary:

    The specification should state when navigation between an association class and the endpoints of that association class are allowed. When there is an association class between two classes, OCL allows navigation between these classes and the association class itself (see Sections 7.5.4 and 7.5.5 of the OCL 2.0 specification ptc/2005-06-06). However, navigability in UML2 is defined with respect to the metaclass Property and the semantics describe navigability in terms of navigating across an association via a property, i.e., from one endpoint to the other (see the definition of isNavigable() in Section 7.3.44, subsection Additional Operations, and descriptions of navigability in sections 7.3.3 - Association, 7.3.7 - Class, and 7.3.44 – Property.) No mention of navigability to and from association classes is found in section 7.3.4 – Association Class, nor any place else in the specification. One simple possibility would be for navigation involving association classes to respect navigation between its endpoints. For example, if classes C1 and C2 are connected by an association class A, then if one can navigate from C1 to C2 (C1->C2), then one can navigate from C1 to A (C1->A) and from A to C2 (A->C2). Another simple possibility would be to always allow navigation from an association class to its endpoints while requiring navigation from an endpoint to the association class to respect navigability. For example, if the association is one-way navigable from C1 to C2 (C1->C2) then one could navigate from C1 to A (C1->A) and from A to C2 (A->C2) as above and, in addition, from A to C1 (A->C1). Anything more complex than these two simple alternatives requires deeper investigation into the semantics of the UML metamodel or even changing the metamodel. For example, the association ownedEnd: Property for Association in section 7.3.3 could subset Classifier::attribute instead of Classifier::feature. Or in the definition of Association Class in 7.3.4 one could allow the inherited associations ownedAttribute: Property and ownedEnd: Property to overlap, i.e., be non-disjoint, although this may have technical difficulties because these two associations are compositions.

  • Reported: UML 2.0 — Thu, 19 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Invalid mandatory compositions and associations

  • Key: UML22-264
  • Legacy Issue Number: 10074
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    I initially thought this just affected chapter 11 and compositions, but the more I looked the wider the impact: this seems quite a systemic problem.

    There are several significant metamodel errors that would prevent population of models in repositories that enforce association semantics. These affect both the diagrams and the metamodel (though I have not checked every association in the metamodel XMI).
    The common problem is metaclasses being shown with multiple mandatory composite owners (i.e. a multiplicity of 1 as opposed to 0..1) next to the black diamond. In some cases this is implicit (the default multiplicity being 1..1, in others explicitly '1'). Since any instance can have at most one composite owner, to have more than one such owner mandatory makes for an 'impossible' (to be valid) metamodel.

    There are non-composition cases where it also does not make sense to have associations mandatory. Often the mandatory nature is implicit (there is not explicit multiplicity shown on the diagrams).

    Here is the list of diagrams and the problematic classes:
    Figure 7.7 Element (not every Element will be constrained)
    Figure 7.8 StructuralFeature (not every StructuralFeature will have a Slot defined for it in some instance model) and Classifier (again not every Classifier will have at least one InstanceSpecification)
    Figure 7.9 NamedElement, Classifier (for redefinedElement, general), RedefinableElement (for redefinedElement, redefinitionContext)
    Figure 7.10 Type
    Figure 7.12 Type (via endType), Class(via superClass), and Property (via opposite, redefinedProperty, subsettedProperty)

    Figure 8.2 Classifier (not every Classifier will realize a Component) and Interface (not every Interface will be both provided and required by at least one Component)

    Figure 10.2 Artifact (inverse of nestedArtifact is mandatory - not every Artifact will be nested in another)
    Figure 10.3 Node (ditto for nestedNode)

    Figure 11.3 InputPin and OutputPin
    Figure 11.4 InputPin and OutputPin
    Figure 11.5 InputPin
    Figure 11.8 InputPin
    Figure 11.13 InputPin
    Figure 11.17 InputPin and OutputPin.

    Figure 11.2 does not have mandatory composition but requires each InputPin (and OutputPin) to be the inputValue of an OpaqueAction which seems quite wrong.

    Figure 12.10 ValueSpecification
    Figure 12.11 ValueSpecification
    Figure 12.13 Constraint
    Figure 12.14 ValueSpecification
    Figure 12.19 ValueSpecification

    Figure 13.12 ValueSpecification
    Figure 13.13 ValueSpecification and Observation (the latter is not a composition error but it seems wrong)

    Figure 14.3 Constraint
    Figure 14.5 NamedElement (again not composition but not every NamedElement should be the signature of a Message)
    Figure 14.7 ValueSpecification

    Figure 15.2 Trigger (there is only one mandatory composition but it makes the optional composition useless since the latter could never be set)

    Figure 17.16 ParameterableElement (not a composition but each ParameterableElement will not be the default of a TemplateParameter)

    Proposed Resolution: mark all the above association ends as 0..1 and update the metamodel accordingly

  • Reported: UML 2.0 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

11.3.47 on StructuralFeatureAction (and related sections on subclasses)

  • Key: UML22-263
  • Legacy Issue Number: 10045
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Consider a link object that is an instance of an association
    > class that owns its ends. In this case, according to the
    > metamodel, it is the association class that is the
    > featuring classifier of the end properties (owningAssociation
    > subsets featuringClassifier). The properties of the object
    > input pin of a StructuralFeatureAction are determined by the
    > featuring classifier of the feature, which would imply that
    > the object being accessed in the case of an owned feature of
    > an association class is the link object that is the instance
    > of that association class.
    >
    > BUT, the semantics of StructuralFeatureAction say that "If
    > the structural feature is an association end, then actions on
    > the feature have the same semantics as actions on the links
    > that have the feature as an end. See specializations of
    > StructuralFeatureAction" – which is consistent with your
    > claims. This is an inconsistency in the spec. For the
    > semantics to work correctly, the syntactic constraints (on
    > typing of the object, visibility,
    > etc.) would have to be adjusted for the case of an
    > association end owned by an association class.

  • Reported: UML 2.0 — Tue, 25 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    (Note that the StructuralFeatureAction subclause is numbered 11.3.48 in Version 2.2.)
    The issue summary states that "the properties of the object input pin of a StructuralFeatureAction are determined by the featuring classifier of the feature." However, the specification does not actually formally require this. Rather, Subclause 11.3.48 includes instead the following constraint:
    [2] The type of the object input pin is the same as the classifier of the object passed on this pin.
    This statement is actually tautological if the normal typing rules are enforced, and does not place any constraint on the relationship of the type of the object input pin and the featuring classifier of the feature.
    The intent really is that a StructuralFeatureAction for a structural feature that is an association end have the same semantics as for the appropriate link action. The ownership of the association end should not matter. For example, this allows a ReadStructuralFeatureAction to be used to read the navigable opposite end of a binary association, whether that end is owned by the opposite end type or owned by the association itself (in which case the ReadStructuralFeatureAction acts like a ReadLinkAction). This way, the action does not have to be changed just because the model may be updated to change the end ownership - the ability to read the end depends only on its navigability.
    If this is clarified and formalized in the specification, then the above issue becomes moot.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.16.1

  • Key: UML22-262
  • Legacy Issue Number: 10007
  • Status: closed  
  • Source: ISP ( Leonid Dvoryansky)
  • Summary:

    Double declaration: RedefinableElement::isRedefinitionContexValid(redefinable: RedefinableElement): Boolean; RedefinableElement::isRedefinitionContextValid (redefined:RedefinableElement):Boolean; isRedifinitionContextValid = redefinitionContext->exists(c | c.allparents()-> includes (redefined.redefinitionContext)) ) Is the "isRedefinitionContexValid" declaration redundant?

  • Reported: UML 2.0 — Fri, 28 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Appears to have already been fixed. See Additional Operation [2] in section 7.3.46. Editorial note: However the fix has not been applied to Infrastructure.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.19.1

  • Key: UML22-261
  • Legacy Issue Number: 10006
  • Status: closed  
  • Source: ISP ( Leonid Dvoryansky)
  • Summary:

    Wrong definition of hasVisibilityOf() Classifier::hasVisibilityOf(n: NamedElement) : Boolean; pre: self.allParents()>collect(c | c.member)>includes ... if (self.inheritedMember->includes ) then hasVisibilityOf = (n.visibility <> #private) else hasVisibilityOf = true ... should be: if (not self.inheritedMember->includes ) then hasVisibilityOf = (n.visibility <> #private) else hasVisibilityOf = true

  • Reported: UML 2.0 — Fri, 28 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    There is more wrong than suggested in the issue. If you work through the logic of hasVisbilityOf, you end up with a tautology as demonstrated by Ed with the following argument:
    To determine if a.hasVisibilityOf is true, assuming n is private, we need to be able to deduce that (including the proposed change)
    if (not a.inheritedMember->includes) then false else true
    is true, under the constraint that
    a.inheritedMember->includesAll(a.inherit(a.parents()->collect(p | p.inheritableMembers(a)))
    where
    p.inheritableMembers(a) = p.member->select(m | a.hasVisibilityOf(m))
    Clearly, given the above constraint, not a.inheritedMember->includes is true if
    not (a.inherit(a.parents()>collect(p | p.member>select(m | a.hasVisibilityOf(m)))->includes)
    This, in turn, is equivalent to
    not (a.parents().member->includes and a.hasVisibilityOf and a.inherit)
    The conclusion so far is, therefore, that a.hasVisibilityOf is true if the above expression is false, that is, if
    a.parents().member->includes and a.hasVisibilityOf and a.inherit implies a.hasVisibilityOf
    Now, if either a.parents().member->includes or a.inherit are false, then the antecedent in the above implication is false, which means that a.hasVisibilityOf must be false. On the other hand, if both a.parents().member->includes and a.inherit are true, then the implication reduces to the tautology
    a.hasVisibilityOf implies a.hasVisibilityOf
    which is true whether or not a.hasVisibilityOf is true.
    However, it is not apparent why if (not a.inheritedMember->includes) is needed at all. If we simply define hasVisibilityOf as n.visibility <> private, i.e. members are visible in a child if they are not private, we remove the tautology and simplify the logic.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.12.1

  • Key: UML22-258
  • Legacy Issue Number: 10003
  • Status: closed  
  • Source: ISP ( Leonid Dvoryansky)
  • Summary:

    In UML Infrastructure version 2.0 formal/05-07-05 p.67 I've found that nonterminal <upper> has the alternative '', but <unlimited_natural> nonterminal range already contains '' as a possible deducible terminal sequence. <multiplicity> ::= <multiplicity-range> <multiplicity-range> ::= [ <lower> ‘..’ ] <upper> <lower> ::= <integer> <upper> ::= ‘*’ | <unlimited_natural>

  • Reported: UML 2.0 — Thu, 27 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Merged Metam.:Property::class with redefinition of non-inherited property

  • Key: UML22-257
  • Legacy Issue Number: 10001
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Merged metamodel has Property::class with redefinition of a non-inherited property
    ----------------------------------------------------------------------------------------------------------------------

    In UML 2.1 we have the following:
    Kernel defines Class which inherits from Classifier, and has Class::ownedAttribute of type Kernel::Property.

    Composite Structures also defines Class which inherits from EncapsulatedClassifier which inherits from StructuredClassifier which inherits from Kernel::Classifier (curiously not Collaborations::Classifier in the same section).
    Now StructuredClassifier also defines property StructuredClassifier::ownedAttribute of type InternalStructures::Property

    So in the Merge, we have:
    L3::Class with property L3::Class::ownedAttribute of type L3::Property
    this will inherit from:
    L3::Classifier and L3::EncapsulatedClassifier, with the latter inheriting from L3::StructuredClassifier.
    And L3::StructuredClassifier will continue to have a property L3::StructuredClassifier::ownedAttribute.
    This would be inherited by L3::Class which has its own ownedAttribute.

    Hence there must be a redefinition L3::Class::ownedAttribute redefines L3::StructuredClassifier::ownedAttribute (there is).
    Likewise there must also be a generalization between the 2 associations (there is).

    However there is a change of the property ownership: at the subclass Property::class is owned by Property, and L3::A_ownedAttribute_structuredClassifier::structuredClassifier is owned by the Association.
    And there is no redefinition (or subsetting) between the two.

    Note that Figure 9.2 of ptc/06-04-02 does show a redefinition - but of "_structuredClassifier" with an underscore (not sure what that is supposed to mean).

    Proposed resolution:

    The Property::class property should be owned by the association (but still be navigable), and a redefinition needs to be added in section 9.3.12

    {redefines structuredClassifier}

    .

    Add Property::classifier as a derived union and have all opposites of ?::ownedAttribute subset it.
    This way, access to a property's (owning) classifier can be obtained uniformly - note that a number of the OCL expressions are currently written (incorrectly) with this assumption.

  • Reported: UML 2.0 — Wed, 26 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

navigating from link to link ends

  • Key: UML22-256
  • Legacy Issue Number: 9961
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    It is not possible to navigate from link to connected instances if slots are not created or Association is not assigned as type.
    Is it possible to create slots in instance of Association even if properties are owned in connected Classes? Are they required? Are they for navigating?

  • Reported: UML 2.0 — Tue, 25 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    An InstanceSpecification can have slots for a Classifier corresponding to any of the members that are StructuralFeatures.
    This is deducable from the OCL but not at all clear in the text.
    See also the resolution to 18177 which allows slots to be created for private members and clarifies further
    which features are slottable.
    This also resolves 12912.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExtensionEnd description refers to old use of navigability

  • Key: UML22-255
  • Legacy Issue Number: 9891
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    18.3.3 second paragraph of description uses the old definition of navigability as implying property ownership

  • Reported: UML 2.0 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.10.3

  • Key: UML22-260
  • Legacy Issue Number: 10005
  • Status: closed  
  • Source: ISP ( Leonid Dvoryansky)
  • Summary:

    Wrong definition of value association: value : InstanceSpecification [*] should be: value : ValueSpecification [*]

  • Reported: UML 2.0 — Fri, 28 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This appears to have been fixedin Superstructure, The text “value: InstanceSpecification” does not appear in the specification. The property value is typed by ValueSpecification in Superstructure.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.13

  • Key: UML22-259
  • Legacy Issue Number: 10004
  • Status: closed  
  • Source: ISP ( Leonid Dvoryansky)
  • Summary:

    MultiplicityElement is derived from itself

  • Reported: UML 2.0 — Thu, 27 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15

  • Key: UML22-285
  • Legacy Issue Number: 10498
  • Status: closed  
  • Source: Université de Mons-Hainaut ( Alessandro Folli)
  • Summary:

    The subject of my thesis is "UML MODEL REFACTORING USING GRAPH TRANSFORMATION" and I'm trying to represent UML models using graphs. I have read the "UML 2.0 Superstructure Specification" document and I can't exactly understand which is the region the transitions belong to. On page 553 it defines the container association as "Designates the region that owns this transition.". On page 529 it defines the transition association as "The set of transitions owned by the region. Note that internal transitions are owned by a region, but applies to the source state." I have taken a look to the previous UML specification version. Regions were not present and it defined the relationship between StateMachine and Transition as "Associates the StateMachine with its Transitions. Note that internal Transitions are owned by the State and not by the StateMachine. All other Transitions which are essentially relationships between States are owned by the StateMachine. Multiplicity is '0..*'. " Is it correct if I suppose that all the transitions, excluded internal transitions, are contained by the top-level region? Thank you.

  • Reported: UML 2.0 — Thu, 30 Nov 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The owner of a transition does not imply any semantics; therefore a specific owner will not be defined. It is suggested that the LCA of the source and target is used, but it can really be any region that is directly or indirectly owned by the state machine context.
    This resolution also affects the constraint on internal transitions sourcing a composite state. Because the internal transition can be owned by any region (and not necessarily a region that belongs to the source state) the restriction that a state must be composite to have internal transitions is unnecessary. Therefore this needs to be corrected as well.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.10

  • Key: UML22-291
  • Legacy Issue Number: 10530
  • Status: closed  
  • Source: Hitachi INS Sosftware ( Toru Arakaki)
  • Summary:

    Old name, "ExecutionOccurences", of "ExecutionSpecification" is still used in the document. Line 14 of the page 465: "ExecutionOccurences are represented ..." Line 22 of the page 465: "Overlapping execution occurrences on the same lifeline ..." Description of Figure 14.15 of the page 465: "Overlapping execution occurrences" Line 18 of the page 463: "An ExecutionEvent models the start or finish of an execution occurrence."

  • Reported: UML 2.0 — Tue, 19 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.14

  • Key: UML22-290
  • Legacy Issue Number: 10529
  • Status: closed  
  • Source: Hitachi INS Software ( Toru Arakaki)
  • Summary:

    The Notation of the InteractionConstraint is incorrect. A character after "Boolean-expression" should be > not ’. AS-IS: <interactionconstraint> ::= [‘[‘ (<Boolean-expression’ | ‘else‘) ‘]’] TO-BE: <interactionconstraint> ::= [‘[‘ (<Boolean-expression> | ‘else‘) ‘]’]

  • Reported: UML 2.0 — Tue, 19 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 9598 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: e. g. 12.2. page 287

  • Key: UML22-296
  • Legacy Issue Number: 10594
  • Status: closed  
  • Source: Jens Kuttig - Computer und Medien ( Jens Kuttig)
  • Summary:

    Some elements are black outlined with a white background, some are red outlined with yellow background. Some edges are black, some are red, some are purple. What does the diffrent colors in the diagramms mean? I cannot find any explanation within the document.

  • Reported: UML 2.0 — Mon, 15 Jan 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

assembly connectors

  • Key: UML22-201
  • Legacy Issue Number: 9578
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Chapter 8.3.2
    An assembly connector is a connector between two components that defines

    that one component provides the services that another component
    requires. An
    assembly connector is a connector that is defined from a required
    interface
    or port to a provided interface or port.

    All constraints are using terms "connector between Interface and Port"
    also.
    I suggest to change or remove this misleading text.

    Agreed. This text is highly misleading in a number of ways:

    (1) It suggests that connectors connect components. They actually connect
    parts typed by components.

    (2) It suggests that connectors connect interfaces – which they do not
    (because only connectable elements can be connected and interfaces are not
    connectable elements).

  • Reported: UML 2.0 — Thu, 20 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This complaint is handled by other resolutions, primarily 8900 and 9464.

    Revised Text:
    None.
    Disposition: Duplicate of 8900 and 9464.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

New Issue on multiple guillemot pairs for same element

  • Key: UML22-200
  • Legacy Issue Number: 9577
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Section 18.3.8 has the following paragraph:

    Presentation Options 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 listing them after each other. A tool can choose whether it
    will
    display stereotypes or not. In particular, some tools can choose not to
    display
    “required stereotypes,” but to display only their attributes (tagged
    values) if
    any.

    Annex B has the following paragraph:

    If multiple keywords and/or stereotype names apply to the same model element,
    they all appear between the same pair of guillemets, separated by commas:
    “«” <label> [“,” <label>]* “»”

    These two paragraphs seem to contradict each other, since the annex B does
    not
    allow multiple guillemet pairs for the same element, while 18.3.8 does.

    Proposed Solution:
    Add clarification that Both presentation options should be allowed.

  • Reported: UML 2.0 — Wed, 19 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

11.3.26 OpaqueAction

  • Key: UML22-210
  • Legacy Issue Number: 9710
  • Status: closed  
  • Source: IBM ( Brent Nicolle)
  • Summary:

    11.3.26 OpaqueAction states it has a Generalization: "Pin (from BasicActions) on page 256." This doesn't make sense; pins and actions are very different things. I think figure 11.2 shows the intended Generalization: "Action (from BasicActions) on page 230."

  • Reported: UML 2.0 — Fri, 12 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This was editorially resolved in UML 2.2.
    Revised Text:
    None.
    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of stereotype placement requires a name

  • Key: UML22-209
  • Legacy Issue Number: 9706
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 18.3.8, Notation states: "When a stereotype is applied to a model element (an instance of a stereotype is linked to an instance of a metaclass), the name of the stereotype is shown within a pair of guillemets above or before the name of the model element."
    This is too specific and does not state how to notate an element which is unnamed (which could be addressed by referring to where the name would be) or has no name property defined: for example Comment (here a more creative approach is needed).

  • Reported: UML 2.0 — Thu, 4 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

the default for a Property should not be inconsistent with its type

  • Key: UML22-206
  • Legacy Issue Number: 9622
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There should be a constraint on Property that the ValueSpecification used for its default should not conflict with its type.
    In some cases, for example if an OpaqueExpression is used, then the type of the value cannot be determined. However if it can then it should not be inconsistent.
    This would, for example require the default for a Integer-typed Property to be an instance of LiteralInteger and not LiteralString or any other LiteralX.

  • Reported: UML 2.0 — Tue, 2 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

packagedElement

  • Key: UML22-204
  • Legacy Issue Number: 9605
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In 06-01-02, I note that in Fig 7.14, packagedElement is not marked as derived but in section 7.3.37 it is – can you clarify which it is?

  • Reported: UML 2.0 — Mon, 24 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ptc/06-01-02:14.3.14, Notation

  • Key: UML22-203
  • Legacy Issue Number: 9598
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The following notation expression isn’t well formed:

    <interactionconstraint> ::= [‘[‘ (<Boolean-expression’ | ‘else‘) ‘]’]

  • Reported: UML 2.0 — Mon, 24 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML's support for null values and semantics is unclear

  • Key: UML22-207
  • Legacy Issue Number: 9700
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    UML's support for null values and semantics is unclear.
    For example if a Property is defined [1..1] then is a value of null (represented by LiteralNull) permitted? (LiteralNull is defined as "LiteralNull is intended to be used to explicitly model the lack of a value.")
    Can null values be used to create a sparse array? If not how is a fixed length sparse array to be modeled?
    Can a unique multivalued property contain multiple nulls?
    How do the StructuralFeatureActions react in the presence of null?
    [Note that the issue is NOT related to the "null token"]

  • Reported: UML 2.0 — Thu, 4 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2/ Super / SendSignalEvent erratum

  • Key: UML22-211
  • Legacy Issue Number: 9718
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A minor issue I stumbled over in UML Superstructure ptc/06-04-02.

    SendSignalEvent [14.3.28] specialises MessageEvent [13.3.18], which
    "specifies the RECEIPT ..." Perhaps that should be reworded?

  • Reported: UML 2.0 — Sat, 13 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Question on InfrastrucutreLibrary::BehavioralFeatures::Parameter

  • Key: UML22-199
  • Legacy Issue Number: 9556
  • Status: closed  
  • Source: Dell Technologies ( Mr. George Ericson)
  • Summary:

    In Infrastructures, since TypedElements::TypedElement is subclassed from Namespaces::NamedElement, is it necessary that BehavioralFeatures::Parameter be subclassed from both TypedElements::TypedElement and Namespaces::NamedElement?

  • Reported: UML 2.0 — Mon, 10 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"Property::lowerValue" is not a good name

  • Key: UML22-208
  • Legacy Issue Number: 9704
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    It could easily be taken to mean a constraint on the value not the multiplicity, e.g. for an 'temperature' property, that its value is not allowed to be below -273. Would be better named "lowerBoundValue" or similar.

  • Reported: UML 2.0 — Thu, 4 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fig 7.14

  • Key: UML22-202
  • Legacy Issue Number: 9597
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In 06-01-02, I note that in Fig 7.14, packagedElement is not marked as derived but in section 7.3.37 it is – can you clarify which it is?

  • Reported: UML 2.0 — Mon, 24 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5

  • Key: UML22-275
  • Legacy Issue Number: 10347
  • Status: closed  
  • Source: CNAM ( Jean-Frederic Etienne)
  • Summary:

    Is it possible in UML 2.0 specification to define a formal template parameter, for which the actual parameter to be given during parameter substitution is not a classifier but an instance of a specific classifier (more precisely, an instance of a specific class). If this is possible, what should be the type of the parameterable element exposed by the formal template parameter?? Does it have to be of type InstanceSpecification (or even ValueSpecification) to indicate that we are expecting an Object as actual parameter?? Moreover, what should be the type of the parameterable element to be exposed as actual parameter to indicate that we are providing a specific instance or value?? Finally what should be the proper notation for such template parameter to make the distinction with classifier template parameter??

  • Reported: UML 2.0 — Fri, 15 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    InstanceSpecification is not a ParameterableElement, so it cannot be used as a TemplateParameter. Providing a specific instance to a part would be done by assignment, not template bindings. See WriteStructuralFeatureAction.
    Revised Text:
    Disposition: Closed, no Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity shape

  • Key: UML22-283
  • Legacy Issue Number: 10388
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    would like to shed some light on Activity notation (symbol) as such (Figure 12.33 in ptc/2006-04-02).
    Is it just alternative notation of Activity Diagram Frame or this symbol is intended to use in Activity diagrams as sub parts of other Activity?

  • Reported: UML 2.0 — Wed, 12 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

text of specs and corresponding XMI specs should be clarified

  • Key: UML22-235
  • Legacy Issue Number: 9833
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The relationship between the text of the specs and the corresponding XMI specifications should be clarified to explicitly state that, in cases of disagreement between the text and the XMI, the latter takes precedence.

  • Reported: UML 2.0 — Thu, 22 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Put a paragraph into clause 2 to clarify this

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2: "isLeaf"

  • Key: UML22-234
  • Legacy Issue Number: 9831
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The "isLeaf" attribute of Class implies that there cannot be any subclasses of a class, but there is no corresponding OCL constraint that enforces that.

    Also, "isLeaf" is only defined in the Superstructure and not in the Infrastructure – should it be defined in the Infrastructure as well?

  • Reported: UML 2.0 — Tue, 20 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The meaning of the 'isLeaf' attribute changed from UML 1.x to UML 2.x
    In UML 1.5 (formal/03-03-01), 'isLeaf' is a property defined in two contexts:

    • In GeneralizableElement (see 2.5.2.23) where it "specifies whether the GeneralizableElement is a GeneralizableElement with no descendents. True indicates that it may not have descendents, false indicates that it may have descendents (whether or not it actuallyhas any descendents at the moment)"
      The fact that the UML 1.5 concept of a leaf in a generalization hierarchy has no equivalent in UML 2.2 has been raised as a separate issue from this - see issue 10515.
    • In Operation (2.5.2.30) where "if true, then the implementation of the operation may not be overriden by a descendant class. If false, then the implementation of the operation may be overridden by a descendant class (but it need not be overridden)."
      The UML 1.5 concept of a non-overridable operation corresponds to the UML 2.2 of RedefinableElement::isLeaf (see 7.3.46)
      The second part of this issue, i.e., whether the UML 2.2 infrastructure (formal/09-02-04) needs a capability for modeling a specialization leaf in a redefinition hierarchy is a strategic issue out of scope for the UML2 RTF.
      See resolution to issue 12532 for the OCL constraint enforcing the meaning of isLeaf in the context of redefinitions.
      Disposition: Closed No Change
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.14 Transition

  • Key: UML22-227
  • Legacy Issue Number: 9824
  • Status: closed  
  • Source: Paranor AG ( Earl Waldin)
  • Summary:

    In section 15.3.14, Transition, subsection Constraints you will find the following constraint: [6] An initial transition at the topmost level (region of a statemachine) either has no trigger or it has a trigger with the stereotype “create”. ... OCL body for constraint ... The element to be stereotyped in this constraint is a Trigger. If you look in Appendix C: Standard Stereotypes you will not find this stereotype. It appears that this constraint is left over from UML1.4/1.5. In UML 1.4 the corresponding stereotyped element in this constraint was an Event. In particular it was a CallEvent. The corresponding <<create>> stereotype is listed in Appendix C as a retired stereotype. So, either the constraint should be deleted or the stereotype must be brought out of retirement.

  • Reported: UML 2.0 — Wed, 14 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 7.4 invalid redefines

  • Key: UML22-238
  • Legacy Issue Number: 9843
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This contains an unnamed property that

    {redefines _namespace}

    . There is
    no property _namespace and the redefining property should be should be
    named.
    In Infra there is no such redefinition in Figure 11.21- is it actually
    needed?

  • Reported: UML 2.0 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EnumerationLiteral should constrain InstanceSpecification

  • Key: UML22-237
  • Legacy Issue Number: 9841
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    EnumerationLiteral currently inherits from InstanceSpecification.
    However it does not make sense for it to have all the capabilities of
    the latter, for example Slots.
    Therefore a constraint should be added to EnumerationLiteral as follows:
    slot.isEmpty
    Furthermore it does not make sense for EnumerationLiteral to have a
    separate classifier than its Enumeration. So the following redefinition
    should be added:
    enumeration

    {redefines classifier}

    (alternatively if this is felt too complex there should be a constraint
    {classifier.isEmpty)

    Another option would be for EnumerationLiteral to inherit from
    ValueSpecification - as suggested by the name of the class (other
    Literal classes are subtypes of ValueSpecification). However this would
    probably be too major a change to justify the benefit.

  • Reported: UML 2.0 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Stereotype attributes inherited from Class

  • Key: UML22-233
  • Legacy Issue Number: 9830
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    What is the interpretation of the various atttributes that Stereotype inherits from Class, such as "isLeaf" and "isAbstract"? Do they mean the same thing, or are they inapplicable, or subtly different?

  • Reported: UML 2.0 — Tue, 20 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 11.4.1 "Classifier" (in Constructs)

  • Key: UML22-231
  • Legacy Issue Number: 9828
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The description says: "Constructs::Classifier merges the definitions of Classifier from Basic and Abstractions."
    a) The "Abstractions"package is not supposed to be merged by Constructs.
    b) There is no Basic::Classifier, so this reference is probably in error. There is Basic::Class, though.

  • Reported: UML 2.0 — Fri, 16 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation (p 154, formal/05-07-04 )

  • Key: UML22-228
  • Legacy Issue Number: 9825
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I observed some minor errors on Document formal/05-07-04 while reading it, but
    there is an aparent inconsistence that must be checked. I will explain it
    below.

    On page 154 we can read:
    "Notation
    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 on page 125 we can read:
    "A Realization dependency is shown as a dashed line with a triangular arrowhead
    at the end that corresponds to the realized element."

    It's clear that the error is on page 154 definition

  • Reported: UML 2.0 — Tue, 13 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 11.4.1 "Classifier" (in Constructs)

  • Key: UML22-230
  • Legacy Issue Number: 9827
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The association "feature" is not marked as a derived element, but probably should be.

  • Reported: UML 2.0 — Fri, 16 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 10.2.1 "Class" (in Basic)

  • Key: UML22-229
  • Legacy Issue Number: 9826
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    "ownedAttribute", "ownedOperation" and "superClass" are listed as attributes, but they probably should be listed as associations

  • Reported: UML 2.0 — Fri, 16 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.7

  • Key: UML22-192
  • Legacy Issue Number: 9375
  • Status: closed  
  • Source: Paranor AG ( Earl Waldin)
  • Summary:

    Incorrect specification of association Class::nestedClassifier. The specification of the association Class::nestedClassifier, section 7.3.7, page 46 states that it subsets Element::ownedMember. The Class Element does not have an association ownedMember. Element does have an association ownedElement, but that is not likely correct because a nested classifier is really a namedElement. Most likely, Class::nestedClassifier should subset Namespace::ownedMember.

  • Reported: UML 2.0 — Thu, 23 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 10829 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AssociationClass is severely underspecified

  • Key: UML22-191
  • Legacy Issue Number: 9374
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    It is not at all clear which Properties will result on both the AssociationClass and the end Classes. The Semantics section of 7.3.4 says nothing more specific than "The semantics of an association class is a combination of the semantics of an ordinary association and of a class." - without saying anything about how they are combined. neither is there any indication as to how to access the attributes of the AssociationClass.
    One specific issue is that the composition property is inherited twice: ownedEnd and ownedAttribute - with no redefinition or subsets relationship between them.
    Neither is anything said about the effect of navigability.

    Proposed resolution:

    AssociationClass should redefine ownedNavigableEnd

    In the example in 7.3.4 the following properties will result. C: indicates here that C owns P via the Class:ownedAttribute property. In this case both ends are owned by the class not the association (though the absence of dots at the line ends would imply otherwise - the example should be redrawn).
    Several extra properties are implied by the diagram and have to be implicitly created by the tool. These are marked !! below.

    Person::company: Company[1..*] association=Job
    !!Person::job: Job[1..*] // This then allows access to the properties of Job such as Salary. Note that Person::job.association isEmpty

    Company::person: Person[*] association=Job
    !!Company::job: Job[*]

    Job::salary: Integer[1]
    !!Job::person: Person[1]
    !!Job::company: Company[1]
    Job.memberEnd=(Person::company, Company::person)
    Job.ownedEnd->isEmpty=true

    There needs to be a discussion and clear rules for the invented names for the new properties and constraints to avoid clashes. Also need to address issues related to unions/subsets/redefines/navigability and their effect on the implicit properties.

    Also there is a complication if the Association class itself has further associations: how in the metamodel are these Properties on t he AssociationClass distinguished from the 'main' Ends representing the line to which the AC is attached.

  • Reported: UML 2.0 — Thu, 23 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    For explanations, see "Changes from previous UML" below. The OCL in this resolution is written according to OCL 2.1 ptc-09-05-02. Where the changes in the revised text pertain to metaclasses in the superstructure merged from InfrastructureLibrary::Core::Constructs which is the resulting package of merging several package increments from InfrastructureLibrary::Core::Abstractions as specified in clause 11.2 of the UML 2.2 Infrastructure, then the revisions described below have to be similarly reflected in InfrastructureLibrary::Core::Constructs (i.e. the resulting metaclass) and in the metaclass increments merged from the sub-packages of InfrastructureLibrary::Core::Abstractions.
    The revised text clarifies that owned ends of an association class, as an association, are disjoint from owned attributes of that same association class.. Navigability for association classes is the same as associations. Navigation from instances of association classes to their end objects, and any other unaddressed aspects of the issue, will be refiled as a separate issue.
    This resolution includes an OCL constraint which depends on the OCL 2.1 revision:
    context AssociationClass
    self.A_general_classifier::classifier
    ->forAll(oclIsKindOf(AssociationClass))
    The meaning of this constraint is as follows:
    self.A_general_classifier::classifier
    This expression navigates the association A_general_classifier in the inverse direction of the navigability of the property /Classifier::general : Classifier[*].
    That is, it provides the set of classifiers that specialize 'self'.
    See 7.5.3 (Properties: AssociationEnds and Navigability), p. 18-19 in OCL 2.1 http://www.omg.org/cgi-bin/doc?ptc/09-05-02

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Show an example of correct notation for the metamodel

  • Key: UML22-190
  • Legacy Issue Number: 9372
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Though section 6.5.2 explains and justifies the convention (in the UML2 spec only) for use of navigability arrows to represent property ownership, it would be worth showing a non-normative example of one of the metamodel diagrams with the correct 'dot at line end' notation used. This depends on the resolution to issue A) above.

    C) Use the new 'dot' notation in examples
    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.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Optional name attribute in NamedElement is misleading and insufficient

  • Key: UML22-184
  • Legacy Issue Number: 9256
  • Status: closed  
  • Source: Borland Software Corporation ( Stephen Palmer)
  • Summary:

    find it very unintuitive that the name attribute of a NamedElement is optional and If specified may be any valid string, including the empty string. A more accurate name for an element that has the capacity to have a name but does not necessarily have one would be, NameableElement instead of the misleading NamedElement.
    However, elements that do not have a name (or that have a name comprising solely of the empty string or white space characters) have no means through which a human can precisely reference them other than through their physical location on a diagram. This leaves open an opportunity for ambiguity in referencing elements and possible mis-communication. For this reason, the name attribute of NamedElement should be required, should not be allowed to contain just the empty string or just white space characters and should be unique within the element's package. In practise, even an artificially generated name for an element is preferable to no name at all.

    The question of whether the name of an element should be displayed on a particular diagram is a completely different subject and should, in general, be a decision made on a case-by-case basis by the modeller. However, even when the name is not displayed on a diagram, requiring elements to have a readable name provides tool-makers with opportunities to show the name of the element in tool tips, status bars, model navigation panes, etc so that the element can still be readily identified and precisely distinguished from others by human users of the model.

    It is very common in many organizations to have both a short name for an element and a longer more descriptive name for an element. For example, a use case may have the short name UC-OP0001 and a longer name 'Place Order'. The current NamedElement has no provision for such a scheme. In practise, it would be frequently very useful NamedElements had an optional longer name as well as a required short name attribute. Whether the short or long name (when provided) are used on a particular diagram or in any other context is again a matter for the modeller and tool-makers.

  • Reported: UML 2.0 — Fri, 20 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The use of NamedElements with no names is well established in a number of cases in UML. Tools can provide all the
    advantages described by the issue author if the modeler gives a NamedElement a name, but it is more convenient to
    allow the modeler the choice of whether to do that.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Components / connectors to interfaces

  • Key: UML22-197
  • Legacy Issue Number: 9464
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In chapter 8 there are several references that indicate that a connector can be drawn between two or more interfaces. This is not possible, since an interface is not a connectable element.

  • Reported: UML 2.0 — Tue, 21 Mar 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Indeed so. The revised text below corrects this.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

reference to Figure 12.87 missing

  • Key: UML22-187
  • Legacy Issue Number: 9341
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Last para on p385 starts: "Figure 12.86 shows a fragment of a Fast Fourier Transform (FFT) computation containing an expansion region. Outside the region, there are operations" - the reference should be to Figure 12.87

  • Reported: UML 2.0 — Tue, 24 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.4

  • Key: UML22-186
  • Legacy Issue Number: 9340
  • Status: closed  
  • Source: Digital River ( Mark Mendel)
  • Summary:

    The comment in figure 14.2 in the top right cell identifies the last message as a reply, but it is in fact a creation message. See 14.3.20 Message, Notation, pg. 478: Synchronous Messages typically represent method calls and are shown with a filled arrow head. The reply message from a method has a dashed line. Object creation Message has a dashed line with an open arrow.

  • Reported: UML 2.0 — Tue, 31 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The only indication of the notation for reply messages in 2.4.1 was table 14.2 and some examples, all of
    which showed a dashed line with open arrowhead. So we assume this was normative even though it was not
    very explicit.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No ObjectEvent corresponding to SendObjectAction

  • Key: UML22-194
  • Legacy Issue Number: 9403
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    SendObjectAction sends the object on its request InputPin the object at its target InputPin.

    AcceptEventAction can have a trigger that is a SignalEvent or CallEvent, but there is no Event type for ObjectEvent to represent the receipt of an object from a SendObjectAction. SignalEvent cannot be the trigger because it is not a Class and is not general enough.

  • Reported: UML 2.0 — Tue, 28 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. The UML 2.5 specification, in subclause 16.3.3, under “Send Actions”, now includes the
    following text in the description of the semantics of SendObjectAction: “If the object [sent by the action] is a Signal
    instance, then it may be handled by the target object in the same way as an instance sent from a SendSignalAction
    or BroadcastSignalAction. Otherwise, the reception of the object can only be handled using an AnyReceiveEvent (as
    described under Message Events in sub clause 13.3.3).”
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fig 12.10

  • Key: UML22-193
  • Legacy Issue Number: 9395
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Fig 12.10 shows Activity.partition with multiplicity 1 but the text on page 329 shows [0..*].I suspect that the former is correct.

  • Reported: UML 2.0 — Thu, 23 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This was resolved in the final resolution of issue 8208 in UML 2.1. (It was actually 0..* that was correct.)
    Revised Text:
    None
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.1/Superstructure/ call triggers vs signal triggers

  • Key: UML22-188
  • Legacy Issue Number: 9351
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    P. 603 makes reference to "CallTriggers" and "SignalTriggers". I believe the wording on that whole paragraph under "Example" should be changed slightly.
    P. 246 makes reference to "SignalTrigger"
    P. 453 makes reference to "call trigger" ( I believe the wording should be modified slightly. )

  • Reported: UML 2.0 — Wed, 1 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

UML 2.2 RTF issue - line styles for profiles

  • Key: UML22-198
  • Legacy Issue Number: 9513
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    UML stereotypes can have an associated icon. For shapes there are 2 options for applying the icon: display the icon in the top right of the standard UML shape, or completely replace the standard shape with the icon.
    However for lines there is only the option of displaying the icon 'near' the standard UML representation of the line. This is somewhat clunky at best and limits the flexibility of profiles.

    The equivalent of using the icon to replace the original UML shape would be to allow the specification of a new line style: the icon could be used to represent both ends and the middle - and the tool would repeat the middle section in order to create an actual line.

  • Reported: UML 2.0 — Wed, 5 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Composite Structure / ambiguous constraint

  • Key: UML22-195
  • Legacy Issue Number: 9413
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There is a constraint on page 159.:

    [5] An assembly connector must only be defined from a required Interface or Ports to a provided Interface or Port.

    The wording is quite unclear. Interfaces are not by themselves required or provided but relative to a port or a classifier. Also, it implies that it should be possible to draw a connector from an Interface to a Port. This constraint needs to be clarified and made more precise.

  • Reported: UML 2.0 — Wed, 8 Mar 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This is a duplicate of 7251

    Revised Text:
    None.

    Disposition: Duplicate of 7251

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.12

  • Key: UML22-132
  • Legacy Issue Number: 8890
  • Status: closed  
  • Source: IBM ( Jaroslav Gergic)
  • Summary:

    The UML 2.0 Specification states at 15.1 that "The state machine formalism described in this section is an object-based variant of Harel statecharts." However, there is a big semantical discrepancy between the Harel statecharts as described in D. Harel and M. Politi, Modeling Reactive Systems with Statecharts: The STATEMATE Approach, (with M. Politi), McGraw-Hill, 1998 and the UML 2.0 specification. The major difference is in the priority of transitions when multiple transitions are enabled in case of a nested (hierarchical) state machine. Harel states (6.3.1 (pages 99-100)): "The criterion for priority of transitions prefers the transition whose source and target have a higher common ancestor state, if possible. If the common ancestors of both transitions are identical, then non-determinism indeed occurs." (i.e. it prefers global, higher-level transitions over local ones) UML 2.0 (15.3.12 page 618) imposes almost a reveres-ed order on the priority of the transitions, by looking up from the current nested leaf state and taking the first enabled transition. The impact of the UML definition is that the author can not only "refine" a high-level state in its descendants, he/she can override the global transitions thus violating the global (high-level) contract of the state machine. This becomes even more dangerous when using submachine state, i.e. the nested state is actually drawn in a separate diagram. Example: imagine an electrical device, which can be in one of 2 top-level states: ON, OFF and having two transitions power_on, power_off. The ON state can have multiple sub-states describing a particular state of the operation. Using the UML 2.0 semantics, one can effectively override the global power_off transition locally in on of the ON's children, forcing the electrical device to keep working, even if the power has been shut down - ignoring the signal using e.g. a self-transition.

  • Reported: UML 2.0 — Wed, 29 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    To avoid confusion, add a clarification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.5.1 DataType (as specialized)

  • Key: UML22-131
  • Legacy Issue Number: 8889
  • Status: closed  
  • Source: University of Kassel, Germany ( Thomas Weise)
  • Summary:

    In section 11.5.1 DataType (as specialized) you write "• ownedAttribute: Attribute[*] The Attributes owned by the DataType. Subsets Classifier::attribute and Element::ownedMember." The type "Attribute" does not exist. You mean Property, which is also shown correctly in the diagramm at page 133

  • Reported: UML 2.0 — Wed, 29 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

event parameters

  • Key: UML22-141
  • Legacy Issue Number: 8936
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Event was able to own set of parameters in UML 1.4 .

    "Any parameter values associated with the current event are available to all actions directly caused by that event
    (transition actions, entry actions, etc.)."

    In UML 2.0 Parameters are removed from Event metaclass, but in chapter "Changes from UML 1.x" there is no comment about that ("None").

    Could you please comment how Parameters from UML 1.4 Event should be mapped into UML 2.0 model?

    I see a big problem, because some MDA tools (like AndroMDA) are based on information stored in Event parameters, hundreds of users have lot of projects, they can't be lost on migration.

  • Reported: UML 2.0 — Thu, 21 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. Tools have long since adapted to this change in UML 2.0 and the UML 2.5 specification no
    longer lists “changes from UML 1.x”.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.13 TypedElement (as specialized)

  • Key: UML22-130
  • Legacy Issue Number: 8888
  • Status: closed  
  • Source: University of Kassel, Germany ( Thomas Weise)
  • Summary:

    In section 11.3.13 TypedElement (as specialized) you write: Attributes • type: Classifier[1] Redefines the corresponding attributes in both Basic and Abstractions. Neither has InfrastructureLibrary::Core::Abstractions::TypedElements::TypedElement such a property, nor does InfrastructureLibrary::Core::Basic::Type::TypedElement, even through inheritance.

  • Reported: UML 2.0 — Wed, 29 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.6 Classifiers diagram

  • Key: UML22-129
  • Legacy Issue Number: 8887
  • Status: closed  
  • Source: University of Kassel, Germany ( Thomas Weise)
  • Summary:

    Issue for: UML 2.0 Infrastructure Specification Section: 11.3.6 Classifiers diagram Document: ptc/03-09-15 URL: http://www.omg.org/cgi-bin/doc?ptc/2003-09-15 Pages: 90,91,95,96,127,130 With this submission I report an serious error in your specification. On Page 127, Section 11.3.6 Classifiers diagram, you show that the type InfrastructureLibrary::Core::Constructs::TypedElement is a generalization of both, InfrastructureLibrary::Core::Abstractions::TypedElements::TypedElement (section 9.19.2, page 91) and InfrastructureLibrary::Core::Basic::TypedElement (section 10.1.3, page 96). This leads to a collission of properties, since both of these defined a property called "type", where the one is of the sort InfrastructureLibrary::Core::Abstractions::TypedElements::Type (section 9.19.1, page 90) and the other is of the sort InfrastructureLibrary::Core::Basic::Type (section 10.1.1, page 95). Both Type-types are incompatible, since none is a generalization of the other. Please help and clarify, because I want to implement your standard for a project and cannot proceed correctly. Thanks, Thomas Weise. tweise@gmx.de University of Kassel Germany

  • Reported: UML 2.0 — Wed, 29 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Page: 62

  • Key: UML22-139
  • Legacy Issue Number: 8920
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    Description

    Figure 36 was not changed to conform to example description. Here, the example indicates that “the dependency is an instantiate dependency, where the Car class is an instance of the Vehicle Type class. However, Fig. 36 illustrates that Car class is an instance of the CarFactory class

    The page indicates issue 6159 addressed this same problem, but apparently it went unchanged.

  • Reported: UML 2.0 — Tue, 5 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Page: 129

  • Key: UML22-125
  • Legacy Issue Number: 8877
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    BNF for property notation states that the name of the property is mandatory. There is no appropriate constraint for that. If it is mandatory there are some wrong diagrams in the specification, e.g. Fig 334.

  • Reported: UML 2.0 — Thu, 23 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Not exactly. The BNF states that the <name> terminal is mandatory. Clarify in the text that where there is
    no property, <name> is empty.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 369/370

  • Key: UML22-124
  • Legacy Issue Number: 8876
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The notation for activity partition allows to notate the specification of the dimension next to the appropriate dimension set. Dimension is a boolean property of an ActivityPartition. It is not clear where the specification of a dimension is stored in the model.

  • Reported: UML 2.0 — Thu, 23 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    An ActivityPartition with isDimension = true is the specification of the dimension, and the partions contained within it are the partitions in that dimension. The dimension name in the notation is the name of an ActivityPartition with isDimension = true. This can be clarified in the text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 157,162,163

  • Key: UML22-136
  • Legacy Issue Number: 8900
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Fig. 87, fig. 92, and fig.93 show composite structure diagrams with interfaces. For example fig 87; delegation connector from port to interface OrderEntry. How can a connector be linked to an interface?

  • Reported: UML 2.0 — Thu, 30 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Figure 87 is now 8.12. Figure 92 is now 8.17. Figure 93 is now 8.18. I include figure 8.15 in this resolution to get a consistent overall picture.
    The solution is to allow connector lines to connect lollipops and sockets, and ball and socket notation, only when the interfaces are on a simple port. Then the connectors become a notational shorthand for actually connecting to the ports.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

9.1 BehavioralFeature package

  • Key: UML22-127
  • Legacy Issue Number: 8880
  • Status: closed  
  • Source: University of Kassel, Germany ( Thomas Weise)
  • Summary:

    The element "Parameter" is shown to generalize both, TypedElement and NamedElement. However, TypedElement is already a generalization of NamedElement (see chapter 9.19). Thus, the second generalization is redundant and can be removed.

  • Reported: UML 2.0 — Mon, 27 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Page: 532

  • Key: UML22-126
  • Legacy Issue Number: 8878
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Associations section: Type of argument is InputPin. In fig. 333 the type is Action

  • Reported: UML 2.0 — Thu, 23 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This seems to refer to the argument association of InteractionUse, as of the UML 2.0 Draft Adopted Specification (ptc-04-10-02). It was corrected as an editorial change in UML 2.1.
    Revised Text:
    None
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 423

  • Key: UML22-133
  • Legacy Issue Number: 8891
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Second constraint of ObjectNode refers to property isUnique. ObjectNode has no such property. It's not a specialized MultiplicityElement

  • Reported: UML 2.0 — Wed, 29 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    this is correct

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: D.4

  • Key: UML22-92
  • Legacy Issue Number: 8616
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In Description for CCMService, either add the ending or remove the opening quotation mark for the last word. The stereotype name for CCMProcess is not the same as that within the guillemets. Complete the Tag cell in CCMHome. Complete the Tag cell in CCMManages. Capitalize and correct spelling of "Always in the Constraints cell of CCMManages. The Description for CCMFactory really doesn't make a lot of sense to me but I'm not at all familiar with CCM Components. However the stereotype name doesn't relate to a create function for me.

  • Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.8 (second issue)

  • Key: UML22-91
  • Legacy Issue Number: 8612
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    "Entry actions of states entered on the path to the state represented by a deep history are performed." It's open which path is taken if there are more than one paths to the state.

  • Reported: UML 2.0 — Sat, 19 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The word 'Path' has raised ambiguity with respect to how the history state will restore the active state configuration. There is only one way that the history will restore the active state, and that is through an implicit direct path from the history state to the innermost active states being reactivated (almost as though a transition is drawn directly from H* to the last active state). It in no way implies a state-by-state approach. (e.g. a path from the initial state to the last active state)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.3.6

  • Key: UML22-90
  • Legacy Issue Number: 8601
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    ypos - Opening "(" dont agree with ")" for either constraint. Clarify the illustration of the first approach (examples in Fig. 450 and 451). It is still confusing. Typo - Under "Using XMI to exchange Profiles" last sentence of first para on pg 724, change "purpose" to "purposes." Last sentence on pg 726, change "and need to be...." to "and these constraints need to be..."

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It is unclear what approaches are being referred to in the second sentence. There are no figures 450 and 451.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17

  • Key: UML22-89
  • Legacy Issue Number: 8594
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraints or a note that OCL notation is not available for this constraint. In the figures show all sub-package names or ellipses associated with the direct generalizations. Use of the words subclass and subclasses is often confusing and inappropriate as these are not shown in associated figures or mentioned in text. Whenever subclasses are mentioned, please clarify by giving examples as was done on page 690. Orgainzation of this Part is confusing after becomming accustomed to the organization used in parts I and II. Placement of all abstract syntax figures in one place helps clarify relationships of figures to each other and makes it easier to see/verify consistency. Names of classifiers and packages in the text often don't agree with the names shown on associated figure.

  • Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1

  • Key: UML22-102
  • Legacy Issue Number: 8705
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Notation section of component states that the relationship between realizing classifiers and the component is displayed by general dependencies. The specialized Realization states that it's notation is similar to the realization dependency. Change fig. 85: Replace dependency arrows by realization arrows (with triangular arrowhead).

  • Reported: UML 2.0 — Thu, 28 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    see page 50 of ptc/2009-09-07 for details

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.36

  • Key: UML22-99
  • Legacy Issue Number: 8692
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    According to fig. 13 an operation is associated with a Datatype. That's not shown in the association section of the class description.

  • Reported: UML 2.0 — Sun, 10 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Activities

  • Key: UML22-107
  • Legacy Issue Number: 8731
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In LoopNode, SetupPart/bodyPart should be setup/body to be consistent with Clause

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Revised Text:
    This is covered in the resolution to Issue 8686.
    Disposition: Merged

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify multiple inputs to expansion regions

  • Key: UML22-106
  • Legacy Issue Number: 8725
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify multiple inputs to expansion regions. Clarify whether expansion regions with multiple input expansion nodes require all values to be present to start execution. If not, how is it indicated which are optional? ExpansionNodes do not have multiplicity.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. The requested semantics for ExpansionRegions are now covered in UML 2.5 in Subclause
    16.12.3.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DataStoreNode has uniqueness, reverse constraint inherited from ObjectNode

  • Key: UML22-105
  • Legacy Issue Number: 8724
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    DataStoreNode has uniqueness, reverse constraint inherited from ObjectNode

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    An ObjectNode is not a MultiplicityElement, and, therefore, it can have no uniqueness constraint to reverse. (There actually is such a constraint given for ObjectNode, but this is an error that should be corrected. See Issue 8891.)
    Revised Text:
    None
    Disposition: Close, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add constraints on conditional, loop, sequence to rule out node contents

  • Key: UML22-87
  • Legacy Issue Number: 8494
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraints on conditional, loop, sequence to rule out node contents that are not in the sequence, or clause, setup/body part

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, LoopNode

  • Key: UML22-86
  • Legacy Issue Number: 8492
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In LoopNode, setup, test, and body parts should be owned by the loop node (they were owned by clauses of loop node, which were owned by the loop node).

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The setup, test and body parts of a loop node should all identify nodes that are contained within the loop node. Such nodes are already owned by the loop node via the node association inherited from StructuredActivityNode. However, a constraint needs to be added to ensure this containment, and to ensure that any all executable nodes contained in the loop node are, indeed, in the setup, test or body parts.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Misleading statement about multiplicity in AssociationClass

  • Key: UML22-104
  • Legacy Issue Number: 8722
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Misleading statement about multiplicity in AssociationClass. In the semantics of AssociationClass, the following is misleading: " Note: It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at each end, i.e. from the instance point of view, the multiplicity of the associations ends are 1." The part after "i,e." is confusing, since it refers to multiplicity of association ends, which has a different meaning that intended above. I'd say just delete it.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Client/supplier on dependencies

  • Key: UML22-103
  • Legacy Issue Number: 8721
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Client/supplier on dependencies should specialize source/target inherited from directed relationship

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    Duplicate of 6405.
    Revised Text:
    None.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Constrain conditional node to have body pins if there is a result pin.

  • Key: UML22-88
  • Legacy Issue Number: 8498
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Constrain conditional node to have body pins if there is a result pin. Constrain to be of the same number and compatible types

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

On page 26, Figure 7.9

  • Key: UML22-173
  • Legacy Issue Number: 9233
  • Status: closed  
  • Source: LIANTIS GmbH ( Constantin Szallies)
  • Summary:

    On page 26, Figure 7.9 there an association between 'Property' and 'Classifier'. The end 'classifier' is non-navigable. 'classifier' subsets 'redefinitionContext'. This means the following constraint of 'Property' is violated: subsettedProperty->exists(sp | sp.isNavigable()) implies isNavigable())

  • Reported: UML 2.0 — Mon, 12 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The noted Property constraint is no longer present in the UML 2.2 specification.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

choice of terminolgy for TransitionKind is non-intuitive

  • Key: UML22-172
  • Legacy Issue Number: 9230
  • Status: closed  
  • Source: Parata Systems ( Mark Uebel)
  • Summary:

    The choice of terminolgy for TransitionKind is non-intuitive for many of us, and therefore leads to misuse. Specifically, one would expect the antonym pair "Internal" and "External" be applied to a conceptual pair such as "Exits the composite state" and "Does not exit the composite state". Instead the terms "External" and "Local" refer to these behaviors, respectively. Further, the term "Internal" is then used to describe a concept that has nothing to do with state transitions, but rather, is a reaction to a trigger. It appears to us that the transition and reaction concepts were generalized based on their members (trigger, guard, effect) and not on their behavior. We have found this approach to be a bad practice. Behavioral generalization is more intuitive, and therefore more appropriate. We suggest the following changes: "Internal implies that the transition, if triggered, will not exit the composite (source) state, but it will apply to any state within the composite state, and these will be exited and entered." "External implies that the transition, if triggered, will exit the composite (source) state." Move what is currently described as an "Internal Transition" to a separate concept named "Reaction".

  • Reported: UML 2.0 — Thu, 8 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    Although terminology is almost always contentious and a matter of taste, the submitter has a solid point that this
    particular case can be particularly confusing. However, it has been around since UML 2.0, and changing it at this
    point would likely lead to more confusion and have an impact existing implementations and texts. It seems better to
    leave it unchanged at this point.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.15

  • Key: UML22-171
  • Legacy Issue Number: 9172
  • Status: closed  
  • Source: Paranor AG ( Knut Wannheden)
  • Summary:

    Given the current wording in the Constraints, Semantics, and Notation sections the "external" and "local" transition kind only applies to transitions with composite states as the source. This does then not leave any transition kind, except "internal", over for transitions with simple states or pseudostates as the source. As I understand it the "external" transition kind should also be available for transitions with simple states and pseudostates as the source. Thus, I think the constraint [2] should be removed and the wording in the Semantics and Notation sections should be changed to make it clear that the "external" transition kind is not reserved for transitions with composite states as the source.

  • Reported: UML 2.0 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    External transitions should be available for all vertices except entry points. Local transitions should be allowed for either composite states or entry points. Internal transitions must source/target a composite state, where source=target.

    The semantics and notation will need to be updated to slightly to reflect this change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.3.2 sub-section "Notation" starting on page 149

  • Key: UML22-170
  • Legacy Issue Number: 9141
  • Status: closed  
  • Source: Cutter Information ( Oliver Sims)
  • Summary:

    Issue:
    The use of the keyword <<component>> on all diagrams in this section is inconsistent with standards used elsewhere in the spec (for example the notation shown in the Interfaces package). When a shape has the small component icon showing, the keyword is not required and arguably should not be shown.

    Rationale:
    The diagrams imply that both the icon and the keyword should always be shown. This is of course not the case. As it is, some tools vendors not only accept this incorrect implication but some have also mistaken the keyword for a stereotype. It would be much clearer if the keyword were only shown on component boxes that did NOT have the plug icon in them.

    Note that the notation shown on Page 152 (first page of section 8.4) is "correct" - i.e. much more appropriate, and less likely to mislead. On the other hand that shown on page 153 is "incorrect".

  • Reported: UML 2.0 — Sat, 10 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The classifier notation of a component is defined showing the keyword "component" and optionally the component icon in the upper right corner. All examples in the component chapter of the UML 2.2. (ptc/2008-05-05) show the component with keyword and icon. However table 8.1 shows a component with an icon and without the keyword. This presentation option must be added to the component definition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

inconsistency wrt UML2 classifier behavior

  • Key: UML22-169
  • Legacy Issue Number: 9138
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Figure 13.6 - Common Behavior (page 412 of formal/05-07-04) shows BehavioredClassifier's ownedBehavior as a composition (black diamond) and it shows classifierBehavior as a directed association (no diamond).

    no problem so far.

    But then the figure also shows classifierBehavior subsets ownedBehavior, and the text says (page 420, section 13.3.4 BehavioredClassifer|Associations) that classifierBehavior specializes BehavioredClassifier.ownedBehavior).

    If classifierBehavior is a specialization and the set of its instances is a subset, then the metaassociation denoting classifierBehavior should have the same association type as the superset, in other words for conssitency, both or neither should be black diamond.

    My assumption here is a form of the covariance thesis, a subset and specialization of a composition must also be a composition.

  • Reported: UML 2.0 — Wed, 2 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    In the UML 2.2 Specification, Behaviored::classifierBehavior is no longer specified in the text as "specializes BehavioredClassifier.ownedBehavior". Instead, it simply notes "subsets BehavioredClassifier::ownedBehavior", which is consistent with the diagram.
    The subset classifierBehavior association doesn't need to be composite, because it implies the superset ownedBehavior one (for the same behavior instance), which is composite, so composite semantics will apply anyway. Deleting an M1 classifier instance will delete the M1 behavior instance linked by the subset association, because that M1 classifier is also linked by the superset composite association.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

keyword, "buildcomponent", and a stereotype, "buildComponent"

  • Key: UML22-168
  • Legacy Issue Number: 9125
  • Status: closed  
  • Source: Profound Rational Organization ( Pae Choi)
  • Summary:

    A keyword, "buildcomponent", and a stereotype, "buildComponent", are
    listed in Annex B, "UML Keywords" and Annex C, "Standard Stereotypes",
    but not consistent. The letters, 'c' of the "buildcomponent" keyword and
    'C' of the "buildComponent."

    Also, there are stereotypes mentioned throughout the document such as:

    o decisionInput
    o multireceive
    o parallel
    o iterative
    o stream

    but not listed in the Annex C, Standard Stereotypes. The stereotypes
    mentioned above may not reflect the entire document.

  • Reported: UML 2.0 — Mon, 31 Oct 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18454

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Element and Comment in Basic

  • Key: UML22-182
  • Legacy Issue Number: 9246
  • Status: closed  
  • Source: Capgemini ( Anneke Kleppe)
  • Summary:

    The definition of the classes Element and Comment in the Basic package is ambiguous. The Basic package
    imports Abstractions::Elements::Element and Abstractions::Comments::Comment. An inheritance
    relationship and an Association called ownedComment is introduced between Element and Comment in the
    package Basic. However, these relationships were already defined for these classes in the package
    Abstractions (see the top two diagrams in Figure 4). Therefore, the complete model of Element and
    Comment in the Basic package is the model shown in Figure 4, clearly showing a redundant association
    called ownedComment, and a redundant inheritance relationship between Abstractions::Elements::Element
    and Comment.
    Abstractions
    Element
    (from Elements)
    Element
    (from Comments)
    Comment
    (from Comments)
    Element
    (from Ownerships)
    +owningElement
    0..1

    {subsets owner}
    ownedComment
    * {subsets ownedElement}
    annotatedElement
    *
    Basic (after import abstractions)
    Element
    (from Comments)
    Element
    (from Ownerships)
    Element
    (from Elements)
    Comment
    (from Comments)
    +owningElement
    0..1{subsets owner}

    annotatedElement
    *
    0..1
    ownedComment
    *

    {subsets ownedElement}

    +ownedComment
    0..n
    Basic
    Comment
    (from Comments)
    Element
    (from Elements)
    +ownedComment
    0..n
    0..1
    <<import>>
    <<import>>
    Figure 4

  • Reported: UML 2.0 — Wed, 18 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Description of Element

  • Key: UML22-181
  • Legacy Issue Number: 9245
  • Status: closed  
  • Source: Capgemini ( Anneke Kleppe)
  • Summary:

    The infrastructure specification [1] described the metaclass Element as followes:
    “Element is an abstract metaclass with no superclass. It is used as the common superclass for all
    metaclasses in the infrastructure library.” [1, page 45 and page 93]
    Both packages, Abstraction and Basic, are using the same definition for Element. Therefore, it is logical to
    assume that both packages will contain their own class Element, as shown in Figure 2.
    InfrastructureLibrary
    Abstractions Basic
    Element Element
    Figure 2
    The Rose Model [2] specifies one single class Element, a metaclass that is part of Abstractions. The exact
    name is Abstractions::Elements::Element. The Basic package imports this metaclass. (see Figure 3). We
    assume this is the correct interpretation, therefore the text on page 93 should be changed accordingly.
    InfrastructureLibrary
    Basic
    Abstractions
    Element
    (from Elements)
    <<import>>
    Figure 3

  • Reported: UML 2.0 — Wed, 18 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Unclear relationship between the Basic and Abstractions packages

  • Key: UML22-180
  • Legacy Issue Number: 9244
  • Status: closed  
  • Source: Capgemini ( Anneke Kleppe)
  • Summary:

    1) According to the infrastructure specification [1] the Basic package is using metaclasses from the
    Abstractions package, as indicated by the following text.
    “Basic also contains metaclasses derived from shared metaclasses defined in packages contained in
    Abstractions. These shared metaclasses are included in Basic by copy.”[1 page 91]
    First, the mentioned copy construction is not defined in the infrastructure. Second, in contrary to the copy
    definition, the Rose Model [2] of the infrastructure defines the deriving of metaclasses as import on the
    package Abstractions::Elements and Abstractions::Multiplicity. (see Figure 1)
    2) Furthermore, the infrastructure specification described the reuse of the package Abstractions::Comments
    as followes.
    “Basic::Comment reuses the definition of Comment from Abstractions::Comments.” [1 page 92]
    The Rose Model [2] does not contain this import.
    Abstractions
    Elements
    Comments
    Ownerships
    <<import>>
    <<import>>
    Multiplicities
    <<import>>
    Basic
    <<import>>
    <<import>>
    Figure 1
    3) The infrastructure specification described the Basic::MultiplicityElement as the reuse of
    Abstractions::MultiplicityElement:
    “Basic::MultiplicityElement reuses the definition from Abstractions::MultiplicityElement”[1 page 97]
    The Abstractions package does not contain an Abstractions::MultiplicityElement. Instead of, the
    Abstractions package does contain an Abstractions::Multiplicities::MultiplicityElement and an
    Abstractions::MultiplicityExpressions::MultiplicityElement. Owing to the import of
    Abstractions::Multiplicities the Abstractions::MultiplicityElement

  • Reported: UML 2.0 — Wed, 18 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

XMI file: Core::Constructs::Operation::bodyCondition should have upper boun

  • Key: UML22-179
  • Legacy Issue Number: 9243
  • Status: closed  
  • Source: Fulcrum Analytics, Inc. ( Richard Vermillion)
  • Summary:

    In the XMI file sent out with Ballot 12, the bodyCondition attribute
    of Core::Constructs::Operation has upper="*" when it should be
    upper="1".

    See line 3009 of Infrastructure.cmof:

    <ownedAttribute xmi:type="cmof:Property" xmi:id="Core- Constructs-Operation-bodyCondition" name="bodyCondition" lower="0"
    upper="*" type="Core-Constructs-Constraint" association="Core- Constructs-A_bodyCondition_bodyContext" subsettedProperty="Core- Constructs-Namespace-ownedRule" isComposite="true"/>

    In Superstructure, Classes::Kernel::Operation seems to correctly have
    an upper bound of 1 for bodyCondition.

    Again, apologies for the late notice on this issues. If there is a
    better way to report these, please let me know. I'm sending them to
    the list because I assume some can be made as editorial changes by
    Bran, while others should be opened as new issues for UML 2.2.

  • Reported: UML 2.0 — Mon, 16 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Infra::Core::Constructs::Operation::bodyCondition : Constraint[0..1] in UML 2.2 CMOF.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

/qualifiedName attribute missing on Core::Constructs::NamedElement

  • Key: UML22-178
  • Legacy Issue Number: 9242
  • Status: closed  
  • Source: Fulcrum Analytics, Inc. ( Richard Vermillion)
  • Summary:

    In the Infrastructure.cmof file distributed as part of ballot 12, the
    Core::Constructs::NamedElement class is missing the qualifiedName
    derived property. The operation qualifiedName() exists, but the
    corresponding derived attribute is missing.

    Core::Abstractions::Namespaces::NamedElement does correctly include
    the qualifiedName derived property and all of the OCL constraints in
    Constructs correctly references a qualifiedName attribute (rather
    than the operation).

    Presumably this is an error in the metamodel.

  • Reported: UML 2.0 — Mon, 16 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Operation::ownedParameter should be ordered in XMI?

  • Key: UML22-177
  • Legacy Issue Number: 9241
  • Status: closed  
  • Source: Fulcrum Analytics, Inc. ( Richard Vermillion)
  • Summary:

    In the latest XMI file (included as part of Ballot 12) the
    ownedParameter attribute of Core::Constructs::Operation redefines
    Core::Constructs::BehavioralFeature::ownedParameter – I'm assuming
    that this redefinition is a result of the merge of Basic.

    However, in Operation, the ownedParameter attribute is not ordered.

    Since both BehavioralFeature::ownedParameter and
    Core::Basic::Operation::ownedParameter are ordered, it seems strange
    for Core::Constructs::Operation's not to be ordered. A check of the
    drafts and ballots does not seem to address this issue or explain why
    it would be the case. Is it a mistake?

  • Reported: UML 2.0 — Sun, 15 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Infra::Core::

    {Basic,Constructs}

    ::Operation::ownedParameter

    {isOrdered=true}

    in UML 2.2 CMOF.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-176
  • Legacy Issue Number: 9237
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Can an instance specification for a classifier specify instances of subtypes of the classifier? For example, if Fido is an instance specification for Class Dog, can the runtime object it specifies be an instance of Terrier?

  • Reported: UML 2.0 — Mon, 2 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    An InstanceSpecification can be partial. The spec is quite clear about this. It is also clear that every slot
    must correspond to a feature of one of the classifiers. If the InstanceSpecification is classified as a Dog, it
    might be a Terrier at runtime but you have no way to know that. Insert some text to make this clear.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

constraints owned by these properties have no context

  • Key: UML22-175
  • Legacy Issue Number: 9236
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A similar issue exists with ParameterSet::condition, State::stateInvariant, Extend::condition, Action::localPrecondition, Action::localPostcondition, StateInvariant::invariant, i.e. constraints owned by these properties have no context. This raises the question of whether a constraint must always have a context (note that some of these owners are not namespaces)...

  • Reported: UML 2.0 — Thu, 22 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    As shown in Figure 7.13 in the UML 2.5 specification, the context of a Constraint is optional. Constraints that are
    required to be owned in some way other than using the context/ownedRule association do not have a context.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operation should be a specialization of TypedElement and MultiplicityElemen

  • Key: UML22-174
  • Legacy Issue Number: 9234
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Operation should be a specialization of TypedElement and MultiplicityElement. Currently it is in InfrastructureLibrary::Core::Basic (L0), but isn't in other packages (LM - L3).

  • Reported: UML 2.0 — Wed, 14 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

section, 12.3.27 ExpansionRegion(from ExtarStructureActivities

  • Key: UML22-167
  • Legacy Issue Number: 9120
  • Status: closed  
  • Source: Profound Rational Organization ( Pae Choi)
  • Summary:

    Under the section, "12.3.27 ExpansionRegion(from ExtarStructureActivities)", it states as

    Attributes

    • mode : ExpansionKind - The way in which the executions interact:

    parallel - all interactions are independent.

    iterative - the interactions occur in order of the elements.

    stream - a stream of values flows into a single execution.

    Notation

    An expansion region is shown as a dashed rounded box with one of the keywords parallel, iterative, or streaming in the

    upper left corner.

    However, in "Figure 12.87 Expansion region" the keyword used is <<concurrent>>. Could you
    please verify this and let me know. Thank you.

  • Reported: UML 2.0 — Tue, 11 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

(merged) compliance levels L2 and L3

  • Key: UML22-166
  • Legacy Issue Number: 9102
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    In (merged) compliance levels L2 and L3, derived union property ActivityGroup::subgroup has no subsets.

    -> Rename ActivityPartition::subgroup to subpartition, replace

    {redefines subgroup}

    with

    {subsets subgroup}

    . Also add properties to StructuredActivityNode and InterruptibleActivityRegion that subset ActivityGroup::subgroup?

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. UML 2.5 no longer defines compliance levels using a merged package structure. Further,
    the suggested change to ActivityPartition::subgroup has already been made. StructuredActivityNodes and InterruptibleAtivityRegions
    do not have subgroups.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(merged) compliance level L1

  • Key: UML22-165
  • Legacy Issue Number: 9101
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    In (merged) compliance level L1, derived union properties ActivityNode::inGroup, ActivityEdge::inGroup, ActivityGroup::subgroup, ActivityGroup::superGroup and have no subsets. Note that ActivityGroup, an abstract metaclass, has no concrete subclasses.

    -> Should ActivityGroup not be originally defined in BasicActivities (nor in Fundamental Activities), but perhaps in IntermediateActivities?

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. UML 2.5 no longer defines compliance levels using a merged package structure.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.20 Message (from BasicInteractions)

  • Key: UML22-164
  • Legacy Issue Number: 9081
  • Status: closed  
  • Source: Edin Pezerovic ( Edin Pezerovic)
  • Summary:

    in 14.3.20 Message (from BasicInteractions) is described: "Object creation Message has a dashed line with an open arrow." the referenced example 14.11 on page 458 shows an object creation Message with a solid line and an open arrow.

  • Reported: UML 2.0 — Mon, 17 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion:
    The figure is all right, but dashed lines are sometimes printed as solid lines. The illustrations use Visio and sometimes the dashed lines are not easily distinguished.
    Disposition: ClosedNoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-163
  • Legacy Issue Number: 9078
  • Status: closed  
  • Source: juno.com ( Pae Choi)
  • Summary:

    In Activities, ExpansionRegion, Notation, first sentence, replace "stream" with "streaming".

  • Reported: UML 2.0 — Fri, 14 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The sentence already has "streaming" (and has since UML 2.0). However, the literal in ExpansionKind is "stream", so perhaps the submitter intended to suggest replacing "streaming" by "stream". This would be consistent with using the literals from EnumerationKind for "parallel" and "iterative".

  • Updated: Fri, 6 Mar 2015 20:58 GMT

StateMachine - Constraints

  • Key: UML22-33
  • Legacy Issue Number: 7051
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    "[1] The classifier context of a state machine cannot be an interface"

    should be:

    [1] The context classifier of a state machine cannot be an interface. not redefinitionContext.oclIsKindOf(Interface)

    "[2] The context classifier of the method state machine of a behavioral feature must be the classifier that owns the behavioral feature."

    should be:

    [2] The context classifier of the method state machine of a behavioral feature must be one of the classifier that features the behavioral feature

    – note that a behavorial feature can be associated with 1..* – classifiers if self.specification->notEmpty() then self.specification.featuringClassifier->includes(redefinitionContext) endif

    "[3] The connection points of a state machine are pseudostates of kind entry point or exit point."

    should be:

    [3] The connection points of a state machine are pseudostates of kind entry point or exit point. connectionPoint->forAll(cp | cp.kind = #entryPoint or cp.kind = #exitPoint )

    "[4] A state machine as the method for a behavioral feature cannot have entry/exit connection points."

    should be:

    [4] A state machine as the method for a behavioral feature cannot have entry/exit connection points. self.specification->notEmpty() implies ( self.connectionPoint->forAll(cp | not (cp.kind = #entryPoint or cp.kind = #exitPoint) ) )

  • Reported: UML 2.0 — Sun, 29 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    In UML 2.5, all of the above have been rewritten and corresponding OCL inserted.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

transtion

  • Key: UML22-32
  • Legacy Issue Number: 6991
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Issue 2: In the same spirit, we would like also to specifiy that a transtion is fired

    only if an event is not available at a given instant. We need the concepts of instant

    and event absence. Note that the absence combined with "and" and "or" can express kinds of

    priorities (e.g., "a and not b").

  • Reported: UML 2.0 — Tue, 17 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Triggering a transition with the absence of an event seems to make sense only under a synchronous semantics which defines slices of time where that event might occur or not. It require a major modification or enhancement to the current, asynchronous Run-To-Completion semantics, where events are handled one by one in a timeless sequence. This therefore needs to be postponed to a more major revision, when we will have time to investigate this proposal and see if and how it can be accommodated.

    Revised Text:
    N/A

    Disposition: Closed, out of scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inheritance of 'Enumerations' is not detailed

  • Key: UML22-30
  • Legacy Issue Number: 6921
  • Status: closed  
  • Source: Fraunhofer FOKUS, Germany ( Michael Soden)
  • Summary:

    Inheritance of 'Enumerations' is not detailed with repsect to their (ordered) owned 'EnumerationLiteral's.

    Proposed resolution: Add a constraint to restrict Enumerations to be unable to inherit from each other (at least favored in MOF) or specify how Literals are ordered.

  • Reported: UML 2.0 — Mon, 19 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The issue is obsolete. The spec defines what generalization means for Enumerations.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

manage simultaneity of events

  • Key: UML22-31
  • Legacy Issue Number: 6990
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Issue 1: to have the possibility to manage simultaneity of events, and be able to

    trigger a transition by a condition on several events. By this way, the triggering

    condition of a transition may be specified through an event formula such as: (e1 and e2) or e3

    This point we then involve to relax a constraint on the semantics of RTC and to introduce then

    the possiblity to dequeue several events of the queue at the same time. May it be just an

    additional open variation semantics point?

  • Reported: UML 2.0 — Tue, 17 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Simultaneous events and transitions triggered by a logical combination of events require a major modification or enhancement to the current Run-To-Completion semantics, where events are handled one at a time. This therefore needs to be postponed to a more major revision, when we will have time to investigate this proposal and see if and how it can be accommodated.

    Revised Text:
    N/A

    Disposition: Closed, out of scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

External exceptions.

  • Key: UML22-112
  • Legacy Issue Number: 8750
  • Status: closed  
  • Source: International Business Machines ( James Rumbaugh)
  • Summary:

    External exceptions. We need an interrupt message that asynchonously causes an exception for some other process/object. In examining real-world examples at IBM, I find we need that concept. And we need interrupts that allow the target process to clean itself up, not just die. This occurs in lots of real problems

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This can already be handled, at least for an asynchronously executing activity or state machine, by sending a signal to the behavior. A concurrent part of the activity or state machine can then receive the signal and interrupt the ongoing behavior, transitioning, if necessary, to some clean up behavior before terminating. In an activity this can be done using an interruptible region. In a state machine it can be used with a orthogonal region.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify which classifier or operation this is referring to

  • Key: UML22-111
  • Legacy Issue Number: 8743
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    CollaborationUse, Constraint 2: Clarify which classifier or operation this is referring to.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    There are several places in chapter 9 where the text refers to the possibility of a CollaborationUse being associated with an Operation. But there is nothing in the metamodel to support this. This issue is resolved by removing these statements from the text, and by clarifying the offending constraint.
    In 9.3.3, there is a paragraph that reads as follows:
    "A collaboration may be attached to an operation or a classifier through a CollaborationUse. A collaboration used in this way describes how this operation or this classifier is realized by a set of cooperating instances. The connectors defined within the collaboration specify links between the instances when they perform the behavior specified in the classifier. The collaboration specifies the context in which behavior is performed. Such a collaboration may constrain the set of valid interactions that may occur between the instances that are connected by a link."
    The placement of this paragraph is peculiar, because it appears under Collaboration, not CollaborationUse. The first two sentences of this paragraph are false, because they talk about attaching a CollaborationUse to an operation. The remainder of the paragraph appears to add no value to what has been already stated in the semantics of Collaboration. I propose to delete this paragraph.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

represents and occurrence keywords are switched

  • Key: UML22-110
  • Legacy Issue Number: 8742
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    CollaborationUse, Presentation Options, first paragraph, the represents and occurrence keywords are switched

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This does not appear in 2.2.

    Revised Text:
    None.

    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Action/Activity

  • Key: UML22-116
  • Legacy Issue Number: 8771
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In the actions and activities chapters default values for attributes that are typed by ValueSpecifications use primitives for the default value. For example: 12.3.5 ActivityEdge, p. 352 Attribute weight has default value "1". Is that correct? What if the ValueSpecification is not computable or the value isn't typed by an Integer?

  • Reported: UML 2.0 — Mon, 9 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Yes, this is correct. ValueSpecifications are used in these cases, because it is often desirable for the given value to be specified in the model as computed.
    The default values are to be interpreted as the corresponding LiteralValue for the given value (e.g., a LiteralUnlimitedNatural, in the case of weight). The type of value to which such a ValueSpecification must evaluate (e.g., UnlimitedNatural for weight) is given in the semantics for the construct. If the ValueSpecification is not computable or evaluates to a value of the incorrect type, then the model is ill-formed and has no meaning.
    Revised Text:
    None.
    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Input tokens to LoopNodes should be destroyed when the loop is done

  • Key: UML22-119
  • Legacy Issue Number: 8780
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Input tokens to LoopNodes should be destroyed when the loop is done

  • Reported: UML 2.0 — Sun, 15 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. This is covered by the current semantics for loopVariableInputs, which are the only InputPins a
    LoopNode may have.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1

  • Key: UML22-118
  • Legacy Issue Number: 8777
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    There is a notational conflict in the white box view of a component. If a part is typed by a component the component symbol is shown in the upper right corner of the part rectangle. The same position is used to show the multiplicity of the part.

  • Reported: UML 2.0 — Thu, 12 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The upper right corner of a connectable element could be used to denote the multiplicity. The same position is used to show the component symbol if the connectable element is typed by a component. It is also used by stereotype symbols. The presentation option for the multiplicity is in conflict with other standard UML notations. However it is only an option and not a mandatory presentation.

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-123
  • Legacy Issue Number: 8866
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 28 (Examples of attributes) has a read-only, derived attribute. Read only attributes can't be changed after initialization, whereas the example implies this particular one can be changed due to derivation.

  • Reported: UML 2.0 — Fri, 10 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.2 Action

  • Key: UML22-122
  • Legacy Issue Number: 8861
  • Status: closed  
  • Source: Sapiens Deutschland GmbH ( Helmut Barthel)
  • Summary:

    Object token flow semantics with input pins seems to be incompletely defined. In section Semantics on page 337 you write: "... an action can only begin execution when all incoming control edges have tokens, and all input pins have object tokens." You didn't explain how and when the object tokens come to the input pins. Further, for step [2], you write: "An action consumes the input control and object tokens and removes them from the sources of control edges and from input pins." Again, you didn't explain how and when the object tokens came to the input pins, from source object nodes.

  • Reported: UML 2.0 — Wed, 8 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In Figure 12, ownedAttribute is bidirectional, in Figure 95, it is unidirec

  • Key: UML22-109
  • Legacy Issue Number: 8741
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Figure 12, ownedAttribute is bidirectional, in Figure 95, it is unidirectional. What happens when these are merged in Figure 98?

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    see pages 21 - 22 of ptc/2011-01-19

  • Updated: Fri, 6 Mar 2015 20:58 GMT

StructuredActivityNode, Semantics, third paragraph, first sentence,

  • Key: UML22-108
  • Legacy Issue Number: 8738
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    StructuredActivityNode, Semantics, third paragraph, first sentence, clarify that "attached" means input pin, output, or expansion nodes

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    The wording of this sentence has already been changed by the resolution to Issue 9855 to refer specifically to pins on a structured activity node. Expansion nodes only apply to expansion regions and are covered in that section.
    Revised Text:
    None.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.7

  • Key: UML22-117
  • Legacy Issue Number: 8776
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Second constraint: "If a connector end references both a role and a partWithPort, then the role must be a port that is defined by the type of the partWithPort." Since role has multiplicity 1..1 and partWithPort 0..1 the if condition is always true if a connector has a partWithPort. It'S sufficient to say "If a connector references a partWithPort,..."

  • Reported: UML 2.0 — Wed, 11 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Agreed, this will make it easier to read.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14

  • Key: UML22-76
  • Legacy Issue Number: 8353
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add Ocl notation to constraints where possible or note that OCL notation is not possible. Page numbers of odd numbered pages are not in the same place as the are for other chapters. Move them to the lower right corner. Delete sub-section headings where the sub-section contains no information or state "None." If a concept is not "(as specialized)" and there are no atttributes, associations, etc. write "None" instead of "No additional xxx." Not all of the figures contain package names for the generalized parents. Add as many of these as possible or use the ellipses as appropriate.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.18

  • Key: UML22-75
  • Legacy Issue Number: 8342
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Second sentence in sub-section Description is missing a word. "...the contents of the referred Interaction xxx [from?? to??] where the InteractionUse is." Change the class name of the association argument:InputPin[*] either on fig 333 to InputPin or to Action in the text. Class name in fig. 333 is Action. This association is also shown in the figure as ordered. Association actualGate:Gate[*] subsets ownedElement. Mention specialization in definition of the association. I'm confused between the BNF use of io-argument and your use of argument. If the name of the association is "io-argument" as indicated by BNF and Issue 1751, should the name on the diagram and in the sub-section Associations be changed to io-argument? Also, para 2 on og 534 italizes argument instead of io-argument. Typo - Second sent. on pg. 534 needs a space between "explained" and "in."

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RemoveStructuralFeatureValueAction specification

  • Key: UML22-74
  • Legacy Issue Number: 8336
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    According to the RemoveStructuralFeatureValueAction specification we always have to specify the value to remove. It is not possible to remove an element from a multi-valued structural feature just by specifying its number in the set and without specifying its value. It would be interesting to have this option.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is resolved by the resolution to Issue 9870.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Decision node

  • Key: UML22-82
  • Legacy Issue Number: 8471
  • Status: closed  
  • Source: sabetta.com ( Antonino Sabetta)
  • Summary:

    Decision node should be able to take decision based on input separate from the flow being routed

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This issue is already resolved in UML 2.2 (see Issue 10815).
    Revised Text:
    None
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions

  • Key: UML22-81
  • Legacy Issue Number: 8470
  • Status: closed  
  • Source: International Business Machines ( Eran Gery [X] (Inactive))
  • Summary:

    Add actions for reading and writing parameter values, so flows are not required in structured activities

  • Reported: UML 2.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Duplicate of issue 9247.
    Revised Text:
    None.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.17

  • Key: UML22-72
  • Legacy Issue Number: 8310
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figure 318 shows the association specification:Interfal[1] that redefines specification. Add this to sub-section Associations in the concept since the concept is not as specialized

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This has already been resolved in UML 2.2.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.11

  • Key: UML22-71
  • Legacy Issue Number: 8306
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Describe more fully that DurationInterval defines the range between the minimum and maximum duration times allowed. To be consistent with other mutliplicities, show the multiplicities of the associations on fir. 318. Add comment that the associations redefine minimum and maximum as indicated by fig. 318. Sub-section Notation mentions DurationExpression but this concept is not defined. Add this as a concept.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    In the UML 2.2 specification, the diagram is now Figure 13.13. Multiplicities for min and max are shown on both the diagram and in the text. The redefinitions should be shown in the text. In the Notation section, DurationExpression should be Duration.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 15

  • Key: UML22-78
  • Legacy Issue Number: 8447
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    General comments - Delete sub-sections tat are empty or state "None." If class is not "as specialized' do not say "No additional xxxx" but rather "None" or delete the sub-section. Add OCL notation or a note that OCL notation is not available for constraints and/or additional operations and/or derived attributes where appropriate.

  • Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14

  • Key: UML22-77
  • Legacy Issue Number: 8414
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    How to show class operation calls in interaction diagrams? A discussion in the umlforum list came to the conclusion that the name in the lifeline header should be the class name. In that case it is not possible to differentiate between "ClassName" only and "RoleName" only. Besides the notational problem I can't see how a class operation call could fit into the interaction meta-model. However it is necessary to show such a call. It's a typical part of an interaction.

  • Reported: UML 2.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18697

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.40

  • Key: UML22-69
  • Legacy Issue Number: 8260
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add package names "(CompleteStructuredActivities, StructuredActivities)" Add OCL notation

  • Reported: UML 2.0 — Tue, 8 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Within the Activities package, OutputPin appears under StructuredActivities and CompleteStructuredActivities. However, Figures 12.21 and 12.22 (of the UML 2.2 Specification, ptc/08-05-05), explicitly referencesUML::Actions::BasicActions::OutputPin. This is not correct, because StructuredActivities (indirectly) merges BasicActions, it does not import it - and, since it merges it, cannot reference elements from it.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.33

  • Key: UML22-68
  • Legacy Issue Number: 8249
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraint. Correct multiplicity of association interrutingEdge:ActivityEdge[0..*] so that fig. 194 and text agree. Typos - Change 2nd sent. of 2nd para in sub-section Semantics to "...and the token arrives at the target even is an interruption occurs... . " - Under sub-section Presentation Option, spell zigzag as one word, not two.

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-84
  • Legacy Issue Number: 8474
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Enumeration should have a constraint that the classifier of its literals is the enumeration

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-83
  • Legacy Issue Number: 8472
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Object node should be a multiplicity element, and use multiplicity upper for upperbound

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Though seemingly small, this would actually be a significant change to the metamodel for activities and it would fundamentally change the current semantics for multiplicity of pins, which now only effect the execution of actions. If object node in general were made a multiplicity element, one would not only have to reconcile the current semantics of object node upper bound with the semantics of the multiplicity upper bound of a pin, one would also need to consider what the general semantics are for the multiplicity lower bound of an object node.
    This issue is thus considered strategic and out of scope for an RTF.
    Revised Text:
    None
    Disposition: Closed Out of Scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.11

  • Key: UML22-65
  • Legacy Issue Number: 8142
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Need to write the info for the Changes from previous UML section or remove it

  • Reported: UML 2.0 — Wed, 26 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Section: Interactions

  • Key: UML22-85
  • Legacy Issue Number: 8475
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Interactions: What object receives SendEvent, etc? Affects how AcceptEventAction is used

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    Not a problem in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Common Behavior

  • Key: UML22-155
  • Legacy Issue Number: 9005
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Second paragraph of Semantics section of Trigger in Common Behavior is inconsistent with the first paragraph of p 605 in semantics of State. The semantics of Trigger does not accomodate deferred events.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The noted paragraph in Trigger is not actually in conflict with deferred events. The semantics of Trigger states that once "an event is dispatched" it is "considered consumed" and is then "no longer available for processing". However, the semantics for deferred event under State says that "an event that does not trigger any transitions in the current state, will not be dispatched" if it is deferred. Therefore, there is no conflict with it being consumed only if it is actually dispatched.
    However, it would probably be helpful to clarify this under Trigger. Also, the semantic variation point on discarding an event if there is no appropriate trigger is not correct, since, for a transition even, at least, if the event is deferred it is not discarded, and if it is not deferred it is.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes (02)

  • Key: UML22-154
  • Legacy Issue Number: 9004
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    raisedException in Figure 10, reused without specialization by Operation in Figure 11 (the entry for it in Operation says it is redefined), but redefined in Figure 315. Should it be a derived union in Figure 10?

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The specialization from A_raisedException_operation to A_raisedException_behavioralFeature comes as a result of L3 package merge. Derived union would make sense if raisedException had a subsetting relationship instead of a specialization refinement.
    (Note also that the redefinition of raisedException is now noted on the diagram for Operation. Also, the resolution of Issue 12558 removed the later BasicBehaviors::BehavioralFeature::raisedException.)
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Common Behavior (02)

  • Key: UML22-153
  • Legacy Issue Number: 9002
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of TimeEvent uses undefined term "active". State machines uses the term for states, not triggers. Need definition independent of state machines in any case.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The UML 2.5 beta specification still uses the phrase “time at which the Trigger becomes active” in 13.3.3
    under “Time Events”. The intended idea seems to be what is now discussed earlier in 13.3.3 under “Even
    Dispatching”: a Behavior may come to a “wait point” at which it has a number of “outstanding Triggers”.
    For any such Triggers with a relative TimeEvent, the starting point should be the time at which the Behavior
    comes to the wait point.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Common Behavior

  • Key: UML22-152
  • Legacy Issue Number: 9001
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Semantics of AnyReceiveEvent. The semantics of AnyReceiveEvent is in terms of state machines even though it is in Common Behavior. Should be defined independently of the kind of behavior using it.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property ownership must be consistent across association redefinitions

  • Key: UML22-151
  • Legacy Issue Number: 8977
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    When an association generalizes another association and redefines its ends, the redefined end must be accessible through the generalization. This means redefining and redefined properties must be ownedEnds of the association or ownedAttributes of the participating classes. Redefining ownership (either directly or indirectly by changing navigability with default ownership) resulting in the redefined property no longer being a member of the general class should not be allowed. UML2 needs to include a constraint capturing this rule

  • Reported: UML 2.0 — Fri, 26 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This is already covered by RedefinableElement::isRedefinitionContextValid() and
    RedefinableElement::redefinition_consistent.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing notation for association classes

  • Key: UML22-150
  • Legacy Issue Number: 8974
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The notation for Associations allows them to be depicted as a diamond (even binary associations).
    However the Notation for AssociationClasses assumes the Association is depicted as a line only, and does not describe an option for attaching an AssociationClass to an Association shown as a diamond. This should be fairly obvious - just have the dotted line attached to the diamond instead of the Association's line.

  • Reported: UML 2.0 — Tue, 23 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is an omission in the text.
    This also resolves issue 12406

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 346-347

  • Key: UML22-149
  • Legacy Issue Number: 8973
  • Status: closed  
  • Source: Systemvaruhuset ( Andreas Hägglund)
  • Summary:

    Figure 207 on page 346 depicts the symbol for an activity as a number of rectangle with rounded corners surrounding a number of action nodes which also are depticed as rectangles with rounded corner. The example (figure 209 on page 347) however, depicts the action nodes not as rectangles with rounded corners but more lika ovals (or rectangles with noticabely more rounded corners than previously). Which symbol is the correct one?

  • Reported: UML 2.0 — Mon, 22 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The referenced figure is 12.33 in Section 12.3.4 of the UML 2.2 specification (ptc/08-05-05). The graphical variation in the action shape in subsequent diagrams does not seem unreasonable and the notation of an action within an activity is clearly given in Section 12.3.2.
    Revised Text:
    None
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 255

  • Key: UML22-148
  • Legacy Issue Number: 8972
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The specification says: "If isReplaceAll is false and the variable is unordered and nonunique, then adding an existing value has no effect." This should be replaced by: "If isReplaceAll is false and the variable is unordered and UNIQUE, then adding an existing value has no effect."

  • Reported: UML 2.0 — Mon, 22 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Behavior

  • Key: UML22-147
  • Legacy Issue Number: 8970
  • Status: closed  
  • Source: MID GmbH ( Mr. Detlef Peters)
  • Summary:

    1) As a specialization of Class, Behavior (and its subclasses) may have properties (+ownedAttribute) and operations (+ownedOperation). Especially for operations, I can't see any use for it.
    I propose to change the Superclass of Behavior from 'Class' to 'Classifier' and to add an explicit ownership of Properties, as already done for Signals.
    2) The description and semantics of Behavior immediately refer to a context classifier. As a consequence, the composite relation to 'BehavioredClassifier' should be of multiplicity 1 instead of 0..1 so that a Behavior must always be owned by a BehavioredClassifier.

  • Reported: UML 2.0 — Fri, 19 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    1) The rationale for allowing attributes and operations on behaviors is actually provided in Subclause 12.3.4 for activities. In part: "An activity execution, as a reflective object, can support operations for managing execution, such as starting, stopping, aborting, and so on; attributes, such as how long the process has been executing or how much it costs; and links to objects, such as the performer of the execution, who to report completion to, or resources being used, and states of execution such as started, suspended, and so on." The submitter may not agree with the need for this capability, or desire to use it, but it was specifically included in UML because there are some who do wish to use it.
    2) A behavior may standalone without being owned by any other behaviored classifier. In this case the behavior is implicitly considered to be its own context when executed. Per the Semantics in Subclause 13.3.2: "When a behavior is instantiated as an object, it is its own context."
    Revised Text:
    None
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 - Invalid subsetting of composition ends

  • Key: UML22-144
  • Legacy Issue Number: 8952
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In figure 3, the association end Element::owner is shown as navigable and as a union of all its subsets. According to the following convention defined in section 6.5.2, this end is owned by the class and not the composition association:

    " • An association with neither end marked by navigability arrows means that:
    • the association is navigable in both directions
    • each association end is owned by the classifier at the opposite end (i.e., neither end is owned by the association)"

    Throughout the spec, there are many places where this association end is specialized into a non-navigable association end (e.g., figures 4, 5, ...). But, according to the following additional rule in 6.5.2:

    " • An association with one end marked by a navigability arrow means that:
    • the association is navigable in the direction of that end,
    • the marked association end is owned by the classifier, and
    • the opposite (unmarked) association end is owned by the association"

    this means that such non-navigable association ends are owned by the association and not by the class.

    Consequently, such ends cannot be valid specializations of Element::owner (as stated in the spec) since they are owned by a classifier (the association) that is not related by generalization to the classifier (i.e., metaclass) that owns the original attribute.

    Recommendation:

    (1) Define Element::owner such that it is owned by the composition association and not by the Element class. This will make all the currently invalid subsettings of this type valid.

    (2) Do this for all other cases of invalid subsets of this type in the spec, if they exist.

    (3) Make it explicit in the spec that these are exceptions to the convention described in 6.5.2

  • Reported: UML 2.0 — Mon, 8 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Actions / Compliance Levels of Actions

  • Key: UML22-143
  • Legacy Issue Number: 8951
  • Status: closed  
  • Source: MID GmbH ( Mr. Detlef Peters)
  • Summary:

    Actions for sending events and for calling operations and behavior are part of the "BasicActions" package which is part of Compliance Level 1. Their 'partner' actions for accepting a call or an event, however, are part of the "CompleteActions" package which is part of Compliance Level 3.
    Since there is not much sense in creating events without ever accepting them later, I recommend one of the following:
    a) Accept the first item of Issue 8459 from Mr. Amsden and move "AcceptEventAction" and "AcceptCallAction", too, to a package of L1, preferrably "BasicActions"
    b) Otherwise (if "Communications" remains an L2 package) move these two Actions together with all "InvocationAction" specializations, too, to a package of L2. In this case, maybe a new L2 package like "CommunicationActions" could be created.

  • Reported: UML 2.0 — Thu, 4 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. There are no compliance levels in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 53-55

  • Key: UML22-162
  • Legacy Issue Number: 9076
  • Status: closed  
  • Source: ZeT ( Jose A. Rodrigues Nt.)
  • Summary:

    In UML v. 2.0, formal/05-07-04: IF 7.3.9 Comment -> Semantics -> "A Comment adds no semantics to the annotated elements,..." AND 7.3.10 Constraint -> "A constraint is a condition or restriction expressed in natural language text or in a machine readable language for the purpose of declaring some of the semantics of an element." AND 7.3.10 Constraint -> Semantics -> "A Constraint represents additional semantic information attached to the constrained elements." AND 7.3.10 Constraint -> Presentation Options -> "The constraint string may be placed in a note symbol and attached to each of the symbols for the constrained elements by a dashed line." THEN Either the constrained element is the "note symbol", the "note symbol" represents a Comment and so a Comment adds semantics to another element or I missed something.

  • Reported: UML 2.0 — Thu, 6 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    Just because both a Comment and a Constraint can both be notated using a similar “note symbol” does not mean
    they are the same thing. A Constraint notated using a note symbol in the concrete syntax of a model still maps to a
    Constraint in the abstract syntax representation, not a Comment.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"ownedType" is not a valid element

  • Key: UML22-161
  • Legacy Issue Number: 9024
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    Having implemented a UML 2 L0 addin for Rational Rose, I exported a sample model to XMI. When this XMI file was imported into another UML2 tool, the tool failed, indicating that "ownedType" is not a valid element. Examination of the Infrastructure Library reveals why this is so. In the InfrastructureLibrary's Basic package (the basis for UML2 L0), the sole means by which a Package owns items is the "ownedType" reference. However, in The Constructs package (the basis for UML 2 L1 and beyond), this reference is now indicated as derived, meaning that it will not be handled by most UML 2 tools. It has been replaced by the "ownedMember" reference, which is unknown to UML 2 L0.

    This is a showstopper issue with respect to UML2 XMI interoperability, since it means that a UML2 tool operating at Level 0 cannot interchange models with UML2 tools operating at any other level.

  • Reported: UML 2.0 — Tue, 4 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-158
  • Legacy Issue Number: 9012
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Associations can have static ends, but this violates the semantics of static (that they are properties of the class or subclasses, not instances). If we are following programming languages, the semantics of isStatic should be that it is properties of instances, but is the same on all instances. The current semantics would be the right one if isStatic identifies "metaproperties".

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This is now covered by the text that says “Where semantics are not explicitly specified for static Features, those
    semantics are undefined” in clause 9.4.3, and also “The semantics are undefined for Associations that have an end
    with isStatic = true” in 16.6.3.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-157
  • Legacy Issue Number: 9011
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 13, what is the classifier of EnumerationLiteral (inherited from InstanceSpecification)? Presumably it should be the enumeration, with the enumeration end of the association to Enumeration redefining the classifier end from InstanceSpecification in Figure 8. Programs accessing classifiers in the repository should find the enumeration literals as instances of their enumerations.

  • Reported: UML 2.0 — Tue, 14 Nov 2000 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-156
  • Legacy Issue Number: 9009
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In LoopNode, the frontend, backend node description is redundant with the semantics of StructuredActivityNode

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. The UML 2.5 description of structured node semantics no longer uses the “frontend, backend
    node” terminology, and is no longer redundant.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML SuperStructure - Inconsistency re State Machine terms

  • Key: UML22-146
  • Legacy Issue Number: 8967
  • Status: closed  
  • Source: Anonymous
  • Summary:

    think there is some inconsistency in your usage of terms
    in chapter 15 State Machines.

    It isn't really clear (I think) what you mean sometimes when
    you use the terms "state machine" "behavioral state machines"
    and "protocol state machines".

    In my (humble) opinion you should never use only the term
    "state machine" when you do not mean both "behavioral state
    machine" and "protocol state machine".

    15.3.12 is a perfect example where I think there is confusion,
    or at least lack of clarity, since you talk about "state machines" executing "activities". Clearly, not all state machines do--
    more precisely--protocol state machines don't.

  • Reported: UML 2.0 — Tue, 16 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue was resolved by the UML 2.5 convention of using explicit meta-class names (e.g., StateMachine and ProtocolStateMachine)
    and by isloating the two types of state machines into distinct sections of the spec.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.20

  • Key: UML22-145
  • Legacy Issue Number: 8965
  • Status: closed  
  • Source: ACTL Systems ltd. ( Dani Mannes)
  • Summary:

    In the UML 1.5 you could specifiy on messages in the collaboration diagram the predesessor. This was very convenient for modeling threads. this has been removed from the UML 2.0. It should be added to the communication diagram message specification.

  • Reported: UML 2.0 — Mon, 15 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    In sequence diagram messages are not totally ordered.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.3

  • Key: UML22-160
  • Legacy Issue Number: 9017
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Fig 16.3. uses note symbol notation of the Hruby Vision template. That's not conform to UML 2.0 at this point. The end of the note anchor line doesn't have a circle in UML 2.0.

  • Reported: UML 2.0 — Mon, 26 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18084

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-159
  • Legacy Issue Number: 9014
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint that incoming edges to input pins on structured activities must have sources outside the structured node. Add constraint that incoming edges to output pins on structured activities must have sources inside the structured node.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 420

  • Key: UML22-142
  • Legacy Issue Number: 8945
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In addition to the elided pins presentation add presentation option that pins can be omitted without a little box above the line.

  • Reported: UML 2.0 — Tue, 2 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Without the little box, the object flow would look identical to a control flow between actions, which would be confusing.
    Revised Text:
    None
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector - "provided Port" and "required Port" not defined Constraint 1

  • Key: UML22-36
  • Legacy Issue Number: 7247
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Connector - "provided Port" and "required Port" not defined Constraint 1, "[1] A delegation connector must only be defined between used Interfaces or Ports of the same kind, e.g. between two provided Ports or between two required Ports." uses the concepts "provided Port" and "required Port". Neither of them is defined in the spec. Furthermore, a Connector is not expected to be defined between Interfaces, but an Association is. A Connector is defined between ConnectableElements whose specializations are Property, Port, Parameter, and Variable, but not Interface. I suggest to replace Constraint [1] with "[1] A delegation connector must only be defined between a ConnectableElement (i.e. a Port) of the component and a ConnectableElement (i.e. a Property or a Port) of one of its internal parts."

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The proposed resolution is still incorrect because a connector in general is n-ary not binary. Also the need for such a constraint is altered because of the resolution of 7364 which makes Connector::kind derived. Instead we need a constraint that ensures that a delegation connector only delegates from one port: it would make no sense to have an n-ary connector that delegated from more than one port. Furthermore the entire Semantics section for Connector in this chapter needs rewriting because of this issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.14.1

  • Key: UML22-48
  • Legacy Issue Number: 7969
  • Status: closed  
  • Source: N/A ( Paul Berry)
  • Summary:

    The allOwnedElements query (defined in Core::Abstractions::Ownerships) operates by recursing downward through the ownership hierarchy. Its OCL implementation looks like this: Element::allOwnedElements(): Set(Element); allOwnedElements = ownedElement->union(ownedElement->collect(e | e.allOwnedElements())) In the absence of sophisticated optimization, this query is only guaranteed to terminate if the ownership hierarchy is non-circular. The ownership hierarchy is guaranteed to be circular by constraint [1] (An element may not directly or indirectly own itself). But the OCL description of constraint [1] is written in terms of the allOwnedElements() query: not self.allOwnedElements()>includes(self) If a modeling tool were to be written based on these rules in a straightforward way, it would never be able to detect a violation of constraint [1]. Instead it would go into infinite recursion while trying to check the constraint. Proposed solution: Add the following operation to 9.14.1: [3] The query isCircularlyOwned walks the chain of direct and indirect owners of an element, checking whether the chain contains any circularities, or any of the elements in the set prohibitedElements. Element::isCircularlyOwned(prohibitedElements: Set(Element)): Boolean; isCircularlyOwned = if owner>isEmpty() then false else if prohibitedElements->including(self)>includes(owner) then true else owner.isCircularlyOwned(prohibitedElements>including(self)) And change constraint [1] to: [1] An element may not be directly or indirectly owned by itself. not self.isCircularlyOwned(Set{})

  • Reported: UML 2.0 — Sun, 5 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    It is not necessary for the OCL in the specification to be implementable in some “straightforward way”. It is only
    necessary that the OCL have the proper meaning according to OCL semantics, which the identified expressions do.
    An implementation is free to implement them in the manner that the issue author suggests. It is not necessary to
    complicate the specification by adopting a specific implementation approach.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation sections for TimeObservation and DurationObservation

  • Key: UML22-42
  • Legacy Issue Number: 7304
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The Notation sections for TimeObservation and DurationObservation seem inadequate: 1. The syntax for TimeObservation only allows "now" as a TimeExpression, but indicates in the previous sentence that more complex expressions are possible. 2. The syntax for DurationObservation includes the unexplained non-terminal symbol "duration". 3. In the example, figure 321, there are no associations to named elements shown. I assume that these refer to the begin and end of the arrow, but that is not indicated.

  • Reported: UML 2.0 — Wed, 5 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue has already been considered by prior RTFs and deemed out of scope, per the following discussion previously recorded for this issue:
    A proper resolution of this issue depends on changes in progress with respect to the action and activity model. In addition, a more encompassing improvement of the "simple time model" and related concepts is required.
    Thus, the resolution of this issue is best considered to be strategic.
    Revised Text:
    None
    Disposition: Closed Out of Scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector - inconsistencies in Constraint[3]

  • Key: UML22-38
  • Legacy Issue Number: 7249
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Connector - inconsistencies in Constraint[3] Constraint [3] says: "[3] If a delegation connector is defined between a source Interface or Port and a target Interface or Port, then the target Interface must support a signature compatible subset of Operations of the source Interface or Port." There are two problems with this constraint: 1. An Interface cannot be the source or the target of a connector, because Interface is not a ConnectableElement. 2. If a connector is defined between a source Port and a target Port (which is possible, because Port is a ConnectableElement) - what is the "target Interface"? One of the Interfaces port.type is implementing? Or one of the Interfaces in port.provided? - what are the Operations of the source Port? The Operations of the Classifier given by port.type? Or the union of all Operations of all Interfaces given by port.required and port.provided? - what does "signature compatible" mean for Interfaces?

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See 7248 for the discussion.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector - inconsistencies in Constraint [2]

  • Key: UML22-37
  • Legacy Issue Number: 7248
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Connector - inconsistencies in Constraint [2] Constraint [2] says: "[2] If a delegation connector is defined between a used Interface or Port and an internal Part Classifier, then that Classifier must have an “implements” relationship to the Interface type of that Port." There are two problems with this constraint: 1. A connector cannot be defined between a used Interface and an internal Part, because Interface is not a ConnectableElement. 2. What is "the Interface type of that Port" ? The Classifier given by port.type? This Classifier can be but does not have to be an Interface. Or one of the Interfaces given by port.required? Which one?

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This constraint and the following two are currently incomprehensible (see 7249 and 7250). According to Internal Structures, "What makes connectable elements compatible is a semantic variation point." I see no particular reason to change this for components, and given that connectors are n-ary, it would be hard to do so. So I propose simply to delete the constraints. Profiles are free to restrict connectors to binary and to impose signature compatibility, based on type or contract compatibility, if they wish to.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector - inconsistencies in Constraint[5]

  • Key: UML22-40
  • Legacy Issue Number: 7251
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Connector - inconsistencies in Constraint[5] Constraint [5] says: "[5] An assembly connector must only be defined from a required Interface or Ports to a provided Interface or Port." There are two problems with this constraint: 1. A connector cannot be defined from or to an Interface, because Interface is not a ConnectableElement. 2. It is not clear what a "required Port" or a "provided Port" is.

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See 7248 for the discussion.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector - inconsistencies in Constraint[4]

  • Key: UML22-39
  • Legacy Issue Number: 7250
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Connector - inconsistencies in Constraint[4] Constraint [4] says: "[4] In a complete model, if a source Port has delegation connectors to a set of delegated target Ports, then the union of the Interfaces of these target Ports must be signature compatible with the Interface that types the source Port." There are two problems with this constraint: 1. What is "the union of the Interfaces of these target Ports"? First, it is not clear, what a "union of interfaces" is. A "union of a set of interfaces" could be an anonymous Interface which specializes all the interfaces in the set of interfaces, but this should be made clear, because "union of interfaces" is not defined somewhere else in the spec. Second, it is not clear what the Interfaces of a target Ports are. All Interfaces provided by the Classifier port.type including the Classifier port.type itself, if port.type is an Interface? Union the Interfaces in port.provided? Do we have to include the Interfaces in port.required as well? 2. What does "signature compatible" mean?

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See 7248 for the discussion.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Presentation Options

  • Key: UML22-50
  • Legacy Issue Number: 7994
  • Status: closed  
  • Source: SINTEF ICT ( Richard Torbjørn Sanders)
  • Summary:

    Presentation Options: Add after first sentence: "State symbols may optionally be used to describe a Constraint" "The regions represent the orthogonal regions of states" - delete this. The identifier need -> The name of the state need

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The text referred in this issue does no longer exist.
    Disposition: ClosedNoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

useless example on p.330, Figure 247

  • Key: UML22-44
  • Legacy Issue Number: 7375
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    p.330, Figure 247. This example is useless, as it canot be understood without much detail on the FFT computation. It would be better to use examples that readers can readily understand.

  • Reported: UML 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The issue is subjective. Some readers might find the example helpful. The example is useful as a depiction of a realistic computation.
    Revised Text:
    None
    Disposition: Closed, no Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property defines an association "datatype" which is redundant

  • Key: UML22-43
  • Legacy Issue Number: 7339
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Property defines an association "datatype". This association is redundant for the following reasons: A DataType is a kind of classifier, so saying that a property can be owned by a DataType adds nothing new. (ii) as feature, one can navigate from the property to the featuringClassifier, and so the navigability to an owning data type is already given. Moreover, an association to a data type would be incorrect if the property would otherwise be owned by a different Classifier. Moreover, if this property is owned by a classifier, there is no guarantee that the datatype association references the same DataType. There are no consistency constraints. Anyway, this association is redundant, can possibly lead to inconsistent models, and should be deleted. The last sentence on p.92 "A property may be owned by and in the namespace of a datatype." is correct even if the association is deleted. However, this sentence adds no new information either and is best deleted also.

  • Reported: UML 2.0 — Sat, 15 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    see pages 14 - 17 of ptc/2011-01-19

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiple typos in ptc/04-10-02

  • Key: UML22-57
  • Legacy Issue Number: 8102
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Multiple typos (If you don't want them submitted this way, I'll complete an issue for each.) section 6.34 page 11 Delete word “to” in “The read/write actions can also be used to by oneÂ…” section 7.3.3 page 38 Delete word “If’ in the Note “If the lower multiplicity for an end ofÂ…” Section 7.3.5 page 46 Correct typo “pr” to “or” in ownedParameter:Parameter[*] Section 7.3.11 page 60 Change “has” to “have” in 2nd para 2nd sentence “Instances of a data type that “has”Â…” Instances is the subject of the sentence Section 7.3.11 page 61 Add word “to” to Notation sentence 6 “In this case, cone or more arrows with their tails on the clients are connected “to” the tailsÂ…” Section 7.3.20 page 71 Change “is” to are in generalizationSet “Designates a set in which instances of Generalization “are” considered members.” The verb refers to the subject of the which clause (instances). Section 7.3.21 page 83 Change “is” to “if” in last sentence of section “Or, “if” a new subclassÂ…” Section 7.3.32 page 97 Change “These constraint” to “These constraints” Section 7.3.32 page 98 Delete word “is” in 2nd sentence of Notation “In general, the notation will include a multiplicity specification shown asÂ…” Section 7.3.37 page 111 Change “is” to “are” in 4th paragraph of Semantics “The public contents of a package areÂ…” Subject of the sentence is contents not package. Section 7.3.49 page 135 and page 136 (Description) Change verb “specify” to “specifies” in “A structureal feature is a typed feature of a classifier that specifies the structureÂ…” Section 7.3.49 page 137 Change verb from “signifies” to signifying” in 1st sentence of Decsription Section 7.3.53 page 139 Delete word “of” in 1st sentence of Semantics

  • Reported: UML 2.0 — Fri, 21 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Clarify the differences between redefining element and redefined element.

  • Key: UML22-56
  • Legacy Issue Number: 8101
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Clarify the differences between redefining element and redefined element.

  • Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

All sections

  • Key: UML22-55
  • Legacy Issue Number: 8087
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    With the new format of putting all of the diagrams at the beginning of the chapters, I am finding it very difficult to determine which diagram goes with what sub-section. Add references in the text to the diagram most applicable to the descriptions/definitions

  • Reported: UML 2.0 — Fri, 14 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.11

  • Key: UML22-64
  • Legacy Issue Number: 8126
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    According to fig. 97, Associations need multiplicities added to all and derived symbol to required:Interface and provided:Interface. Add OCL notation to Constraints

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.2

  • Key: UML22-63
  • Legacy Issue Number: 8119
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    "In a system context where there are multople components that provide or require a particular interface, a notation abstraction can be used that combines by joining the multiple connectors." Combines what? Client keyword missing from fig. 93.

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    I cannot find any such text in section 8.3.2, or indeed anywhere in the current specification.

    Revised Text:
    None.

    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

constrainedElement direction

  • Key: UML22-51
  • Legacy Issue Number: 8020
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    constrainedElement direction The association between Constraint and Element named "constrainedElement" is unidirectional from Constraint to Element. This means implementations are not required to provide efficient navigation from an element to the constraints on it. Since the constraints of a model element are part of the definition of that element, the required navigation should at least be from the element to the constraint.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    A Constraint can constrain multiple constrainedElements and, thus, is not necessarily owned by any one of them. In
    this sense, the Constraint is not, in general, part of the formal “definition” of the constrainedElements. Rather, if
    the Constraint has a context (which may or may not be a constrainedElement), then it is more proper to think of the
    constraint as part of the definition of that context, and the context association end is navigable.
    Further, one wants to be able to add constraints to elements of the model without having tomodify an owned property
    of the elements being constrained, but making the association from Element to Constraint would imply (by the usual
    UML abstract syntax metamodel conventions) that the “constraint” association end would become owned by Element.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Derived union notation

  • Key: UML22-52
  • Legacy Issue Number: 8022
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Derived union notation Why is the semantics and notation for subsetting/redefinition in Association, while derived union is in Property?

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.7

  • Key: UML22-61
  • Legacy Issue Number: 8114
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Correct multiplicity of role:ConnectableElement[1] so that fig. 96 agrees with that defined in Associations. Add OCL notation for Constraints. Ports under Notation also reads to me like it could be expressed in OCL notation somewhere--like a constraint which would need to be added.

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.6

  • Key: UML22-60
  • Legacy Issue Number: 8113
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Need OCL notation for Constraints. Correct page reference number for StructuredClassifier

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.2

  • Key: UML22-62
  • Legacy Issue Number: 8118
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Reword/rewrite the last two paragraphs of Semantics. Many grammatical mistakes between sentence subject and verb plurality (because of intervening phrases), hard to understand sentences, and an incomplete sentence (last one).

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    I cannot find any such problem in section 8.3.2. However I do find the following, which has duplicated text:
    "A component's behavior may typically be realized (or implemented) by a number of Classifiers. In effect, it forms an abstraction for a collection of model elements. In that case, a component owns a set of Component Realization Dependencies to these Classifiers. In effect, it forms an abstraction for a collection of model elements. In that case, a component owns a set of Realization Dependencies to these Classifiers"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.2

  • Key: UML22-58
  • Legacy Issue Number: 8106
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Constraints have no OCL syntax or mention that constraints are not definable in OCL. Type in constraint [5] - delete "s" from first "Ports".

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This actually refers to 8.3.3. The constraints have been fixed or deleted by other resolutions (7247-7251).

    Revised Text:
    None.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.4

  • Key: UML22-59
  • Legacy Issue Number: 8111
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    OCL notation is missing from Constraints. Please add or add note that OCL notation is not able to express constraints

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • 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: Fri, 6 Mar 2015 20:58 GMT

Relations

  • Key: MOF24-42
  • Legacy Issue Number: 8751
  • Status: closed  
  • Source: gmx.net ( Markus Brigl)
  • Summary:

    All relations should be descended somehow from Relation, or DirectedRelation if that applies. Then all the diagrams could be traversed with the DirectedRelationship API as generic graphs. For example, the arcs on behavioral models should be descended from directed relations.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    It is not clear that all connections between elements in the UML2 model are a kind of Relationship or DirectedRelationship. A better way to achieve generic traversal is to use MOF reflection to navigate metaclass containment associations. Tools would be free to merge MOF2 Reflection into UML2 compliance levels to provide this capability. If this change were to be made it could have a significant impact on existing implementations and, therefore, is outside the scope of an RTF

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 107

  • Key: UMLR-75
  • Legacy Issue Number: 9145
  • Status: open  
  • Source: University College London ( James Skene)
  • Summary:

    I'm attempting to implement a JMI repository for the UML2 superstructure. This is made more difficult by the use of package merge in the model. The following issues should be clarified in the definition of package merge: 1. Do classifiers in the resulting package extend classifiers in the merged package? If they do: The meta-model must contain all infrastructure packages and extension packages defined in the superstructure spec e.g. 'ProtocolStateMachines', 'PackagingComponents' etc., in order to facilitate reflective access to instances of types defined in these packages. However, these packages are not collected in one or more sensible enclosing namespaces (e.g. root 'infrastructure' and 'superstructure' packages), so the root namespace will be cluttered. Root packages for these elements should therefore be introduced in the infrastructure and superstructure specifications. If they do not: Some infrastructure packages will still be needed in the resulting meta-model, because the infrastructure specification uses import + generalisation rather than merge to establish the relationships between packages, e.g. in core::abstractions. For conformance level 0, instances of types in package UML would therefore not be instances of types in core::basic, because this package is merged into UML. However, they would be instances of types in other infrastructure packages, e.g. core::abstractions::elements::Element, because core::basic imports this type, rather than merging it. This seems illogical. Why should core::abstractions::elements have instances in this case, but not core::basic? This could be corrected by using merge in the infrastructure spec, hence avoiding dragging imports into the UML package. However, using merge in this way means redefining the semantics for each copy of the same type, which is why there is so much unnecessary duplication in the infrastructure and superstructure specs. In both interpretations of merge, infrastructure classes and packages penetrate the UML meta-model, leading to a lack of good namespace organisation. This has an impact on the ease with which reflection can be used in the repository. 2. On page 107 the specification states that the use of explicit merges and pre-applied merges in a meta-model is equivalent with regards to the semantics of the meta-model. This is false when reflection is considered, as the meta-model retreived by reflective methods will be different depending on the approach taken. This is significant: To retrieve all features of a classifier where merge has been used in the meta-model, you need not only to recurse the generalisation hierarchy, but also the package containment hierarchy to determine if any containing package is the recipient of a merge that could modify the features of the classifier. This is highly inconvenient. My recommendation to address these problems is that classifiers in a package that is the recipient of a merge should be defined to generalise matching types in the merged package. The package structure of the infrastructure and superstructure specifications should be revised to reflect the fact that most packages and types defined in the specification will therefore be retained in any UML2 specification. Alternatively, use merge rather than import in the infrastructure specification, with the prescription that meta-models accessed by reflection must have the merges rolled out. Also therefore provide explicit documentation of the rolled out meta-models for the various conformance levels for the superstructure.

  • Reported: UML 2.0 — Thu, 10 Nov 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Classes

  • Key: UMLR-70
  • Legacy Issue Number: 9008
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    In Classes, Association, Semantics says: "Subsetting represents the familiar set-theoretic concept. It is applicable to the collections represented by association ends, not the association itself." and "Specialization is, in contrast to subsetting, a relationship in the domain of intensional semantics, which is to say it characterized the criteria whereby membership in the collection is defined, not by the membership. One classifier may specialize another by adding or redefining features; a set cannot specialize another set. A naive but popular and useful view has it that as the classifier becomes more specialized, the extent of the collection(s) of classified objects narrows. In the case of associations, subsetting ends, according to this view, correlates positively with specializing the association. This view falls down because it ignores the case of classifiers which, for whatever reason, denote the empty set. Adding new criteria for membership does not narrow the extent if the classifier already has a null denotation." ISSUE: It is the semantics of Generalization in UML is that all the instances of the subtype are instances of the supertype, so subtyping in UML implies subsetting. It is not necessarily proper subsetting, however, as the example above shows. Subsetting in UML can be achieved by subtyping (adding attributes, etc), but can only be done by adding constraints to the subtype. Also, for association classes, the user should be able to specialize an association class with another association class with the same semantics as subsetting ends.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Classes

  • Key: UMLR-72
  • Legacy Issue Number: 9015
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Classes should be able to support interfaces without being a BehavioredClassier (see figure 16). This introduces an unnecessary dependency of Classes on CommonBehavior

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Activities

  • Key: UMLR-71
  • Legacy Issue Number: 9013
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What is the effect of unique association ends the actions for creating and deleting links? For example, what if one end is unique and the other not?

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Properties on Association for end objects

  • Key: UMLR-40
  • Legacy Issue Number: 8077
  • Status: open  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    The memberEnd/ownedEnd/NavigableOwnedEnd properties of Association represent the navigations from one end object to other end objects along the association. There are no properties available for navigating from an instance of an association (link) to the end objects. This has a number of negative effects: - The model cannot represent structured associations properly, because association classes that are also structured classifiers cannot have connectors to end objects, because the end objects cannot be reached with StructuredClassifier.role (see constraint 3 on Connector). - An InstanceSpecification for link can use memberEnd properties of association as properties of the link, even though these properties are ownedAttribute of the end classes, rather than the association. This is due to the loose definition of Classifier.allFeatures. - A special action is needed to retrieve (the end objects of links (ReadLinkObjectEndAction), rather than (using the action for attribute values ReadStructuralFeatureAction. The metamodel should have an association for properties that have the end objects of link objects as values.

  • Reported: UML 2.0 — Wed, 5 Jan 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for classifierBehavior

  • Key: UMLR-39
  • Legacy Issue Number: 8034
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Need a notation for instances of the classifierBehavior metaassociation (Figure 311).

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Contextualized attribute values Figures 121

  • Key: UMLR-38
  • Legacy Issue Number: 8026
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Contextualized attribute values Figures 121 is an unworkable solution to defining contextualized attribute values. It requires restating all the parts and connectors in the composite class, otherwise the constructor would be incomplete. The class-based solution requires separate properties for each contextualized value with connectors to them from the contextualized property. The metamodel should be extended to include contextualized datatype properties, or at least a presentation option for the current cumbersome model (see Figure 12 and discussion in http://www.jot.fm/issues/issue_2004_11/column5

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ReadStructuralFeatureAction

  • Key: UMLR-42
  • Legacy Issue Number: 8335
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    This issue concerns the ReadStructuralFeatureAction. This action reads the values of a structural feature, in order if the structural feature is ordered. According to the sepcification, the multiplicity of the structural feature must be compatible with the multiplicity of the output pin, so the output pin will contain all the values of the structural feature. There is no way to read the value of a single element from a multi-valued structural feature without reading all its values. Adding an input pin (readAt) to ReadStructuralFeatureAction would allow this. This input pin would represent the index of the value we want to read in the structural feature. This issue stands for ReadVariableAction as well.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Classes, Behavior

  • Key: UMLR-34
  • Legacy Issue Number: 8012
  • Status: open  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    There doe snot appear to be a way to model parameters to operations that are multi-dimensional arrays. In general, such arrays can be modeled based on qualifiers. However, this assumes that there is an association between two Classifiers. This doesn't apply to parameters. Note that Parameters are MultiplicityElements, but that only allows the modeling of single dimensions.

  • Reported: UML 2.0 — Wed, 29 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

End objects of a link In the semantics of AssociationClass

  • Key: UMLR-37
  • Legacy Issue Number: 8024
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    End objects of a link In the semantics of AssociationClass, it says: It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at each end , i.e. from the instance point of view, the multiplicity of the associations ends are "1". Two comments: - This is applicable to Association generally. - The portion after "i.e" is misleding. Instances have no multiplicity.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Action for retrieving activity instance

  • Key: UMLR-36
  • Legacy Issue Number: 8016
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Action for retrieving activity instance: There should be an action for getting the instance of the activity class currently executing, for reflective applications.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Activities section

  • Key: UMLR-44
  • Legacy Issue Number: 8473
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Add presentation option for multiple object flows between two actions, shown as one line.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 16.3.1

  • Key: UMLR-43
  • Legacy Issue Number: 8464
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete sub-sections Attributes and Rationale as there are none. I question, in light of Constraint [1] and the second paragraph in sub-section Semantics, that there are no associations for an actor. Both constraint [1] and Semantics clearly indicate that there are associations and the Semantics paragraph even indicates multiplicity possibilities greater than one. Figure 401 shows no navigability and association between UseCase and Actor although both Constraint [1] and Semantics indicate that there should be some. Typo - There are eleven "(" but only ten ")" in constraint [1]. Personal preference - Restate Changes from previous UML to "The additon of the constraint that requires that all actors must have names has been added."

  • Reported: UML 2.0 — Fri, 4 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add constraints on ConditionalNode

  • Key: UMLR-48
  • Legacy Issue Number: 8495
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraints on ConditionalNode to ensure the test and body are owned by the conditional node (or have them owned by the clause with body outputs being referred to by a single clause. This would prevent sharing bodies across clauses It is unclear if this is much of a benefit, since changing the body of one clause will change another, which may not be the intention.).

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ExpansionRegion (behavior in the shorthand notation)

  • Key: UMLR-47
  • Legacy Issue Number: 8489
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In ExpansionRegion, clarify that the behavior in the shorthand notation must have exactly one return parameter

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Activities : Why is exception type needed?

  • Key: UMLR-46
  • Legacy Issue Number: 8480
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint in ExceptionHandler that exception type must be compatible with the exception handler input. Why is exception type needed?

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Activities - clarification

  • Key: UMLR-45
  • Legacy Issue Number: 8479
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify the constraints on ExceptionHandler, that results must be output pins introduced on structured nodes in CompleteStructuredActivities.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 7

  • Key: UMLR-103
  • Legacy Issue Number: 10345
  • Status: open  
  • Source: NUI Maynooth ( Jacqueline McQuillan)
  • Summary:

    There is no way to indicate that an Operation is an abstract Operation, perhaps the Operation class should have an isAbstract attribute?( similar to the way the Classifer class has an isAbstract attribute to indicate that its abstract)

  • Reported: UML 2.0 — Tue, 12 Sep 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 14.3.3 Page: 508+

  • Key: UMLR-59
  • Legacy Issue Number: 8765
  • Status: open  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    Sequence diagrams are often used for early specification of requirements. The distinction between potential and mandatory behavior is not adequately described in UML 2.0 Interactions. To improve this we suggest an additional operator "xalt" that describes alternative operands that are mandatory meaning that any refinement should keep at least some of the behavior of each operand. See paper at <<UML2003>>: Haugen, Stølen: STAIRS - Steps to Analyze Interactions with Refinement Semantics

  • Reported: UML 2.0 — Wed, 4 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 14.3.3

  • Key: UMLR-58
  • Legacy Issue Number: 8764
  • Status: open  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    In sequence diagrams, the neg operator is used to describe invalid behaviours. However, people tend to interpret neg slightly differently depending on the context in which it appears, thus making it difficult to define a precise semantics for it. Two examples: A sequence diagram with a neg fragment is usually taken to describe also positive (valid) behaviours, i.e. the behaviours of the diagram with the neg fragment simply omitted. This implies that the empty trace should be positive for the neg fragment in this context. Another common use of neg is to state that one of the alternatives (operands) of an alt construct describes the invalid behaviour. In this case, the neg fragment has no positive behaviours (not even the empty trace). Recommendation: Consider introducing another operator in addition, due to the different uses of the neg operator.

  • Reported: UML 2.0 — Wed, 4 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 10.3.1

  • Key: UMLR-51
  • Legacy Issue Number: 8693
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Bidirectional association between artifact and operation required Fig. 124 on page 205 show an unidirectional association from artifact to operation. In the context of the Actions it is necessary to access the owner of an operation. Therefore the association must be bidirectional.

  • Reported: UML 2.0 — Sun, 10 Apr 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ConditionalNode inputs used by more than one test

  • Key: UMLR-60
  • Legacy Issue Number: 8779
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ConditionalNode inputs used by more than one test. In ConditionalNode, the tokens in input pins might be consumed by one test body execution and not available to another. They need a similar mechanism to LoopNode that copies the inputs to test body in puts and destroys the original inputs when the loop node is done

  • Reported: UML 2.0 — Sun, 15 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Possibility to define a Collection as default Value needed

  • Key: UMLR-55
  • Legacy Issue Number: 8756
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Multiple default values. In Figures 10 and 12, the max multiplicity for defaultValue is 1. What if the property or parameter is multivalued? There is no value specification for collections.

  • Reported: UML 2.0 — Tue, 3 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

SequenceNode should have way to set output pins in CompleteStructured

  • Key: UMLR-49
  • Legacy Issue Number: 8501
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    SequenceNode should have way to set output pins in CompleteStructured, like ConditionalNode and LoopNode do.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: Sequence diagrams

  • Key: UMLR-80
  • Legacy Issue Number: 9370
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A "par"-like operator with two concurrent regions where one region is interrupted when the other is completed. According to me, the only way to express the same semantics today is to use many nested "opt" operators, which is not practical. I am under the impression that this should be quite a common need.

  • Reported: UML 2.0 — Tue, 21 Feb 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Alternative entry and exit point notation is ambiguous

  • Key: UMLR-32
  • Legacy Issue Number: 7952
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Alternative entry and exit point notation is ambiguous. It is not clear if it relates to an entry point or to an exit point.

  • Reported: UML 2.0 — Mon, 29 Nov 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

More explanation needed on Figure 339

  • Key: UMLR-3
  • Legacy Issue Number: 6086
  • Status: open  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    The Figure 339 on page 425 needs more explanation. The use of lifelines to represent return value, and the notation for interaction occurrences with return value should be explained in greater length. Furthermore it should be made clear how the operations put and get are used to set and read values from lifelines representing attributes and parameters.

  • Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

More examples

  • Key: UMLR-2
  • Legacy Issue Number: 6083
  • Status: open  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    The Interaction chapter contains a number of examples, but there have been requests for even more examples especially on the different kinds of combined fragments (Section 14.3.1)

  • Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Parameterization of lifelines

  • Key: UMLR-4
  • Legacy Issue Number: 6088
  • Status: open  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    In general there is a need to have lifelines as formal parameters such that Interactions can be used in slightly different contexts. This may now be partly achieved through templates, but more notation etc. is needed for this to be really practical.

  • Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class R

  • Key: UMLR-19
  • Legacy Issue Number: 6922
  • Status: open  
  • Source: Fraunhofer FOKUS, Germany ( Michael Soden)
  • Summary:

    Redefinitions of OCL constraints must be aligned with MOF2.0/UML2.0 class Redefinition. I could not find any detailed information with respect to redefinition of (especially OCL class OclExpression) constraints in the docs ptc/03-09-15, ptc/03-10-04. A more precise semantic would help for the QVT redefinitions w.r.t patterns and technology mappings interoperability (JMI <> MOF2IDL alignment).

    Proposed resolution: It would be useful to add more precise abstract semantic for redefinition contexts of constraints (e.g. class 'Constraint' should specify that redefinition context must also be inheritance)

  • Reported: UML 2.0 — Mon, 19 Jan 2004 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

inconsistency in the action model

  • Key: UMLR-27
  • Legacy Issue Number: 7337
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    There is an inconsistency in the action model between actions for StructuralFeatures in general, and actions operating on links. The family of structural feature action, such as WriteStructuralFeatureAction, are defined for any kind of structural feature. Consequentially, these actions can manipulate values that are not due to attributes or assication ends (both special cases of Property) but of any kind of StructuralFeature. However, actions defined for links can only operate on links that are due to associations in the model. This because LinkEnd is identified through the association to a Property (named "end"). However, there are other links in the model, such as those due to Connectors. To make these consistent, one either should limit the structural feature actions to apply to Properties (rather than StructuralFeatures), or one should generalize the link actions to apply to liks identified by any StructuralFeature, not just to links identified by Properties. This difference in generality does, of course, not matter for the UML as defined, but it could hamper the deployment of actions to profiles that define other kinds of links. (This is, luckily, not a problem for links due to Connectors, as we can argue that for links due to connectors that are not explicitly typed, these are identified by the ends of the derived associations.)

  • Reported: UML 2.0 — Sat, 15 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

large overlap between structural features and variables

  • Key: UMLR-26
  • Legacy Issue Number: 7329
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    There is large overlap between structural features and variables. For example, examine the structural features actions and compare them to variable action. Upon study, one will discover that structural features and variables have much more in common. In fact, the following equation seems to hold: StructuralFeature = Variable + Feature That is: a variable denotes a location able to hold an instance. A structural feature is a feature of an object and denotes a location ale to hold an instance. Therefore, I suggest that StructuralFeature be made a subtype of Variable. In the infrastructure, variable would have no interpretation, other than being an abstract metaclass indicating the ability to hold a value. In the superstructure, variable is concrete as described in Activities. Not only would this allow to eliminate the duplication of actions related to accessing variables, but also, other duplications (as, e.g., with respect to their being connectable elements and the related explanations) could be avoided.

  • Reported: UML 2.0 — Sun, 9 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

metaattribute isReadOnly

  • Key: UMLR-28
  • Legacy Issue Number: 7338
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The metaattribute isReadOnly is defined both for StructuralFeature and its subclass Property. Clearly, one or the other is incorrect. This, I believe, points to an unclarity in what StructuralFeatures are, as opposed to Property. By definition, StructuralFeatures denote values that are held in slots of an object. I believe that the intuition behind Property is that a property denotes a value that might be added, modified, or deleted during the course of the lifetime of a system. This is exemplified in the two variants of property: attribute and association end. As "isReadOnly" has to do with limiting the modification of the value, it is best placed on Property, assuming this intuition is correct. This intuition is substantiated by that Port is not a property but a structural feature, and ports cannot be modified, changed, or assigned to. (Note that if this intuition is not correct, the difference between Property and StructuralFeature needs to be clarified.) A consequence of this is also that one needs to clarify the set of actions that apply to StructuralFeatures (e.g., WriteStructuralFeatureAction). If it is Properties that are modified, etc., then these actions should really apply to properties, not structural features in general. Again, this change is consistent, as none of these actions makes sense for Ports. Further, for links the actions are already limited to properties (see LinkEndData). An issue regarding the inconsistency between actions applying to structural features and actions applying to links has been submitted and should be dealt with consistently.

  • Reported: UML 2.0 — Sat, 15 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

surface notation for state machines

  • Key: UMLR-29
  • Legacy Issue Number: 7372
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The surface notation for state machines allows to show, on the line representing a transition, certain key actions that will be performed by the behavior associated with the transition. This is straightforward, when the behavior is an activity (as those actions can be referenced). However, for any other behavior, e.g., an opaque behavior, we need a method of (in the metamodel) show that this behavior does contain certain actions. Note that this should not give an alternative way of defining sequences of actions; rather, this should merely state that this behavior will contain the exhibited actions but it may contain many more. Those actions would merely give a means of representing the graphical constructs in the metamodel

  • Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide exception handling for all behaviors.

  • Key: UMLR-30
  • Legacy Issue Number: 7398
  • Status: open  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    UML2 has added the capability of dealing with exceptional behavior. Exception handling can occur at various levels of the model. Unfortunately, the exception handling mechanism has not been systematically developed. Any kind of behavior should support the mechanism of catching and handling an exception that was raised somewhere within that behavior. Unfortunately, currently only activities allow for this. Similar capabilities should be available for interactions and statemachines, and even for use cases. Recommendation: Provide exception handling for all behaviors.

  • Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT