Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — Closed Issues

  • Acronym: UML
  • Issues Count: 3,267
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
UML22-21 UML 2 Issue: isUnique UML 1.5 UML 2.2 Resolved closed
UML22-457 New proposal for conjugate types for ports UML 2.1.2 UML 2.2 Resolved closed
UML22-459 Semantics of Ports in Components and CompositeStructures are incompatible UML 2.1.2 UML 2.2 Resolved closed
UML22-319 Explanation of Observation notation UML 2.1 UML 2.2 Resolved closed
UML25-345 Location: 9.6.4 Notation p 128: Confusing indentation UML 2.4.1 UML 2.5 Resolved closed
UML22-307 Repr. of applied stereotypes and their properties insufficiently described UML 2.1 UML 2.2 Resolved closed
UML25-684 Typo in Interaction Example UML 2.5b1 UML 2.5 Duplicate or Merged closed
UML22-1381 presentation option for transitions UML 2.0 UML 2.1.1 Resolved closed
UML14-1046 Type vs. Implementastion class UML 1.1 UML 1.2 Resolved closed
UML22-1380 Section: 7.3.10/Associations UML 2.1.2 UML 2.2 Duplicate or Merged closed
UML14-1045 Compliance ambiguity UML 1.3 UML 1.4 Duplicate or Merged closed
UML14-1044 Wording od OCL definition UML 1.1 UML 1.2 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
UML2-4 section 8.3.2, a "Connector" UML 1.5 UML 2.0 Resolved closed
UML2-3 Property.association UML 1.5 UML 2.0 Resolved closed
UML2-2 Activity Diagrams: Relax Traverse-to-Completion semantics UML 1.5 UML 2.0 Resolved 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
UML241-47 No unambiguous way in UML 2.4 to serialize StructuredActivityNode UML 2.4 UML 2.4.1 Resolved closed
UML24-152 navigation only possible to generalization but not to specializations of elements UML 2.3 UML 2.4 Closed; No Change closed
UML23-155 Japan Superstructure PAS Ballot Comments - comment 9 UML 2.2 UML 2.3 Resolved closed
UML23-154 New proposal for conjugate types for ports UML 2.1.2 UML 2.3 Resolved closed
UML23-153 proper content for Figure 13.8 UML 2.1 UML 2.3 Closed; No Change closed
UML23-152 Section: 15.3.8 UML 2.1.1 UML 2.3 Resolved closed
UML23-151 Section: 14.3.20 UML 2.0 UML 2.3 Resolved closed
UML22-1375 7.3.41 Parameter (from Kernel, AssociationClasses)" UML 2.1 UML 2.1.2 Resolved closed
UML23-150 UML 2 Super / Activities / missing subsets UML 2.1 UML 2.3 Resolved closed
UML22-1374 Profiles::ObjectNode has wrong default multiplicity UML 2.1 UML 2.1.1 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
UML25-682 InformationFlow cannot have an Activity as source or target UML 2.4.1 UML 2.5b1 Resolved closed
UML25-681 Location p 162 ParameterSet associationends: Exceptions and parametersets UML 2.4.1 UML 2.5b1 Resolved closed
UML23-147 LiteralReal has no default value. It would make sense if it had a value of 0 as for LiteralInteger. UML 2.2 UML 2.3 Resolved closed
UML14-1043 Change syntax of certain pre-defined operations UML 1.2 UML 1.3 Resolved closed
UML14-1042 Package symbol as a polygon UML 1.1 UML 1.3 Resolved closed
UML25-680 Profile::references_same_metamodel UML 2.5b1 UML 2.5 Resolved closed
UML25-679 Operation::isConsistentWith() UML 2.5b1 UML 2.5 Resolved closed
UML25-678 redefined states UML 2.5b1 UML 2.5 Resolved closed
UML25-677 Event pools for passive objects? UML 2.5b1 UML 2.5 Resolved closed
UML25-676 Who owns MessageEnds? UML 2.5b1 UML 2.5 Resolved closed
UML23-146 UML 2 chapter 17: template model cannot represent templates parameterized by value types UML 2.2 UML 2.3 Resolved closed
UML22-1372 Instance modeling does not take into account stereotypes properties UML 2.1.2 UML 2.2 Resolved closed
UML22-1371 Comments owned by Packages (02) UML 2.1.2 UML 2.2 Resolved closed
UML22-1370 Comments owned by Packages UML 2.1.2 UML 2.2 Resolved closed
UML22-1369 section 15.3.14 Transition :: Constraints UML 2.1.2 UML 2.2 Resolved closed
UML22-1368 Regarding the quote on p128 UML 2.1.2 UML 2.2 Resolved closed
UML22-1367 Section: Composite Structures/Abstract syntax UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1366 ptc/06-01-02:14.3.14, Notation UML 2.1 UML 2.1.1 Resolved closed
UML22-1365 Events UML 2.0 UML 2.1 Resolved closed
UML22-1364 Additional events for Interactions UML 2.0 UML 2.1 Resolved closed
UML22-1363 Incorrect constraints on Pin and ObjectFlow On Pin UML 2.0 UML 2.1 Resolved closed
UML22-1362 resolution to issue 6093 removed too much constraint UML 2.0 UML 2.1 Resolved closed
UML22-1361 Section: 9.3.12 UML 2.0 UML 2.1 Resolved closed
UML22-1360 Section: 7.11.4 UML 2.0 UML 2.1 Resolved closed
UML22-1359 Notation for property has gone missing UML 2.0 UML 2.1 Resolved closed
UML22-1358 ReadSelfAction UML 2.0 UML 2.1 Resolved closed
UML22-1357 Attribute scope is of type StructuredActivityNode instead of StructuredActi UML 2.0 UML 2.1 Resolved closed
UML22-1356 Section: 12.3.16 UML 2.0 UML 2.1 Resolved closed
UML22-1355 What are the "edges" we're talking about? UML 2.0 UML 2.1 Resolved closed
UML22-1354 Section: 12.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-1353 Figure 205, p292: UML 2.0 UML 2.1 Resolved closed
UML22-1350 Figure 51, p106 UML 2.0 UML 2.1 Resolved closed
UML22-1349 ExceptionHandler UML 2.0 UML 2.1 Resolved closed
UML22-1352 figure 175 UML 2.0 UML 2.1 Resolved closed
UML22-1351 Figure 52, p107: shouldn't the <> relationship be reversed ? UML 2.0 UML 2.1 Resolved closed
UML22-1348 Section: 12.3.16 -- Typo UML 2.0 UML 2.1 Resolved closed
UML22-1347 Templates, Classifier UML 2.0 UML 2.1 Resolved closed
UML22-1346 ProtocolConformance - inconsistency with Figure 356 UML 2.0 UML 2.1 Resolved closed
UML22-1341 Can connectors co-operate? UML 2.0 UML 2.1 Resolved closed
UML22-1345 ParameterableElement - constraint [2] - error in OCL UML 2.0 UML 2.1 Resolved closed
UML22-1344 TemplateableElement - inconsistency UML 2.0 UML 2.1 Resolved closed
UML22-1343 TemplateSignature - Typo UML 2.0 UML 2.1 Resolved closed
UML22-1342 TemplateSignature - inconsistency UML 2.0 UML 2.1 Resolved closed
UML22-1338 association "implementingClassifier UML 2.0 UML 2.1 Resolved closed
UML22-1340 Removed text in 9.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-1339 $issue.summary UML 2.0 UML 2.1 Resolved closed
UML22-1337 PrimitiveFunction UML 2.0 UML 2.1 Resolved closed
UML22-1336 MarshallAction and UnmarshallAction UML 2.0 UML 2.1 Resolved closed
UML22-1335 Constraint 2 of AcceptEventAction - typo UML 2.0 UML 2.1 Resolved closed
UML22-1334 SAN semantics for starting and stopping UML 2.0 UML 2.1 Resolved closed
UML22-1333 Variable pins Extend input and output pins to get and set variables UML 2.0 UML 2.1 Resolved closed
UML22-1332 Activities UML 2.0 UML 2.1 Resolved closed
UML22-1331 p.352, section 12.3.35. The attribute Parameter.isStream is inappropriate UML 2.0 UML 2.1 Resolved closed
UML22-1330 empty sections in activities chapter UML 2.0 UML 2.1 Resolved closed
UML22-1329 p.328, Figure 245, and p.331, Figure 249 UML 2.0 UML 2.1 Resolved closed
UML22-1328 Inappropriate to reference RFP documents UML 2.0 UML 2.1 Resolved closed
UML22-1327 attribute Activity.isSingleExecution UML 2.0 UML 2.1 Resolved closed
UML22-1326 Section 9.3.5. (ConnectableElement) UML 2.0 UML 2.1 Resolved closed
UML22-1325 Section 9.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-1324 typo UML 2.0 UML 2.1 Resolved closed
UML22-1323 typo UML 2.0 UML 2.1 Resolved closed
UML22-1322 component deployment UML 2.0 UML 2.1 Resolved closed
UML22-1321 signal UML 2.0 UML 2.1 Resolved closed
UML22-1320 association between two Nodes UML 2.0 UML 2.1 Resolved closed
UML22-1319 Figure 273 - Arrow direction Figure 273 UML 2.0 UML 2.1 Resolved closed
UML22-1318 ParameterSet - Typo UML 2.0 UML 2.1 Resolved closed
UML22-1317 ObjectNode UML 2.0 UML 2.1 Resolved closed
UML22-1316 ActivityEdge - Typo UML 2.0 UML 2.1 Resolved closed
UML22-1315 ActivityEdge - Section Semantics - Typo UML 2.0 UML 2.1 Resolved closed
UML22-1313 formal parameter or a return result UML 2.0 UML 2.1 Resolved closed
UML22-1314 typo p. 149 UML 2.0 UML 2.1 Resolved closed
UML22-1312 association "context" UML 2.0 UML 2.1 Resolved closed
UML22-1311 behaviors UML 2.0 UML 2.1 Resolved closed
UML22-1309 Page: 589 UML 2.0 UML 2.1 Resolved closed
UML22-1308 Section: 12.3.20 UML 2.0 UML 2.1 Resolved closed
UML22-1307 enumerated type MessageSort UML 2.0 UML 2.1 Resolved closed
UML22-1310 There is no redefinitionContext established UML 2.0 UML 2.1 Resolved closed
UML22-1306 heading of table 19 UML 2.0 UML 2.1 Resolved closed
UML22-1305 Notation of ExecutionOccurrence UML 2.0 UML 2.1 Resolved closed
UML22-1304 Section: 15.3.12 UML 2.0 UML 2.1 Resolved closed
UML22-1303 introductory text for Property states UML 2.0 UML 2.1 Resolved closed
UML22-1301 notation for statemachine transitions omitted from spec UML 2.0 UML 2.1 Resolved closed
UML22-1300 behavior packages (Interactions, Statemachines UML 2.0 UML 2.1 Resolved closed
UML22-1302 "Implementation" is ommitted UML 2.0 UML 2.1 Resolved closed
UML22-1299 InformationItem - Typo UML 2.0 UML 2.1 Resolved closed
UML22-1298 ReadLinkObjectEndQualifierAction - errors in OCL UML 2.0 UML 2.1 Resolved closed
UML22-1296 StartOwnedBehaviorAction - OCL error in constraint UML 2.0 UML 2.1 Resolved closed
UML22-1297 ReadLinkObjectEndAction - errors in OCL UML 2.0 UML 2.1 Resolved closed
UML22-1294 ReplyAction - Typo UML 2.0 UML 2.1 Resolved closed
UML22-1293 ReplyAction - Inconsistency with Figure 150 UML 2.0 UML 2.1 Resolved closed
UML22-1292 AcceptCallEvent - inconsistent multiplicity "• trigger UML 2.0 UML 2.1 Resolved closed
UML22-1295 ReadIsClassifiedObjectAction - OCL errors in constraints UML 2.0 UML 2.1 Resolved closed
UML22-1291 AcceptEventAction - inconsistencies in Semantics and typos UML 2.0 UML 2.1 Resolved closed
UML22-1290 AcceptEventAction - inconsistency UML 2.0 UML 2.1 Resolved closed
UML22-1289 AcceptEventAction - inconsistent multiplicities UML 2.0 UML 2.1 Resolved closed
UML22-1288 Message - inconsistency "Messageident equalling ‘*’ UML 2.0 UML 2.1 Resolved closed
UML22-1287 Message - inconsistency (02) UML 2.0 UML 2.1 Resolved closed
UML22-1286 Message - inconsistency UML 2.0 UML 2.1 Resolved closed
UML22-1285 Figure 77 UML 2.0 UML 2.1 Resolved closed
UML22-1284 Interface - Typos in Figure 63 UML 2.0 UML 2.1 Resolved closed
UML22-1282 Connector - inconsistency UML 2.0 UML 2.1 Resolved closed
UML22-1281 Connector - typo and inconsistency UML 2.0 UML 2.1 Resolved closed
UML22-1283 ConnectorEnd - multipliciy of role UML 2.0 UML 2.1 Resolved closed
UML22-1280 Connector - inconsistency UML 2.0 UML 2.1 Resolved closed
UML22-1279 Typo in ptc/03-08-02 p. 178 UML 2.0 UML 2.1 Resolved closed
UML22-1278 Typo Section: 12.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-1275 Stereotype - Inconsistency in notation Section "Notation", last sentence UML 2.0 UML 2.1 Resolved closed
UML22-1274 Stereotype - typo in OCL UML 2.0 UML 2.1 Resolved closed
UML22-1277 ActivityPartition - inconsistencies UML 2.0 UML 2.1 Resolved closed
UML22-1276 Typo In section "Description" UML 2.0 UML 2.1 Resolved closed
UML22-1271 AddVariableValueAction - OCL in constraint [1] not correct UML 2.0 UML 2.1 Resolved closed
UML22-1273 Stereotype UML 2.0 UML 2.1 Resolved closed
UML22-1272 Typo, section "Description", paragraph 1 UML 2.0 UML 2.1 Resolved closed
UML22-1270 VariableAction - undefined query UML 2.0 UML 2.1 Resolved closed
UML22-1267 ReadLinkAction - Constraints use deprecated UML elements UML 2.0 UML 2.1 Resolved closed
UML22-1266 ReadLinkAction - inconsistency with Figure 147 UML 2.0 UML 2.1 Resolved closed
UML22-1269 Variable - Typo in Attributes UML 2.0 UML 2.1 Resolved closed
UML22-1268 DestroyLinkAction - Semantics based on non existing "settability addOnly" UML 2.0 UML 2.1 Resolved closed
UML22-1265 MultiplicityElement - section is obsolete UML 2.0 UML 2.1 Resolved closed
UML22-1264 LinkEndData - Additional operation not correct UML 2.0 UML 2.1 Resolved closed
UML22-1263 LinkEndData - Typo in OCL UML 2.0 UML 2.1 Resolved closed
UML22-1262 AddStructuralFeatureValueAction - Settability removeOnly does not exist UML 2.0 UML 2.1 Resolved closed
UML22-1260 DestroyObjectAction - inconsistency in constraints UML 2.0 UML 2.1 Resolved closed
UML22-1259 Component - problem with provided interfaces (see also Issue 6875, 6338) UML 2.0 UML 2.1 Resolved closed
UML22-1261 Typo - section Description, first sentence UML 2.0 UML 2.1 Resolved closed
UML22-1258 Manifestation - visual representation should be dashed arrow UML 2.0 UML 2.1 Resolved closed
UML22-1256 Deployment - keyword <> not introduced UML 2.0 UML 2.1 Resolved closed
UML22-1255 InteractionOccurrence - Syntax rules for name not clear UML 2.0 UML 2.1 Resolved closed
UML22-1257 DeploymentTarget - Missing OCL expression UML 2.0 UML 2.1 Resolved closed
UML22-1254 Figure 95 UML 2.0 UML 2.1 Resolved closed
UML22-1253 Connector - Constraint [3] not necessary ? UML 2.0 UML 2.1 Resolved closed
UML22-1252 Connector - Constraint [2] is inprecise UML 2.0 UML 2.1 Resolved closed
UML22-1251 ReadSelfAction - Typos in OCL constraints UML 2.0 UML 2.1 Resolved closed
UML22-1249 Typo UML 2.0 UML 2.1 Resolved closed
UML22-1248 Typo UML 2.0 UML 2.1 Resolved closed
UML22-1250 ReadSelfAction - delete constraint [4] UML 2.0 UML 2.1 Resolved closed
UML22-1247 TestIdentityAction - additional constraint UML 2.0 UML 2.1 Resolved closed
UML22-1246 TestIdentityAction- delete constraint [2] UML 2.0 UML 2.1 Resolved closed
UML22-1245 Typo UML 2.0 UML 2.1 Resolved closed
UML22-1244 DeleteObjectAction - delete constraint [1] UML 2.0 UML 2.1 Resolved closed
UML22-1241 SendSignalAction UML 2.0 UML 2.1 Resolved closed
UML22-1240 Delete the following sentence in section "Notation": UML 2.0 UML 2.1 Resolved closed
UML22-1243 CreateObjectAction - delete constraint [4] UML 2.0 UML 2.1 Resolved closed
UML22-1242 Typo UML 2.0 UML 2.1 Resolved closed
UML22-1239 Sentence not finished in section "Changes from previous UML" UML 2.0 UML 2.1 Resolved closed
UML22-1235 Collaboration - inconsistency with Figure 99 UML 2.0 UML 2.1 Resolved closed
UML22-1237 Typo in Figure 124 on page 182 UML 2.0 UML 2.1 Resolved closed
UML22-1236 StructuredClassifier - Regular expression for namestring too complicated UML 2.0 UML 2.1 Resolved closed
UML22-1238 Typo UML 2.0 UML 2.1 Resolved closed
UML22-1233 GeneralizationSet - constraints expressed in OCL UML 2.0 UML 2.1 Resolved closed
UML22-1232 GeneralizationSet - Incorrect Mulitiplicities of associations UML 2.0 UML 2.1 Resolved closed
UML22-1234 GeneralizationSet - example in section "Semantics" is not clear UML 2.0 UML 2.1 Resolved closed
UML22-1231 GeneralizationSet description conf. about meaning of "specific" + "general UML 2.0 UML 2.1 Resolved closed
UML22-1230 GeneralizationSet - outdated description UML 2.0 UML 2.1 Resolved closed
UML22-1229 Region - Additional structural constraints necessary UML 2.0 UML 2.1 Resolved closed
UML22-1228 Constraint [2], p.70 UML 2.0 UML 2.1 Resolved closed
UML22-1227 Figure 355 - mulitplicities of redefinitionContext should be 0..1 UML 2.0 UML 2.1 Resolved closed
UML22-1226 Figure 355 - ownedStateMachine should subset ownedBehavior UML 2.0 UML 2.1 Resolved closed
UML22-1225 Typo p 497 UML 2.0 UML 2.1 Resolved closed
UML22-1221 State - Constraints - errors in OCL and inconsistencies UML 2.0 UML 2.1 Resolved closed
UML22-1223 Change Constraint [1] to UML 2.0 UML 2.1 Resolved closed
UML22-1222 Non-existent property isFinal referenced UML 2.0 UML 2.1 Resolved closed
UML22-1224 ownedStateMachine not described correctly UML 2.0 UML 2.1 Resolved closed
UML22-1220 Define containingStateMachine() for Vertex UML 2.0 UML 2.1 Resolved closed
UML22-1219 State - Inconsistency UML 2.0 UML 2.1 Resolved closed
UML22-1218 p.461, first sentence: UML 2.0 UML 2.1 Resolved closed
UML22-1216 AssociationClass - Additional Operation [1] should be deleted UML 2.0 UML 2.1 Resolved closed
UML22-1215 AssociationClass Constraint [1] should be reformulated UML 2.0 UML 2.1 Resolved closed
UML22-1214 Association - endType should be of type Classifier UML 2.0 UML 2.1 Resolved closed
UML22-1217 Constraints of ConnectionPointReference - OCL not correct UML 2.0 UML 2.1 Resolved closed
UML22-1213 Stereotype «buildComponent» defined twice, description not clear UML 2.0 UML 2.1 Resolved closed
UML22-1212 Typo p 589 UML 2.0 UML 2.1 Resolved closed
UML22-1210 ExtensionPoint should be a specialization of Feature (from Kernel) UML 2.0 UML 2.1 Resolved closed
UML22-1211 Typo p 587 UML 2.0 UML 2.1 Resolved closed
UML22-1209 Multiplicity of extensionLocation should be 1..1 instead of 1..* UML 2.0 UML 2.1 Resolved closed
UML22-1207 Constraint not precise enough UML 2.0 UML 2.1 Resolved closed
UML22-1206 Unnecessary sentence p 339 UML 2.0 UML 2.1 Resolved closed
UML22-1208 Imprecise sentence p 334 UML 2.0 UML 2.1 Resolved closed
UML22-1205 "Joining of tokens" not clear UML 2.0 UML 2.1 Resolved closed
UML22-1204 Typo p 339 UML 2.0 UML 2.1 Resolved closed
UML22-1203 Typo - Missing colon p 302 UML 2.0 UML 2.1 Resolved closed
UML22-1201 Constraint not precise enough UML 2.0 UML 2.1 Resolved closed
UML22-1200 Typo p 320 UML 2.0 UML 2.1 Resolved closed
UML22-1202 No Activity Edges from with equal source and target UML 2.0 UML 2.1 Resolved closed
UML22-1197 Typo p 161 UML 2.0 UML 2.1 Resolved closed
UML22-1196 Another Inconsistency with Figure 100 UML 2.0 UML 2.1 Resolved closed
UML22-1199 Multiple activity edges between a given pair of activity nodes possible ? UML 2.0 UML 2.1 Resolved closed
UML22-1198 Inconsistency between constraint of ControlNode and Semantics of JoinNode UML 2.0 UML 2.1 Resolved closed
UML22-1195 Inconsistency with Figure 100 UML 2.0 UML 2.1 Resolved closed
UML22-1194 Figure 103 at the wrong place UML 2.0 UML 2.1 Resolved closed
UML22-1193 Connector - default value für "kind" UML 2.0 UML 2.1 Resolved closed
UML22-1192 Typo p 137 UML 2.0 UML 2.1 Resolved closed
UML22-1191 Missing multiplicities UML 2.0 UML 2.1 Resolved closed
UML22-1190 Typo p. 595, Table 25, row 6, column 3 UML 2.0 UML 2.1 Resolved closed
UML22-1189 Additional Operations specification of NamedElement::allNamespaces() UML 2.0 UML 2.1 Resolved closed
UML22-1186 Second row of table 22, column "Notation", labels switched UML 2.0 UML 2.1 Resolved closed
UML22-1185 UseCase - Inconsistencies with Figure 401 UML 2.0 UML 2.1 Resolved closed
UML22-1188 typo UML 2.0 UML 2.1 Resolved closed
UML22-1187 Typo in OCL UML 2.0 UML 2.1 Resolved closed
UML22-1184 UseCase - Extend is not a Namespace UML 2.0 UML 2.1 Resolved closed
UML22-1183 Inconsistent multiplicity UML 2.0 UML 2.1 Resolved closed
UML22-1182 Inconsistency betw. Figure 328 and associations listed in s. Associations UML 2.0 UML 2.1 Resolved closed
UML22-1180 Wrong association name UML 2.0 UML 2.1 Resolved closed
UML22-1179 Constraint [2] - Missing parenthesis in OCL UML 2.0 UML 2.1 Resolved closed
UML22-1181 type p 419 UML 2.0 UML 2.1 Resolved closed
UML22-1178 Inconsistency between section "Associations" and Figure 327 UML 2.0 UML 2.1 Resolved closed
UML22-1177 typo p 340 UML 2.0 UML 2.1 Resolved closed
UML22-1176 object edges" should be replaced by "object flows UML 2.0 UML 2.1 Resolved closed
UML22-1172 graphic nodes UML 2.0 UML 2.1 Resolved closed
UML22-1171 typo p 421 UML 2.0 UML 2.1 Resolved closed
UML22-1175 object edges" sould be replaced by "object flows UML 2.0 UML 2.1 Resolved closed
UML22-1174 typo p 356 UML 2.0 UML 2.1 Resolved closed
UML22-1173 typo p 240 UML 2.0 UML 2.1 Resolved closed
UML22-1170 typo p 420 UML 2.0 UML 2.1 Resolved closed
UML22-1169 typo p 403 UML 2.0 UML 2.1 Resolved closed
UML22-1168 Inconsistencies between Figure 43 and the detailled description of Package UML 2.0 UML 2.1 Resolved closed
UML22-1165 The section "Associations (BasicActivities)" is not complete UML 2.0 UML 2.1 Resolved closed
UML22-1164 The query 'hostElement' has some errors UML 2.0 UML 2.1 Resolved closed
UML22-1167 Inconsistencies between Figure 3 and the detailled description of package UML 2.0 UML 2.1 Resolved closed
UML22-1166 • /context : Classifier [0..1] UML 2.0 UML 2.1 Resolved closed
UML22-1163 See CommonBehavior for a description of Event specifications UML 2.0 UML 2.1 Resolved closed
UML22-1162 page 95 diagram UML 2.0 UML 2.1 Resolved closed
UML22-1161 On templateableElment - additonal features UML 2.0 UML 2.1 Resolved closed
UML22-1160 Figure 346 needs updating UML 2.0 UML 2.1 Resolved closed
UML22-1157 Incorrect mentioning of General Order On p 412 UML 2.0 UML 2.1 Resolved closed
UML22-1159 Omission of non-terminal ‘arguments’ (p. 424) UML 2.0 UML 2.1 Resolved closed
UML22-1158 Remove occurrences of “TBD” UML 2.0 UML 2.1 Resolved closed
UML22-1153 Message notation. Incorrect notation in Figure 333 p.414 UML 2.0 UML 2.1 Resolved closed
UML22-1155 Message End association to Interaction should be removed UML 2.0 UML 2.1 Resolved closed
UML22-1154 Strict ordering in Inline Part Decomposition UML 2.0 UML 2.1 Resolved closed
UML22-1156 EventOccurrence, multiplicities incorrect in metamodel diagram UML 2.0 UML 2.1 Resolved closed
UML22-1152 On page 140, the title for Parameter is "Parameter (Collaboration, as speci UML 2.0 UML 2.1 Resolved closed
UML22-1151 The title of the Property description on page 144 UML 2.0 UML 2.1 Resolved closed
UML22-1150 labels for ExecutionOccurrence UML 2.0 UML 2.1 Resolved closed
UML22-1149 duration observation" vs DurationObservationAction etc UML 2.0 UML 2.1 Resolved closed
UML22-1148 Missing sections for for enumeration MessageKind or MessageSor UML 2.0 UML 2.1 Resolved closed
UML22-1147 figure 8-137 and 8-139 UML 2.0 UML 2.1 Resolved closed
UML22-1146 CommonBehaviors describes "Operation (from Communications, as specialized) UML 2.0 UML 2.1 Resolved closed
UML22-1144 inconsistency between figure 5.1 on page 179 and figure 7-122 on page 337. UML 2.0 UML 2.1 Resolved closed
UML22-1143 OpaqueExpression in CommonBehaviors UML 2.0 UML 2.1 Resolved closed
UML22-1145 CommonBehaviors UML 2.0 UML 2.1 Resolved closed
UML22-1142 Output tokens UML 2.1 UML 2.1.1 Duplicate or Merged closed
UML14-1041 There is a bug in additional operation 1 of the Namespace element UML 1.4 UML 1.4.2 Resolved closed
UML14-1040 How to properly designate exception returned from message sent to Java obje UML 1.4 UML 1.4.2 Resolved closed
UML14-1039 In 3.23.1 "Notation" (Internationalization issues) UML 1.3 UML 1.4 Resolved closed
UML14-1038 No servant with object . minorcode=0 completed=NO UML 1.3 UML 1.4 Closed; No Change closed
UML14-1037 The index shows incorrect section numbering for sections 2.9.4.1 to 2.9.4 UML 1.3 UML 1.4 Resolved closed
UML14-1036 Setting Action as abstract in UML-MetaModel MDL to correspond to Semantics UML 1.3 UML 1.4 Resolved closed
UML14-1035 Who owns an Event? UML 1.3 UML 1.4 Resolved closed
UML14-1033 UML RTF 1.4 editorial comments (Part 9 - Statechart Diagrams) UML 1.3 UML 1.4 Resolved closed
UML14-1034 UML 1.4 RTF Issue: Namespace notation too specific UML 1.3 UML 1.4 Resolved closed
UML14-1032 UML RTF 1.4 editorial comments (Part 6 - Use Case Diagrams) UML 1.3 UML 1.4 Resolved closed
UML14-1031 UML RTF 1.4 editorial comments (Part 3 - Behavioral Elements) UML 1.3 UML 1.4 Resolved closed
UML14-1030 UML RTF 1.4 editorial comments (Part 2 Diagram Elements) UML 1.3 UML 1.4 Resolved closed
UML14-1029 UML 1.4 RTF Issue: Association generalization has notation but no semantics UML 1.2 UML 1.3 Resolved closed
UML14-1028 UML 1.4 RTF Issue: Ordering of attribute values UML 1.2 UML 1.3 Resolved closed
UML14-1023 UML 1.4 RTF issue: OCL: Unary operator "-" missing UML 1.2 UML 1.3 Resolved closed
UML14-1027 UML 1.4 RTF Issue: Multiple languages for uninterpreted strings UML 1.2 UML 1.3 Resolved closed
UML14-1026 UML 1.4 RTF Issue: changeability in associations UML 1.2 UML 1.3 Resolved closed
UML14-1025 UML 1.4 RTF issue: OCL: grammar is ambigous UML 1.2 UML 1.3 Resolved closed
UML14-1024 UML 1.4 RTF issue: OCL: navigation context in iterate UML 1.2 UML 1.3 Resolved closed
UML14-1021 UML 1.4 RTF issue: OCL: Iterator declarators UML 1.2 UML 1.3 Resolved closed
UML14-1020 OCL: Declarators for iterate UML 1.2 UML 1.3 Resolved closed
UML14-1022 UML 1.4 RTF issue: OCL: Precedence of relational operators UML 1.2 UML 1.3 Resolved closed
UML14-1019 In 2.10.4, semantics of Collaboration, the 1st sentence is confusing UML 1.2 UML 1.3 Resolved closed
UML14-1016 Page 2-114, 2nd paragraph. It should be collaboration template UML 1.2 UML 1.3 Resolved closed
UML14-1015 Confusing wording UML 1.2 UML 1.3 Resolved closed
UML14-1017 In 2.10.5, you give pattern a non-standard definition UML 1.2 UML 1.3 Resolved closed
UML14-1018 Ad 3.69.3. In these paragraphs, it should be "Classifier" rather than "Cla UML 1.2 UML 1.3 Resolved closed
UML14-1010 Terminology: Collaboration and Collaboration Template UML 1.2 UML 1.3 Resolved closed
UML14-1014 use of the phrase "In the metamodel..." is unclear UML 1.2 UML 1.3 Resolved closed
UML14-1013 why is AssociationRole is a subtype of Association? UML 1.2 UML 1.3 Resolved closed
UML14-1012 2. In 2.10.1, 3rd paragraph, it should be "OOram", not "OOFRam". UML 1.2 UML 1.3 Resolved closed
UML14-1011 Focus is on 2.10 Collaborations UML 1.2 UML 1.3 Resolved closed
UML14-1009 Design patterns and collaboration templates. UML 1.2 UML 1.3 Resolved closed
UML14-1008 "Unused" data types UML 1.2 UML 1.3 Resolved closed
UML14-1007 Notation for Namespace ownership UML 1.2 UML 1.3 Resolved closed
UML14-1006 UML RTF 1.4 Issue: Typo in state exit UML 1.2 UML 1.3 Resolved closed
UML14-1005 Misleading description of feature inheritance on roles. UML 1.2 UML 1.3 Resolved closed
UML14-1001 Incorrect example of constraining elements in collaborations. UML 1.2 UML 1.3 Resolved closed
UML14-1004 UML RTF 1.4 Issue: Messages do not have signatures UML 1.2 UML 1.3 Resolved closed
UML14-1003 UML RTF 1.4 Issue: Guard condition in collaborations poorly named. UML 1.2 UML 1.3 Resolved closed
UML14-1002 UML RTF 1.4 Issue: Multi-objects in collaborations UML 1.2 UML 1.3 Resolved closed
UML14-1000 UML RTF 1.4 Issue: Duplicate association end names from Constraint. UML 1.2 UML 1.3 Resolved closed
UML14-999 UML RTF 1.4 Issue: Create action in collaborations UML 1.2 UML 1.3 Resolved closed
UML14-998 UML RTF 1.4 Issue: What does it mean for ReturnAction to be synchronous? UML 1.2 UML 1.3 Resolved closed
UML14-997 UML RTF 1.4 Issue: Action composition meta-modelled improperly: UML 1.2 UML 1.3 Resolved closed
UML14-994 UML RTF 1.4 Issue: Confusing example of sequence diagram UML 1.2 UML 1.3 Resolved closed
UML14-993 UML RTF 1.4 Issue: Arrowhead semantics in collaboration unclear UML 1.2 UML 1.3 Resolved closed
UML14-992 UML RTF 1.4: Description of context role, between state machine and model UML 1.2 UML 1.3 Resolved closed
UML14-996 UML RTF 1.4 Issue: Flow relationship has the incorrect semantics UML 1.2 UML 1.3 Resolved closed
UML14-995 UML RTF 1.4 Issue: <> keyword/stereotype UML 1.2 UML 1.3 Resolved closed
UML14-989 UML RTF 1.4 Issue: Deferred event ambiguity UML 1.2 UML 1.3 Resolved closed
UML14-988 UML RTF 1.4 Issue: Join in collaboration UML 1.2 UML 1.4 Resolved closed
UML14-987 UML RTF 1.4 Issue: State constraint on host object UML 1.2 UML 1.3 Resolved closed
UML14-991 UML RTF 1.4 Issue: ownerScope and targetScope UML 1.2 UML 1.3 Resolved closed
UML14-990 UML RTF 1.4 Issue: Guard evaluation for choice points. UML 1.2 UML 1.4 Resolved closed
UML14-986 UML RTF 1.4 Issue: Notation for call state UML 1.2 UML 1.3 Resolved closed
UML14-985 State machine name space UML 1.2 UML 1.3 Resolved closed
UML14-984 Issue Activity Package UML 1.2 UML 1.3 Resolved closed
UML14-983 ISSUE FOR UML, SECTION ActivityGraphs UML 1.2 UML 1.3 Resolved closed
UML14-982 Shouldn't the UML Package be allowed to own/reference UML 'Instances'? UML 1.2 UML 1.3 Resolved closed
UML14-981 Inheritance of Stereotypes UML 1.2 UML 1.3 Resolved closed
UML14-980 Why is "FinalState" a separate metaclass ? UML 1.2 UML 1.3 Resolved closed
UML14-977 OCL: Let-expressions UML 1.2 UML 1.3 Resolved closed
UML14-979 Invalid OCL expression in initial transition UML 1.2 UML 1.3 Resolved closed
UML14-978 OCL: Samples of invalid typing UML 1.2 UML 1.3 Resolved closed
UML14-976 OCL: class operation has no 'self' UML 1.2 UML 1.3 Resolved closed
UML14-975 OCL: String literals UML 1.2 UML 1.3 Resolved closed
UML14-974 OCL: Numeric constants missing UML 1.2 UML 1.3 Resolved closed
UML14-973 OCL: Literal collections UML 1.2 UML 1.3 Resolved closed
UML14-972 OCL: Enumeration types inconsistent with UML metamodel UML 1.2 UML 1.3 Resolved closed
UML14-971 OCL: Enumeration types UML 1.2 UML 1.3 Resolved closed
UML14-970 OCL: Feature calls on default target UML 1.2 UML 1.3 Resolved closed
UML14-967 OCL: Are keywords reserved or not UML 1.2 UML 1.3 Resolved closed
UML14-966 OCL: Consistency in grammar description UML 1.2 UML 1.3 Resolved closed
UML14-965 "Physical" Metamodel References in Diagrams (uml-rtf) UML 1.2 UML 1.3 Resolved closed
UML14-969 textual syntax cannot deal with identical class names in different package UML 1.2 UML 1.3 Resolved closed
UML14-968 OCL: Class context specification grammar incomplete UML 1.2 UML 1.3 Resolved closed
UML14-964 "Physical" Metamodel References (uml-rtf) UML 1.2 UML 1.3 Resolved closed
UML14-963 Precise "Physical" Metamodels Missing from Specification (uml-rtf UML 1.2 UML 1.3 Resolved closed
UML14-962 Language Name (uml-rtf) UML 1.2 UML 1.3 Resolved closed
UML14-961 OCL Error UML 1.2 UML 1.3 Resolved closed
UML14-960 Use of interfaces in associations UML 1.2 UML 1.3 Resolved closed
UML14-959 Generalization should be meta-metamodel element UML 1.2 UML 1.3 Resolved closed
UML14-958 role concept in UML remains rather vague UML 1.2 UML 1.3 Resolved closed
UML14-957 OCL issue UML 1.1 UML 1.3 Resolved closed
UML14-956 Strange GENERAl USE RESTRICTION UML 1.1 UML 1.3 Resolved closed
UML14-955 Error in the third postcondition for String::concat on page 6-31 UML 1.1 UML 1.3 Resolved closed
UML14-954 The not-equals operator, "<>", UML 1.1 UML 1.3 Resolved closed
UML14-953 Divide operator is incorrect UML 1.1 UML 1.3 Resolved closed
UML14-952 pages 6-28 to 6-29 of OCL documentation UML 1.1 UML 1.3 Resolved closed
UML14-951 page 6-10 of OCL documentation for 1.3alphaR5 UML 1.1 UML 1.3 Resolved closed
UML14-948 The second postcondition on Integer::div is incorrect UML 1.1 UML 1.3 Resolved closed
UML14-950 The postcondition seems to be incorrect for sequence::subSequence UML 1.1 UML 1.3 Resolved closed
UML14-949 The postcondition on set::collect seems to be incorrect UML 1.1 UML 1.3 Resolved closed
UML14-947 (Minor) Activity diagram change recommendation UML 1.1 UML 1.3 Resolved closed
UML14-946 OCL Standard package UML 1.1 UML 1.3 Resolved closed
UML14-945 There is an association between between Constraint and ModelElement UML 1.1 UML 1.3 Resolved closed
UML14-944 OCL should allow one constraint to reference another UML 1.1 UML 1.3 Resolved closed
UML14-941 action state symbol/state symbol difficult to distinguish when drawn by ha UML 1.1 UML 1.3 Resolved closed
UML14-940 UML Semantics, OMG-UML V1.2 Use Cases July 1998, page 2-99 UML 1.1 UML 1.4 Resolved closed
UML14-943 UML has symbol for multiobject, not for multi-instances of other classifie UML 1.1 UML 1.3 Resolved closed
UML14-942 Dependencies (and other relationships) with role ends UML 1.1 UML 1.3 Resolved closed
UML14-939 Add Responsibilities as a new metatype UML 1.1 UML 1.3 Resolved closed
UML14-935 On aggregation. The white diamond name should be "shareable" UML 1.1 UML 1.3 Resolved closed
UML14-934 Metamodel and semantics for aggregations UML 1.1 UML 1.3 Resolved closed
UML14-938 Interface issue UML 1.1 UML 1.3 Resolved closed
UML14-937 Only single stereotyping is supported UML 1.1 UML 1.3 Resolved closed
UML14-936 Use of black diamond in the metamodel UML 1.1 UML 1.3 Resolved closed
UML14-933 Some attributes can be expressed in OCL UML 1.1 UML 1.4 Resolved closed
UML14-932 Widen the naming characteristics UML 1.1 UML 1.3 Resolved closed
UML14-931 BooleanExpression written in OCL or some other language? UML 1.1 UML 1.3 Resolved closed
UML14-927 Infix operator use should be clarified UML 1.1 UML 1.2 Resolved closed
UML14-930 Generalized change events UML 1.1 UML 1.2 Resolved closed
UML14-929 There are issues that make OCL hard to formalize--document ad/98-10-01 UML 1.1 UML 1.2 Resolved closed
UML14-928 Definition of OclAny leads to problems when formalizing OCL UML 1.1 UML 1.2 Resolved closed
UML14-924 Common operations should be added to collection types in OCL UML 1.1 UML 1.3 Resolved closed
UML14-923 Add OCL operation to refer to all new instances created during operation UML 1.1 UML 1.2 Resolved closed
UML14-922 Need well defined way to extend OCL UML 1.1 UML 1.2 Resolved closed
UML14-926 Set of allInstances should be referrable by the class name UML 1.1 UML 1.4 Resolved closed
UML14-925 Add "Let"-like construct to OCL UML 1.1 UML 1.2 Resolved closed
UML14-919 Synchronous request UML 1.1 UML 1.4 Resolved closed
UML14-921 Notation says swimlanes are packages UML 1.1 UML 1.2 Resolved closed
UML14-920 ModelElement to Partition multiplicity should be many UML 1.1 UML 1.2 Resolved closed
UML14-918 Asynchronous action UML 1.1 UML 1.4 Resolved closed
UML14-917 Not instantiable UML 1.1 UML 1.3 Resolved closed
UML14-916 UML RTF Issue: Normative MOF-Compatible version of UML UML 1.1 UML 1.2 Resolved closed
UML14-915 Core package-backbone diagram UML 1.1 UML 1.2 Resolved closed
UML14-912 Issue: Missing role names UML 1.1 UML 1.2 Resolved closed
UML14-911 Issue: Inheritance inconsistencies UML 1.1 UML 1.2 Resolved closed
UML14-914 MOF does not support association attributes in metamodels. UML 1.1 UML 1.2 Resolved closed
UML14-913 issue: Missing association names UML 1.1 UML 1.2 Resolved closed
UML14-910 Issue: Action does not define attributes UML 1.1 UML 1.2 Resolved closed
UML14-909 Issue: Name attribute inheritance UML 1.1 UML 1.2 Resolved closed
UML14-908 Issue: abstract class inconsistencies UML 1.1 UML 1.2 Resolved closed
UML14-907 Figure 2-18 : redundant attributes UML 1.1 UML 1.2 Resolved closed
UML14-906 UML Semantics (page 109) UML 1.1 UML 1.2 Resolved closed
UML14-905 Association attributes UML 1.1 UML 1.2 Resolved closed
UML14-904 missing association names UML 1.1 UML 1.2 Resolved closed
UML14-903 Issue: inheritance inconsistencies UML 1.1 UML 1.2 Resolved closed
UML14-902 Diagram missing attributes UML 1.1 UML 1.2 Resolved closed
UML14-900 Are subsystems instantiable? UML 1.1 UML 1.2 Resolved closed
UML14-901 Abstract class inconsistencies UML 1.1 UML 1.2 Resolved closed
UML14-899 Associations as parts of a composite. UML 1.1 UML 1.3 Resolved closed
UML14-898 Section 5.17 of Notation Guide: No mapping is given UML 1.1 UML 1.3 Resolved closed
UML14-896 Notation section describing activity states needed UML 1.1 UML 1.2 Resolved closed
UML14-897 Existance of classes in classes UML 1.1 UML 1.2 Resolved closed
UML14-895 States leading to joins in activity models UML 1.1 UML 1.2 Resolved closed
UML14-894 Activities operate by and on objects UML 1.1 UML 1.2 Resolved closed
UML14-893 ClassifierInState does not satisfy one of its stated usages UML 1.1 UML 1.2 Resolved closed
UML14-892 Rules 3 and 4 for Transitions in state machines should be limited UML 1.1 UML 1.3 Resolved closed
UML14-891 UML Semantics, section Common behavior UML 1.1 UML 1.2 Resolved closed
UML14-890 Notion of "conceptual" or "specification-only" not supported UML 1.1 UML 1.2 Resolved closed
UML14-889 OCL should allow the use of "let" expressions UML 1.1 UML 1.2 Resolved closed
UML14-888 Text on page 2-49 section 2.2 UML 1.1 UML 1.3 Resolved closed
UML14-887 Text in Figure 2.13.7.1 ActivityState seems to be incorrect UML 1.1 UML 1.2 Resolved closed
UML14-886 Need to have relative precedence and, or, xor UML 1.1 UML 1.2 Resolved closed
UML14-885 Need way to approximate comparisons UML 1.1 UML 1.2 Resolved closed
UML14-882 Change events issue UML 1.1 UML 1.2 Resolved closed
UML14-881 Collection operation size not defined for infinite collections UML 1.1 UML 1.2 Resolved closed
UML14-884 pre value of object UML 1.1 UML 1.2 Resolved closed
UML14-883 It"s mistake to automatically flatten collections of collections UML 1.1 UML 1.2 Resolved closed
UML14-880 States of an object not referenceable from OCL expression UML 1.1 UML 1.2 Resolved closed
UML14-879 Implicit transitive import between packages UML 1.1 UML 1.2 Resolved closed
UML14-878 Protocol state diagrams issue UML 1.1 UML 1.2 Resolved closed
UML14-877 Changes to figure 15 and description of ClassifierRole on page 82 UML 1.1 UML 1.2 Resolved closed
UML14-876 Semantics for dynamic invocation of concurrent activity models are missing UML 1.1 UML 1.2 Resolved closed
UML14-875 Collection type within OCL missing UML 1.1 UML 1.2 Resolved closed
UML14-874 Operation asSequence Issue UML 1.1 UML 1.2 Resolved closed
UML14-873 No discription of the association between Classifier and Parameter is give UML 1.1 UML 1.2 Resolved closed
UML14-872 Stereotypes on Dependency, page 43 of V 1.1 (figure 7) UML 1.1 UML 1.2 Resolved closed
UML14-871 Reflexive association in section 5.20.2 UML 1.1 UML 1.2 Resolved closed
UML14-870 The class "Subsystem" inherits from "GeneralizedElement" twice UML 1.1 UML 1.2 Resolved closed
UML14-869 Class "Model" is too prescriptive UML 1.1 UML 1.2 Resolved closed
UML14-868 Clarify how types of attributes and parameters should be instantiated UML 1.1 UML 1.2 Resolved closed
UML14-867 Merge "Class" and "Interface" into one class UML 1.1 UML 1.2 Resolved closed
UML14-866 UML 1.1 issue on Associations UML 1.1 UML 1.2 Resolved closed
UML14-865 Extension Point UML 1.1 UML 1.2 Resolved closed
UML14-864 Specification for method in a derived class UML 1.1 UML 1.2 Resolved closed
UML14-863 State diagrams: action expressions UML 1.1 UML 1.2 Resolved closed
UML14-860 Responsibilities hardly figure in these documents UML 1.1 UML 1.2 Resolved closed
UML14-862 Permit multiple stereotyping on relationship UML 1.1 UML 1.2 Resolved closed
UML14-861 General recommended use of UML UML 1.1 UML 1.2 Resolved closed
UML14-858 Aggregation is poorly defined UML 1.1 UML 1.2 Resolved closed
UML14-859 "Inheritance" connection used is a generalization relationship UML 1.1 UML 1.2 Resolved closed
UML14-857 Page 98: arrowhead issue UML 1.1 UML 1.2 Resolved closed
UML14-856 Page 94 --editorial UML 1.1 UML 1.2 Resolved closed
UML14-855 Page 82: Add explanation UML 1.1 UML 1.2 Resolved closed
UML14-854 Page 80: Confusion with headings UML 1.1 UML 1.2 Resolved closed
UML14-852 Page 72: Example needs rejigging UML 1.1 UML 1.2 Resolved closed
UML14-851 Page 71: Distinction between Dependency and Association UML 1.1 UML 1.2 Resolved closed
UML14-849 Page 67: Why is discriminator not discussed in terms of power types? UML 1.1 UML 1.2 Resolved closed
UML14-850 Page 68 overlapping UML 1.1 UML 1.2 Resolved closed
UML14-853 Page 79: Poor choice of arrowhead UML 1.1 UML 1.2 Resolved closed
UML14-846 Page 52 figure 20 UML 1.1 UML 1.2 Resolved closed
UML14-845 Typos on pages 24, 40, and 50 UML 1.1 UML 1.2 Resolved closed
UML14-848 Page 58: Add index entry UML 1.1 UML 1.2 Resolved closed
UML14-847 Page 57: mathematical issue UML 1.1 UML 1.2 Resolved closed
UML14-844 Page 35/6: Why are attributes and association not inherited? UML 1.1 UML 1.2 Resolved closed
UML14-843 Page 35/6: Use of word type is confusing UML 1.1 UML 1.2 Resolved closed
UML14-841 Page 30: Class scope attribute underlined UML 1.1 UML 1.2 Resolved closed
UML14-840 Page 29: Protected member UML 1.1 UML 1.2 Resolved closed
UML14-842 Page 35/6 : Stereotypes UML 1.1 UML 1.2 Resolved closed
UML14-839 Page 26: rename reponsibilities, rules, modification histories etc. UML 1.1 UML 1.2 Resolved closed
UML14-838 Page 24 Section 5.4.3 para 1: missing compartments UML 1.1 UML 1.2 Resolved closed
UML14-837 Page 24: add link to Interface UML 1.1 UML 1.2 Resolved closed
UML14-835 Page 13: Packages are GeneralizableElements UML 1.1 UML 1.2 Resolved closed
UML14-834 Page 11: Operation-Call UML 1.1 UML 1.2 Resolved closed
UML14-836 Page 20: Section 4.3.1 could be misleading UML 1.1 UML 1.2 Resolved closed
UML14-833 Editorials on pages iv, v, 3, and 4 UML 1.1 UML 1.2 Resolved closed
UML14-832 Typos on page 90, 151 plus errors in page numbering UML 1.1 UML 1.2 Resolved closed
UML14-831 Page 143: "uses" as a stereotype on Generalization UML 1.1 UML 1.2 Resolved closed
UML14-830 Page 143: uses is a stereotyped dependency UML 1.1 UML 1.2 Resolved closed
UML14-829 Page 136: Model package relationship UML 1.1 UML 1.2 Resolved closed
UML14-828 Page 98: Transition is an aggregation of guards UML 1.1 UML 1.2 Resolved closed
UML14-827 Uses and extends not types of generalization UML 1.1 UML 1.2 Resolved closed
UML14-826 Page 93: use case UML 1.1 UML 1.2 Resolved closed
UML14-824 Discussion on Collaborations and Interactions is confusing UML 1.1 UML 1.2 Resolved closed
UML14-823 Typos on pages 55 and 62 UML 1.1 UML 1.2 Resolved closed
UML14-825 Page 93: Is Namespace really aggregeation of use cases? UML 1.1 UML 1.2 Resolved closed
UML14-822 Page 50 Table 3 "refinement" UML 1.1 UML 1.2 Resolved closed
UML14-818 Page 47: Dependency is a unidirectional, client-server UML 1.1 UML 1.2 Resolved closed
UML14-817 Page 45 dependency lines 2/3 between model elements not instances? UML 1.1 UML 1.2 Resolved closed
UML14-820 Page 50: should stereotypes be defined at the subclass level? UML 1.1 UML 1.2 Resolved closed
UML14-819 Page 50: "instance" should be changed to "instatiate" UML 1.1 UML 1.2 Resolved closed
UML14-821 Page 50: table 3 component UML 1.1 UML 1.2 Resolved closed
UML14-814 Page 38 para 2 line 3, one of its containers is deleted UML 1.1 UML 1.2 Resolved closed
UML14-813 Page 35 Diagram (02) UML 1.1 UML 1.2 Resolved closed
UML14-812 Page 35 -Diagram UML 1.1 UML 1.2 Resolved closed
UML14-811 Class to be defined as an intension UML 1.1 UML 1.2 Resolved closed
UML14-816 Aggregation of class? UML 1.1 UML 1.2 Resolved closed
UML14-815 Page 40 table 2 Model Element class UML 1.1 UML 1.2 Resolved closed
UML14-810 How to stop an interface realizing a Data Type ? UML 1.1 UML 1.2 Resolved closed
UML14-809 Why does GeneralizableElement inherit from Namespace? UML 1.1 UML 1.2 Resolved closed
UML14-806 Page 16 lost fact that Class realizes an interface UML 1.1 UML 1.2 Resolved closed
UML14-808 Page 16 ---editorial (Element Ownership) UML 1.1 UML 1.2 Resolved closed
UML14-807 Is name space really a *composite aggregation* of model elements? UML 1.1 UML 1.2 Resolved closed
UML14-805 Interface must also have features UML 1.1 UML 1.2 Resolved closed
UML14-804 Why is Classifier an Aggregate of Features? UML 1.1 UML 1.2 Resolved closed
UML14-803 Collaboration as a Classifier UML 1.1 UML 1.2 Resolved closed
UML14-802 Interfaces and support classes UML 1.1 UML 1.2 Resolved closed
UML14-801 UML Semantics, p 81, 145 UML 1.1 UML 1.2 Resolved closed
UML14-798 UseCaseInstance badly defined UML 1.1 UML 1.2 Resolved closed
UML14-800 Extension/recommendation needed for inner/outer transitions UML 1.1 UML 1.2 Resolved closed
UML14-799 Notation for state machine inheritance UML 1.1 UML 1.2 Resolved closed
UML14-793 Collaboration showing instances UML 1.1 UML 1.2 Resolved closed
UML14-792 Inconsistency between stereotype tables UML 1.1 UML 1.2 Resolved closed
UML14-796 Multiple transitions from initial states should be allowed UML 1.1 UML 1.2 Resolved closed
UML14-795 Modeling of guards UML 1.1 UML 1.2 Resolved closed
UML14-794 Collaboration::constrainingElement semantics UML 1.1 UML 1.2 Resolved closed
UML14-797 Semantics of terminate transitions UML 1.1 UML 1.2 Resolved closed
UML14-790 Stereotypes for superclasses do not apply to superclasses UML 1.1 UML 1.2 Resolved closed
UML14-789 Inconsistent use of stereotypes, tagged values, and metamodel UML 1.1 UML 1.2 Resolved closed
UML14-788 Class WFR (01) UML 1.1 UML 1.2 Resolved closed
UML14-787 Modeling of realization/specification UML 1.1 UML 1.2 Resolved closed
UML14-791 Stereotype modeled in two ways UML 1.1 UML 1.2 Resolved closed
UML14-786 GeneralizableElement should not inherit from Namespace UML 1.1 UML 1.2 Resolved closed
UML14-785 Syntax for Sequence Expressions inconsistently used UML 1.1 UML 1.2 Resolved closed
UML14-784 Threads of control in Collaboration Diagrams UML 1.1 UML 1.2 Resolved closed
UML14-783 Control Flow types not modeled UML 1.1 UML 1.2 Resolved closed
UML14-782 RaiseAction and TimingMark are not defined UML 1.1 UML 1.2 Resolved closed
UML14-781 Mapping of concurrent subregions UML 1.1 UML 1.2 Resolved closed
UML14-780 "do" action not supported UML 1.1 UML 1.2 Resolved closed
UML14-779 Notation for iteration in sequence diagram UML 1.1 UML 1.2 Resolved closed
UML14-778 "derived" not defined UML 1.1 UML 1.2 Resolved closed
UML14-775 WFR for bound elements missing UML 1.1 UML 1.2 Resolved closed
UML14-774 The meta-type of template parameters UML 1.1 UML 1.2 Resolved closed
UML14-773 Dependency wrongly mapped UML 1.1 UML 1.2 Resolved closed
UML14-777 <>, <>, <>, <>, not well supported UML 1.1 UML 1.2 Resolved closed
UML14-776 Namespace in case of containment UML 1.1 UML 1.2 Resolved closed
UML14-772 Package importing transitive UML 1.1 UML 1.2 Resolved closed
UML14-771 "invoked" not defined UML 1.1 UML 1.2 Resolved closed
UML14-770 Bad example for LCA, main source, main target UML 1.1 UML 1.3 Resolved closed
UML14-769 Transition WFR badly written UML 1.1 UML 1.3 Resolved closed
UML14-768 Entry/Exit actions execution order UML 1.1 UML 1.2 Resolved closed
UML14-767 CompositeStates with non-composite subregions allowed UML 1.1 UML 1.2 Resolved closed
UML14-766 Message::base undefined UML 1.1 UML 1.2 Resolved closed
UML14-765 AssociationEnd-AssociationEndRole inconsistencies UML 1.1 UML 1.2 Resolved closed
UML14-764 Argument::type not defined UML 1.1 UML 1.2 Resolved closed
UML14-762 WFR for instance links UML 1.1 UML 1.2 Resolved closed
UML14-761 Well-formedness Rules for Action::actualArguments UML 1.1 UML 1.2 Resolved closed
UML14-760 CallAction::request UML 1.1 UML 1.2 Resolved closed
UML14-759 CallAction::isAsynchronous and CallAction::mode UML 1.1 UML 1.2 Resolved closed
UML14-763 MessageInstance not used UML 1.1 UML 1.2 Resolved closed
UML14-754 Node and Component parent UML 1.1 UML 1.2 Resolved closed
UML14-753 Qualifier badly modeled UML 1.1 UML 1.2 Resolved closed
UML14-758 Action::isAsynchronous and Action::script not defined UML 1.1 UML 1.2 Resolved closed
UML14-757 Signal::isAsynchronous and Signal::direction not defined UML 1.1 UML 1.2 Resolved closed
UML14-756 Request"s parents UML 1.1 UML 1.2 Resolved closed
UML14-755 "implementation" association not defined UML 1.1 UML 1.2 Resolved closed
UML14-752 Signature conflicts across an inheritance hierarchy UML 1.1 UML 1.2 Resolved closed
UML14-751 Exotic uses of generalization UML 1.1 UML 1.2 Resolved closed
UML14-750 Set of inheritable features not defined UML 1.1 UML 1.3 Resolved closed
UML14-749 Correspondence between operation and method (02) UML 1.1 UML 1.3 Resolved closed
UML14-748 Correspondence between operation and method UML 1.1 UML 1.2 Resolved closed
UML14-744 Signature conflicts not well defined (02) UML 1.1 UML 1.2 Resolved closed
UML14-743 Features and ownedElements (2) UML 1.1 UML 1.2 Resolved closed
UML14-742 "feature" defined twice UML 1.1 UML 1.2 Resolved closed
UML14-747 Use of language-dependant type expressions UML 1.1 UML 1.2 Resolved closed
UML14-746 Return types for BehavioralFeatures UML 1.1 UML 1.2 Resolved closed
UML14-745 Package importing not well supported UML 1.1 UML 1.2 Resolved closed
UML14-739 UML Semantics 1.1, p26, Operation::isPolymorphic UML 1.1 UML 1.2 Resolved closed
UML14-741 Features and ownedElements (1) UML 1.1 UML 1.2 Resolved closed
UML14-740 Signature conflicts not well defined UML 1.1 UML 1.2 Resolved closed
UML14-738 OCL Specification 1.1, section 8 UML 1.1 UML 1.2 Resolved closed
UML14-737 OCL specification 1.1, p. 14, 5.13, example UML 1.1 UML 1.2 Resolved closed
UML14-736 OCL specification 1.1, p. 15, 5.14, second last paragraph UML 1.1 UML 1.2 Resolved closed
UML14-733 OCL specification 1.1, p. 32 UML 1.1 UML 1.3 Resolved closed
UML14-732 OCL specification 1.1, p. 10, 5.4.3, example 3 UML 1.1 UML 1.2 Resolved closed
UML14-735 OCL specification 1.1, p. 24, 7.1.7 UML 1.1 UML 1.2 Resolved closed
UML14-734 OCL specification 1.1, p. 30, 7.2.4 UML 1.1 UML 1.2 Resolved closed
UML14-731 OCL specification 1.1, section 7.2.2 UML 1.1 UML 1.2 Resolved closed
UML14-730 Definition of select and reject operations for Set"s is erranious UML 1.1 UML 1.2 Resolved closed
UML14-729 Difference between methods, attributes and operations not clear UML 1.1 UML 1.2 Resolved closed
UML14-728 Editorial issue: OCL spec 1.1, section 6.3, example 2, last row UML 1.1 UML 1.2 Resolved closed
UML14-727 UML 1.1 Semantics, section 8.2, page 66 UML 1.1 UML 1.2 Resolved closed
UML14-726 Contents of section "Control Icons" is vague UML 1.1 UML 1.2 Resolved closed
UML14-723 Missing sentence UML 1.1 UML 1.2 Resolved closed
UML14-722 Editorial error in Semantics UML 1.1 UML 1.2 Resolved closed
UML14-725 Missing word - editorial UML 1.1 UML 1.2 Resolved closed
UML14-724 Procedure undefined UML 1.1 UML 1.2 Resolved closed
UML14-721 ActionState implicit deferring of events UML 1.1 UML 1.2 Resolved closed
UML14-720 internalTransition UML 1.1 UML 1.2 Resolved closed
UML14-718 Deep History Vertex UML 1.1 UML 1.2 Resolved closed
UML14-719 deferredEvent mentioned twice in Abstract Syntax UML 1.1 UML 1.2 Resolved closed
UML14-713 No mapping for send/receive time in Sequence Diagram UML 1.1 UML 1.2 Resolved closed
UML14-717 Inconsistent definition of extends relationship UML 1.1 UML 1.2 Resolved closed
UML14-715 No mapping for TimingMark in Sequence Diagram UML 1.1 UML 1.2 Resolved closed
UML14-714 No mapping for "transition string" UML 1.1 UML 1.2 Resolved closed
UML14-716 No notation for ActivityState UML 1.1 UML 1.2 Resolved closed
UML14-709 Inconsistent constraint for discriminator UML 1.1 UML 1.2 Resolved closed
UML14-708 Missing notation for templates UML 1.1 UML 1.2 Resolved closed
UML14-712 No mapping for swimlanes in Sequence Diagram UML 1.1 UML 1.3 Resolved closed
UML14-711 Property "derived" not defined UML 1.1 UML 1.2 Resolved closed
UML14-710 Interface specifier not mapped UML 1.1 UML 1.2 Resolved closed
UML14-705 Well-formedness rules only expressed in English UML 1.1 UML 1.3 Resolved closed
UML14-704 Well-formedness rules missing UML 1.1 UML 1.2 Resolved closed
UML14-707 Confusing text UML 1.1 UML 1.2 Resolved closed
UML14-706 Missing mapping for directed constraint UML 1.1 UML 1.2 Resolved closed
UML14-703 Inconsistent definition of stereotype "thread" UML 1.1 UML 1.2 Resolved closed
UML14-700 Stereotypes applied to more than one ModelElement UML 1.1 UML 1.2 Resolved closed
UML14-699 English contradicts OCL in rule for CompositeState UML 1.1 UML 1.2 Resolved closed
UML14-698 Misleading name Link.linkRole UML 1.1 UML 1.2 Resolved closed
UML14-697 Enumeration OperationDirectionKind obsolete UML 1.1 UML 1.2 Resolved closed
UML14-702 Inconsistent definition of stereotype " process" UML 1.1 UML 1.2 Resolved closed
UML14-701 Inconsistent definition of enumeration UML 1.1 UML 1.2 Resolved closed
UML14-696 ordered missing for Constraint.constrainedStereotype UML 1.1 UML 1.2 Resolved closed
UML14-695 Inconsistent definition of stereotype "friend" UML 1.1 UML 1.2 Resolved closed
UML14-694 Inconsistent definition of stereotype "thread" UML 1.1 UML 1.2 Resolved closed
UML14-693 Wrong aggregation kind for templates UML 1.1 UML 1.2 Resolved closed
UML14-689 Inconsistent attachment of Activity Diagram UML 1.1 UML 1.2 Resolved closed
UML14-692 Method visibility UML 1.1 UML 1.2 Resolved closed
UML14-691 Feature.owner must be optional UML 1.1 UML 1.2 Resolved closed
UML14-690 Extension points of operations not defined UML 1.1 UML 1.2 Resolved closed
UML14-688 Inconsistent definition of state machine attachment UML 1.1 UML 1.2 Resolved closed
UML14-687 Inconsistent format of signal/event UML 1.1 UML 1.2 Resolved closed
UML14-686 More arrow types than message kinds UML 1.1 UML 1.2 Resolved closed
UML14-684 Attachment of message in Sequence Diagram UML 1.1 UML 1.2 Resolved closed
UML14-685 Inconsistent mapping of labels in Sequence Diagram UML 1.1 UML 1.2 Resolved closed
UML14-682 UML 1.0: "role" should be "end" UML 1.1 UML 1.2 Resolved closed
UML14-681 UML 1.0: Template example cannot be representaed in model UML 1.1 UML 1.3 Resolved closed
UML14-683 UML 1.0: Unknown model element "Qualifier" UML 1.1 UML 1.2 Resolved closed
UML14-680 UML 1.0: Inconsistent name of stereotype "import" UML 1.1 UML 1.2 Resolved closed
UML14-679 UML 1.0: multiplicity "unspecified" not possible UML 1.1 UML 1.2 Resolved closed
UML14-676 Inconsistent name space rules UML 1.1 UML 1.2 Resolved closed
UML14-675 UML 1.0: instances UML 1.1 UML 1.3 Resolved closed
UML14-678 UML 1.0: Stereotype "uses" applied to more than one class UML 1.1 UML 1.2 Resolved closed
UML14-677 Inconsistent name for stereotype implementationClass UML 1.1 UML 1.2 Resolved closed
UML14-673 UML 1.0: Tagged value "location" UML 1.1 UML 1.2 Resolved closed
UML14-672 UML 1.0: Inconsistent mapping of interface circles UML 1.1 UML 1.2 Resolved closed
UML14-669 UML 1.0: Attachment of messages in Collaboration Diagrams UML 1.1 UML 1.2 Resolved closed
UML14-671 UML 1.0: Node/Component Instances not defined UML 1.1 UML 1.2 Resolved closed
UML14-670 UML 1.0: No notation for ModelElement.implementation etc. UML 1.1 UML 1.2 Resolved closed
UML14-674 UML 1.0: Inconsistent arrow heads for dependencies UML 1.1 UML 1.2 Resolved closed
UML14-666 UML 1.o: Qualified things in Collaborations UML 1.1 UML 1.2 Resolved closed
UML14-665 UML 1.0: Collaborations not well defined UML 1.1 UML 1.2 Resolved closed
UML14-668 UML 1.0: No notation for ClassifierRole.availableFeature UML 1.1 UML 1.2 Resolved closed
UML14-667 UML 1.0: Collaborations and Association (role) UML 1.1 UML 1.2 Resolved closed
UML14-664 CallEvent: operation label in figure 18 is not present UML 1.1 UML 1.2 Resolved closed
UML14-663 Signal label in figure 18 is not present UML 1.1 UML 1.2 Resolved closed
UML14-662 Figure 15, AssociationRole class issue UML 1.1 UML 1.2 Resolved closed
UML14-659 Description of ActionSequence indicates that it is composition of Actions UML 1.1 UML 1.2 Resolved closed
UML14-658 ActionSequence class issue UML 1.1 UML 1.2 Resolved closed
UML14-661 Collaboration package: constrainingElement aggregation misdrawn UML 1.1 UML 1.2 Resolved closed
UML14-660 Collaborations package--editorial UML 1.1 UML 1.2 Resolved closed
UML14-657 Reception class has wrong attribute UML 1.1 UML 1.2 Resolved closed
UML14-656 Figure 12 shows no attributes for exceptions UML 1.1 UML 1.2 Resolved closed
UML14-655 Behavioral Features called context UML 1.1 UML 1.2 Resolved closed
UML14-654 Request class is not an abstract class as indicated UML 1.1 UML 1.2 Resolved closed
UML14-653 Action class is no abstract class as indicated UML 1.1 UML 1.2 Resolved closed
UML14-652 Description of ViewElement indicates that it is subclass of Element UML 1.1 UML 1.2 Resolved closed
UML14-647 Inconsistency of UML metamodel UML 1.1 UML 1.2 Resolved closed
UML14-649 Node class shown as subclass of classifier UML 1.1 UML 1.2 Resolved closed
UML14-648 Node class issue (01) UML 1.1 UML 1.2 Resolved closed
UML14-651 Comment class shown as subclass of ModelElement class UML 1.1 UML 1.2 Resolved closed
UML14-650 Description of component shown as subclass of class UML 1.1 UML 1.2 Resolved closed
UML14-645 UML Notation Guide, boolean properties UML 1.1 UML 1.2 Resolved closed
UML14-644 UML Notation Guide, association ends UML 1.1 UML 1.2 Resolved closed
UML14-646 Association between Method and Operation UML 1.1 UML 1.2 Resolved closed
UML14-643 UML stereotypes UML 1.1 UML 1.2 Resolved closed
UML14-642 UML potential inconsistency about stereotypes UML 1.1 UML 1.2 Resolved closed
UML14-641 Inconsistency of UML metamodel UML 1.1 UML 1.2 Resolved closed
UML14-640 Parameters/Attributes need Specification Classifiers UML 1.1 UML 1.2 Resolved closed
UML14-639 Predefined LinkEnd constraints issue UML 1.1 UML 1.2 Resolved closed
UML14-638 Predefined LinkEnd constraints shown as stereotypes in Notation Guide UML 1.1 UML 1.2 Resolved closed
UML14-636 diagram fragment at start of Model section on page 136 UML 1.1 UML 1.2 Resolved closed
UML14-635 No notation defined in the Notation Guide UML 1.1 UML 1.2 Resolved closed
UML14-634 ActivityState in Figure 22 UML 1.1 UML 1.2 Resolved closed
UML14-633 well-formedness rules for BehavioralFeature UML 1.1 UML 1.2 Resolved closed
UML14-637 Figure 8 (Semantics, p. 44) UML 1.1 UML 1.2 Resolved closed
UML14-630 Figure 5 Semantics document (p. 16) UML 1.1 UML 1.2 Resolved closed
UML14-629 Second para, Section 5.16.1: conflict with statement on p 141 UML 1.1 UML 1.2 Resolved closed
UML14-632 Well-formedness rulw [2] for Class (Semantics, p. 27-28) UML 1.1 UML 1.2 Resolved closed
UML14-631 Well-formedness rule [4] for Association UML 1.1 UML 1.2 Resolved closed
UML14-628 Section 5.16.1--editorial UML 1.1 UML 1.2 Resolved closed
UML14-627 Page 53 UML semantics: base class of TaggedValue not shown UML 1.1 UML 1.2 Resolved closed
UML14-624 Missing role descriptions UML 1.1 UML 1.2 Resolved closed
UML14-623 ModelElement Associations (02) UML 1.1 UML 1.2 Resolved closed
UML14-626 Page 44 UML 1.1 Semantics, figure 8: no base class for ViewElement UML 1.1 UML 1.2 Resolved closed
UML14-625 Page 44 UML 1.1 Semantics, figure 8: no component role name UML 1.1 UML 1.2 Resolved closed
UML14-622 ModelElement Associations (01) UML 1.1 UML 1.2 Resolved closed
UML14-621 ElementOwnership subclass of ModelElement? UML 1.1 UML 1.2 Resolved closed
UML14-619 Package dependencies (08) UML 1.1 UML 1.2 Resolved closed
UML14-618 Package dependencies (07) UML 1.1 UML 1.2 Resolved closed
UML14-620 Package dependencies (09) UML 1.1 UML 1.2 Resolved closed
UML14-617 Package dependencies (06) UML 1.1 UML 1.2 Resolved closed
UML14-616 Package dependencies (05) UML 1.1 UML 1.2 Resolved closed
UML14-613 Package dependencies (01) UML 1.1 UML 1.2 Resolved closed
UML14-612 UML 1.1 bug UML 1.1 UML 1.2 Resolved closed
UML14-615 Package dependencies (03) UML 1.1 UML 1.2 Resolved closed
UML14-614 Package dependencies (02) UML 1.1 UML 1.2 Resolved closed
UML14-609 Page 10 UML 1.1 Semantics, duplicate entries listed UML 1.1 UML 1.2 Resolved closed
UML14-608 Page 98 of UML 1.1 Semantics, figure 18 (02) UML 1.1 UML 1.2 Resolved closed
UML14-611 UML 1.1 Semantics: Partition (pp.121 123) UML 1.1 UML 1.2 Resolved closed
UML14-610 Page 102 of UML 1.1, StateVertex class misses description UML 1.1 UML 1.2 Resolved closed
UML14-607 Page 98 of UML 1.1 Semantics, figure 18 UML 1.1 UML 1.2 Resolved closed
UML14-606 Page 98 of UML 1.1 Semantics, figure 17 (04) UML 1.1 UML 1.2 Resolved closed
UML14-605 Page 98 of UML 1.1 Semantics, figure 17 (03) UML 1.1 UML 1.2 Resolved closed
UML14-604 Page 98 of UML 1.1 Semantics, figure 17 (02) UML 1.1 UML 1.2 Resolved closed
UML14-603 Page 98 of UML 1.1 Semantics, figure 17 (01) UML 1.1 UML 1.2 Resolved closed
UML14-598 Page 43 of UML Semantics, figure 7 UML 1.1 UML 1.2 Resolved closed
UML14-597 Page 43 UML 1.1 Semantics, figure 7 --editorial UML 1.1 UML 1.2 Resolved closed
UML14-600 Page 46 of UML 1.1 Semantics, description of associations for ModelElement UML 1.1 UML 1.2 Resolved closed
UML14-599 Page 44 UML 1.1 Semantics, figure 8 UML 1.1 UML 1.2 Resolved closed
UML14-602 Page 47 of UML 1.1 Semantics, description of ViewElement UML 1.1 UML 1.2 Resolved closed
UML14-601 Page 47 of UML 1.1 Semantics, description of Refinement UML 1.1 UML 1.2 Resolved closed
UML14-596 Page 16 of UML Semantics, figure 5 UML 1.1 UML 1.2 Resolved closed
UML14-595 Page 62---editorial UML 1.1 UML 1.2 Resolved closed
UML14-594 Page 62 "PseudostateKind"--editorial UML 1.1 UML 1.2 Resolved closed
UML14-592 Page 61: CallConcurrencyKind and EventOriginKind not defined UML 1.1 UML 1.2 Resolved closed
UML14-593 Page 61 "EnumerationLiteral"--editorial UML 1.1 UML 1.2 Resolved closed
UML14-587 Page 50 table 3: Dependency Model elements (02) UML 1.1 UML 1.2 Resolved closed
UML14-586 Page 50 table 3: Dependency model element UML 1.1 UML 1.2 Resolved closed
UML14-591 Page 60 figure 10: Data types UML 1.1 UML 1.2 Resolved closed
UML14-590 Page 9 figure 2: foundation packages UML 1.1 UML 1.2 Resolved closed
UML14-589 Page 137 table 6: Model management - Standard Elements UML 1.1 UML 1.2 Resolved closed
UML14-588 Page 50 table 3: Component model element UML 1.1 UML 1.2 Resolved closed
UML14-585 Page 50 table 3: Auxiliary Elements-Standard Elements (Component model ele UML 1.1 UML 1.2 Resolved closed
UML14-584 Page 40 table2: Generalization model element UML 1.1 UML 1.2 Resolved closed
UML14-583 page 40 table2: Classifier model element UML 1.1 UML 1.2 Resolved closed
UML14-582 Page 40 table 2:Constraints Model UML 1.1 UML 1.2 Resolved closed
UML14-581 Page 40, table 2: Core - Standard Elements UML 1.1 UML 1.2 Resolved closed
UML14-580 Page 54 - ConstrainedStereotype UML 1.1 UML 1.2 Resolved closed
UML14-579 Page 39 - ModelElement/Dependency associations UML 1.1 UML 1.2 Resolved closed
UML14-578 Page 16- The association from parameter to classifier has a 1-1 cardinalit UML 1.1 UML 1.2 Resolved closed
UML14-577 Page 121 - Partition has no parent class UML 1.1 UML 1.2 Resolved closed
UML14-576 Page 98: ActionSequence has no parent class UML 1.1 UML 1.2 Resolved closed
UML14-572 Page 60 - GraphicMarker UML 1.1 UML 1.2 Resolved closed
UML14-574 Page 35/37 - AssociationRole UML 1.1 UML 1.2 Resolved closed
UML14-573 Page 60 - MultiplicityRange UML 1.1 UML 1.2 Resolved closed
UML14-575 Page 81: message has no parent class UML 1.1 UML 1.2 Resolved closed
UML14-571 Page 60 - visibilityKind UML 1.1 UML 1.2 Resolved closed
UML14-569 page 60 - EventOriginKind UML 1.1 UML 1.2 Resolved closed
UML14-568 page 60 - CallConcurrencyKind UML 1.1 UML 1.2 Resolved closed
UML14-570 Page 60 - PseudostateKind UML 1.1 UML 1.2 Resolved closed
UML14-564 UML Documentation--Typos (05) UML 1.1 UML 1.2 Resolved closed
UML14-565 UML Documentation--Typos (06) UML 1.1 UML 1.2 Resolved closed
UML14-566 UML Documentation--Typos (07) UML 1.1 UML 1.2 Resolved closed
UML14-567 Error on association owners UML 1.1 UML 1.2 Resolved closed
UML14-562 UML Documentation--Typos (03) UML 1.1 UML 1.2 Resolved closed
UML14-561 UML Documentation--Typos (02) UML 1.1 UML 1.2 Resolved closed
UML14-560 UML Documentation-Typos (01) UML 1.1 UML 1.2 Resolved closed
UML14-563 UML Documentation--Typos (04) UML 1.1 UML 1.2 Resolved closed
UML25-672 Problems with OCL definition of Package::makesVisible UML 2.5b1 UML 2.5 Resolved closed
UML25-671 an instance spec should be a legitimate value of a property typed by a classifier UML 2.4.1 UML 2.5 Resolved closed
UML25-668 A comment is a specialization of Element UML 2.4.1 UML 2.5 Resolved closed
UML25-667 Surplus classifier field serialized in Superstructure.xmi UML 2.4.1 UML 2.5 Resolved closed
UML25-670 Attribute is represented by Property UML 2.4.1 UML 2.5 Resolved closed
UML25-669 Operation "isConsistentWith" is not overridden for any RedefinableElement UML 2.4.1 UML 2.5 Resolved closed
UML25-664 Question About Arrows In Communication Diagramms UML 2.4.1 UML 2.5 Resolved closed
UML25-663 Constraint [1] uses undefined attribute "ownedAttribute UML 2.4.1 UML 2.5 Resolved closed
UML25-662 Inconsistency: CentralBufferNode (ch .12.3.16) and fig. 12.15 UML 2.4.1 UML 2.5 Resolved closed
UML25-665 missing words in section 14.1 UML 2.4.1 UML 2.5 Resolved closed
UML25-673 Incomplete sentence UML 2.5b1 UML 2.5 Resolved closed
UML25-666 DurationObservation#event should be ordered UML 2.4.1 UML 2.5 Resolved closed
UML25-661 LifeLine instead of Lifeline UML 2.4.1 UML 2.5 Resolved closed
UML25-607 UML 2 Super/Templates/Inconsistent organization UML 1.4.2 UML 2.5 Resolved closed
UML25-606 UML 2 Superstructure -Incompatible use of term link UML 1.4.2 UML 2.5 Resolved closed
UML25-604 UML 2.0 Issue: Semantics of Provided and Required Interfaces UML 1.4.2 UML 2.5 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-615 9.3.11 Port (from Ports) UML 1.4.2 UML 2.5 Resolved closed
UML25-614 .3.44 Property (from Kernel) UML 1.4.2 UML 2.5 Resolved closed
UML25-610 UML2 super/CommonBehavior/Opaque behavior : bad OO modelling UML 1.4.2 UML 2.5 Resolved closed
UML25-611 7.3.24 Interface (from Interfaces) UML 1.4.2 UML 2.5 Resolved closed
UML25-605 UML 2 Superstructure - cross-hair notation for nested classes UML 1.4.2 UML 2.5 Resolved closed
UML25-612 9.3.6 Connector (from InternalStructures) UML 1.4.2 UML 2.5 Resolved closed
UML25-613 8.3.1 Component (from BasicComponents, PackagingComponents) UML 1.4.2 UML 2.5 Resolved closed
UML25-630 UML 2.3: Transitions outgoing junction vertexes should be allowed to have triggers UML 2.4.1 UML 2.5 Resolved closed
UML25-622 inconsistent Generalization subsections in spec format UML 1.4.2 UML 2.5 Resolved closed
UML25-621 notational standard for {subsets x} in textual contexts UML 1.4.2 UML 2.5 Resolved closed
UML25-629 15.3.11 State (from BehaviorStateMachines, ProtocolStateMachines) XMI 1.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-623 "Class" should read "Classifier" in Generalization subsection for Behaviore UML 1.4.2 UML 2.5 Resolved closed
UML25-620 15.3.14 Transition (from BehaviorStateMachines) XMI 1.0 UML 2.5 Resolved closed
UML25-619 15.3.10 Region (from BehaviorStateMachines) UML 1.4.2 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-626 UML2 Super / Templates / ordering of subExpressions UML 1.4.2 UML 2.5 Resolved closed
UML25-617 15.3.16 Vertex (from BehaviorStateMachines) UML 1.4.2 UML 2.5 Resolved closed
UML25-616 Artifact (from Artifacts) UML 1.4.2 UML 2.5 Resolved closed
UML25-625 UML 2 Super/ Classes / issue with Property::isComposite UML 1.4.2 UML 2.5 Resolved closed
UML25-618 15.3.8 Pseudostate (from BehaviorStateMachines) UML 1.4.2 UML 2.5 Resolved closed
UML25-675 Modeling sent messages in State Machines UML 2.3b1 UML 2.5 Resolved closed
UML25-674 TestIdentityAction for datatypes FUML 1.0b2 UML 2.5 Resolved closed
UML25-660 Behavior should be derived from Classifier, not Class UML 2.4.1 UML 2.5 Resolved closed
UML25-659 Package merge on Class metatype causes semantic issues - particularly with state machine context UML 2.4.1 UML 2.5 Resolved closed
UML25-648 Error in UML diagrams? UML 2.4.1 UML 2.5 Resolved closed
UML25-647 Suggestions for editorial changes UML 2.4.1 UML 2.5 Resolved closed
UML25-654 how to instantiate associations between stereotypes UML 2.4.1 UML 2.5 Resolved closed
UML25-653 Core package caption wrong UML 2.4.1 UML 2.5 Resolved closed
UML25-658 Add an example for the lifeline head shape UML 2.4.1 UML 2.5 Resolved closed
UML25-657 color of the notation is specified UML 2.4.1 UML 2.5 Resolved closed
UML25-656 The property “packagedElement: PackageableElement [*]” is not a derived property and should not be prefixed with "/" UML 2.4.1 UML 2.5 Resolved closed
UML25-655 Opposite ends of derived unions should be derived unions UML 2.4.1 UML 2.5 Resolved closed
UML25-651 Use of term "locus of control" UML 2.4.1 UML 2.5 Resolved closed
UML25-650 V2.4.1 from 11-08-05 on page 14 in Figure 7.3 UML 2.4.1 UML 2.5 Resolved closed
UML25-646 default is wrong UML 2.4.1 UML 2.5 Resolved closed
UML25-645 V2.4.1 from 11-08-05 on page 14 in Figure 7.3 UML 2.4.1 UML 2.5 Resolved closed
UML25-649 Reference in index to item that does not exist in contents UML 2.4.1 UML 2.5 Resolved closed
UML25-652 incorrect upper value of coveredBy of Lifeline UML 2.4.1 UML 2.5 Resolved closed
UML25-632 ChangeEvent association mismatch UML 2.4.1 UML 2.5 Resolved closed
UML25-631 EnumerationLiterals in the XMI UML 2.4.1 UML 2.5 Resolved closed
UML25-635 "A_realization_abstraction_component" is useless UML 2.4.1 UML 2.5 Resolved closed
UML25-634 Subpart I and II are missing in Bookmarks UML 2.4.1 UML 2.5 Resolved closed
UML25-644 default value of ClassifierTemplateParameter#allowSubstitutable is "..." UML 2.4.1 UML 2.5 Resolved closed
UML25-643 Figure 15.2 does not include TransitionKind UML 2.4.1 UML 2.5 Resolved closed
UML25-640 role "interval" appears "interva" UML 2.4.1 UML 2.5 Resolved closed
UML25-639 OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..." UML 2.4.1 UML 2.5 Resolved closed
UML25-642 misspelling: io-oargument UML 2.4.1 UML 2.5 Resolved closed
UML25-641 OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..." UML 2.4.1 UML 2.5 Resolved closed
UML25-636 RedefinableElement (from Kernel) is preferable UML 2.4.1 UML 2.5 Resolved closed
UML25-633 UML Superstructure Specification UML 2.4.1 UML 2.5 Resolved closed
UML25-637 poor figure resolution and a misspelling: fal...( false ) UML 2.4.1 UML 2.5 Resolved closed
UML25-638 {ordered} is rather far from +bodyOutput UML 2.4.1 UML 2.5 Resolved closed
UML25-601 UML 2 Super and Infra/ defualt property of Parameter::effect UML 1.4.2 UML 2.5 Resolved closed
UML25-602 Associations between interfaces UML 1.4.2 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-499 Association notation for properties does not allow representation of aggregation UML 2.5b1 UML 2.5 Resolved closed
UML25-498 UML2.5 issue: incorrect use of oclKindOf()->notEmpty() UML 2.5b1 UML 2.5 Resolved closed
UML25-497 wrong multiplicity of redefining states UML 2.5b1 UML 2.5 Resolved closed
UML25-496 Keywords are inconsistently defined and applied UML 2.5b1 UML 2.5 Resolved closed
UML25-487 InformationFlow::sources_and_target_kind UML 2.5b1 UML 2.5 Resolved closed
UML25-494 UML2.5 issue: clause 7.7.5 does not correctly refer to Instantiate stereotype UML 2.5b1 UML 2.5 Resolved closed
UML25-493 UML 2.5 - clause 14 does not put Examples at the correct heading level UML 2.5b1 UML 2.5 Resolved closed
UML25-489 Table C.1 apply UML 2.5b1 UML 2.5 Resolved closed
UML25-488 Metaclass operations incomplete UML 2.5b1 UML 2.5 Resolved closed
UML25-492 UML2.5 issue: clause 10 Signal and Reception UML 2.5b1 UML 2.5 Resolved closed
UML25-491 Conflict in use of unlimited natural UML 2.4.1 UML 2.5 Resolved closed
UML25-495 UML 2.5: ActivityPartition::represents keywords UML 2.5b1 UML 2.5 Resolved closed
UML25-490 UML 2.5 FTF - Clause 17 Interactions, Section 17.2.3 Semantics, subsection Interaction UML 2.5b1 UML 2.5 Resolved closed
UML25-486 Classifier::hasVisibilityOf(...) UML 2.5b1 UML 2.5 Resolved closed
UML25-485 Two entries UML 2.5b1 UML 2.5 Resolved closed
UML25-519 About UseCase description UML 2.5b1 UML 2.5 Resolved closed
UML25-518 Annex B summary table UML 2.5b1 UML 2.5 Resolved closed
UML25-529 actors of a use case express the requirements of its subject(s) regarding its/their environment. UML 2.5b1 UML 2.5 Resolved closed
UML25-528 UML: Parameter Direction and Effect UML 2.5b1 UML 2.5 Resolved closed
UML25-523 UML 2.5 Issue: specification for qualified association ends is in wrong clause UML 2.5b1 UML 2.5 Resolved closed
UML25-522 UML 2.5 class_name UML 2.5b1 UML 2.5 Resolved closed
UML25-526 Event pools for passive objects UML 2.5b1 UML 2.5 Resolved closed
UML25-525 Behavior after exceptions are encountered UML 2.5b1 UML 2.5 Resolved closed
UML25-521 UseCases editorial change UML 2.5b1 UML 2.5 Resolved closed
UML25-520 The current criteria used in UML for BehavioralFeature::isDistinguishable() is insufficient in practice UML 2.5b1 UML 2.5 Resolved closed
UML25-517 Clarify that stereotypes can be applied to UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-516 UML2.5 clause 17 keyword inconsistency UML 2.5b1 UML 2.5 Resolved closed
UML25-524 Completion events disambiguation UML 2.5b1 UML 2.5 Resolved closed
UML25-527 UML 2.5: Clarification of semantics for CreateLinkAction and DestroyLinkAction UML 2.5b1 UML 2.5 Resolved closed
UML25-530 UML 2.5 FTF Receptions may not have a method UML 2.5b1 UML 2.5 Resolved closed
UML25-414 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Or Pre-conditions appears limiting UML 2.4.1 UML 2.5 Resolved closed
UML25-417 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Clarification meaning of not part of the subject UML 2.4.1 UML 2.5 Resolved closed
UML25-416 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Point to Figures to help explain subject vs owner UML 2.4.1 UML 2.5 Resolved closed
UML25-415 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Initiating ? Interacting with UML 2.4.1 UML 2.5 Resolved closed
UML25-420 18.1.3 Semantics Use Case and Actors Extends P. 687 - Omitted conditions are true UML 2.4.1 UML 2.5 Resolved closed
UML25-419 18.1.3 Semantics Use Case and Actors Extends P. 687 - Easy UML 2.4.1 UML 2.5 Resolved closed
UML25-418 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Additional behavior vs Additional use case UML 2.4.1 UML 2.5 Resolved closed
UML25-422 Location: 18.1.4 Notation P. 688 - Point to diagram UML 2.4.1 UML 2.5 Resolved closed
UML25-421 18.1.3 Semantics Use Case and Actors Extends P. 687 - Clarify role of owner UML 2.4.1 UML 2.5 Resolved closed
UML25-574 State Machine Package--Compliance RAS 2.0b1 UML 2.5 Resolved closed
UML25-573 Actions need to be independent from Activities RAS 2.0b1 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-566 Composite structures/contradictory constraint on connector RAS 2.0b1 UML 2.5 Resolved closed
UML25-568 UML 2 Super/Interfaces RAS 2.0b1 UML 2.5 Resolved closed
UML25-571 Issue in UML 2 CombinedFragment class RAS 2.0b1 UML 2.5 Resolved closed
UML25-570 Issue in UML 2 Message class RAS 2.0b1 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-569 Issue in UML 2 Message class RAS 2.0b1 UML 2.5 Resolved closed
UML25-572 Issue in UML 2 Gate class RAS 2.0b1 UML 2.5 Resolved closed
UML25-503 Interactions needs to fix Gate name Distinguishability rules UML 2.5b1 UML 2.5 Resolved closed
UML25-502 ActionInputPin notations missing UML 2.5b1 UML 2.5 Resolved closed
UML25-515 UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole UML 2.5b1 UML 2.5 Resolved closed
UML25-514 UML2.5's Connector role constraint excludes inherited roles UML 2.5b1 UML 2.5 Resolved closed
UML25-505 Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature UML 2.5b1 UML 2.5 Resolved closed
UML25-504 Classifier operation inherit(NamedElement[*]) : NamedElement[*] UML 2.5b1 UML 2.5 Resolved closed
UML25-511 Forked association notation ill-formed UML 2.5b1 UML 2.5 Resolved closed
UML25-501 UML 2.5 Beta 1 9.5.3 Qualifiers UML 2.5b1 UML 2.5 Resolved closed
UML25-500 Transition redefinition UML 2.5b1 UML 2.5 Resolved closed
UML25-513 parts should be allowed to show their interfaces UML 2.5b1 UML 2.5 Resolved closed
UML25-512 Behavior is not allowed to be source or target of an InformationFlow UML 2.4.1 UML 2.5 Resolved closed
UML25-510 UML 2.5 FTF] Editorial / §15.5.1 p429 UML 2.5b1 UML 2.5 Resolved closed
UML25-509 Inheriting Connectors UML 2.5b1 UML 2.5 Resolved closed
UML25-507 UML 2.5 FTF 14.2.3 Page 327 Typo UML 2.5b1 UML 2.5 Resolved closed
UML25-506 Incorrect text on state list notation interchange UML 2.5b1 UML 2.5 Resolved closed
UML25-508 UML 2.5 FTF 15.3.3 Page 406 decisionInputBehavior rather than decisionInput UML 2.5b1 UML 2.5 Resolved closed
UML25-582 UML 2 Super/Components/missing description of Connector::contract UML 1.4.2 UML 2.5 Resolved closed
UML25-581 UML 2 Super/Interactions/notation for accessing a static feature UML 1.4.2 UML 2.5 Resolved closed
UML25-584 Missing notation for Behaviors in a BehavioredClassifier UML 1.4.2 UML 2.5 Resolved closed
UML25-583 Name without a colon for Property in Composite Structures UML 1.4.2 UML 2.5 Resolved closed
UML25-586 Profiles in Compliance Level 1? UML 1.4.2 UML 2.5 Resolved closed
UML25-585 Redundant parameter specifications for Operation and Behavior UML 1.4.2 UML 2.5 Resolved closed
UML25-576 There is no "precise mapping UML 2.0 UML 2.5 Resolved closed
UML25-579 UML 2 Super/Activities/Class-Activity association missing UML 1.4.2 UML 2.5 Resolved closed
UML25-578 UML2 super&infra/Profiles/ownership of Image UML 1.4.2 UML 2.5 Resolved closed
UML25-588 Figures 103 and 121 use <> dependencies UML 1.4.2 UML 2.5 Resolved closed
UML25-587 . <> on Usage UML 1.4.2 UML 2.5 Resolved closed
UML25-580 UML 2 Super/Templates/Template substitution symbol problematic UML 1.4.2 UML 2.5 Resolved closed
UML25-577 Port should specialize featuringClassifier UML 1.4.2 UML 2.5 Resolved closed
UML25-575 Semantics section of StructuralFeature UML 2.0 UML 2.5 Resolved closed
UML25-538 Clarification of use of BNF for textual notations UML 2.5b1 UML 2.5 Resolved closed
UML25-537 ActivityParameterNode notation UML 2.5b1 UML 2.5 Resolved closed
UML25-539 Avoid covariant parameters in metamodel operation redefinition UML 2.5b1 UML 2.5 Resolved closed
UML25-536 The resolution to Issue 18528 contains incorrect OCL and operation names UML 2.5b1 UML 2.5 Resolved closed
UML25-535 The resolution to issue 18415 contains invalid OCL UML 2.5b1 UML 2.5 Resolved closed
UML25-546 Wording corrections in Behavior Diagrams and Activity Diagram Labels UML 2.5b1 UML 2.5 Resolved closed
UML25-545 Labels for generalization sets in UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-541 Classifier and state annotations in UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-540 Dashed interaction lifelines in UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-532 Action operation redefinition is invalid UML 2.5b1 UML 2.5 Resolved closed
UML25-531 Association::endType() is inconsistent UML 2.5b1 UML 2.5 Resolved closed
UML25-534 Improve documentation of how derived properties are calculated UML 2.5b1 UML 2.5 Resolved closed
UML25-533 The resolution to 18697 contains errors UML 2.5b1 UML 2.5 Resolved closed
UML25-544 Template parameter rectangles UML 2.5b1 UML 2.5 Resolved closed
UML25-543 Ownership of property qualifier rectangles UML 2.5b1 UML 2.5 Resolved closed
UML25-542 Dependencies with more than two ends in UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-432 Location: 18.1.5 Examples Figure 18-9. 690 - Description does not match figure 18-9 UML 2.4.1 UML 2.5 Resolved closed
UML25-431 Location: 18.1.5 Examples Figure 18-2. 689 - Explain about multiplicity UML 2.4.1 UML 2.5 Resolved closed
UML25-424 Location: 18.1.4 Notation P. 688 - Point to diagram (03) UML 2.4.1 UML 2.5 Resolved closed
UML25-423 Location: 18.1.4 Notation P. 688 - Point to diagram (02) UML 2.4.1 UML 2.5 Resolved closed
UML25-429 Location: 18.1.4 Notation P. 688 - Point to diagram (08) UML 2.4.1 UML 2.5 Resolved closed
UML25-428 Location: 18.1.4 Notation P. 688 - Point to diagram (07) UML 2.4.1 UML 2.5 Resolved closed
UML25-427 Location: 18.1.4 Notation P. 688 - Point to diagram (06) UML 2.4.1 UML 2.5 Resolved closed
UML25-426 Location: 18.1.4 Notation P. 688 - Point to diagram (05) UML 2.4.1 UML 2.5 Resolved closed
UML25-430 Location: 18.1.5 Examples Figure 18-2. 689 - Explain about «Subsystem» UML 2.4.1 UML 2.5 Resolved closed
UML25-436 Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - At least one actor UML 2.4.1 UML 2.5 Resolved closed
UML25-435 Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - At least one actor UML 2.4.1 UML 2.5 Resolved closed
UML25-425 Location: 18.1.4 Notation P. 688 - Point to diagram (04) UML 2.4.1 UML 2.5 Resolved closed
UML25-433 Location: 18.1.5 Examples Figure 18-10. 691 - Duplicate Diagram UML 2.4.1 UML 2.5 Resolved closed
UML25-434 Location: 18.2 Classifier Descriptions Include Constraints. 696 - Includes must be a DAG UML 2.4.1 UML 2.5 Resolved closed
UML25-483 UML 2.5 issue: Clause 6.3 should contain a definition of "execution scope" UML 2.5b1 UML 2.5 Resolved closed
UML25-482 Fixed-point issues with the definition of default values for literals UML 2.5b1 UML 2.5 Resolved closed
UML25-475 Fix the notation to allow assignment of a decision to partition when the swimlanes are not practical. UML 2.5b1 UML 2.5 Resolved closed
UML25-474 UML association semantics vis-a-vis Interfaces (and other types of classifiers) UML 2.5b1 UML 2.5 Resolved closed
UML25-473 confusing wording and terminology for TransitionKind in the section “Transition kinds relative to source”. UML 2.5b1 UML 2.5 Resolved closed
UML25-470 Section 11: feature inheritance should be orthogonal to the topology of well-formed connections in a structured classifi UML 2.4.1 UML 2.5 Resolved closed
UML25-469 ConnectableElement-end" has @isOrdered='true' UML 2.4.1 UML 2.5 Resolved closed
UML25-472 The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance UML 2.5b1 UML 2.5 Resolved closed
UML25-471 UML 2.5 issue: structural features with isStatic = true may not have a slot in InstanceSpecifications UML 2.5b1 UML 2.5 Resolved closed
UML25-478 Notation for state machine specializations UML 2.5b1 UML 2.5 Resolved closed
UML25-477 UML2.5 issue : missing constraints on aggregation / composition UML 2.5b1 UML 2.5 Resolved closed
UML25-476 Two different Dashed Arrow Styles for Reply message in Figure 17.2 Interaction Example UML 2.5b1 UML 2.5 Resolved closed
UML25-481 Error in Dependency notation example UML 2.5b1 UML 2.5 Resolved closed
UML25-480 Error in diagram using StringExpressions UML 2.5b1 UML 2.5 Resolved closed
UML25-479 Inconsistent template binding notation example UML 2.5b1 UML 2.5 Resolved closed
UML25-468 UML2.5: clarification about the semantics of redefinition UML 2.4.1 UML 2.5 Resolved closed
UML25-467 Lifeline has no type. UML 2.4.1 UML 2.5 Resolved closed
UML25-466 Location: Table B.1 UML Keywords p 778 - Use of # in Semantics col UML 2.4.1 UML 2.5 Resolved closed
UML25-484 UML 2.5 issue; the word "individual" is incorrect in 9.8 UML 2.5b1 UML 2.5 Resolved closed
UML25-451 Location: B.4.4 State Shapes P. 752 - State List Limitations UML 2.4.1 UML 2.5 Resolved closed
UML25-450 Location: B.2.4 P. 739 - confusing model and diagram UML 2.4.1 UML 2.5 Resolved closed
UML25-441 Location: Table 21-1 PrimitiveType semantics Real P. 726 - IEEE 754 UML 2.4.1 UML 2.5 Resolved closed
UML25-440 Location: 21.1 Summary P. 726 - Missing header UML 2.4.1 UML 2.5 Resolved closed
UML25-438 Location: Figure 18-3 Example Extend p.689 - Circle on comment "anchor" not standard UML 2.4.1 UML 2.5 Resolved closed
UML25-437 Location: 18.1.1 Summary p 685 - emergent behavior UML 2.4.1 UML 2.5 Resolved closed
UML25-445 Location: Table 21-1 String P. 726 UML 2.4.1 UML 2.5 Resolved closed
UML25-444 Location: Table 21-1 P. 726 - Title of table not great UML 2.4.1 UML 2.5 Resolved closed
UML25-443 Location: 21.2 Semantics P. 726 - Subsection title UML 2.4.1 UML 2.5 Resolved closed
UML25-442 Location: Table 21-1 PrimitiveType semantics Real P. 726 - Real Number representation UML 2.4.1 UML 2.5 Resolved closed
UML25-448 Location: Figure 21-3 UML 2.4.1 UML 2.5 Resolved closed
UML25-447 Location: Table 21-1 P. 726 - Row ordering UML 2.4.1 UML 2.5 Resolved closed
UML25-446 Location: Table 21-1 Unlimited Natural P. 726 - Infinity UML 2.4.1 UML 2.5 Resolved closed
UML25-439 Location: Figure 20-4 and accompanying text P. 719 - InformationItem can represent multiple types? UML 2.4.1 UML 2.5 Resolved closed
UML25-449 Location: B.2.3 P. 738 - confusing model and diagram UML 2.4.1 UML 2.5 Resolved closed
UML25-595 Active and passive UML 1.4.2 UML 2.5 Resolved closed
UML25-594 P.58 Missing closing bracket in second constraint UML 1.4.2 UML 2.5 Resolved closed
UML25-592 "required interface" UML 2.0 UML 2.5 Resolved closed
UML25-591 Compliance points - Diagram Interchange UML 1.4.2 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-598 included use case wrongly referred to as the including use case UML 1.4.2 UML 2.5 Resolved closed
UML25-597 check the BNF example given in the text UML 1.4.2 UML 2.5 Resolved closed
UML25-590 Bidirectional messages to a port object UML 1.4.2 UML 2.5 Resolved closed
UML25-589 Figures 120 and 121 UML 1.4.2 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
UML25-593 P.35 Typo in OCL definition of isDistinguishableFrom query UML 1.4.2 UML 2.5 Resolved closed
UML25-553 misleading omission UML 2.5b1 UML 2.5 Resolved closed
UML25-552 Validation errors in UML metamodel UML 2.5b1 UML 2.5 Resolved closed
UML25-547 PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value UML 2.5b1 UML 2.5 Resolved closed
UML25-549 Assocation display options too narrow UML 2.5b1 UML 2.5 Resolved closed
UML25-548 Annex E lacks sub-clauses for the XMI details for StandardProfile and UMLDI UML 2.5b1 UML 2.5 Resolved closed
UML25-551 UML 2.5 issue: subsettingContext() has incorrect logic UML 2.5b1 UML 2.5 Resolved closed
UML25-550 Headed composite and not ownedElement UML 2.5b1 UML 2.5 Resolved closed
UML25-554 Activity::structuredNode is incorrectly marked as readOnly = true UML 2.5b1 UML 2.5 Resolved closed
UML25-456 Location: Annex C Keywords p 777 - Capitalization of «trace» UML 2.4.1 UML 2.5 Resolved closed
UML25-455 Location: Annex C Keywords P. 777 - Previously unmentioned constraints given in Keywords Annex UML 2.4.1 UML 2.5 Resolved closed
UML25-453 Location: B.6 UMLILabel Constraints. P 766 - Use Case Oval. UML 2.4.1 UML 2.5 Resolved closed
UML25-452 Location: B.6 Classifier Description UMLInheritedStateBorderKind [Enumeration] Literals p 763 UML 2.4.1 UML 2.5 Resolved closed
UML25-458 Location: Table B.1 UML Keywords p 778 - Keywords should be in index UML 2.4.1 UML 2.5 Resolved closed
UML25-457 Location: Annex C Keywords p 777 - Capitalization of «create» UML 2.4.1 UML 2.5 Resolved closed
UML25-464 Location: Index p. 796 among others - Index items with only one page UML 2.4.1 UML 2.5 Resolved closed
UML25-463 Location: Index p 795 - Index of "is" UML 2.4.1 UML 2.5 Resolved closed
UML25-460 Location: Index UML 2.4.1 UML 2.5 Resolved closed
UML25-459 Location: Annex C Keywords P. 780 - Bizarre definition of statemachine UML 2.4.1 UML 2.5 Resolved closed
UML25-454 Location B.6 UMLStateShape statelist p 770 - StateList Limitations UML 2.4.1 UML 2.5 Resolved closed
UML25-462 Location: Index p 793 - emergent behavior UML 2.4.1 UML 2.5 Resolved closed
UML25-465 Location: Index Mis. - Missing terms in the Index UML 2.4.1 UML 2.5 Resolved closed
UML25-461 Type: Structural - Location Index p 790, 794, UML 2.4.1 UML 2.5 Resolved closed
UML25-394 Location: 15.5.1 - typo UML 2.4.1 UML 2.5 Resolved closed
UML25-393 Location: Figure 15.57 page 426 UML 2.4.1 UML 2.5 Resolved closed
UML25-399 Location: 17.2.3 Semantics Interaction Fragments p 607 UML 2.4.1 UML 2.5 Resolved closed
UML25-398 17.1.5 Interaction Diagram Variants p 607 UML 2.4.1 UML 2.5 Resolved closed
UML25-397 Location: p 484 - Exception store UML 2.4.1 UML 2.5 Resolved closed
UML25-396 Location: Figure 15-23 p.411 UML 2.4.1 UML 2.5 Resolved closed
UML25-391 Location: Figure 15-23 UML 2.4.1 UML 2.5 Resolved closed
UML25-390 Location: p. 357 StateMachine Redefinition UML 2.4.1 UML 2.5 Resolved closed
UML25-389 Location: p. 338 Transition execution sequence UML 2.4.1 UML 2.5 Resolved closed
UML25-388 Location: p. 338 Transition execution sequence UML 2.4.1 UML 2.5 Resolved closed
UML25-395 Location: Figure 15-63 UML 2.4.1 UML 2.5 Resolved closed
UML25-387 Location: p. 337 Conflicting Transitions UML 2.4.1 UML 2.5 Resolved closed
UML25-392 Location: Page 413, 15.3.2 Abstract Syntax Control Nodes Figure 15-26 UML 2.4.1 UML 2.5 Resolved closed
UML25-386 Location: p. 337 Conflicting Transitions UML 2.4.1 UML 2.5 Resolved closed
UML25-317 What is “Intentionally Not specified”? UML 2.4.1 UML 2.5 Resolved closed
UML25-316 What is aggregation UML 2.4.1 UML 2.5 Resolved closed
UML25-311 inout parameters and effects UML 2.4.1 UML 2.5 Resolved closed
UML25-310 Effect Intent UML 2.4.1 UML 2.5 Resolved closed
UML25-308 Return Parameter order UML 2.4.1 UML 2.5 Resolved closed
UML25-307 Default value of readonly should be referenced UML 2.4.1 UML 2.5 Resolved closed
UML25-313 Parameter Sets UML 2.4.1 UML 2.5 Resolved closed
UML25-312 isException and direction and effect UML 2.4.1 UML 2.5 Resolved closed
UML25-320 Location: 9.5.3 p 122 In the common case UML 2.4.1 UML 2.5 Resolved closed
UML25-319 Location: 9.5.3 p 121 Why not all empty UML 2.4.1 UML 2.5 Resolved closed
UML25-314 Use isReadOnly default UML 2.4.1 UML 2.5 Resolved closed
UML25-315 Redefinition does not allow for overloading UML 2.4.1 UML 2.5 Resolved closed
UML25-318 What is “Intentionally Not specified”? UML 2.4.1 UML 2.5 Resolved closed
UML25-309 Return Parameter pronoun UML 2.4.1 UML 2.5 Resolved closed
UML25-223 Two categories is not enough UML 2.4.1 UML 2.5 Resolved closed
UML25-222 UML Semantics UML 2.4.1 UML 2.5 Resolved closed
UML25-224 Semantics Areas section not clear UML 2.4.1 UML 2.5 Resolved closed
UML25-413 Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Variants are not defined UML 2.4.1 UML 2.5 Resolved closed
UML25-412 Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Actors need not initiate UML 2.4.1 UML 2.5 Resolved closed
UML25-411 Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Are actors mandatory? UML 2.4.1 UML 2.5 Resolved closed
UML25-405 Location: Pg. 615, Figure 17.4.3: Semantics, Sub-clause: Messages UML 2.4.1 UML 2.5 Resolved closed
UML25-404 Pg. 613, Clause 17.3.4: Notation UML 2.4.1 UML 2.5 Resolved closed
UML25-403 Location: Pg. 612, Clause 17.2.5 - Minor rewording to Clause 17.2.5 UML 2.4.1 UML 2.5 Resolved closed
UML25-402 Location: Pg. 612, Figure 17.5 - Modify Figure 17.5 to enhance readability UML 2.4.1 UML 2.5 Resolved closed
UML25-410 Location: 18.1.1 Summary P. 685 - A Subject may only refer to a single system UML 2.4.1 UML 2.5 Resolved closed
UML25-409 General value lifeline Row p 647 UML 2.4.1 UML 2.5 Resolved closed
UML25-408 Location: Table 17.6 entire table p 646 UML 2.4.1 UML 2.5 Resolved closed
UML25-401 Pg. 611, Clause 17.2.5: Examples - : Insert “formal” in reference to gates in the “Examples” clause (17.2.5) UML 2.4.1 UML 2.5 Resolved closed
UML25-400 Location: 17.2.4 Notation ExecutionSpecification p608 - : Specification of color UML 2.4.1 UML 2.5 Resolved closed
UML25-407 Location: LostMessage Row p 639 UML 2.4.1 UML 2.5 Resolved closed
UML25-406 Pg. 617, Figure 17.4.3: Semantics, Sub-clause: Gates - Replace “formal” with “actual” in Clause 17.4.3 UML 2.4.1 UML 2.5 Resolved closed
UML25-264 Default value for LiteralString UML 2.4.1 UML 2.5 Resolved closed
UML25-263 Optional String Multiplicity UML 2.4.1 UML 2.5 Resolved closed
UML25-256 Excessive null checks UML 2.4.1 UML 2.5 Resolved closed
UML25-255 Single and set of aren't really parallel UML 2.4.1 UML 2.5 Resolved closed
UML25-252 Missing a UML 2.4.1 UML 2.5 Resolved closed
UML25-251 inconsistent spacing on diagram UML 2.4.1 UML 2.5 Resolved closed
UML25-260 TypedElement description could be expanded UML 2.4.1 UML 2.5 Resolved closed
UML25-259 It seems to me that a relationship requires a minimum of two relatedElements UML 2.4.1 UML 2.5 Resolved closed
UML25-254 Use of the diamond symbol (?)needs to be explained UML 2.4.1 UML 2.5 Resolved closed
UML25-253 Instantiate Dependency UML 2.4.1 UML 2.5 Resolved closed
UML25-261 Generalization Relationship to itself? UML 2.4.1 UML 2.5 Resolved closed
UML25-262 Negatively phrased sentence UML 2.4.1 UML 2.5 Resolved closed
UML25-258 Sentence difficult to read UML 2.4.1 UML 2.5 Resolved closed
UML25-257 allNamespace description doesn't match OCL UML 2.4.1 UML 2.5 Resolved closed
UML25-338 Location p 152 Generalization Attributes: IsSubstitutable UML 2.4.1 UML 2.5 Resolved closed
UML25-340 Location p 153 complete_and_disjoint: Abstract Implication UML 2.4.1 UML 2.5 Resolved closed
UML25-339 Location p 153 complete_and_disjoint: Complete vs covering? UML 2.4.1 UML 2.5 Resolved closed
UML25-334 Location: p 145 CallConcurrencyKind [Enumeration - blocks -- > locks UML 2.4.1 UML 2.5 Resolved closed
UML25-333 Location: p 145 (3X) Detail: simultaneously -- > concurrently UML 2.4.1 UML 2.5 Resolved closed
UML25-337 Location p 146 Classifier Description: isAbstract UML 2.4.1 UML 2.5 Resolved closed
UML25-336 Location p 145 Classifier Description: objects -> instances UML 2.4.1 UML 2.5 Resolved closed
UML25-343 Location p 162 two_parameter_sets: Why UML 2.4.1 UML 2.5 Resolved closed
UML25-342 Location p 157 isConsistentWith: missing rules UML 2.4.1 UML 2.5 Resolved closed
UML25-341 Location p 154 Association Ends: Instances of multiple classifiers UML 2.4.1 UML 2.5 Resolved closed
UML25-344 Location p 162 ParameterSet constraints input: Exceptions and parameterset UML 2.4.1 UML 2.5 Resolved closed
UML25-335 Location p 145 Classifier Description - objects -> instances UML 2.4.1 UML 2.5 Resolved closed
UML25-249 While-->And UML 2.4.1 UML 2.5 Resolved closed
UML25-248 Unclear description of multiplicities UML 2.4.1 UML 2.5 Resolved closed
UML25-243 Imports UML 2.4.1 UML 2.5 Resolved closed
UML25-242 ElementImport cannot be further imported UML 2.4.1 UML 2.5 Resolved closed
UML25-247 Confusing description of types UML 2.4.1 UML 2.5 Resolved closed
UML25-238 Note refers to an undiscussed concept UML 2.4.1 UML 2.5 Resolved closed
UML25-240 Packageable Elements and Imports UML 2.4.1 UML 2.5 Resolved closed
UML25-239 Missing word UML 2.4.1 UML 2.5 Resolved closed
UML25-246 Missing TypedElement - use of the term constrained seems to be circular UML 2.4.1 UML 2.5 Resolved closed
UML25-245 Missing TypedElement UML 2.4.1 UML 2.5 Resolved closed
UML25-250 Missing OCL UML 2.4.1 UML 2.5 Resolved closed
UML25-241 Packageable Elements and Imports (02) UML 2.4.1 UML 2.5 Resolved closed
UML25-244 Incorrect text describing diagram elements UML 2.4.1 UML 2.5 Resolved closed
UML25-358 Location 13.1 Summary p 305 - Use of the word “emergent” UML 2.4.1 UML 2.5 Resolved closed
UML25-357 Operations p 245 (2X) typo UML 2.4.1 UML 2.5 Resolved closed
UML25-355 Location Figure 11-23 s p.217 - Instance/roll names UML 2.4.1 UML 2.5 Resolved closed
UML25-354 Location Figure 11-22 s p.216 - Title doesn’t match contents UML 2.4.1 UML 2.5 Resolved closed
UML25-351 Location: Constraints p 193 - Missing constraint? UML 2.4.1 UML 2.5 Resolved closed
UML25-350 Location 10.4.4 Notations p.188 - Reception compartment UML 2.4.1 UML 2.5 Resolved closed
UML25-349 Location 10.3.3 Signals p.186 UML 2.4.1 UML 2.5 Resolved closed
UML25-348 10.2.4 Notation p 184. - Enumeration attributes and operations UML 2.4.1 UML 2.5 Resolved closed
UML25-346 Location: 10.2.3 Enumeration p. 184: New EnumerationLiterals UML 2.4.1 UML 2.5 Resolved closed
UML25-347 Location: 10.2.4 Notation p 184 UML 2.4.1 UML 2.5 Resolved closed
UML25-353 Location Figure 11-21 s p.216 - Instance/roll names UML 2.4.1 UML 2.5 Resolved closed
UML25-356 Location Figure 11-23 s p.217 - Instance/roll names (02) UML 2.4.1 UML 2.5 Resolved closed
UML25-352 Location: Figure 11-3 UML 2.4.1 UML 2.5 Resolved closed
UML25-281 Wrong Reference UML 2.4.1 UML 2.5 Resolved closed
UML25-280 missing headings UML 2.4.1 UML 2.5 Resolved closed
UML25-290 Min/Max UML 2.4.1 UML 2.5 Resolved closed
UML25-289 Two anonymous invariants UML 2.4.1 UML 2.5 Resolved closed
UML25-292 8.6 p 100 isCompatibleWith() ..save space UML 2.4.1 UML 2.5 Resolved closed
UML25-291 Save Space UML 2.4.1 UML 2.5 Resolved closed
UML25-288 result() error UML 2.4.1 UML 2.5 Resolved closed
UML25-287 French UML 2.4.1 UML 2.5 Resolved closed
UML25-284 Invariant name UML 2.4.1 UML 2.5 Resolved closed
UML25-283 Improve readability of constraint names UML 2.4.1 UML 2.5 Resolved closed
UML25-295 Association Descriptions not that useful UML 2.4.1 UML 2.5 Resolved closed
UML25-294 IsNull not Boolean UML 2.4.1 UML 2.5 Resolved closed
UML25-282 Duration Definition UML 2.4.1 UML 2.5 Resolved closed
UML25-286 Set--> List UML 2.4.1 UML 2.5 Resolved closed
UML25-285 Why is value optional UML 2.4.1 UML 2.5 Resolved closed
UML25-293 Turing Machine lurking paradox? UML 2.4.1 UML 2.5 Resolved closed
UML25-323 Location: 9.6.3 Operations p 127 Undefined ? UML 2.4.1 UML 2.5 Resolved closed
UML25-322 Location: 9.5.3 p 121 Can’t qualifiers be queries? UML 2.4.1 UML 2.5 Resolved closed
UML25-330 Location: 9.8.4 Notation p 141 UML 2.4.1 UML 2.5 Resolved closed
UML25-329 Location: 9.8.3 Semantics p 139 UML 2.4.1 UML 2.5 Resolved closed
UML25-326 Location: 9.6.4 Notation p 128 Is return a reserved parameter name? UML 2.4.1 UML 2.5 Resolved closed
UML25-325 Location: 9.6.4 Notation p 127 Simplify description of syntax UML 2.4.1 UML 2.5 Resolved closed
UML25-321 Location: 9.5.3 p 122 Qualifiers must be enumerated type UML 2.4.1 UML 2.5 Resolved closed
UML25-324 Location: 9.6.3 Operations p 127 UML 2.4.1 UML 2.5 Resolved closed
UML25-328 Location: 9.7.5 Examples p 135 Political Correctness UML 2.4.1 UML 2.5 Resolved closed
UML25-327 Location: 9.7.5 Examples p 134 Generalization Sets UML 2.4.1 UML 2.5 Resolved closed
UML25-331 Location: 9.8.4 Notation p 141 representing the roles vs representing the instances UML 2.4.1 UML 2.5 Resolved closed
UML25-332 Location: 9.9 Classifier Descriptions Association Ends p 144 Behavioral --> Behavior UML 2.4.1 UML 2.5 Resolved closed
UML25-237 Clarification of imports UML 2.4.1 UML 2.5 Resolved closed
UML25-236 Namespace Abstract Syntax incorrect UML 2.4.1 UML 2.5 Resolved closed
UML25-230 Add reference to association notation section UML 2.4.1 UML 2.5 Resolved closed
UML25-229 How does dot notation work UML 2.4.1 UML 2.5 Resolved closed
UML25-227 Extraneous Note UML 2.4.1 UML 2.5 Resolved closed
UML25-226 Sentence does not make sense UML 2.4.1 UML 2.5 Resolved closed
UML25-233 Owning Comments UML 2.4.1 UML 2.5 Resolved closed
UML25-232 Root Abstract Syntax missing adornments/metamodel incorrect UML 2.4.1 UML 2.5 Resolved closed
UML25-234 Owning Rules UML 2.4.1 UML 2.5 Resolved closed
UML25-231 Owning Comments UML 2.4.1 UML 2.5 Resolved closed
UML25-225 Figure 6.1 does not relate to rest of Specification UML 2.4.1 UML 2.5 Resolved closed
UML25-235 Can Comments own comments? UML 2.4.1 UML 2.5 Resolved closed
UML25-228 What type of slash? UML 2.4.1 UML 2.5 Resolved closed
UML25-367 Location: Page 330, 331, 333, 14.2.3, Page 347, 14.2.4, Page 375, 14.5 PseudostateKind UML 2.4.1 UML 2.5 Resolved closed
UML25-366 Location: Page 329 States - Stable UML 2.4.1 UML 2.5 Resolved closed
UML25-362 Location: Page 315 Association ends - Explain about having no nestedClassifier UML 2.4.1 UML 2.5 Resolved closed
UML25-361 Location: Page 313, 13.2.4 Notation relative UML 2.4.1 UML 2.5 Resolved closed
UML25-369 Location: Page 341, 14.2.4 - Example for graphical expression of behavior in states UML 2.4.1 UML 2.5 Resolved closed
UML25-365 Location: Page 328 Regions 14.2.3 - Text about regions without initial state UML 2.4.1 UML 2.5 Resolved closed
UML25-371 Location: Page 346, State List Notations UML 2.4.1 UML 2.5 Resolved closed
UML25-370 Location: Page 341, State - More examples needed UML 2.4.1 UML 2.5 Resolved closed
UML25-368 Location: Page 338, Transition selection algorithm - Maximal Set UML 2.4.1 UML 2.5 Resolved closed
UML25-364 Location: 14.2.1 Summary - Behavior StateMachines for UseCases UML 2.4.1 UML 2.5 Resolved closed
UML25-363 Location: 14.1 Summary p 326 UML 2.4.1 UML 2.5 Resolved closed
UML25-360 Location Behavior Parameters p 307 - Streaming and Multiplicity UML 2.4.1 UML 2.5 Resolved closed
UML25-359 Location Behavior Parameters p 307 - Optional with default value UML 2.4.1 UML 2.5 Resolved closed
UML25-304 Alterative Scopes? UML 2.4.1 UML 2.5 Resolved closed
UML25-303 Multiplicity of 0..0 UML 2.4.1 UML 2.5 Resolved closed
UML25-301 Location p.112 (9.3 Classifier Templates) UML 2.4.1 UML 2.5 Resolved closed
UML25-300 Incompatible with SysML UML 2.4.1 UML 2.5 Resolved closed
UML25-297 the parent of a Classifier is not its owner.” UML 2.4.1 UML 2.5 Resolved closed
UML25-302 Location: p.116 (9.4.3 Semantics) UML 2.4.1 UML 2.5 Resolved closed
UML25-298 What is inherited or not UML 2.4.1 UML 2.5 Resolved closed
UML25-299 Inherited members UML 2.4.1 UML 2.5 Resolved closed
UML25-306 Redefinable Static attributes UML 2.4.1 UML 2.5 Resolved closed
UML25-305 Examples of alternative scopes? UML 2.4.1 UML 2.5 Resolved closed
UML25-296 Objects? UML 2.4.1 UML 2.5 Resolved closed
UML25-378 Location: p. 329 State Configurations UML 2.4.1 UML 2.5 Resolved closed
UML25-377 Location: p. 328 Regions - Resolve intentional ambiguity UML 2.4.1 UML 2.5 Resolved closed
UML25-373 Location: Transition , bottom of page 352 UML 2.4.1 UML 2.5 Resolved closed
UML25-372 Location: Page 347, 14.2.4 UML 2.4.1 UML 2.5 Resolved closed
UML25-376 Location: p 378 State Description - What is hidden? UML 2.4.1 UML 2.5 Resolved closed
UML25-375 Location: p 373 outgoing_from_initial - Limitations on guards UML 2.4.1 UML 2.5 Resolved closed
UML25-374 Page 353, 14.2.4 - StateMachine symbols on graphical representations of Transitions UML 2.4.1 UML 2.5 Resolved closed
UML25-382 Location: p. 333 FinalState UML 2.4.1 UML 2.5 Resolved closed
UML25-381 Location: p. 331 Exiting a State - Clarification of Exiting a State UML 2.4.1 UML 2.5 Resolved closed
UML25-385 Location: p. 337 2nd ¶ UML 2.4.1 UML 2.5 Resolved closed
UML25-384 Location: p. 336 Compound transitions UML 2.4.1 UML 2.5 Resolved closed
UML25-383 Location: p. 333 Transitions - How do multiple triggers work? UML 2.4.1 UML 2.5 Resolved closed
UML25-379 Location: p. 330 Deferred Events - Value of Deferred Events UML 2.4.1 UML 2.5 Resolved closed
UML25-380 Location: p. 331 Explicit Entry - Clarification of Explicit Entry UML 2.4.1 UML 2.5 Resolved closed
UML25-268 Unlimited Natural UML 2.4.1 UML 2.5 Resolved closed
UML25-267 String concrete syntax is missing UML 2.4.1 UML 2.5 Resolved closed
UML25-270 BNF rules allow for a real 0 UML 2.4.1 UML 2.5 Resolved closed
UML25-269 Notation: Real UML 2.4.1 UML 2.5 Resolved closed
UML25-266 LiteralNull semantics UML 2.4.1 UML 2.5 Resolved closed
UML25-265 Default value for LiteralReal UML 2.4.1 UML 2.5 Resolved closed
UML25-279 Always non-negative UML 2.4.1 UML 2.5 Resolved closed
UML25-278 Duration UML 2.4.1 UML 2.5 Resolved closed
UML25-274 set - > list UML 2.4.1 UML 2.5 Resolved closed
UML25-273 Plural headers when class name is singular UML 2.4.1 UML 2.5 Resolved closed
UML25-276 body text strings UML 2.4.1 UML 2.5 Resolved closed
UML25-275 sentence unclear UML 2.4.1 UML 2.5 Resolved closed
UML25-271 Past vs Present UML 2.4.1 UML 2.5 Resolved closed
UML25-277 String expression notation missing UML 2.4.1 UML 2.5 Resolved closed
UML25-272 {ordered} at wrong end UML 2.4.1 UML 2.5 Resolved closed
UMLDI-20 UML diagram interchange: limitation of complex properties UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-19 A schema definition has to be added for the completeness of the specificati UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-5 Introduce a 'Nesting Guide' UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-4 Change role name in DI metamodel UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-14 UML diagram interchange: unit of measurement UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-13 UML diagram interchange: translucent property unnecessary? UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-12 UML diagram interchange: do diagrams have to be nodes? UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-16 UML diagram interchange: containment vs reference UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-15 UML diagram interchange: association as a graph node UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-7 UML diagram interchange: inappropriate diagram properties UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-6 UML diagram interchange: views may need more context UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-11 UML diagram interchange: cut-out diagram feature UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-10 UML diagram interchange: dubious value of leaf elements UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-18 Rename the specification to OMG Diagram Interchange Specification UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-17 UML 2 Diagram Interchange / Assigning icons to stereotypes UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-9 UML diagram interchange: more features in schema? UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-8 UML diagram interchange: limitation of complex properties UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-1 property CoreSemanticModelBridge.element UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-3 Allow a Diagram Element to represent multiple Model Elements UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UMLDI-2 UML Diagram interchange -- change Rational ref to IBM UMLDI 1.0b1 UMLDI 1.0 Resolved closed
UML25-219 Incarnation ? UML 2.4.1 UML 2.5 Resolved closed
UML25-218 Show how UML is a MOF metamodel UML 2.4.1 UML 2.5 Resolved closed
UML25-214 Conformance definitions ? UML 2.4.1 UML 2.5 Resolved closed
UML25-213 Impact of merging profiles isn't small UML 2.4.1 UML 2.5 Resolved closed
UML25-217 Keyword Usage UML 2.4.1 UML 2.5 Resolved closed
UML25-216 ISO version of UML 2? UML 2.4.1 UML 2.5 Resolved closed
UML25-220 Within the System UML 2.4.1 UML 2.5 Resolved closed
UML25-212 Capture Submitters, Supporters, etc UML 2.4.1 UML 2.5 Resolved closed
UML25-221 Modeling Individuals UML 2.4.1 UML 2.5 Resolved closed
UML25-215 DI Conformance implies Model Interchange Conformance UML 2.4.1 UML 2.5 Resolved closed
UML25-191 Clarification on the semantics of Multiplicities UML 2.4.1 UML 2.5 Resolved closed
UML25-190 Clarification on the semantics of UML UML 2.4.1 UML 2.5 Resolved closed
UML25-189 Conformance point UML 2.4.1 UML 2.5 Resolved closed
UML25-193 Clarification on the semantics of Properties UML 2.4.1 UML 2.5 Resolved closed
UML25-192 Clarification on the semantics of Parameters UML 2.4.1 UML 2.5 Resolved closed
UML25-197 Clarification on the semantics of Manifestation UML 2.4.1 UML 2.5 Resolved closed
UML25-196 Clarification on the aim of Collaborations UML 2.4.1 UML 2.5 Resolved closed
UML25-195 Clarification on the semantics of ports in Encapsulated Classifiers UML 2.4.1 UML 2.5 Resolved closed
UML25-194 Clarification on the semantics of Connectors within Structured Classifiers UML 2.4.1 UML 2.5 Resolved closed
UML25-198 Declassifying of Annex D UML 2.4.1 UML 2.5 Resolved closed
UML25-200 Missing word in section 7.4.3, "Semantics" UML 2.5b1 UML 2.5 Resolved closed
UML25-199 Four typos UML 2.5b1 UML 2.5 Resolved closed
UML25-206 ElementImport semantics UML 2.5b1 UML 2.5 Resolved closed
UML25-205 Same name" vs. "indistinguishable name" UML 2.5b1 UML 2.5 Resolved closed
UML25-211 Missing Table of Figures, Table of Tables - Location: TOC p 10 UML 2.4.1 UML 2.5 Resolved closed
UML25-210 Minor vs Major revision UML 2.4.1 UML 2.5 Resolved closed
UML25-204 Further clarify Element ownership constrains UML 2.5b1 UML 2.5 Resolved closed
UML25-203 Semantic conformance implies Abstract Syntax conformance UML 2.5b1 UML 2.5 Resolved closed
UML25-207 isConsistentWith() definition broken UML 2.5b1 UML 2.5 Resolved closed
UML25-202 Suggested improvements to conformance section UML 2.5b1 UML 2.5 Resolved closed
UML25-209 Section 11.5. - Clause 11: Structured Classifiers UML 2.4.1 UML 2.5 Resolved closed
UML25-201 PDF links to Primitive Types don't work UML 2.5b1 UML 2.5 Resolved closed
UML25-208 Superfluous word on p309 UML 2.5b1 UML 2.5 Resolved closed
UML24-111 Problem with ExtensionEnd::lower UML 2.3 UML 2.4 Resolved closed
UML24-108 UML state machines: inconsistent subset of StateMachine::extendedStatemachine UML 2.3 UML 2.4 Resolved closed
UML24-107 isDerived with DefaultValue UML 2.3 UML 2.4 Resolved closed
UML24-104 Change all properties typed by data types to aggregation=none UML 2.3 UML 2.4 Resolved closed
UML24-103 Give all constraints unique names within their context. UML 2.3 UML 2.4 Resolved closed
UML24-110 UML 2.4 - ConditionalNode - Semantics UML 2.3 UML 2.4 Resolved closed
UML24-109 DecisionNode at all guards evaluated to false UML 2.3 UML 2.4 Resolved closed
UML24-101 EnumerationHasOperations : UML::VisibilityKind::bestVisibility UML 2.3 UML 2.4 Resolved closed
UML24-100 Parameter have Effects UML 2.3 UML 2.4 Resolved closed
UML24-106 Property::isID should not be optional UML 2.3 UML 2.4 Resolved closed
UML24-112 stereotype <> for defining parameterized classes is nowhere defined UML 2.3 UML 2.4 Resolved closed
UML24-105 UML 2.4 - Interaction UML 2.3 UML 2.4 Resolved closed
UML24-102 The metamodel contains instances of Model UML 2.3 UML 2.4 Resolved closed
UML24-80 xmi files in the 2.4 RTF deliverables have cmof tags contained in a non-XMI root element UML 2.3 UML 2.4 Resolved closed
UML24-82 Operation::isConsistentWith UML 2.3 UML 2.4 Resolved closed
UML24-81 UML2.4: StandardProfileL2 & L3 are incomplete as delivered UML 2.3 UML 2.4 Resolved closed
UML24-84 bodyCondition and isQuery UML 2.3 UML 2.4 Resolved closed
UML24-83 isConsistentWith UML 2.3 UML 2.4 Resolved closed
UML24-74 "unique" annotation UML 2.3 UML 2.4 Resolved closed
UML24-77 The stereotype «Create» and keyword «create» are both defined in the UML 4 document UML 2.3 UML 2.4 Resolved closed
UML24-76 Figure 9.2 (Abstractions subpackage dependencies) has wrong dependency UML 2.3 UML 2.4 Resolved closed
UML24-79 "isStatic" property of Feature no longer appears in any diagram UML 2.3 UML 2.4 Resolved closed
UML24-78 coveredBy : InteractionFragment [0..1] should be [*] UML 2.3 UML 2.4 Resolved closed
UML24-85 redefinitionContext of Property UML 2.3 UML 2.4 Resolved closed
UML24-73 Ambiguous constraints for transitions UML 2.3 UML 2.4 Resolved closed
UML24-72 Typo: isStric => isStrict UML 2.3 UML 2.4 Resolved closed
UML24-75 Qualified name is incorrectly claimed to be unambiguous UML 2.3 UML 2.4 Resolved closed
UML24-68 UML 2.4: Add package:URI UML 2.3 UML 2.4 Resolved closed
UML24-67 UML 2.4: Add Property::isId UML 2.3 UML 2.4 Resolved closed
UML24-71 UML 2.4: Inconsistent rendering of OCL in UML metamodel UML 2.3 UML 2.4 Resolved closed
UML24-70 Over-general sentence about MOF and Profiles UML 2.3 UML 2.4 Resolved closed
UML24-69 UML 2.3 Superstructure: Non-sensible text for modelLibrary stereotype UML 2.3 UML 2.4 Resolved closed
UML24-58 UML 2.3, Figure 18.1 UML 2.3 UML 2.4 Resolved closed
UML24-57 Term "method activation" deprecated? UML 2.3 UML 2.4 Resolved closed
UML24-66 UML 2.3 Issue: Constraint InformationFlow.sources_and_target_kinds UML 2.3 UML 2.4 Resolved closed
UML24-65 NamedElement::clientDependency constrained to subset DirectedRelationship::source UML 2.3 UML 2.4 Resolved closed
UML24-64 Figure 7.10 shows Feature::isStatic as abstract UML 2.3 UML 2.4 Resolved closed
UML24-59 split the addition of generalization relationships among association in 14977 in two parts UML 2.3 UML 2.4 Resolved closed
UML24-62 It seems odd to say that Service “computes a value”. UML 2.3 UML 2.4 Resolved closed
UML24-61 Create UML 2.3 UML 2.4 Resolved closed
UML24-63 issues relating to Figure 7.14 - The Packages diagram of the Kernel package UML 2.3 UML 2.4 Resolved closed
UML24-60 Auxiliary UML 2.3 UML 2.4 Resolved closed
UML24-130 MultiplicityElement constraint 1 inconsistent with possible [0..0] multiplicity UML 2.3 UML 2.4 Resolved closed
UML24-128 Figure 7.31 propose an “association-like” notation for attributes UML 2.3 UML 2.4 Resolved closed
UML24-127 Statement mistake UML 2.3 UML 2.4 Resolved closed
UML24-129 Section numbering UML 2.3 UML 2.4 Resolved closed
UML24-124 UML 2.4: “Figure 7.31 shows the dot at the wrong end.” UML 2.3 UML 2.4 Resolved closed
UML24-123 UML 2: Multiplicity of Lifeline's coveredBy is incorrectly specified UML 2.3 UML 2.4 Resolved closed
UML24-116 Fix minor inconsistencies between infrastructure specification document & metamodel UML 2.3 UML 2.4 Resolved closed
UML24-115 Missing relation between "Namespaces" package and "Ownerships" package in fig. 9.2 (p. 30)? UML 2.3 UML 2.4 Resolved closed
UML24-120 Deep history for orthogonal states UML 2.3 UML 2.4 Resolved closed
UML24-119 Parameter semantics related to Behavior and BehavioralFeature UML 2.3 UML 2.4 Resolved closed
UML24-118 Property.isReadOnly is redundant with StructuralFeature.isReadOnly UML 2.3 UML 2.4 Resolved closed
UML24-122 Part document structures in Infrastructure need to conform to ISO Standard Document Template Conventions UML 2.3 UML 2.4 Resolved closed
UML24-121 Big UML 2.4 problem: missing defaults in XMI UML 2.3 UML 2.4 Resolved closed
UML24-114 Operation with multiple return parameter UML 2.3 UML 2.4 Resolved closed
UML24-113 Wrong constraint on Operation::bodyCondition UML 2.3 UML 2.4 Resolved closed
UML24-117 Be explicit that type does not need to be set for LiteralBoolean etc. UML 2.3 UML 2.4 Resolved closed
UML24-126 Constraint is Wrong UML 2.3 UML 2.4 Resolved closed
UML24-125 Wrong Classifier Name UML 2.3 UML 2.4 Resolved closed
UML24-49 UML2 - Invalid constraint for Actor UML 2.3 UML 2.4 Resolved closed
UML24-48 Detailed modeling of the Standard Profiles UML 2.3 UML 2.4 Resolved closed
UML24-52 UML 2 issue - misleadingly named associations UML 2.3 UML 2.4 Resolved closed
UML24-51 Meaning of BodyCondition and its alignment with OCL UML 2.3 UML 2.4 Resolved closed
UML24-53 Resolution to issue 14063 UML 2.3 UML 2.4 Resolved closed
UML24-55 Issue 14287 and 13330 resolutions are inconsistent and incorrectly applied. UML 2.3 UML 2.4 Resolved closed
UML24-54 UML 2 Subclasses of Classifier should subset redefinedClassifier when they redefine UML 2.3 UML 2.4 Resolved closed
UML24-47 MessageEvents UML 2.3 UML 2.4 Resolved closed
UML24-46 Association owned derived union UML 2.3 UML 2.4 Resolved closed
UML24-50 composite tags UML 2.3 UML 2.4 Resolved closed
UML24-56 UML2 Issue: OCL in resolution 11114 is incorrect UML 2.3 UML 2.4 Resolved closed
UML24-45 UML2.3 definition of Classifier::hasVisibilityOf is circular UML 2.3 UML 2.4 Resolved closed
UML24-44 UML2.3: Missing subsetting from A_redefinedClassifier_classifier in XMI UML 2.3 UML 2.4 Resolved closed
UML24-29 loopVariable ownership UML 2.3 UML 2.4 Resolved closed
UML24-95 Association conflicts with MemberEnds IsDerived flags UML 2.3 UML 2.4 Resolved closed
UML24-94 Fix association end multiplicities UML 2.3 UML 2.4 Resolved closed
UML24-98 Multiplicity Element Is MultiValued With Default Value UML 2.3 UML 2.4 Resolved closed
UML24-97 Derived properties that are not marked read-only UML 2.3 UML 2.4 Resolved closed
UML24-89 Message's signature is still derived property (in text only): UML 2.3 UML 2.4 Resolved closed
UML24-88 UML 2 issue: UML 2.4 normative deliverables should be published in MOF2.4 / XMI 2.4 format UML 2.3 UML 2.4 Resolved closed
UML24-96 Redefinition of association-owned ends requires association generalization UML 2.3 UML 2.4 Resolved closed
UML24-93 Fix 14977 vs. 14638 UML 2.3 UML 2.4 Resolved closed
UML24-92 Association-owned association end name changes UML 2.3 UML 2.4 Resolved closed
UML24-87 The resolution to issue 13993 that moved PrimitiveTypes to an independent package contained a mistake UML 2.3 UML 2.4 Resolved closed
UML24-86 Missing subsetting of redefinitionContext by Property::owningAssociation UML 2.3 UML 2.4 Resolved closed
UML24-99 InstanceValue has no type UML 2.3 UML 2.4 Resolved closed
UML24-90 DestructionOccurenceSpecification is inherited from OccurenceSpecification instead of MessageOccurenceSpecification UML 2.3 UML 2.4 Resolved closed
UML24-91 DestructionOccurenceSpecification text in Semantics still refers to events UML 2.3 UML 2.4 Resolved closed
UML24-38 serialization of a profile should always include the nsURI and nsPrefix tags UML 2.3 UML 2.4 Resolved closed
UML24-37 Incomplete resolution to 10826 UML 2.3 UML 2.4 Resolved closed
UML24-31 Definition of Behavior::context is not correct UML 2.3 UML 2.4 Resolved closed
UML24-30 Context of a behavior owned as a nested classifier UML 2.3 UML 2.4 Resolved closed
UML24-32 Matching subsettting across association ends UML 2.3 UML 2.4 Resolved closed
UML24-43 Activity vs Action completion UML 2.3 UML 2.4 Resolved closed
UML24-42 Enumeration Literal UML 2.3 UML 2.4 Resolved closed
UML24-40 Lack of graphical example of multi-element Dependency Notation UML 2.3 UML 2.4 Resolved closed
UML24-39 Poor example of Dependency notation UML 2.3 UML 2.4 Resolved closed
UML24-41 Figure 7.15 UML 2.3 UML 2.4 Resolved closed
UML24-35 The containment between Activity and StructuredActivityNode has one end redefining and the other subsetting UML 2.3 UML 2.4 Resolved closed
UML24-34 UML 2: property redefinitions should be symmetric across associations UML 2.3 UML 2.4 Resolved closed
UML24-33 Expansion nodes using all the tokens in them as a single collection FUML 1.0b2 UML 2.4 Resolved closed
UML24-36 Subsetting clauses should show the subsetted property fully qualified. UML 2.3 UML 2.4 Resolved closed
UML23-145 Semantics of the AddVariableValueAction UML 2.2 UML 2.3b1 Resolved closed
UML24-15 Errros with some "subsets" and redefines" where the contexts of subsetting/redefintion do not conform UML 2.3 UML 2.4 Resolved closed
UML24-14 Attributes without a type UML 2.3 UML 2.4 Resolved closed
UML24-10 UML 2 Events referred to by OccurrenceSpecifications should be optional UML 2.3 UML 2.4 Resolved closed
UML24-13 Associations with same name that live in different packages violate unique name constraint UML 2.3 UML 2.4 Resolved closed
UML24-12 All enumertion literals in the model have their "classifier" collections empty UML 2.3 UML 2.4 Resolved closed
UML24-4 Constraint [3] on TestIdentityAction is incorrect UML 2.3 UML 2.4 Resolved closed
UML24-3 Constraint [1] for WriteStructuralFeatureAction is incorrect UML 2.3 UML 2.4 Resolved closed
UML24-7 UML2 - derivation for DeploymentTarget.deployedElement is invalid UML 2.3 UML 2.4 Resolved closed
UML24-6 UML2 - non-unique association names in L3.merged.cmof UML 2.3 UML 2.4 Resolved closed
UML24-11 Some owned operations with OCL expression bodies but without their "isQuery" set to "true" UML 2.3 UML 2.4 Resolved closed
UML24-8 UML2 - definition of Property.opposite is wrong UML 2.3 UML 2.4 Resolved closed
UML24-5 Parameter type of MultiplicityElement::includesMultiplicity() UML 2.3 UML 2.4 Resolved closed
UML24-9 UML2: Incomplete definition for Activity.structuredNode UML 2.3 UML 2.4 Resolved closed
UML23-143 What is "top-tier packages of the UML metamodel"? UML 2.2 UML 2.3 Resolved closed
UML23-125 Names of ownedEnds that were there in UML 2.1.1 are missing in UML 2.2 UML 2.2 UML 2.3 Resolved closed
UML23-127 notation of objet flow <> and <> UML 2.2 UML 2.3 Resolved closed
UML23-126 UML 2.3 draft, 11.3.1 - AcceptCallAction UML 2.2 UML 2.3 Resolved closed
UML23-124 Duplicate association in normative UML 2.3 superstructure file UML 2.2 UML 2.3 Resolved closed
UML23-123 Japan Infrastructure PAS Ballot Comments - comment 9 UML 2.2 UML 2.3 Resolved closed
UML23-122 Japan Infrastructure PAS Ballot Comments - comment 8 UML 2.2 UML 2.3 Resolved closed
UML23-118 Japan Infrastructure PAS Ballot Comments - comment 4 UML 2.2 UML 2.3 Resolved closed
UML23-117 Japan Infrastructure PAS Ballot Comments - comment 3 UML 2.2 UML 2.3 Resolved closed
UML23-114 Japan Superstructure PAS Ballot Comments - comment 20 UML 2.2 UML 2.3 Resolved closed
UML23-113 Japan Superstructure PAS Ballot Comments - comment 19 UML 2.2 UML 2.3 Resolved closed
UML23-121 Japan Infrastructure PAS Ballot Comments - comment 7 UML 2.2 UML 2.3 Resolved closed
UML23-120 Japan Infrastructure PAS Ballot Comments - comment 6 UML 2.2 UML 2.3 Resolved closed
UML23-116 Japan Infrastructure PAS Ballot Comments - comment 2 UML 2.2 UML 2.3 Resolved closed
UML23-119 Japan Infrastructure PAS Ballot Comments - comment 5 UML 2.2 UML 2.3 Resolved closed
UML23-115 Japan Infrastructure PAS Ballot Comments - comment 1 UML 2.2 UML 2.3 Resolved closed
UML241-12 UML type Real specification UML 2.4 UML 2.4.1 Resolved closed
UML241-11 Interface element - associations multiplicity not defined UML 2.4 UML 2.4.1 Resolved closed
UML241-9 Property::isID UML 2.4 UML 2.4.1 Resolved closed
UML241-6 Wrong package name on several Figures UML 2.4 UML 2.4.1 Resolved closed
UML241-10 Missing Namespace in Dependencies package definition? UML 2.4 UML 2.4.1 Resolved closed
UML241-3 typo on page 46 UML 2.4 UML 2.4.1 Resolved closed
UML24-1 typo in new attribute name UML 2.3 UML 2.4 Resolved closed
UML23-144 Section: Classes RAS 2.2 UML 2.3 Resolved closed
UML24-2 CMOF missing several redefined property relationships UML 2.3 UML 2.4 Resolved closed
UML23-95 Setting Classes-Interfaces-Interface-ownedAttribute would fail to populate Classes-Kernel-Property-owner UML 2.2 UML 2.3 Resolved closed
UML23-94 Incorrect OCL in Infrastructure.xmi for 'Core-Constructs-Operation-isConsistentWith' UML 2.2 UML 2.3 Resolved closed
UML23-99 Japan Superstructure PAS Ballot Comments - comment 4 UML 2.2 UML 2.3 Resolved closed
UML23-98 Japan Superstructure PAS Ballot Comments - comment 3 UML 2.2 UML 2.3 Resolved closed
UML23-93 Language unit of Usage UML 2.2 UML 2.3 Resolved closed
UML23-92 Documentation of merge increments in the superstructure UML 2.2 UML 2.3 Resolved closed
UML23-97 Japan Superstructure PAS Ballot Comments - comment 2 UML 2.2 UML 2.3 Resolved closed
UML23-96 Japan Superstructure PAS Ballot Comments - comment 1 UML 2.2 UML 2.3 Resolved closed
UML24-23 is composite, but does not subset ownedElement UML 2.3 UML 2.4 Resolved closed
UML24-22 wrong Actor's constraint [1]" UML 2.3 UML 2.4 Resolved closed
UML24-20 AcceptEventAction notation UML 2.3 UML 2.4 Resolved closed
UML24-19 Some associations in the normative XMI has one memberEnd UML 2.3 UML 2.4 Resolved closed
UML24-18 Namespace collission due to package import UML 2.3 UML 2.4 Resolved closed
UML24-17 Cycles in package imports UML 2.3 UML 2.4 Resolved closed
UML24-16 Errors with types of association ends not conforming to their subsetted ends UML 2.3 UML 2.4 Resolved closed
UML24-28 Unclear constraint on stereotype associations UML 2.3 UML 2.4 Resolved closed
UML24-26 remove BehavioredClassifier::ownedTrigger UML 2.3 UML 2.4 Resolved closed
UML24-25 lowered multiplicity UML 2.3 UML 2.4 Resolved closed
UML24-21 Issue on generalization UML 2.3 UML 2.4 Resolved closed
UML24-24 is composite and subsets not derived composite property: UML 2.3 UML 2.4 Resolved closed
UML24-27 UML is vague about which Element should own Comments UML 2.3 UML 2.4 Resolved closed
UML23-129 UML 2.3: Errors in example serialization for Profiles in Chapter 18 UML 2.2 UML 2.3 Resolved closed
UML23-128 errors in OCL statements of Additional Operations? UML 2.2 UML 2.3 Resolved closed
UML23-132 Value of a Property UML 2.2 UML 2.3 Resolved closed
UML23-131 Interface-redefinedInterface should subset Classifier-redefinedClassifier UML 2.2 UML 2.3 Resolved closed
UML23-142 'false' is not a member of VisibilityKind UML 2.2 UML 2.3 Resolved closed
UML23-141 Guard of activity edge should be optional UML 2.2 UML 2.3 Resolved closed
UML23-140 Bug in Core::Abstractions::Super::Classifier::hasVisibilityOf UML 2.2 UML 2.3 Resolved closed
UML23-130 Ordered derived unions UML 2.2 UML 2.3 Resolved closed
UML23-135 Package Extension UML 2.2 UML 2.3 Resolved closed
UML23-134 Wrong Spelling for "development" UML 2.2 UML 2.3 Resolved closed
UML23-133 Cyclick dependency UML 2.2 UML 2.3 Resolved closed
UML23-138 Invalid type for NamedElement.namespace UML 2.2 UML 2.3 Resolved closed
UML23-137 Invalid type for Slot.value UML 2.2 UML 2.3 Resolved closed
UML23-139 Minor bug in Namespace::importMembers() query UML 2.2 UML 2.3 Resolved closed
UML23-136 Contents of Dependencies package UML 2.2 UML 2.3 Resolved closed
UML23-101 Japan Superstructure PAS Ballot Comments - comment 6 UML 2.2 UML 2.3 Resolved closed
UML23-100 Japan Superstructure PAS Ballot Comments - comment 5 UML 2.2 UML 2.3 Resolved closed
UML23-109 Japan Superstructure PAS Ballot Comments - comment 15 UML 2.2 UML 2.3 Resolved closed
UML23-105 Japan Superstructure PAS Ballot Comments - comment 11 UML 2.2 UML 2.3 Resolved closed
UML23-104 Japan Superstructure PAS Ballot Comments - comment 10 UML 2.2 UML 2.3 Resolved closed
UML23-111 Japan Superstructure PAS Ballot Comments - comment 17 UML 2.2 UML 2.3 Resolved closed
UML23-110 Japan Superstructure PAS Ballot Comments - comment 16 UML 2.2 UML 2.3 Resolved closed
UML23-102 Japan Superstructure PAS Ballot Comments - comment 7 UML 2.2 UML 2.3 Resolved closed
UML23-107 Japan Superstructure PAS Ballot Comments - comment 13 UML 2.2 UML 2.3 Resolved closed
UML23-106 Japan Superstructure PAS Ballot Comments - comment 12 UML 2.2 UML 2.3 Resolved closed
UML23-103 Japan Superstructure PAS Ballot Comments - comment 8 UML 2.2 UML 2.3 Resolved closed
UML23-108 Japan Superstructure PAS Ballot Comments - comment 14 UML 2.2 UML 2.3 Resolved closed
UML23-112 Japan Superstructure PAS Ballot Comments - comment 18 UML 2.2 UML 2.3 Resolved closed
UML241-22 Irritating occurrence of subsystem stereotype in use case example diagrams UML 2.4 UML 2.4.1 Resolved closed
UML241-21 UML 2.4: NamedElement.ownedRule could be ordered UML 2.4 UML 2.4.1 Resolved closed
UML241-19 property.opposite UML 2.4 UML 2.4.1 Resolved closed
UML241-18 ProfileApplication::appliedProfile as "importedProfile" instead of "appliedProfile" UML 2.4 UML 2.4.1 Resolved closed
UML241-25 ChangeEvent::changeExpression should be of type ValueSpecification UML 2.4 UML 2.4.1 Resolved closed
UML241-24 Validity duration of implicitly assigned parameters in SignalEvent/CallEvent UML 2.4 UML 2.4.1 Resolved closed
UML241-17 XMI in small caps UML 2.4 UML 2.4.1 Resolved closed
UML241-16 Core Package versus Construct Package UML 2.4 UML 2.4.1 Resolved closed
UML241-20 UML Appendix A : Figure A.3 Two Diagrams of Packages” UML 2.4 UML 2.4.1 Resolved closed
UML241-15 XML Metadata Interchange (XMI) - p9 UML 2.4 UML 2.4.1 Resolved closed
UML241-14 XML Metadata Interchange (XMI) UML 2.4 UML 2.4.1 Resolved closed
UML241-23 Implicit parameter assignment may cause name clashes UML 2.4 UML 2.4.1 Resolved closed
UML241-13 Number of Compliance Levels UML 2.4 UML 2.4.1 Resolved closed
UML241-2 Presentation options of statemachine transitions: Figure 15.45 is ambiguous or wrong UML 2.4 UML 2.4.1 Resolved closed
UML241-1 Can a Generalization really be in multiple GeneralizationSets? UML 2.4 UML 2.4.1 Resolved closed
UML241-5 No Rules for Element Names UML 2.4 UML 2.4.1 Resolved closed
UML241-4 Figure 15.32 UML 2.4 UML 2.4.1 Resolved closed
UML241-8 Figure 15.32 UML 2.4 UML 2.4.1 Resolved closed
UML241-7 Typo: "joint" should say "join" UML 2.4 UML 2.4.1 Resolved closed
UML22-1141 Section: Activities: Modifications to the approved resolution of 10815 SysML 1.0 UML 2.1.2 Resolved closed
UML22-1122 Diagram metaclass shall be introduced and shall be subclass of Element UML 2.1 UML 2.1.2 Resolved closed
UML22-1121 Setting structural features of a data type UML 2.1 UML 2.1.2 Resolved closed
UML22-1124 Figure 7.14: "Type" does not show its inheritance from "PackageableElement" UML 2.1 UML 2.1.2 Resolved closed
UML22-1123 ConnectorEnd shall have references to provided or required interfaces UML 2.1 UML 2.1.2 Resolved closed
UML22-1134 constraining Classifiers UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1133 defaultClassifier of ClassifierTemplateParameter SysML 1.0 UML 2.1.2 Resolved closed
UML22-1129 Section: 9.3.11 p 182 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1128 Wrong notation description SysML 1.0 UML 2.1.2 Resolved closed
UML22-1127 Section: 9.3.8 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1126 page 449 chapter 13.3.24 (Signal (from Communications) SysML 1.0 UML 2.1.2 Resolved closed
UML22-1125 UML 2 superstructure -- figure 9.4 is duplicate of figure 9.3 SysML 1.0 UML 2.1.2 Resolved closed
UML22-1136 Change multiplicity of ClassifierTemplateParameter role UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1135 Any ownedBehavior should be able to have AcceptEventAction UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1132 composite values SysML 1.0 UML 2.1.2 Resolved closed
UML22-1131 Section: 9 composite structures SysML 1.0 UML 2.1.2 Resolved closed
UML22-1130 "representation" SysML 1.0 UML 2.1.2 Resolved closed
UML22-1138 TimeEvent UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1137 Figure 14.5 - Messages. UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1140 Section: 7.3.7 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1139 Figures 9.4 identical to figure 9.3 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1120 Flowing data into decision input behaviors UML 2.1 UML 2.1.2 Resolved closed
UML22-1119 Section: Composite Structures UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1107 issue regarding required and provided interfaces UML 2.1 UML 2.1.2 Resolved closed
UML22-1106 UML 2: Semantics of isOrdered need to be clarified UML 2.1 UML 2.1.2 Resolved closed
UML22-1118 Ptc/06-04-02/Pg 188 UML 2.1 UML 2.1.2 Resolved closed
UML22-1117 Section: 7.3.32 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1116 A notation for Trigger UML 2.1 UML 2.1.2 Resolved closed
UML22-1102 Section: Activities - Action semantic clarification UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1101 Section: Activities -StartClassifeirBehaviorAction and classifier behaviors UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1100 Section: Activities - isSingleExecution default UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1105 Profile Structure Diagrams are missing from Annex A SysML 1.0b1 UML 2.1.2 Resolved closed
UML22-1104 Missing inheritance in 9.3.12 SysML 1.0b1 UML 2.1.2 Resolved closed
UML22-1103 No default value specified for Generalization::isSubstitutable SysML 1.0b1 UML 2.1.2 Resolved closed
UML22-1115 consistent descriptions of semantics of event consumption needed UML 2.1 UML 2.1.2 Resolved closed
UML22-1114 section 13.3.2 – doc ptc/2006-04-02, v.2.1 UML 2.1 UML 2.1.2 Resolved closed
UML22-1113 Uses notation "Subsets Element::ownedElement" and similar UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1112 UML2: Behavior without a specification should not be a classifier behavior UML 2.1 UML 2.1.2 Resolved closed
UML22-1109 Figure 13.8 shows the wrong diagram UML 2.1 UML 2.1.2 Resolved closed
UML22-1108 Section: 13.3.25 UML 2.1 UML 2.1.2 Resolved closed
UML22-1111 Section: 13 SimpleTime UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1110 Section: 13.2 UML 2.1 UML 2.1.2 Resolved closed
UML22-1084 UML2: No notation for BehavioredClassifier::ownedTrigger UML 2.0 UML 2.1.2 Resolved closed
UML22-1083 UML 2/Templates -- single argument? UML 2.0 UML 2.1.2 Resolved closed
UML22-1082 Use the new 'dot' notation in examples UML 2.0 UML 2.1.2 Resolved closed
UML22-1099 Section: Activities - Join node edge constraint UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1098 Section: Activities - Offer ordering on joins UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1097 Section: Activities - Multiple activity parameters nodes for a single inout UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1088 A notation for Trigger SysML 1.0b1 UML 2.1.2 Resolved closed
UML22-1087 Section: 9.3.13 - connectors UML 2.1 UML 2.1.2 Resolved closed
UML22-1096 Section: Activities - Semantics of fork node wording UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1095 ReadLinkAction UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1094 Section: Activities - Weight notation UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1093 Section: Activities - Weight description UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1092 Section: Activities UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1091 Section: 9.3.11 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1090 Section: 9.3.11 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1089 Section: 9.2 UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1086 Section: 13.3.24 Signal (from Communications) UML 2.1.1 UML 2.1.2 Resolved closed
UML22-1085 page 467, Section 13.3.24 UML 2.0 UML 2.1.2 Resolved closed
UML23-53 Figure 18.15 does not reflect the example before UML 2.2 UML 2.3 Resolved closed
UML23-52 The XMI document contains elements which should be UML 2.2 UML 2.3 Resolved closed
UML23-47 chapter 2.2, p.3 Last paragaph, second sentence UML 2.2 UML 2.3 Resolved closed
UML23-46 "Associations" part of the "9.10.3 Slot" chapter/section UML 2.2 UML 2.3 Resolved closed
UML23-44 In paragraph 4, the text should read "Class has a derived association ...". Currently, the sentence is missing "a". UML 2.2 UML 2.3 Resolved closed
UML23-43 In paragraph 2, the package reference to InfrastructureLibrary::Constructs::Class omits intermediate package "Core" UML 2.2 UML 2.3 Resolved closed
UML23-50 18.3.6 Typo in Profile section UML 2.2 UML 2.3 Resolved closed
UML23-49 Section: Fig. 7.15: subsets at wrong side UML 2.2 UML 2.3 Resolved closed
UML23-41 Figure 13.2 shows class InfrastructureLibrary::Profiles::Element. Section 13 doesn't define a class named Element. UML 2.2 UML 2.3 Resolved closed
UML23-42 Figure 13.2 shows an association between ProfileApplication and Profile that has role "appliedProfile UML 2.2 UML 2.3 Resolved closed
UML23-48 Section: Chapter 2.2 Compliance levels UML 2.2 UML 2.3 Resolved closed
UML23-45 In the Attributes section, "integer" should be capitalized UML 2.2 UML 2.3 Resolved closed
UML23-51 Section: 18.3.2 UML 2.2 UML 2.3 Resolved closed
UML23-23 UML 2.2 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents UML 2.2 UML 2.3 Resolved closed
UML23-17 UML 2: conflicting specifications for how to calculate context for a Behavior UML 2.2 UML 2.3 Resolved closed
UML23-16 use of "internal" transition is used incorrectly in many places where "local" should be used. UML 2.2 UML 2.3 Resolved closed
UML23-18 default multiplicty of association ends are defined more than one UML 2.2 UML 2.3 Resolved closed
UML23-25 Section: 7.4 Diagrams text on page 144 UML 2.2 UML 2.3 Resolved closed
UML23-24 UML 2.2 Beta1 Figure 12.18 is misleading about Parameter::effect : ParameterEffectKind [0..1] UML 2.2 UML 2.3 Resolved closed
UML23-28 Figure 12.95 - "Fork node example" UML 2.2 UML 2.3 Resolved closed
UML23-27 UML2 : Lifeline identity for InteractionUse UML 2.2 UML 2.3 Resolved closed
UML23-22 In the XMI, Ownerships::Element erroneously includes an association for ownedComment. UML 2.2 UML 2.3 Resolved closed
UML23-21 In the XMI, Ownerships::Element fails to include a superClass attribute for Elements::Element UML 2.2 UML 2.3 Resolved closed
UML23-20 Section: 9.8.3 XMI fails to include a "lower" attribute UML 2.2 UML 2.3 Resolved closed
UML23-19 The UML XMI fails to include an ownedRule for the Constraint specified for an OpaqueExpression UML 2.2 UML 2.3 Resolved closed
UML23-26 "Table 7.3 - Graphic paths included in structure diagrams" on pp.143-144 UML 2.2 UML 2.3 Resolved closed
UML23-15 Statemachine diagram in section 15.3.12 diagram 15.42 (and the text above) UML 2.2 UML 2.3 Resolved closed
UML23-88 Propagate RTF 2.3 changes to Infrastructure UML 2.2 UML 2.3 Resolved closed
UML23-87 Need to copy down merged content to make constraints parse in receiving package UML 2.2 UML 2.3 Resolved closed
UML23-86 Remove InputPint from StructuredActivities UML 2.2 UML 2.3 Resolved closed
UML23-85 BNF of Constructs::Property UML 2.2 UML 2.3 Resolved closed
UML23-84 Ambiguity in the names of the stereotypes in the standard profiles UML 2.2 UML 2.3 Resolved closed
UML23-91 The primitive types in the UML 2.3 infrastructure.xmi are private; they should be public UML 2.2 UML 2.3 Resolved closed
UML23-90 Difference between OCL and text in constraint [2] of 15.3.15 UML 2.2 UML 2.3 Resolved closed
UML23-89 Remove redundantant constraint [2] in 7.3.4 UML 2.2 UML 2.3 Resolved closed
UML23-73 UML 2.2 Issue - availability of PrimitiveTypes for UML models UML 2.2 UML 2.3 Resolved closed
UML23-72 lowerBound/upperBound constraints and derivations wrong UML 2.2 UML 2.3 Resolved closed
UML23-81 UML2: Missing semantics in definition of RedefinableTemplateSignature with multiple parents UML 2.2 UML 2.3 Resolved closed
UML23-80 remove StructuredActivities::ActivityGroup UML 2.2 UML 2.3 Resolved closed
UML23-83 Profile::allOwningPackages UML 2.2 UML 2.3 Resolved closed
UML23-82 Properties need not be owned UML 2.2 UML 2.3 Resolved closed
UML23-71 Operation-interface should subset Feature-featuringClassifier and NamedElement-namespace UML 2.2 UML 2.3 Resolved closed
UML23-70 UML2.2 chapter 16 : Actor constraint [1] has invalid OCL UML 2.2 UML 2.3 Resolved closed
UML23-76 UML2: error in definition of Class::nestedClassifier UML 2.2 UML 2.3 Resolved closed
UML23-75 confusion re diagram on p. 83 UML 2.2 UML 2.3 Resolved closed
UML23-79 Currently is it possible for a Classifier to specialize the same classifier directly more than once UML 2.2 UML 2.3 Resolved closed
UML23-77 nestedClassifier UML 2.2 UML 2.3 Resolved closed
UML23-74 Section 9.9 should classifier be added to the diagram on p 50? UML 2.2 UML 2.3 Resolved closed
UML23-78 type mismatch UML 2.2 UML 2.3 Resolved closed
UML23-32 Section 12.3.48 on page 412 UML 2.2 UML 2.3 Resolved closed
UML23-34 Figure 7.1 shows no dependency UML 2.2 UML 2.3 Resolved closed
UML23-33 Section 2.3 para 1 needs to be re-written UML 2.2 UML 2.3 Resolved closed
UML23-40 Section 13 "Core::Profiles" inconsistency UML 2.2 UML 2.3 Resolved closed
UML23-39 Should the definition of Element state that it reuses the definition of Element from Abstractions::Elements? UML 2.2 UML 2.3 Resolved closed
UML23-37 The "Generalizations" heading is missing before the "ValueSpecification" bullet. UML 2.2 UML 2.3 Resolved closed
UML23-36 Paragraph 5: The text states that class Comment has no generalizations UML 2.2 UML 2.3 Resolved closed
UML23-31 UML 2 7.3.3 : incorrect text about aggregationKind in associations UML 2.2 UML 2.3 Resolved closed
UML23-29 Table 12.1 - "Graphic nodes included in activity diagrams", UML 2.2 UML 2.3 Resolved closed
UML23-30 Generalizations" for StructuredActivityNode on p. 417 UML 2.2 UML 2.3 Resolved closed
UML23-38 Two issues regarding Figure 10.2: 1 UML 2.2 UML 2.3 Resolved closed
UML23-35 Parameter is part of the BehavioralFeatures package. UML 2.2 UML 2.3 Resolved closed
UML23-65 Validator issues with TestCase 2 UML 2.2 UML 2.3 Resolved closed
UML23-64 current definition of a 'local' transition does not allow the case to have a local transition UML 2.2 UML 2.3 Resolved closed
UML23-59 Figures 9.17 and 9.19 and related text UML 2.2 UML 2.3 Resolved closed
UML23-58 what's the difference > between weight=1 and weight=*? UML 2.2 UML 2.3 Resolved closed
UML23-63 Clarify that input pins do not accept more tokens than their actions can immediately consume UML 2.2 UML 2.3 Resolved closed
UML23-62 The OCL for /required interfaces of Component is using ports.provided instead of ports.required UML 2.2 UML 2.3 Resolved closed
UML23-67 Clarification need on circle plus notation for containment UML 2.2 UML 2.3 Resolved closed
UML23-66 Color errors on figures in UML 2.2 UML 2.2 UML 2.3 Resolved closed
UML23-69 Figure 7.38 needs to be revised UML 2.2 UML 2.3 Resolved closed
UML23-68 Activity groups should be named UML 2.2 UML 2.3 Resolved closed
UML23-57 Table 2.2 Example feature support statement references Note (4) and Note (5) UML 2.2 UML 2.3 Resolved closed
UML23-56 Description of Level 1 diagram does not make sense with respect to figure 2.2 UML 2.2 UML 2.3 Resolved closed
UML23-61 Clarify how the provided and required interfaces of a Port are calculated UML 2.2 UML 2.3 Resolved closed
UML23-60 Missing keyword? UML 2.2 UML 2.3 Resolved closed
UML23-54 Replace "extensionClock" with "extension_Clock" and "baseClass" with "base_Class" UML 2.2 UML 2.3 Resolved closed
UML23-55 URIs do not refer to existing resources (404 errors) Annex H UML 2.2 UML 2.3 Resolved closed
UML23-14 Section: 14.3.13 Interaction (from BasicInteraction, Fragments) UML 2.2 UML 2.3 Resolved closed
UML23-13 Notation for ExecutionSpecification UML 2.2 UML 2.3 Resolved closed
UML23-6 Section: 7.3.39 PackageImport (from Kernel) UML 2.2 UML 2.3 Resolved closed
UML23-5 Section: 7.3.12 Dependency (from Dependencies) UML 2.2 UML 2.3 Resolved closed
UML23-11 Val(MyCar.Interaction [SVWB UML 2.2 UML 2.3 Resolved closed
UML23-10 Section: 12.3.14 Figure 12.29 on page 320 UML 2.2 UML 2.3 Resolved closed
UML23-8 Section: 14.3.24 MessageSort (from BasicInteractions) UML 2.2 UML 2.3 Resolved closed
UML23-7 Section: 14.3.3 CombinedFragment (from Fragments) UML 2.2 UML 2.3 Resolved closed
UML23-9 "description" section of the Behavior metaclass UML 2.2 UML 2.3 Resolved closed
UML23-2 Parameter isn't package (Heading 2 level) UML 2.2 UML 2.3 Resolved closed
UML23-1 Super package should import NamedElement from the Visibilities package, not Namespaces UML 2.2 UML 2.3 Resolved closed
UML23-12 description of Interaction provided by the Semantic section inconsistent UML 2.2 UML 2.3 Resolved closed
UML23-4 Section: 14.3.20 Actors in Interactions UML 2.2 UML 2.3 Resolved closed
UML23-3 Figure 9.20 UML 2.2 UML 2.3 Resolved closed
UML22-1081 UML 2 Superstructure / CommonBehaviors / Incorrect types in text UML 2.0 UML 2.1.2 Resolved closed
UML22-1080 7.3.41 Parameter (from Kernel, AssociationClasses)" UML 2.0 UML 2.1.2 Resolved closed
UML22-1063 UML 2.0 issue: ownedMember xsi:type="uml:Stereotype" should be used UML 2.0 UML 2.1 Resolved closed
UML22-1062 UML 2.0: CMOF/UML mixup for profiles UML 2.0 UML 2.1 Resolved closed
UML22-1069 Required attributes UML 2.0 UML 2.1 Resolved closed
UML22-1068 Parameter::effect UML 2.0 UML 2.1 Resolved closed
UML22-1065 UML 2.1 XMI Issue UML 2.0 UML 2.1 Resolved closed
UML22-1064 UML 2.0: Inconsistencies in profile example XMI UML 2.0 UML 2.1 Resolved closed
UML22-1073 parameter of operation isRedefinitionContextValid() is inconistently named UML 2.0 UML 2.1 Resolved closed
UML22-1072 Compliance package L2 does not merge StructuredActions in the metamodel UML 2.0 UML 2.1 Resolved closed
UML22-1071 The following properties should not subset DirectedRelationship::target UML 2.0 UML 2.1 Resolved closed
UML22-1070 The following properties should not subset DirectedRelationship::source UML 2.0 UML 2.1 Resolved closed
UML22-1067 Artifact::fileName UML 2.0 UML 2.1 Resolved closed
UML22-1066 uml::Extension::ownedEnd should not subset uml::Association::ownedEnd UML 2.0 UML 2.1 Resolved closed
UML22-1079 Figure 12.18: Small typo: "subsets ownedMember" not "ownedmember" UML 2.0 UML 2.1.2 Resolved closed
UML22-1078 Page: 161 UML 2.0 UML 2.1.2 Resolved closed
UML22-1075 Issue regarding "Action::effect : String" UML 1.3 UML 2.1 Resolved closed
UML22-1074 Transition guards cannot currently be evaluated because they have no contex UML 2.0 UML 2.1 Resolved closed
UML22-1077 StateMachine::extendedStateMachine should have a multiplicity of 0..*. UML 2.0 UML 2.1 Resolved closed
UML22-1076 Behavior::context UML 2.0 UML 2.1 Resolved closed
UML22-1058 UML 2.0 issue: Package Primitive Types not merged UML 2.0 UML 2.1 Resolved closed
UML22-1057 Section: Appendix A: Diagrams UML 2.0 UML 2.1.2 Resolved closed
UML22-1056 Section 7.2.1 of ptc/04-10-14 UML 2.0 UML 2.1.2 Resolved closed
UML22-1055 Section: 7.3.36 Operation UML 2.0 UML 2.1.2 Resolved closed
UML22-1054 Section 8 Issue - Component Realization-Classifier multiplicity UML 2.0 UML 2.1.2 Resolved closed
UML22-1053 Section: Actions, Figure 156 UML 2.0 UML 2.1 Resolved closed
UML22-1052 UML 2.1 Regressions UML 2.0 UML 2.1 Resolved closed
UML22-1051 Realization classifier UML 2.0 UML 2.1 Resolved closed
UML22-1050 UML 2 issue: redefining isComposite on association ends UML 2.0 UML 2.1 Resolved closed
UML22-1049 Classifier::parameter, Operation::parameter, and ConnectableElement::parame UML 2.0 UML 2.1 Resolved closed
UML22-1048 Component::realization should NOT be derived UML 2.0 UML 2.1 Resolved closed
UML22-1047 Rename ActivityGroup::activity to containingActivity UML 2.0 UML 2.1 Resolved closed
UML22-1046 Rename OpaqueAction::output to outputPin. UML 2.0 UML 2.1 Resolved closed
UML22-1045 Make ActivityGroup::containedNode a derived union UML 2.0 UML 2.1 Resolved closed
UML22-1044 Make ActivityGroup::containedEdge a derived union UML 2.0 UML 2.1 Resolved closed
UML22-1039 compliance levels L2 and L3 UML 2.0 UML 2.1 Resolved closed
UML22-1038 Change type of WriteStructuralFeatureAction::value to ValueSpecification UML 2.0 UML 2.1 Resolved closed
UML22-1037 Change type of WriteStructuralFeatureAction::value UML 2.0 UML 2.1 Resolved closed
UML22-1061 UML 2.0: separate profile application from profile importing UML 2.0 UML 2.1 Resolved closed
UML22-1060 UML 2.0: invalid package merge diagrams for compliance points UML 2.0 UML 2.1 Resolved closed
UML22-1059 UML 2.0 issue: Profile::ownedStereotype should be derived UML 2.0 UML 2.1 Resolved closed
UML22-1043 Rename LinkAction::input to inputPin UML 2.0 UML 2.1 Resolved closed
UML22-1042 Rename OpaqueAction::input to inputPin UML 2.0 UML 2.1 Resolved closed
UML22-1041 Rename InformationFlow::source UML 2.0 UML 2.1 Resolved closed
UML22-1040 Rename InformationFlow::target UML 2.0 UML 2.1 Resolved closed
UML22-1036 Rename ActivityPartition::subgroup to subpartition UML 2.0 UML 2.1 Resolved closed
UML22-1035 Replace {redefines redefinedElement} UML 2.0 UML 2.1 Resolved closed
UML22-1034 Replace {redefines redefinedElement} UML 2.0 UML 2.1 Resolved closed
UML22-1033 Replace {redefines redefinedElement} UML 2.0 UML 2.1 Resolved closed
UML22-1026 body expression for Property::isConsistentWith(RedefinableElement) UML 2.0 UML 2.1 Resolved closed
UML22-1025 following imports from merged packages to unmerged packages should be remov UML 2.0 UML 2.1 Resolved closed
UML22-1024 UML2 Superstructure Fig 2.2 Incomplete UML 2.0 UML 2.1 Resolved closed
UML22-1023 Section: 14.4 UML 2.0 UML 2.1 Resolved closed
UML22-1020 Section: Common Behaviors UML 2.0 UML 2.1.2 Resolved closed
UML22-1019 Section: Actions UML 2.0 UML 2.1.2 Resolved closed
UML22-1022 7.3.22 InstanceSpecification UML 2.0 UML 2.1 Resolved closed
UML22-1021 Section: Activities UML 2.0 UML 2.1 Resolved closed
UML22-1018 Section: Classes UML 2.0 UML 2.1.2 Resolved closed
UML22-1017 Section: Activities UML 2.0 UML 2.1 Resolved closed
UML22-1016 Invalid stereotype in StandardProfile UML 2.0 UML 2.1 Resolved closed
UML22-1015 UML 2 Super / miscellaneous figure-text discrepancies UML 2.0 UML 2.1 Resolved closed
UML22-1028 Rename Package::ownedMember UML 2.0 UML 2.1 Resolved closed
UML22-1027 Rename Constraint::namespace UML 2.0 UML 2.1 Resolved closed
UML22-1030 Rename ActivityEdge::redefinedElement UML 2.0 UML 2.1 Resolved closed
UML22-1029 Rename Component::ownedMember UML 2.0 UML 2.1 Resolved closed
UML22-1032 Replace {redefines redefinedElement} UML 2.0 UML 2.1 Resolved closed
UML22-1031 Rename ActivityNode::redefinedElement UML 2.0 UML 2.1 Resolved closed
UML22-1012 Section: 6.5 UML 2.0 UML 2.1.2 Resolved closed
UML22-1011 UML2 should specify default property ownership for association ends UML 2.0 UML 2.1 Resolved closed
UML22-1002 Figure 430 references invalid metaclass UML 2.0 UML 2.1 Resolved closed
UML22-1001 Section: 9.3.5 UML 2.0 UML 2.1.2 Resolved closed
UML22-1006 UML2 Navigability Impact on Tools UML 2.0 UML 2.1 Resolved closed
UML22-1005 UML 2 XMI DTD requirement UML 2.0 UML 2.1 Resolved closed
UML22-998 UML2 issue: {unrestricted} described in text but not BNF UML 2.0 UML 2.1 Resolved closed
UML22-997 UML Superstructure / Actions / Missing package heading UML 2.0 UML 2.1 Resolved closed
UML22-1010 UML 2 Super / Undocumented properties UML 2.0 UML 2.1 Resolved closed
UML22-1009 Page: 591,592 UML 2.0 UML 2.1 Resolved closed
UML22-1008 Core::Constructs::Operation UML 2.0 UML 2.1.2 Resolved closed
UML22-1007 Interaction::lifeline should be ordered UML 2.0 UML 2.1.2 Resolved closed
UML22-1004 UML 2 Classes Notation for association end ownership UML 2.0 UML 2.1 Resolved closed
UML22-1003 connection point reference UML 2.0 UML 2.1 Resolved closed
UML22-1014 UML 2 Super / Collaboration use issues (02) UML 2.0 UML 2.1 Resolved closed
UML22-1013 UML 2 Super / Collaboration use issues (01) UML 2.0 UML 2.1 Resolved closed
UML22-1000 Section: 12.3.18 and 12.3.35 UML 2.0 UML 2.1 Resolved closed
UML22-999 Section: 15.3.14 UML 2.0 UML 2.1 Resolved closed
UML22-987 p. 732: Show examples of new stereotype notation RAS 2.2 UML 2.1 Resolved closed
UML22-986 p. 732: Change example to be consistent with new definition of Clock RAS 2.2 UML 2.1 Resolved closed
UML22-994 Section: 12.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-993 Page: 163 UML 2.0 UML 2.1 Resolved closed
UML22-983 Make instance model consistent with new definition of Clock RAS 2.2 UML 2.1 Resolved closed
UML22-982 p. 729: Extend the Clock example to show metaclass property RAS 2.2 UML 2.1 Resolved closed
UML22-985 p. 731: Make example consistent with new definition of Clock. RAS 2.2 UML 2.1 Resolved closed
UML22-984 p. 731: Make this example consistent with the new definition of Clock RAS 2.2 UML 2.1 Resolved closed
UML22-989 Section: 12.3.37 ObjectFlow UML 2.0 UML 2.1 Resolved closed
UML22-996 UML Superstructure / Actions / incorrect form for subsetting UML 2.0 UML 2.1 Resolved closed
UML22-995 Section: 12.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-988 pp. 733-734: Add association as valid graphic path RAS 2.2 UML 2.1 Resolved closed
UML22-991 TimeExpression RAS 2.2 UML 2.1 Resolved closed
UML22-990 OpaqueAction UML 2.0 UML 2.1 Resolved closed
UML22-992 abstract Action in Activity diagram RAS 2.2 UML 2.1 Resolved closed
UML22-981 p. 728: New presentation options. Replace the following paragraph RAS 2.2 UML 2.1 Resolved closed
UML22-980 p. 721: Allow stereotypes to have properties that are typed by metaclasses RAS 2.2 UML 2.1 Resolved closed
UML22-968 Can't specify mutator semantics for derived properties RAS 2.2 UML 2.1 Resolved closed
UML22-967 Section: 12.3.37 RAS 2.2 UML 2.1 Resolved closed
UML22-976 MessageEnd RAS 2.2 UML 2.1 Resolved closed
UML22-975 ExecutableNode should be abstract in Figure 195. It is in Figure 197. UML 2.0 UML 2.1 Resolved closed
UML22-979 Section: 12 and 13 UML 2.0 UML 2.1 Resolved closed
UML22-978 Incorrect Communication Domain Model RAS 2.2 UML 2.1 Resolved closed
UML22-977 Obsolete term EventOccurrence still used in multiple places RAS 2.2 UML 2.1 Resolved closed
UML22-972 Notation of Attributes and Associations subsections RAS 2.2 UML 2.1.2 Resolved closed
UML22-971 Page: 330 UML 2.0 UML 2.1.2 Resolved closed
UML22-970 Section: 11.3.48 UML 2.0 UML 2.1 Resolved closed
UML22-969 Section: Actions UML 2.0 UML 2.1 Resolved closed
UML22-974 Actions should be able to overlap partitions, to support multiple participa UML 2.0 UML 2.1 Resolved closed
UML22-973 Section: 8.3.1 Page: 156 ff UML 2.0 UML 2.1.2 Resolved closed
UML22-966 OpaqueAction RAS 2.2 UML 2.1 Resolved closed
UML22-965 Page: 591 UML 2.0 UML 2.1 Resolved closed
UML22-961 Clarify caption of Figure 56 UML 2.0 UML 2.1 Resolved closed
UML22-960 Section: Interactions UML 2.0 UML 2.1 Resolved closed
UML22-953 Clarify first constraint on InputPin and OutputPin, move "only" to before " UML 2.0 UML 2.1 Resolved closed
UML22-952 LoopNode should move rather than copy values to/from loop variables UML 2.0 UML 2.1 Resolved closed
UML22-951 In Figure 210, put merge before Use Part to merge the incoming flows UML 2.0 UML 2.1 Resolved closed
UML22-950 Exceptions thrown across synchronous invocations UML 2.0 UML 2.1 Resolved closed
UML22-949 Multiple exception handlers UML 2.0 UML 2.1 Resolved closed
UML22-955 Actions, CallBehaviorAction, third sentence, UML 2.0 UML 2.1 Resolved closed
UML22-954 The Syle Guidelines for Stereotype UML 2.0 UML 2.1 Resolved closed
UML22-959 CollaborationUse: Constraint 1, UML 2.0 UML 2.1.2 Resolved closed
UML22-958 ConditionalNode and LoopNode test and bodies should be ExecutableNodes UML 2.0 UML 2.1 Resolved closed
UML22-957 ExpansionRegion UML 2.0 UML 2.1 Resolved closed
UML22-956 ControlFlow UML 2.0 UML 2.1 Resolved closed
UML22-964 Last element in transition BNF UML 2.0 UML 2.1 Resolved closed
UML22-962 Notation for connector end multiplicities. UML 2.0 UML 2.1.2 Resolved closed
UML22-963 ParameterSet, first line: "inputs *or* outputs". UML 2.0 UML 2.1 Resolved closed
UML22-942 In Activities, Figure 176, Action should be abstract UML 2.0 UML 2.1 Resolved closed
UML22-941 Profile Semantics, pag 723 RAS 2.2 UML 2.1 Resolved closed
UML22-935 Section: 12 UML 1.4.2 UML 2.1 Resolved closed
UML22-934 token UML 1.4.2 UML 2.1 Resolved closed
UML22-944 String is primitive but has structure. UML 2.0 UML 2.1 Resolved closed
UML22-937 ``conditional node or conditional node'' delete one. UML 1.4.2 UML 2.1 Resolved closed
UML22-936 add the rule of ``natural termination'' UML 1.4.2 UML 2.1 Resolved closed
UML22-948 Solid triange notation for Association UML 2.0 UML 2.1 Resolved closed
UML22-947 The create stereotype on Usage dependency UML 2.0 UML 2.1.2 Resolved closed
UML22-939 Section: 12.2 UML 2.0 UML 2.1 Resolved closed
UML22-938 Delete sentence UML 1.4.2 UML 2.1 Resolved closed
UML22-946 Element to Constraint navigation UML 2.0 UML 2.1.2 Resolved closed
UML22-945 Disjointness should be independent of generalization UML 2.0 UML 2.1.2 Resolved closed
UML22-943 Semantics for instances applies to InstanceSpecification? UML 2.0 UML 2.1 Resolved closed
UML22-940 policy to describe the Associations sub section of a meta class description RAS 2.2 UML 2.1 Resolved closed
UML22-933 UML 2 -- Need explanations of XMI structure and usage UML 1.4.2 UML 2.1 Resolved closed
UML22-932 token movement UML 1.4.2 UML 2.1 Resolved closed
UML22-931 output tokens (02) UML 1.4.2 UML 2.1 Resolved closed
UML22-927 Section: 12 UML 1.4.2 UML 2.1 Resolved closed
UML22-926 Section: Appendix F UML 2.0 UML 2.1 Resolved closed
UML22-925 Section: E.1 UML 2.0 UML 2.1 Resolved closed
UML22-930 text p.297 UML 1.4.2 UML 2.1 Resolved closed
UML22-929 Section 12 (03) UML 1.4.2 UML 2.1 Resolved closed
UML22-928 Section 12 (02) UML 1.4.2 UML 2.1.2 Resolved closed
UML22-920 Section: Appendix C Table 27 UML 2.0 UML 2.1 Resolved closed
UML22-919 Section: Appendix C Table 26 UML 2.0 UML 2.1 Resolved closed
UML22-922 Section: D.1 UML 2.0 UML 2.1 Resolved closed
UML22-921 Section: 15.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-924 Section: D.3 UML 2.0 UML 2.1 Resolved closed
UML22-923 Section: D.2 UML 2.0 UML 2.1 Resolved closed
UML22-915 Section: 18 UML 2.0 UML 2.1 Resolved closed
UML22-914 Section: 18.4 UML 2.0 UML 2.1 Resolved closed
UML22-913 Section: 18.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-918 Section: Appendix C Table 25 UML 2.0 UML 2.1 Resolved closed
UML22-917 Section: Appendix B (02) UML 2.0 UML 2.1 Resolved closed
UML22-916 Section: Appendix B UML 2.0 UML 2.1 Resolved closed
UML22-912 Section: 18.3.7 UML 2.0 UML 2.1 Resolved closed
UML22-911 Section: 18.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-910 Section: 18.3.2 UML 2.0 UML 2.1 Resolved closed
UML22-909 Section: 18.2 UML 2.0 UML 2.1 Resolved closed
UML22-908 Section: 18.3.2 UML 2.0 UML 2.1 Resolved closed
UML22-893 Section: 17.5.6 UML 2.0 UML 2.1 Resolved closed
UML22-892 Section: 17.5.5 UML 2.0 UML 2.1 Resolved closed
UML22-891 Section: 17.5.4 UML 2.0 UML 2.1 Resolved closed
UML22-895 Section: 17.5.7 UML 2.0 UML 2.1 Resolved closed
UML22-894 Section: 17.1 UML 2.0 UML 2.1 Resolved closed
UML22-901 Section: 17.5.15 UML 2.0 UML 2.1 Resolved closed
UML22-900 Section: 17.5.14 UML 2.0 UML 2.1 Resolved closed
UML22-897 Section: 17.5.12 UML 2.0 UML 2.1 Resolved closed
UML22-896 Section: 17.5.8 UML 2.0 UML 2.1 Resolved closed
UML22-907 Section: 18.1.2 UML 2.0 UML 2.1 Resolved closed
UML22-906 Section: 17.5.20 UML 2.0 UML 2.1 Resolved closed
UML22-899 Section: 12 Activities UML 2.0 UML 2.1 Resolved closed
UML22-898 Section: 17.5.13 UML 2.0 UML 2.1 Resolved closed
UML22-903 Section: 17.5.17 UML 2.0 UML 2.1 Resolved closed
UML22-902 Section: 17.5.16 UML 2.0 UML 2.1 Resolved closed
UML22-905 Section: 17.5.19 UML 2.0 UML 2.1 Resolved closed
UML22-904 Section: 17.5.18 UML 2.0 UML 2.1 Resolved closed
UML22-883 Section: 17.2.2 UML 2.0 UML 2.1 Resolved closed
UML22-882 Section: 17.2.1 UML 2.0 UML 2.1 Resolved closed
UML22-872 Expansion region description UML 2.0 UML 2.1 Resolved closed
UML22-871 ExpansionRegioin example, Figure 261: concurrent => parallel UML 2.0 UML 2.1 Resolved closed
UML22-870 Section: Activities, ExpansionRegion (05) UML 2.0 UML 2.1 Resolved closed
UML22-879 mustIsolate: UML 2.0 UML 2.1 Resolved closed
UML22-878 No notation UML 2.0 UML 2.1 Resolved closed
UML22-875 Semantics of isAssured/isDeterminant in conditional node UML 2.0 UML 2.1 Resolved closed
UML22-874 Add constraint in LoopNode UML 2.0 UML 2.1 Resolved closed
UML22-873 Section: Activities UML 2.0 UML 2.1 Resolved closed
UML22-890 Section: 17.5.3 UML 2.0 UML 2.1 Resolved closed
UML22-889 Section: 17.5.3 UML 2.0 UML 2.1 Resolved closed
UML22-888 Section: 17.5.1 UML 2.0 UML 2.1 Resolved closed
UML22-885 Section: 17.4 UML 2.0 UML 2.1 Resolved closed
UML22-884 Section: 17.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-887 Section: 17.5.2 UML 2.0 UML 2.1 Resolved closed
UML22-886 Section: 17.5.1 UML 2.0 UML 2.1 Resolved closed
UML22-881 Clarify the semantics of minimum multiplicity > 0 for streaming parameters UML 2.0 UML 2.1 Resolved closed
UML22-880 Figure 209 of Activites UML 2.0 UML 2.1 Resolved closed
UML22-877 Add constraints on conditional and loop nodes (02) UML 2.0 UML 2.1 Resolved closed
UML22-876 Add constraints on conditional and loop nodes UML 2.0 UML 2.1 Resolved closed
UML22-853 UML 2 Super / Conformance / inconsistencies UML 1.4.2 UML 2.1 Resolved closed
UML22-852 UML 2 Super / General / missing merges UML 1.4.2 UML 2.1 Resolved closed
UML22-851 UML 2 Super / General / improper subsetting UML 1.4.2 UML 2.1 Resolved closed
UML22-855 UML 2 Super / General / invalid subset rule too strict UML 1.4.2 UML 2.1 Resolved closed
UML22-854 UML 2 Super / Kernel / excessive restriction on redefinition UML 1.4.2 UML 2.1 Resolved closed
UML22-861 Section: 14.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-860 Section: 16.3.6 UML 2.0 UML 2.1 Resolved closed
UML22-869 Section: Activities, ExpansionRegion (04) UML 2.0 UML 2.1 Resolved closed
UML22-868 Section: Activities, ExpansionRegion (03) UML 2.0 UML 2.1 Resolved closed
UML22-867 Section: Activities, ExpansionRegion (02) UML 2.0 UML 2.1 Resolved closed
UML22-859 Section: 16.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-858 Section: 16.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-857 Section: 16.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-856 UML 2 Super / Common Behaviors / missing multiplicites UML 1.4.2 UML 2.1 Resolved closed
UML22-866 Section: Activities, ExpansionRegion UML 2.0 UML 2.1 Resolved closed
UML22-865 Section: Activities UML 2.0 UML 2.1 Resolved closed
UML22-864 ValueSpecificationAction, Attribute section, is missing the return pin UML 2.0 UML 2.1 Resolved closed
UML22-863 Section: Actions UML 2.0 UML 2.1 Resolved closed
UML22-862 Section: Common Behavior UML 2.0 UML 2.1 Resolved closed
UML22-841 Section: 15.3.14 UML 2.0 UML 2.1 Resolved closed
UML22-840 Section: Appendix A UML 2.0 UML 2.1 Resolved closed
UML22-837 Section: 15.3.11 UML 2.0 UML 2.1 Resolved closed
UML22-836 Section: 15.3.11 UML 2.0 UML 2.1 Resolved closed
UML22-835 Action Semantics Section: 9.5 UML 1.4.2 UML 2.1 Resolved closed
UML22-839 Appendix C.1 UML 2.0 UML 2.1 Resolved closed
UML22-838 Section: 15.3.12 UML 2.0 UML 2.1 Resolved closed
UML22-834 Specification: Action Semantics Section: 9.5 UML 1.4.2 UML 2.1 Resolved closed
UML22-833 Section: 15.3.10 UML 2.0 UML 2.1 Resolved closed
UML22-832 Section: 15.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-843 Section: 15.3.16 UML 2.0 UML 2.1 Resolved closed
UML22-842 Section: 15.3.15 UML 2.0 UML 2.1 Resolved closed
UML22-850 UML 2 Super / Collaborations / improper subset UML 1.4.2 UML 2.1 Resolved closed
UML22-849 Profiles::ObjectNode has wrong default multiplicity UML 1.4.2 UML 2.1 Resolved closed
UML22-848 Profiles::ExtensionEnd has wrong default multiplicity UML 1.4.2 UML 2.1 Resolved closed
UML22-845 Should Profiles::Image be an Element? UML 1.4.2 UML 2.1 Resolved closed
UML22-844 Section: 15.3.7 UML 2.0 UML 2.1 Resolved closed
UML22-847 Remove redundant superclass for Element UML 1.4.2 UML 2.1 Resolved closed
UML22-846 OCL for Property::opposite() is incorrect: UML 1.4.2 UML 2.1 Resolved closed
UML22-831 Section: 15.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-830 Section: 15.3.7 UML 2.0 UML 2.1 Resolved closed
UML22-817 Section: 14.3.26 UML 2.0 UML 2.1 Resolved closed
UML22-816 Section: 14.3.25 UML 2.0 UML 2.1 Resolved closed
UML22-823 Section: 15.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-822 Section: 8.3.1 UML 2.0 UML 2.1.2 Resolved closed
UML22-829 Section: 15.3.6 UML 2.0 UML 2.1 Resolved closed
UML22-828 Section: 11.3.42 UML 2.0 UML 2.1 Resolved closed
UML22-812 Section: 14.3.20 UML 2.0 UML 2.1 Resolved closed
UML22-811 Section: 14.3.19 UML 2.0 UML 2.1 Resolved closed
UML22-815 Section: 14.3.24 UML 1.4.2 UML 2.1 Resolved closed
UML22-814 Section: 14.3.21 UML 2.0 UML 2.1 Resolved closed
UML22-813 Section: 14.3.21 UML 2.0 UML 2.1 Resolved closed
UML22-827 Section: 15.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-826 Section: 15.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-819 Section: 14.4 UML 2.0 UML 2.1 Resolved closed
UML22-818 Section: 14.3.29 UML 2.0 UML 2.1 Resolved closed
UML22-821 Section: 12.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-820 Section: 11.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-825 Section: 15.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-824 Section: 15.3.2 UML 2.0 UML 2.1 Resolved closed
UML22-810 Section: 14.3.17 UML 2.0 UML 2.1 Resolved closed
UML22-809 Section: 14.3.16 UML 2.0 UML 2.1 Resolved closed
UML22-808 Section: 14.3.15 UML 2.0 UML 2.1 Resolved closed
UML22-797 Section: 14.3.2 UML 2.0 UML 2.1 Resolved closed
UML22-796 Section: 13 UML 2.0 UML 2.1 Resolved closed
UML22-795 Section: 13.3.30 UML 2.0 UML 2.1 Resolved closed
UML22-807 Section: 14.3.13 UML 2.0 UML 2.1 Resolved closed
UML22-806 Section: 14.3.14 UML 2.0 UML 2.1 Resolved closed
UML22-799 Section: 14.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-798 Section: 14.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-803 Section: 14.3.10 UML 2.0 UML 2.1 Resolved closed
UML22-802 Section: 14.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-801 Section: 14.3.6 UML 2.0 UML 2.1 Resolved closed
UML22-800 Section: 14.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-794 Section: 13.3.29 UML 2.0 UML 2.1 Resolved closed
UML22-793 Section: 13.3.28 UML 2.0 UML 2.1 Resolved closed
UML22-792 Section: 13.3.27 UML 2.0 UML 2.1 Resolved closed
UML22-805 Section: 14.3.12 UML 2.0 UML 2.1 Resolved closed
UML22-804 Section: 14.3.3 & 14.3.11 UML 2.0 UML 2.1 Resolved closed
UML22-791 Section: 13.3.26 UML 2.0 UML 2.1 Resolved closed
UML22-790 Section: 13.3.24 UML 2.0 UML 2.1 Resolved closed
UML22-776 Section: 13.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-775 Section: 13.3.2 UML 2.0 UML 2.1.2 Resolved closed
UML22-784 Section: 13.3.14 UML 2.0 UML 2.1 Resolved closed
UML22-783 Section: 13.3.12 UML 2.0 UML 2.1 Resolved closed
UML22-778 Section: 13.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-780 Section: 13.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-779 Section: 13.3.7 UML 2.0 UML 2.1 Resolved closed
UML22-789 Section: 13.3.23 UML 2.0 UML 2.1 Resolved closed
UML22-788 Section: 13.3.22 UML 2.0 UML 2.1 Resolved closed
UML22-782 Section: 13.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-781 Section: 13.3.10 UML 2.0 UML 2.1 Resolved closed
UML22-786 Section: 13.3.19 UML 2.0 UML 2.1 Resolved closed
UML22-785 Section: 13.3.15 UML 2.0 UML 2.1 Resolved closed
UML22-787 Section: 13.3.20 UML 2.0 UML 2.1 Resolved closed
UML22-777 Section: 7.3.36 UML 2.0 UML 2.1 Resolved closed
UML22-755 Section: 12.3.35 UML 2.0 UML 2.1 Resolved closed
UML22-754 Section: 12.3 UML 2.0 UML 2.1 Resolved closed
UML22-753 Section: 12.3.35 UML 2.0 UML 2.1 Resolved closed
UML22-767 Section: 11.3.48 UML 2.0 UML 2.1 Resolved closed
UML22-766 Section: 12.3.48 UML 2.0 UML 2.1 Resolved closed
UML22-771 Section: 12 UML 2.0 UML 2.1 Resolved closed
UML22-770 Section: 12.4 UML 2.0 UML 2.1 Resolved closed
UML22-758 Section: 12.3.38 UML 2.0 UML 2.1 Resolved closed
UML22-757 Section: 12.3.37 UML 2.0 UML 2.1 Resolved closed
UML22-756 Profiles:Extension End UML 1.4.2 UML 2.1 Resolved closed
UML22-765 Section: 12.2 UML 2.0 UML 2.1 Resolved closed
UML22-764 Section: 12.3.47 UML 2.0 UML 2.1 Resolved closed
UML22-763 UML 2 super/templates/ UML 1.4.2 UML 2.1 Resolved closed
UML22-760 Section: 12.3.43 UML 2.0 UML 2.1 Resolved closed
UML22-759 Section: 12.3.41 UML 2.0 UML 2.1 Resolved closed
UML22-774 Section: 12.3.49 UML 2.0 UML 2.1 Resolved closed
UML22-773 Section: 12.3.46 UML 2.0 UML 2.1 Resolved closed
UML22-772 Section: 13.1 UML 2.0 UML 2.1 Resolved closed
UML22-762 UML 2 Super/templates/inexplicable constraint on defaults UML 1.4.2 UML 2.1 Resolved closed
UML22-761 Section: 12.3.44 UML 2.0 UML 2.1 Resolved closed
UML22-769 Section: 12.3.51 UML 2.0 UML 2.1 Resolved closed
UML22-768 Section: 12.3.50 UML 2.0 UML 2.1 Resolved closed
UML22-752 Section: 12.3.34 UML 2.0 UML 2.1 Resolved closed
UML22-751 Section: 12.3.33 UML 2.0 UML 2.1 Resolved closed
UML22-738 Section: 12.3.17 UML 2.0 UML 2.1 Resolved closed
UML22-737 Section: 12.3.16 UML 2.0 UML 2.1 Resolved closed
UML22-736 Section: 12.3.15 UML 2.0 UML 2.1 Resolved closed
UML22-735 Section: 12.3.14 UML 2.0 UML 2.1.2 Resolved closed
UML22-731 MultiplicityElement BNF too restrictive UML 1.4.2 UML 2.1 Resolved closed
UML22-730 Section: 12.3.13 UML 2.0 UML 2.1 Resolved closed
UML22-741 Section: 12.3.6 & 12.3.19 UML 2.0 UML 2.1 Resolved closed
UML22-740 Section: 12.3.19 UML 2.0 UML 2.1 Resolved closed
UML22-739 Section: 12.3.18 UML 2.0 UML 2.1 Resolved closed
UML22-746 Section: 12.3.28 UML 2.0 UML 2.1 Resolved closed
UML22-745 Section: 12.3.27 UML 2.0 UML 2.1 Resolved closed
UML22-744 Section: 12.3.23 UML 2.0 UML 2.1 Resolved closed
UML22-734 Used of "Redefines ...from Abstractions" in descriptions is misleading UML 1.4.2 UML 2.1 Resolved closed
UML22-733 BNF Notation for Operation is too restrictive UML 1.4.2 UML 2.1 Resolved closed
UML22-732 Incomplete BNF for Property UML 1.4.2 UML 2.1 Resolved closed
UML22-743 Section: 12.3.24 UML 2.0 UML 2.1 Resolved closed
UML22-742 Section: 12.3.22 UML 2.0 UML 2.1 Resolved closed
UML22-748 Section: 12.3.38 UML 2.0 UML 2.1 Resolved closed
UML22-747 Section: 12.3.30 UML 2.0 UML 2.1 Resolved closed
UML22-750 Section: 12.3.32 UML 2.0 UML 2.1 Resolved closed
UML22-749 Section: 12.3.31 UML 2.0 UML 2.1 Resolved closed
UML22-729 Section: 12.1 UML 2.0 UML 2.1 Resolved closed
UML22-728 Section: 12.3.12 UML 2.0 UML 2.1 Resolved closed
UML22-727 Section: 12.3.10 UML 2.0 UML 2.1 Resolved closed
UML22-726 Section: 12 UML 2.0 UML 2.1 Resolved closed
UML22-725 Section: 12.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-716 Section: 12.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-715 Section: 12.3.2 UML 2.0 UML 2.1 Resolved closed
UML22-714 Section: 12.2 UML 2.0 UML 2.1 Resolved closed
UML22-721 Section: 12.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-720 Section: 12.3.7 UML 2.0 UML 2.1 Resolved closed
UML22-719 Section: 12.3.6 UML 2.0 UML 2.1 Resolved closed
UML22-683 Section: 11.3.25 UML 2.0 UML 2.1 Resolved closed
UML22-682 Section: 11.3.24 UML 2.0 UML 2.1 Resolved closed
UML22-629 Section: 7.3.35 UML 2.0 UML 2.1 Resolved closed
UML22-631 Section: 8.3.1 - typo UML 2.0 UML 2.1 Resolved closed
UML22-630 Section: 8.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-628 Section: 7.3.34 UML 2.0 UML 2.1 Resolved closed
UML22-627 Section: 7.3.33 UML 2.0 UML 2.1 Resolved closed
UML22-637 Section: 9.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-636 Section: 9.3.3 UML 1.4.2 UML 2.1 Resolved closed
UML22-635 Section: 9.3.2 UML 2.0 UML 2.1 Resolved closed
UML22-632 Section: 8.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-633 Section: 9.20.2 UML 2.0 UML 2.1 Resolved closed
UML22-634 Section: 9.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-638 Section: 9.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-561 InfrastructureLibrary defines, but should not use package merge UML 1.4.2 UML 2.1 Resolved closed
UML22-557 section 2.10.4.1 detailed semantics of collaborations UML 1.4.2 UML 2.1 Resolved closed
UML22-554 Section: 7.3.43 UML 2.0 UML 2.1 Resolved closed
UML22-559 Interactions UML 1.4.2 UML 2.1 Resolved closed
UML22-558 Section: 7.3.44 - OCL incorrect UML 1.4.2 UML 2.1 Resolved closed
UML22-555 Section: 7.2.8 UML 1.4.2 UML 2.1 Resolved closed
UML22-560 UML 2 Super Basic Interactions UML 1.4.2 UML 2.1.2 Resolved closed
UML22-562 An observed time value must be written into a structural feature UML 2.0 UML 2.1.2 Resolved closed
UML22-556 Classes UML 1.4.2 UML 2.1 Resolved closed
UML22-691 Section: 11.3.34 UML 2.0 UML 2.1 Resolved closed
UML22-690 Section: 11.3.33 UML 2.0 UML 2.1 Resolved closed
UML22-689 Section: 11.3.31 UML 2.0 UML 2.1 Resolved closed
UML22-684 Section: 11.3.26 UML 2.0 UML 2.1 Resolved closed
UML22-694 Section: 11.3.27 UML 2.0 UML 2.1 Resolved closed
UML22-693 Section: 11.3.36 UML 2.0 UML 2.1 Resolved closed
UML22-686 Section: 11.3.28 UML 2.0 UML 2.1 Resolved closed
UML22-687 Section: 11.3.29 UML 2.0 UML 2.1 Resolved closed
UML22-692 Section: 11.3.35 UML 2.0 UML 2.1 Resolved closed
UML22-688 Section: 11.3.30 UML 2.0 UML 2.1 Resolved closed
UML22-685 Section: 11.3.27 UML 2.0 UML 2.1 Resolved closed
UML22-588 Optional inputs UML 2.0 UML 2.1 Resolved closed
UML22-587 Preserve order in result of read actions UML 2.0 UML 2.1 Resolved closed
UML22-582 Interactions chapter refers to ActivityInvocations UML 2.0 UML 2.1 Resolved closed
UML22-583 Destruction semantics in StructuredClassifier UML 2.0 UML 2.1 Resolved closed
UML22-585 Figure 119 missing multiplicity UML 2.0 UML 2.1 Resolved closed
UML22-584 Link maintenance in StructuredClassifier UML 2.0 UML 2.1 Resolved closed
UML22-591 ObjectNode, constraint 1 In ObjectNode UML 2.0 UML 2.1 Resolved closed
UML22-590 DestroyObjectAction semantics UML 2.0 UML 2.1 Resolved closed
UML22-589 IsReadOnly constriant UML 2.0 UML 2.1 Resolved closed
UML22-586 Notation for method UML 2.0 UML 2.1 Resolved closed
UML22-659 Section: 11.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-658 Section: 11.1 UML 2.0 UML 2.1 Resolved closed
UML22-621 Section: 7.3.15 UML 2.0 UML 2.1 Resolved closed
UML22-620 Section: 7.3.12 UML 2.0 UML 2.1 Resolved closed
UML22-626 Section: 7.3.32 Page: 96-99 UML 2.0 UML 2.1 Resolved closed
UML22-625 Section: 7.3.32 UML 2.0 UML 2.1 Resolved closed
UML22-624 Section: 7.3.22 UML 2.0 UML 2.1 Resolved closed
UML22-616 Section: 6.5.1: Error in example UML 2.0 UML 2.1 Resolved closed
UML22-619 Section: 7.3.10 UML 2.0 UML 2.1 Resolved closed
UML22-622 Section: 7.3.20 UML 2.0 UML 2.1 Resolved closed
UML22-618 Section: 7.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-623 Stereotypes applying in UML 2.0 UML 1.4.2 UML 2.1 Resolved closed
UML22-617 Section: 7.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-678 Section: 11.3.20 UML 2.0 UML 2.1 Resolved closed
UML22-677 Section: 11.3.19 UML 2.0 UML 2.1 Resolved closed
UML22-680 Section: 11.3.22 -- significant revision? UML 2.0 UML 2.1 Resolved closed
UML22-679 Section: 11.3.21 UML 2.0 UML 2.1 Resolved closed
UML22-696 Section: 11.3.40 UML 2.0 UML 2.1 Resolved closed
UML22-695 Section: 11.3.38 UML 2.0 UML 2.1 Resolved closed
UML22-681 Section: 11.3.23 -- significant revision? UML 2.0 UML 2.1 Resolved closed
UML22-672 Section: 11.3.14 UML 2.0 UML 2.1 Resolved closed
UML22-676 Section: 11.3.18 UML 2.0 UML 2.1 Resolved closed
UML22-674 Section: 11.3.16 UML 2.0 UML 2.1 Resolved closed
UML22-675 Section: 11.3.17 UML 2.0 UML 2.1 Resolved closed
UML22-673 Section: 11.3.15 UML 2.0 UML 2.1 Resolved closed
UML22-709 Section: 11.3.53 UML 2.0 UML 2.1 Resolved closed
UML22-708 Section: 11.3.42 UML 2.0 UML 2.1 Resolved closed
UML22-698 Section: 11.3.43 UML 2.0 UML 2.1 Resolved closed
UML22-697 Section: 11.3.41 UML 2.0 UML 2.1 Resolved closed
UML22-660 Section: 11.3.2 UML 2.0 UML 2.1 Resolved closed
UML22-667 Section: 11.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-666 Section: 11.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-670 Section: 11.3.12 UML 2.0 UML 2.1 Resolved closed
UML22-669 Section: 11.3.11 UML 2.0 UML 2.1.2 Resolved closed
UML22-668 Section: 11.3.10 UML 2.0 UML 2.1 Resolved closed
UML22-664 Section: 11.3.6 UML 2.0 UML 2.1 Resolved closed
UML22-665 Section: 11.3.7 UML 2.0 UML 2.1 Resolved closed
UML22-663 Section: 11.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-671 Section: 11.3.13 UML 2.0 UML 2.1 Resolved closed
UML22-579 Connector multiplicity notation UML 2.0 UML 2.1 Resolved closed
UML22-578 Associations between interfaces UML 2.0 UML 2.1 Resolved closed
UML22-580 create dependency Figures 103 and 121 UML 2.0 UML 2.1 Resolved closed
UML22-573 Transitivity in composition UML 2.0 UML 2.1 Resolved closed
UML22-581 underlined association name UML 2.0 UML 2.1.2 Resolved closed
UML22-577 Section: Classes UML 2.0 UML 2.1 Resolved closed
UML22-572 Add concept "StateInvariant" UML 2.0 UML 2.1 Resolved closed
UML22-574 Pin/parameter matching constraints UML 2.0 UML 2.1 Resolved closed
UML22-576 Section: Classes UML 2.0 UML 2.1 Resolved closed
UML22-575 Section: CB/ACT UML 2.0 UML 2.1 Resolved closed
UML22-723 Section: 12.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-722 Section: 12.1 UML 2.0 UML 2.1 Resolved closed
UML22-641 Section: 8.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-640 Section: 9.3.10 UML 2.0 UML 2.1 Resolved closed
UML22-647 Section: 10.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-648 Section: 10.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-644 Section: 12.3.13 UML 2.0 UML 2.1 Resolved closed
UML22-645 Section: 12.3.13 UML 2.0 UML 2.1 Resolved closed
UML22-643 Section: 9.3.13 UML 2.0 UML 2.1 Resolved closed
UML22-639 Section: 9.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-646 Section: 9.2 UML 2.0 UML 2.1 Resolved closed
UML22-642 Section: 9.3.12 UML 2.0 UML 2.1 Resolved closed
UML22-615 Section: 7.4.1 UML 2.0 UML 2.1 Resolved closed
UML22-614 Section: 7.3.6 UML 2.0 UML 2.1 Resolved closed
UML22-610 Section: 11.8.3 UML 2.0 UML 2.1 Resolved closed
UML22-609 Section: 11.6.1 UML 2.0 UML 2.1 Resolved closed
UML22-613 Section: 7.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-612 Section: 13.1.5 UML 2.0 UML 2.1 Resolved closed
UML22-607 Section: 11.5 UML 2.0 UML 2.1 Resolved closed
UML22-606 search for referenced item -- Section: 11.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-603 Figure 68 UML 2.0 UML 2.1 Resolved closed
UML22-602 methods not defined under attributes UML 2.0 UML 2.1 Resolved closed
UML22-611 Section: 13.1.2 UML 2.0 UML 2.1 Resolved closed
UML22-605 Section: 11.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-604 Section: 11.3.1 UML 2.0 UML 2.1 Resolved closed
UML22-608 Actor is a specialized Classifier and not BehavioredClassifier UML 2.0 UML 2.1 Resolved closed
UML22-711 Section: 12.1 UML 2.0 UML 2.1 Resolved closed
UML22-710 Section: 11.3.54 UML 2.0 UML 2.1 Resolved closed
UML22-713 {redefined } should be named {redefines } UML 2.0 UML 2.1 Resolved closed
UML22-712 Property string {bag} is redundant UML 2.0 UML 2.1.2 Resolved closed
UML22-718 Section: 12.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-717 Section: 12.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-703 Section: 11.3.48 UML 2.0 UML 2.1 Resolved closed
UML22-701 Section: 11.3.46 UML 2.0 UML 2.1 Resolved closed
UML22-700 Section: 11.3.45 UML 2.0 UML 2.1 Resolved closed
UML22-707 Section: 11.3.52 UML 2.0 UML 2.1 Resolved closed
UML22-706 Section: 11.3.51 UML 2.0 UML 2.1 Resolved closed
UML22-705 Section: 11.3.50 UML 2.0 UML 2.1 Resolved closed
UML22-699 Section: 11.3.44 UML 2.0 UML 2.1 Resolved closed
UML22-704 Section: 11.3.49 UML 2.0 UML 2.1 Resolved closed
UML22-702 Section: 11.3.47 UML 2.0 UML 2.1 Resolved closed
UML22-596 unclear statement UML 2.0 UML 2.1 Resolved closed
UML22-595 Text references Figure 8 and the correct figure number is 6 UML 2.0 UML 2.1 Resolved closed
UML22-599 Section is badly worded and does not make a lot of sense UML 2.0 UML 2.1 Resolved closed
UML22-598 clarify what a directed association is UML 2.0 UML 2.1 Resolved closed
UML22-593 Terminology Issue UML 1.4.2 UML 2.1.2 Resolved closed
UML22-600 typing error in the statement :unrestricted ? UML 2.0 UML 2.1 Resolved closed
UML22-597 extra word in the last sentence of the paragraph under Attributes UML 2.0 UML 2.1 Resolved closed
UML22-594 section 9.20.2 VisibilityKind lists two types of visibility UML 2.0 UML 2.1 Resolved closed
UML22-592 StructuredActivityNode specialized multiplicity UML 2.0 UML 2.1 Resolved closed
UML22-601 What happened to real numbers UML 2.0 UML 2.1 Resolved closed
UML22-724 Section: 12 UML 2.0 UML 2.1 Resolved closed
UML22-662 Section: 11.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-661 Section: 11.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-655 Section: 10.3.10 UML 2.0 UML 2.1 Resolved closed
UML22-654 Section: 10.3.9 UML 2.0 UML 2.1 Resolved closed
UML22-657 Section: 10.4 UML 1.4.2 UML 2.1 Resolved closed
UML22-652 Section: 10.3.6 UML 2.0 UML 2.1 Resolved closed
UML22-656 Section: 10.3.11 UML 2.0 UML 2.1 Resolved closed
UML22-650 Section: 10.3.4 UML 2.0 UML 2.1 Resolved closed
UML22-653 Section: 10.3.8 UML 2.0 UML 2.1 Resolved closed
UML22-649 Section: 10.3.3 UML 2.0 UML 2.1 Resolved closed
UML22-651 Section: 10.3.5 UML 2.0 UML 2.1 Resolved closed
UML22-565 ReduceAction UML 1.4.2 UML 2.1 Resolved closed
UML22-564 UML 2 Super / Incorrect statement on port visibility UML 1.4.2 UML 2.1 Resolved closed
UML22-566 Section: 14.3.7 UML 2.0 UML 2.1 Resolved closed
UML22-563 Minor error in BNF of an message argument UML 2.0 UML 2.1 Resolved closed
UML22-568 Section: 14.3.14 UML 2.0 UML 2.1 Resolved closed
UML22-569 Section: 14.3.16 UML 2.0 UML 2.1 Resolved closed
UML22-571 StateInvariants/Continuations UML 2.0 UML 2.1 Resolved closed
UML22-570 Section: Table 14 UML 2.0 UML 2.1 Resolved closed
UML22-567 Section: 14.3.13 UML 2.0 UML 2.1 Resolved closed
UML22-553 DataType attributes UML 2 Super (ptc/04-10-02) UML 1.4.2 UML 2.1 Resolved closed
UML22-458 UML 2.2 superstructure section 9.3.11 page 184: Port.isService UML 2.1.2 UML 2.2 Resolved closed
UML22-456 Could you please clarify what does the UML2 specifications intend for "provided port" and "required port"? UML 2.1.2 UML 2.2 Resolved closed
UML22-455 Inconsistency in Superstructure 2.2 p. 550 UML 2.1.2 UML 2.2 Resolved closed
UML22-454 InstanceSpecifications UML 2.1.2 UML 2.2 Resolved closed
UML22-453 specificMachine association should be changed to be type StateMachine UML 2.1.2 UML 2.2 Resolved closed
UML22-452 p269-p270 Constraint UML 2.1.2 UML 2.2 Resolved closed
UML22-451 operation allConnections UML 2.1.2 UML 2.2 Resolved closed
UML22-450 TYPO p.54 Additional Operations UML 2.1.2 UML 2.2 Resolved closed
UML22-446 Classifier has association end "attribute" UML 2.1.2 UML 2.2 Resolved closed
UML22-445 Typo 9.3.13 p190 UML 2.1.2 UML 2.2 Resolved closed
UML22-449 Metaclass Property is denoted in Interfaces Package on p.36 UML 2.1.2 UML 2.2 Resolved closed
UML22-448 7.3.33 p100 UML 2.1.2 UML 2.2 Resolved closed
UML22-447 Property 7.3.44 p125 UML 2.1.2 UML 2.2 Resolved closed
UML22-444 7.3.44 additional operation P128 UML 2.1.2 UML 2.2 Resolved closed
UML22-399 first paragraph of section 7.8 UML kernel UML 2.1.2 UML 2.2 Resolved closed
UML22-398 Section: 7.3.7 and 8.3.1 UML 2.1.2 UML 2.2 Resolved closed
UML22-401 Port UML 2.1.2 UML 2.2 Resolved closed
UML22-400 Section 14 Interaction UML 2.1.2 UML 2.2 Resolved closed
UML22-389 Section: 15.3.11/Notation UML 2.1.2 UML 2.2 Resolved closed
UML22-388 Section 11.3.25 gives the definition of MultiplicityExpression::isConsisten UML 2.1.2 UML 2.2 Resolved closed
UML22-396 interpreting InstanceSpecification UML 2.1.2 UML 2.2 Resolved closed
UML22-395 Figure showing an AssociationClass as a ternary association UML 2.1.2 UML 2.2 Resolved closed
UML22-391 Section: 7.3.10/Associations UML 2.1.2 UML 2.2 Resolved closed
UML22-390 Section: 13.3.3/ Changes from previous UML UML 2.1.2 UML 2.2 Resolved closed
UML22-394 Car dependency example UML 2.1.2 UML 2.2 Resolved closed
UML22-393 Section: 12.3.8/Generalizations UML 2.1.2 UML 2.2 Resolved closed
UML22-387 qualifiers UML 2.1.2 UML 2.2 Resolved closed
UML22-397 Section: 15 StateMachines: doActivity and internal transitions UML 2.1.2 UML 2.2 Resolved closed
UML22-392 Section: 7.3.10/Associations - insert reference UML 2.1.2 UML 2.2 Resolved closed
UML22-432 Unspecified constraint [1] on ActivityNode UML 2.1.2 UML 2.2 Resolved closed
UML22-431 constraint [4] on AcceptEventAction and unordered result:OutputPin property UML 2.1.2 UML 2.2 Resolved closed
UML22-434 figure 13.12 UML 2.1.2 UML 2.2 Resolved closed
UML22-433 Unspecified constraint [1] on ActivityNode (StructuredActivities) UML 2.1.2 UML 2.2 Resolved closed
UML22-436 Clarification on use of Profiles. UML 2.1.2 UML 2.2 Resolved closed
UML22-435 Property – Additional Operations, page 127. UML 2.1.2 UML 2.2 Resolved closed
UML22-443 7.3.44 Property P128 UML 2.1.2 UML 2.2 Resolved closed
UML22-442 18.3.8 Stereotype UML 2.1.2 UML 2.2 Resolved closed
UML22-430 Unspecified constraint [3] on Activity UML 2.1.2 UML 2.2 Resolved closed
UML22-440 Typo P205 10.3.4 UML 2.1.2 UML 2.2 Resolved closed
UML22-439 On the table 2.3, page 8 UML 2.1.2 UML 2.2 Resolved closed
UML22-438 On the communication diagram in Fig 6.2 (second issue) UML 2.1.2 UML 2.2 Resolved closed
UML22-437 On the communication diagram in Fig 6.2 (P12) UML 2.1.2 UML 2.2 Resolved closed
UML22-441 7.3.11 DataType, P61 UML 2.1.2 UML 2.2 Resolved closed
UML22-383 UML 2.1.2:18.3.5 Package (from Profiles) UML 2.1.2 UML 2.2 Resolved closed
UML22-382 UML Super 2.1.2:Feature UML 2.1.2 UML 2.2 Resolved closed
UML22-384 A final node that returns to the caller but leaves alive any parallel flow UML 2.1.2 UML 2.2 Resolved closed
UML22-380 section '10.3.12 Property (from Nodes)' UML 2.1.2 UML 2.2 Resolved closed
UML22-379 PackageableElement (from Kernel), subsection: "Attribute" UML 2.1.2 UML 2.2 Resolved closed
UML22-386 CMOF file for UML2 does not have derived Associations marked as such UML 2.1.2 UML 2.2 Resolved closed
UML22-385 Section: 8.3.3 UML 2.1.2 UML 2.2 Resolved closed
UML22-378 description of MessageOccurenceSpecification UML 2.1.2 UML 2.2 Resolved closed
UML22-377 The list of literal described for the ennumeration MessageSort is not compl UML 2.1.2 UML 2.2 Resolved closed
UML22-381 undefined term 'Element::redefinedElement' occurs three times in standard UML 2.1.2 UML 2.2 Resolved closed
UML22-419 Section: 7.4 figure 7.1 missing dependency UML 2.1.2 UML 2.2 Resolved closed
UML22-418 UML2: Need a better mechanism for integrating UML2 Profiles UML 2.1.2 UML 2.2 Resolved closed
UML22-421 Regression in XMI from UML 2.1.2 to UML 2.2 UML 2.1.2 UML 2.2 Resolved closed
UML22-420 Section: 2.2-2.4 compliance level clarifiction needed UML 2.1.2 UML 2.2 Resolved closed
UML22-424 Unspecified constraint [1] on AcceptEventAction UML 2.1.2 UML 2.2 Resolved closed
UML22-423 Incorrect OCL expression for constraint [1] on BehavioredClassifier UML 2.1.2 UML 2.2 Resolved closed
UML22-415 OCL 2.0 8.2 Real UML 2.1.2 UML 2.2 Resolved closed
UML22-414 UML2 issue regarding RedefinableTemplateSignature UML 2.1.2 UML 2.2 Resolved closed
UML22-427 Unspecified constraint [1] on ActivityEdge (CompleteStructuredActivities) UML 2.1.2 UML 2.2 Resolved closed
UML22-426 Unspecified constraint [2] on ActivityEdge UML 2.1.2 UML 2.2 Resolved closed
UML22-429 Unspecified constraint [2] on Activity UML 2.1.2 UML 2.2 Resolved closed
UML22-428 Unspecified constraint [1 on Activity UML 2.1.2 UML 2.2 Resolved closed
UML22-417 Section 7.3.50 "substitution" UML 2.1.2 UML 2.2 Resolved closed
UML22-416 Keyword ambiguity for DataType Section UML 2.1.2 UML 2.2 Resolved closed
UML22-425 Unspecified constraint [1] on ActivityEdge UML 2.1.2 UML 2.2 Resolved closed
UML22-422 Section: 9.3.8 UML 2.1.2 UML 2.2 Resolved closed
UML22-406 Section 10.3.10 UML 2.1.1 UML 2.2 Resolved closed
UML22-405 definition of RedefinableElement::isLeaf UML 2.1.2 UML 2.2 Resolved closed
UML22-404 Behavior's parameter list UML 2.1.2 UML 2.2 Resolved closed
UML22-403 PackageMerge relationships UML 2.1.2 UML 2.2 Resolved closed
UML22-413 Section: 7.3.36 UML 2.1.2 UML 2.2 Resolved closed
UML22-412 Section: 11.3.30,12.3.23 UML 2.1.2 UML 2.2 Resolved closed
UML22-410 Section: 13.3.3 UML 2.1.2 UML 2.2 Resolved closed
UML22-411 Section: 12.2 UML 2.1.2 UML 2.2 Resolved closed
UML22-408 The behavior of an OpaqueExpression should itself be opaque UML 2.1.2 UML 2.2 Resolved closed
UML22-409 Section: 13.3.23 UML 2.1.2 UML 2.2 Resolved closed
UML22-402 Classifiers UML 2.1.2 UML 2.2 Resolved closed
UML22-407 Section: 7.3.35 UML 2.1.2 UML 2.2 Resolved closed
UML22-468 Packaging Issues with Stereotype Extension UML 2.1.2 UML 2.2 Resolved closed
UML22-467 inconsistency with how constraints are specified in UML and OCL UML 2.1.2 UML 2.2 Resolved closed
UML22-470 Allowing multiple Associations in a Package with the same name UML 2.1.2 UML 2.2 Resolved closed
UML22-469 P479L.14 Section "Notation" in 14.3.10 ExecutionOccurences - Typo UML 2.1.2 UML 2.2 Resolved closed
UML22-472 Figure 18.2 (which describes the contents of the Profiles package) is currently misleading UML 2.1.2 UML 2.2 Resolved closed
UML22-466 ParameterableElement as a formal template parameter UML 2.1.2 UML 2.2 Resolved closed
UML22-465 UML. Clarify relationship of Substitution and InterfaceRealization UML 2.1.2 UML 2.2 Resolved closed
UML22-462 UML2 section 8.3.1 OCL derivations on Component.provided and Component.required are still invalid UML 2.1.2 UML 2.2 Resolved closed
UML22-464 transitionkind Constraints UML 2.1.2 UML 2.2 Resolved closed
UML22-463 UML 2.2 figure 8.10 has arrows the wrong way around UML 2.1.2 UML 2.2 Resolved closed
UML22-461 UML2.2 Section 9.3.1 Presentation Options section UML 2.1.2 UML 2.2 Resolved closed
UML22-460 UML 2.2 Section 9.3.1 nested classes paragrpah in wrong chapter UML 2.1.2 UML 2.2 Resolved closed
UML22-471 Figure 2.2 contains more than four packages, description referes to four packages UML 2.1.2 UML 2.2 Resolved closed
UML22-534 In normative XMI file for the metamodel, no Associations have a name. XMI 2.0 UML 2.1 Resolved closed
UML22-533 UML 2 Super/Interactions/Constraints for create messages XMI 2.0 UML 2.1 Resolved closed
UML22-536 UML2 Infra/11.5.1/Invalid reference to Attribute class XMI 2.0 UML 2.1 Resolved closed
UML22-535 Figure 78 UML 2.0 UML 2.1.2 Resolved closed
UML22-532 Class InfrastructureLibrary::Core::Basic::Property UML 2.0 UML 2.1 Resolved closed
UML22-531 In 2.13.3, the first sub-section about ActivityGraph is not numbered UML 1.5 UML 2.1 Resolved closed
UML22-529 missing closing parenthesis UML 1.5 UML 2.1 Resolved closed
UML22-528 The Composition section does not follow the usual conventions UML 1.5 UML 2.1 Resolved closed
UML22-526 In "2.9.3.5 Instance", numbering of different well-formedness rules wrong UML 1.5 UML 2.1 Resolved closed
UML22-525 The numbering of the sub-sections in 2.7.2 is wrong UML 1.5 UML 2.1 Resolved closed
UML22-523 Associations section of element JumpHandler UML 1.5 UML 2.1 Resolved closed
UML22-522 Remove one of the dots between protectedAction and availableOutput UML 1.5 UML 2.1 Resolved closed
UML22-524 UML 2.0 infra and super Constraints Diagram of the Kernel UML 1.5 UML 2.1 Resolved closed
UML22-527 The section about Procedure does not contain any well-formedness rules UML 1.5 UML 2.1 Resolved closed
UML22-530 At the bottom of the page, the characters "antics." should be removed UML 1.5 UML 2.1 Resolved closed
UML22-549 Inconsistent use of 'Element' between MOF and UML UML 1.4.2 UML 2.1 Resolved closed
UML22-548 Missing XMI tags in spec and XMI rendition of metamodel UML 1.4.2 UML 2.1 Resolved closed
UML22-504 ptc-03-09-15/Constructs::Class superClass property UML 1.5 UML 2.1 Resolved closed
UML22-503 ptc-03-09-15/Non-navigable ends with no role names nor multiplicities UML 1.5 UML 2.1 Resolved closed
UML22-502 UML 2 Issue: Message notation UML 1.5 UML 2.1 Resolved closed
UML22-508 Why not using the UML1 activity symbol for UML2 actions? UML 1.5 UML 2.1 Resolved closed
UML22-507 Multiplicity seems to be broken - UML2 Infra & Super UML 1.5 UML 2.1 Resolved closed
UML22-499 UML 2 Super / Dependency / ownership of dependencies UML 1.5 UML 2.1 Resolved closed
UML22-498 Clarification of Information Flow semantics UML 1.5 UML 2.1 Resolved closed
UML22-497 Activity diagram problems UML 1.5 UML 2.1 Resolved closed
UML22-490 UML 2 Infra/Metamodel::Constructs/invalid OCL constraint for "opposite" UML 1.5 UML 2.1 Resolved closed
UML22-489 UML 2 Super/Metamodel::Kernel/missing merges UML 1.5 UML 2.1 Resolved closed
UML22-488 UML 2 Super/Package merge/redefinitions issue - lost association ends UML 1.5 UML 2.1 Resolved closed
UML22-487 UML 2 Super/Metamodel::Super/missing merge UML 1.5 UML 2.1 Resolved closed
UML22-493 raisedException UML 1.5 UML 2.1 Resolved closed
UML22-492 UML 2 Super / Templates / TemplateParameter not named UML 1.5 UML 2.1 Resolved closed
UML22-491 UML 2 Super/pg.75/kinds of changeability UML 1.5 UML 2.1 Resolved closed
UML22-496 Section 9.3.4 page 161, Presentation Option UML 1.5 UML 2.1 Resolved closed
UML22-495 UML 2 Super / Kernel features / cannot exclude superclass properties UML 1.5 UML 2.1 Resolved closed
UML22-494 Syntax of names UML 1.5 UML 2.1 Resolved closed
UML22-501 UML 2 Issue: definition of navigability UML 1.5 UML 2.1.2 Resolved closed
UML22-500 Use 'represent' for the relationship of a model UML 1.5 UML 2.1 Resolved closed
UML22-506 Rose Model of UML 2.0 spec UML 1.5 UML 2.1 Resolved closed
UML22-505 ptc-03-09-15/Relationships among Core packages UML 1.5 UML 2.1 Resolved closed
UML22-547 Move Comment into Basic and add Kind UML 1.4.2 UML 2.1 Resolved closed
UML22-546 Unconsistent Profile extension description (02) UML 1.4.2 UML 2.1 Resolved closed
UML22-545 Unconsistent association extension description UML 1.4.2 UML 2.1 Resolved closed
UML22-538 Section 11.7 UML 2.0 UML 2.1 Resolved closed
UML22-537 simple time model" in CommonBehavior UML 2.0 UML 2.1.2 Resolved closed
UML22-551 Problem with diagram references in Profiles section UML 1.4.2 UML 2.1 Resolved closed
UML22-550 Design principles UML 1.4.2 UML 2.1 Resolved closed
UML22-544 The specification is fond of using 'typically.' UML 2.0 UML 2.1 Resolved closed
UML22-543 TimeObservationAction and DurationObservationAction UML 2.0 UML 2.1.2 Resolved closed
UML22-541 add an interaction fragment UML 2.0 UML 2.1 Resolved closed
UML22-540 Interactions model sequences of events UML 2.0 UML 2.1.2 Resolved closed
UML22-539 Clarify example in figure 133 UML 2.0 UML 2.1 Resolved closed
UML22-542 XMI schema RAS 2.0b1 UML 2.1 Resolved closed
UML22-552 DataType attributes UML 2 Super (ptc/04-10-02) UML 1.4.2 UML 2.1 Resolved closed
UML22-486 UML 2 Super/Metamodel::Constructs/owningComment UML 1.5 UML 2.1 Resolved closed
UML22-485 Classes diagram of the Core::Constructs package UML 2.0 UML 2.1 Resolved closed
UML22-484 cross-reference missing UML 2.0 UML 2.1 Resolved closed
UML22-483 Relationship and DirectedRelationship in Core::Constructs UML 2.0 UML 2.1 Resolved closed
UML22-482 document appears to be inconsistent in how it handles concepts UML 2.0 UML 2.1 Resolved closed
UML22-477 Designates a Generalization UML 1.4 UML 2.1 Resolved closed
UML22-476 Namespace issue (UML 1.4 formal/2002-09-67, 2.5.3.26 Namespace ) UML 1.4 UML 2.1.2 Resolved closed
UML22-475 Sending a signal after a delay XMI 1.3 UML 2.1.2 Resolved closed
UML22-474 Does visibility apply to creating an destroying links? XMI 1.2 UML 2.1 Resolved closed
UML22-481 relationship should just be a cross-reference UML 1.5 UML 2.1 Resolved closed
UML22-480 formal/03-03-01 : Omission of definition of Class "Action" UML 1.5 UML 2.1 Resolved closed
UML22-473 Specify XMI parameters for the UML / XMI interchange format UML 1.3 UML 2.1 Resolved closed
UML22-479 logic upperbound is the same as the lower bound. UML 1.5 UML 2.1 Resolved closed
UML22-478 2.5.2.27 ModelElement UML 1.4 UML 2.1 Resolved closed
UML22-511 UML 2 Super / Classes / dependencies should be unidirectional UML 1.5 UML 2.1 Resolved closed
UML22-510 two classes "NamedElement UML 1.5 UML 2.1 Resolved closed
UML22-515 well-formedness rules are not numbered correctly UML 1.5 UML 2.1 Resolved closed
UML22-514 number of the figure is wrong UML 1.5 UML 2.1 Resolved closed
UML22-520 UML 1.5 table of contents XMI 2.0 UML 2.1 Resolved closed
UML22-519 In the last paragraph, the period after the word "collections" on the secon UML 1.5 UML 2.1 Resolved closed
UML22-518 In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11 UML 1.5 UML 2.1 Resolved closed
UML22-517 The multiplicity of association named subaction of type Action ill formed UML 1.5 UML 2.1 Resolved closed
UML22-521 Operations and derived attributes UML 1.5 UML 2.1 Resolved closed
UML22-509 class "InfrastructureLibrary.core.constructs.Association", UML 1.5 UML 2.1 Resolved closed
UML22-513 remove paragraph UML 1.5 UML 2.1 Resolved closed
UML22-512 UML 2 Infra/Metamodel/missing derivation indicators UML 1.5 UML 2.1.2 Resolved closed
UML22-516 multiplicity of the association named "type" of type DataType UML 1.5 UML 2.1 Resolved closed
UML22-327 Behaviors Owned by State Machines UML 2.1 UML 2.2 Resolved closed
UML22-326 Section: 12.3.41 Streaming parameters for actions UML 2.1.1 UML 2.2 Resolved closed
UML22-316 Section: 13.3.24 UML 2.1.1 UML 2.2 Resolved closed
UML22-315 Section: 15.3.14 UML 2.1.1 UML 2.2 Resolved closed
UML22-321 Wrong subsets UML 2.1 UML 2.2 Resolved closed
UML22-320 Section: 15.3.11 UML 2.1.1 UML 2.2 Resolved closed
UML22-328 information flow source and target UML 2.1 UML 2.2 Resolved closed
UML22-318 description of 14.3.24 MessageSort (from BasicInteractions) - typo UML 2.1 UML 2.2 Resolved closed
UML22-317 drawing a frame to represent Combined Fragment or an Interaction Occurrence UML 2.1 UML 2.2 Resolved closed
UML22-325 Section: 14 Interactions: Lifeline representing an actor UML 2.1.1 UML 2.2 Resolved closed
UML22-324 Section: 9 Composite Structures / Port notation UML 2.1.1 UML 2.2 Resolved closed
UML22-323 Section: 16.3.2 Classifier (from UseCases) UML 2.1.1 UML 2.2 Resolved closed
UML22-322 Section 18.3.1 UML 2.1 UML 2.2 Resolved closed
UML22-247 Section: Common Behavior - isReentrant should default to true UML 2.1.1 UML 2.2 Resolved closed
UML22-246 Actions on non-unique properties with location specified UML 2.1.1 UML 2.2 Resolved closed
UML22-243 Section: Actions - Output of read actions for no values UML 2.1.1 UML 2.2 Resolved closed
UML22-242 Section: Actions - InputPin semantics wording UML 2.1.1 UML 2.2 Resolved closed
UML22-245 Section: Activities - Output pin semantics clarification UML 2.1.1 UML 2.2 Resolved closed
UML22-244 Section: Activities - ForkNode semantics wording UML 2.1.1 UML 2.2 Resolved closed
UML22-241 Section: Activities - Preserving order of multiple tokens offered. UML 2.1.1 UML 2.2 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-375 definition of 'isCompatibleWith' for ValueSpecification UML 2.1.2 UML 2.2 Resolved closed
UML22-374 formal definitions of 'isCompatibleWith' (pages 622, 647, 649) UML 2.1.2 UML 2.2 Resolved closed
UML22-373 association 'ownedTemplateSignature' of a Classifier UML 2.1.2 UML 2.2 Resolved closed
UML22-376 term 'templatedElement' not defined UML 2.1.2 UML 2.2 Resolved closed
UML22-309 Usage of "Element::ownedMember" UML 2.1 UML 2.2 Resolved closed
UML22-308 Consistency in description of ends owned by associations UML 2.1 UML 2.2 Resolved closed
UML22-306 Section: 12.3.30 UML 2.1.1 UML 2.2 Resolved closed
UML22-312 Section: 15.3.12 UML 2.1 UML 2.2 Resolved closed
UML22-311 "PackageableElement::visibility" uses "false" as default value UML 2.1 UML 2.2 Resolved closed
UML22-302 Mismatch between Superstructure ptc/06-04-02 and XML Schema ptc/06-04-05 UML 2.1 UML 2.2 Resolved closed
UML22-301 Page: 155, 162 UML 2.1 UML 2.2 Resolved closed
UML22-305 Section: 17/17.5.7 UML 2.1.1 UML 2.2 Resolved closed
UML22-304 Port.provided:Interface UML 2.1 UML 2.2 Resolved closed
UML22-300 Section: 14.3.28 ReceiveSignalEvent (from BasicInteractions) UML 2.1 UML 2.2 Resolved closed
UML22-299 Section: 12.3.38 UML 2.1.1 UML 2.2 Resolved closed
UML22-303 UML2: Actor cannot have ownedAttributes UML 2.1 UML 2.2 Resolved closed
UML22-314 State Machines UML 2.1.1 UML 2.2 Resolved closed
UML22-313 Section: 18.3.8 UML 2.1.1 UML 2.2 Resolved closed
UML22-310 "Constraint::context" is marked as derived in the metaclass description UML 2.1 UML 2.2 Resolved closed
UML22-222 discrepancies between package dependencies and XMI file for Superstructure UML 2.1 UML 2.2 Resolved closed
UML22-224 Section: Figure 14.5 UML 2.1 UML 2.2 Resolved closed
UML22-223 Section: Appendix F UML 2.1 UML 2.2 Resolved closed
UML22-218 Section: 8.3.1 UML 2.1.1 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-225 Section: 7.3.44 UML 2.1.1 UML 2.2 Resolved closed
UML22-221 Section: 7.2 UML 2.1 UML 2.2 Resolved closed
UML22-220 Page: 64 & 112 UML 2.1.1 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-334 UML 2.2 scope statement UML 2.1 UML 2.2 Resolved closed
UML22-333 Property::isAttribute() query needs no argument UML 2.1 UML 2.2 Resolved closed
UML22-330 Section: 11.4 UML 2.1 UML 2.2 Resolved closed
UML22-329 Section: 11.4 Classifiers Diagram UML 2.1 UML 2.2 Resolved closed
UML22-340 Actor concept was indeed changed UML 2.1 UML 2.2 Resolved closed
UML22-339 Section: 13.3.3 UML 2.1 UML 2.2 Resolved closed
UML22-343 composite subsets UML 2.1 UML 2.2 Resolved closed
UML22-342 UML 2.1.2: Path names for CMOF files UML 2.1 UML 2.2 Resolved closed
UML22-332 Section: 7.3.21 figure 7.47 UML 2.1.1 UML 2.2 Resolved closed
UML22-331 Section: 7.3.21 UML 2.1.1 UML 2.2 Resolved closed
UML22-337 Section: Abstractions (02) UML 2.1 UML 2.2 Resolved closed
UML22-336 Section: Constructs UML 2.1 UML 2.2 Resolved closed
UML22-338 Namespace URI for Standard Profile(s) UML 2.1 UML 2.2 Resolved closed
UML22-335 Section: Abstractions UML 2.1 UML 2.2 Resolved closed
UML22-341 Section: 14.3.3 UML 2.1.1 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-265 Invalid redefinitions introduced into metamodel UML 2.1 UML 2.2 Resolved closed
UML22-267 Section: 13.2 UML 2.1.1 UML 2.2 Resolved closed
UML22-266 Section: 11.3.5 UML 2.1 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-270 Section: 7.3.3 UML 2.1.1 UML 2.2 Resolved closed
UML22-269 Figure 7.31 UML 2.1 UML 2.2 Resolved closed
UML22-268 Section: Annex C.1 UML 2.1.1 UML 2.2 Resolved closed
UML22-355 StructuredActivityNode [UML 2.1.1] UML 2.1.2 UML 2.2 Resolved closed
UML22-357 UML2 Issue - 'abstract' not listed in keyword Annex UML 2.1.2 UML 2.2 Resolved closed
UML22-356 UML2 issue: ProfileApplication treated as Import UML 2.1.2 UML 2.2 Resolved closed
UML22-348 context of Constraint UML 2.1.1 UML 2.2 Resolved closed
UML22-347 Section: 18.3.6 Profile (from Profiles) UML 2.1.1 UML 2.2 Resolved closed
UML22-354 Section: 7.3.33 UML 2.1.1 UML 2.2 Resolved closed
UML22-353 In section 7.3.12 Figure 7.38 UML 2.1.1 UML 2.2 Resolved closed
UML22-351 Incorrect word renders sentence meaningless: Chap. 12.3.41 UML 2.1.1 UML 2.2 Resolved closed
UML22-350 The section titled "Changes from previous UML" is not complete UML 2.1.1 UML 2.2 Resolved closed
UML22-346 first constraint for CombinedFragment UML 2.1.1 UML 2.2 Resolved closed
UML22-345 Section: 12.3.1 AcceptEventAction UML 2.1.1 UML 2.2 Resolved closed
UML22-344 RedefinableTemplateSignature UML 2.1.1 UML 2.2 Resolved closed
UML22-352 ElementImport UML 2.1.1 UML 2.2 Resolved closed
UML22-349 UML 2.1.1 - fig 7.14 UML 2.1.1 UML 2.2 Resolved closed
UML22-287 Section: 7 UML 2.1.1 UML 2.2 Resolved closed
UML22-286 Section: 15 UML 2.1 UML 2.2 Resolved closed
UML22-285 Section: 15 UML 2.0 UML 2.2 Resolved closed
UML22-295 UML 2.1 Spec, Interactions: 14.3.18 UML 2.1 UML 2.2 Resolved closed
UML22-294 UML 2.1 Spec, Interactions: 14.3.18 - InteractionUse UML 2.1 UML 2.2 Resolved closed
UML22-293 A_outgoing_source and A_incoming_target should not be bidirectional UML 2.1 UML 2.2 Resolved closed
UML22-289 UML 2 Superstructure/Components/overly stringent constraints UML 2.1 UML 2.2 Resolved closed
UML22-288 AcceptCallAction has not operation UML 2.1 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-297 UML2: notation issue UML 2.1 UML 2.2 Resolved closed
UML22-296 Section: e. g. 12.2. page 287 UML 2.0 UML 2.2 Resolved closed
UML22-292 A_end_role should not be bidirectional UML 2.1 UML 2.2 Resolved closed
UML22-298 ReplyAction::replyValue type is incorrct UML 2.1 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-205 Section: 7.3.10 UML 2.1.1 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-370 Table 8.2 must be named "Graphic paths..." instead of "Graphic nodes..." UML 2.1.1 UML 2.2 Resolved closed
UML22-369 Datatypes in UML profiles UML 2.1.2 UML 2.2 Resolved closed
UML22-364 TemplateSignature / TemplateParameter / StructuredClassifier UML 2.1.2 UML 2.2 Resolved closed
UML22-363 inability to specify ordering of messages connected to gates is problematic UML 2.1.2 UML 2.2 Resolved closed
UML22-372 The semantics of an assembly connector remains unspecified UML 2.1.2 UML 2.2 Resolved closed
UML22-371 Table 8.2 UML 2.1.1 UML 2.2 Resolved closed
UML22-362 UML2: Missing ActionOutputPin UML 2.1.2 UML 2.2 Resolved closed
UML22-361 The spec needs to clarify the isConsistentWith() method for transitions UML 2.1.2 UML 2.2 Resolved closed
UML22-367 paragraph on "deferred events" on page 552 UML 2.1.2 UML 2.2 Resolved closed
UML22-366 Section 14.3.19 UML 2.1.2 UML 2.2 Resolved closed
UML22-360 Figure 7.6 UML 2.1.2 UML 2.2 Resolved closed
UML22-359 Section: 12 UML 2.1.1 UML 2.2 Resolved closed
UML22-368 15.3.14: This paragraph refers to signal and change events UML 2.1.2 UML 2.2 Resolved closed
UML22-358 Section: 8.3.2 Connector UML 2.1.1 UML 2.2 Resolved closed
UML22-365 UML 2.1.1 Issue: Invalid association end in Figure 7.20 UML 2.1.2 UML 2.2 Resolved closed
UML22-275 Section: 17.5 UML 2.0 UML 2.2 Resolved closed
UML22-274 UML 2 state machines / entry point outgoing transitions UML 2.1 UML 2.2 Resolved closed
UML22-278 Page 60 of the pdf UML 2.1 UML 2.2 Resolved closed
UML22-277 UML2: Parameter::isException overlaps with Operation::raisedException UML 2.1 UML 2.2 Resolved closed
UML22-279 uml.xsd schema file in ptc/2006-04-05 is not correctly generated UML 2.1 UML 2.2 Resolved closed
UML22-284 UML2: ReadSelfAction with a context cannot access behavior owned attributes UML 2.1 UML 2.2 Resolved closed
UML22-283 Activity shape UML 2.0 UML 2.2 Resolved closed
UML22-273 12.3.27 ExpansionRegion UML 2.1.1 UML 2.2 Resolved closed
UML22-272 12.3.26 ExpansionNode UML 2.1.1 UML 2.2 Resolved closed
UML22-281 Meaning of Constraint visibility UML 2.1 UML 2.2 Resolved closed
UML22-280 Section: 7.3.38 UML 2.1.1 UML 2.2 Resolved closed
UML22-276 Section: 12.3.2 Action UML 2.1.1 UML 2.2 Resolved closed
UML22-271 redefined properties UML 2.1 UML 2.2 Resolved closed
UML22-282 Change references in Infra- and Superstructure to UML 2.1.1- URGENT ISSUE- UML 2.1 UML 2.2 Resolved closed
UML22-240 Section: Activities - Pin ordering semantics UML 2.1.1 UML 2.2 Resolved closed
UML22-239 Section Activities: Default weight UML 2.1.1 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-226 Section: 7 UML 2.1.1 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-232 Section: 12.3.8 UML 2.1.1 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-236 Section: 15.3.12 UML 2.1.1 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-185 Page: 338, 339 UML 2.1 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-189 Page: 625 UML 2.1 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-196 Section: 12.3.48 UML 2.1 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-140 Meaning of navigability UML 1.4.2 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-138 page 134, Chapter 11.4.1 UML 1.4.2 UML 2.2 Resolved closed
UML22-137 page 97, Chapter 10.2.2. MultiplicityElement UML 1.4.2 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-135 ObjectNode UML 1.4.2 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-134 UseCase and Actors UML 1.4.2 UML 2.2 Resolved closed
UML22-133 Page: 423 UML 2.0 UML 2.2 Resolved closed
UML22-128 Section: 10.1 Types Diagram UML 1.4.2 UML 2.2 Resolved closed
UML22-93 Figure 179 (Control nodes) UML 1.4.2 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-101 Section: Actions UML 1.4.2 UML 2.2 Resolved closed
UML22-100 CombinedFragment Loop notation UML 1.4.2 UML 2.2 Resolved closed
UML22-99 Section: 7.3.36 UML 2.0 UML 2.2 Resolved closed
UML22-98 editorial in section 12 UML 1.4.2 UML 2.2 Resolved closed
UML22-97 UML 2 Different constraints for Property in Super and Infra UML 1.4.2 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-96 rewording isuse? UML 1.4.2 UML 2.2 Resolved closed
UML22-95 reword sentence UML 1.4.2 UML 2.2 Resolved closed
UML22-94 A test cannot be empty UML 1.4.2 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-2 Starting state machine UML 1.4 UML 2.2 Resolved closed
UML22-3 Starting a state machine UML 1.4 UML 2.2 Resolved closed
UML22-5 saying {nonunique} on one end of a binary association is meaningless UML 1.5 UML 2.2 Resolved closed
UML22-4 behaviour of the shallow history state and deep history state UML 1.5 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-22 UML 2 Issue: Qualified pathnames UML 1.5 UML 2.2 Resolved closed
UML22-35 show object flow or interactions UML 1.5 UML 2.2 Resolved closed
UML22-34 UML 2 Super/Interactions/Need constraints that cover multiple Lifelines UML 1.5 UML 2.2 Resolved closed
UML22-24 ptc-03-09-15/Separate classification and generalization in Core::Basic UML 1.5 UML 2.2 Resolved closed
UML22-23 Ports in Protocol State Machines UML 1.5 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-27 UML2 Super/Kernel Classes UML 1.5 UML 2.2 Resolved closed
UML22-26 UML Superstructure FTF : isRoot property disappeared UML 1.5 UML 2.2 Resolved closed
UML22-30 Inheritance of 'Enumerations' is not detailed UML 2.0 UML 2.2 Resolved closed
UML22-29 Part subtype UML 1.5 UML 2.2 Resolved closed
UML22-31 manage simultaneity of events UML 2.0 UML 2.2 Resolved closed
UML22-25 Federated models - UML2 issue UML 1.5 UML 2.2 Resolved closed
UML22-28 UML 2.0 Kernel Operations Diagram and Features Diagram and mdl UML 1.5 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-114 Events in Sequence diagram UML 1.4.2 UML 2.2 Resolved closed
UML22-113 1. Deployment UML 1.4.2 UML 2.2 Resolved closed
UML22-116 Section: Action/Activity UML 2.0 UML 2.2 Resolved closed
UML22-115 Nested Nodes UML 1.4.2 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-120 Return message UML 1.4.2 UML 2.2 Resolved closed
UML22-121 multiplicity should not be used/shown in an communicates association UML 1.4.2 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-73 inconsistent description UML 1.4.2 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-80 UML 2 Super / Kernel / invalid restriction in isConsistentWith() UML 1.4.2 UML 2.2 Resolved closed
UML22-67 namespace UML 1.4.2 UML 2.2 Resolved closed
UML22-66 Figure 89 on page 158 is incorrect UML 1.4.2 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-70 UML2/Infra section 11.6.2/ Enumerations should not have attributes UML 1.4.2 UML 2.2 Resolved closed
UML22-79 Default values for ValueSpecification are not specified properly UML 1.4.2 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-46 isComposite inconsistency in UML 2.0 and MOF 2.0 UML 1.4.2 UML 2.2 Resolved closed
UML22-48 Section: 9.14.1 UML 2.0 UML 2.2 Resolved closed
UML22-47 should retain Comment and its associations to Element UML 1.4.2 UML 2.2 Resolved closed
UML22-42 Notation sections for TimeObservation and DurationObservation UML 2.0 UML 2.2 Resolved closed
UML22-41 completion transitions UML 1.5 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-49 Use case extension inconsistencies UML 1.4.2 UML 2.2 Resolved closed
UML22-45 AssociationClass UML 1.5 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-54 ClassifierInState not supported in UML2.0 ? UML 1.4.2 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-53 Association specialization semantics UML 1.4.2 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
UML22-7 Reentrancy 1 UML 1.5 UML 2.2 Resolved closed
UML22-6 Suspension Region UML 1.5 UML 2.2 Resolved closed
UML22-18 UML 2 Super / Missing OCL constraints UML 1.5 UML 2.2 Resolved closed
UML22-17 03-04-01 Chap 2 p. 112/Components: Different ways to wire components UML 1.5 UML 2.2 Resolved closed
UML22-20 UML 2 Issue: AssociationEnd UML 1.5 UML 2.2 Resolved closed
UML22-19 instantiations of Classifiers UML 1.5 UML 2.2 Resolved closed
UML22-15 Section 9.3.3 UML 1.5 UML 2.2 Resolved closed
UML22-14 UML 2 Super/Interactions/missing OCL constraints UML 1.5 UML 2.2 Resolved closed
UML22-10 UML 2 Super/Metamodel/redefinition and substitutability UML 1.5 UML 2.2 Resolved closed
UML22-9 Target pin notation UML 1.5 UML 2.2 Resolved closed
UML22-12 Notes versus curly braces UML 1.5 UML 2.2 Resolved closed
UML22-11 Activity OCL UML 1.5 UML 2.2 Resolved closed
UML22-16 UML2 super/ad-03-04-01/Derived attributes and associations UML 1.5 UML 2.2 Resolved closed
UML22-13 UML 2 super / Dependencies / improper subsetting? UML 1.5 UML 2.2 Resolved closed
UML22-8 State extension UML 1.5 UML 2.2 Resolved closed
UML14-559 UML 2 issue, Common Behaviors RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-558 Components / provided and required interfaces -- derived or subsets XMI 2.0 UML 1.4.2 Resolved closed
UML14-557 Feature;ModelElement UML 1.5 UML 1.4.2 Resolved closed
UML14-554 "Physical" Metamodel Package Structure (uml-rtf) XMI 1.1 UML 1.4.2 Resolved closed
UML14-556 TaggedValue in TaggedValue XMI 1.3 UML 1.4.2 Resolved closed
UML14-555 Ambiguous semantics of classifier ownerscope XMI 1.2 UML 1.4.2 Resolved closed
UML14-471 UML2 super/notation/Keywords XMI 2.0 UML 1.4.2 Resolved closed
UML14-470 Appendix B/Standard Stereotypes too heavyweight and incompletely defined XMI 2.0 UML 1.4.2 Resolved closed
UML14-480 UML 2 Super / Interactions / incorrect multiplicity for PartDecomposition XMI 2.0 UML 1.4.2 Resolved closed
UML14-479 The contents of the Interfaces package is shown in Figure 51 XMI 2.0 UML 1.4.2 Resolved closed
UML14-482 UML 2 Super / Interactions / navigability of enclosingOperation XMI 2.0 UML 1.4.2 Resolved closed
UML14-481 UML 2 Super / Dependencies / Abstraction should have an optional mapping XMI 2.0 UML 1.4.2 Resolved closed
UML14-478 UML 2 Super / Templates / subsetting templateParameter XMI 2.0 UML 1.4.2 Resolved closed
UML14-477 UML 2 Super / General / Idenitfy sections specifying run-time semantics XMI 2.0 UML 1.4.2 Resolved closed
UML14-476 UML 2 Super / Classes / XMI 2.0 UML 1.4.2 Resolved closed
UML14-473 importedMember property XMI 2.0 UML 1.4.2 Resolved closed
UML14-475 UML 2 Super / Interactions / Two typos XMI 2.0 UML 1.4.2 Resolved closed
UML14-474 missing closing bracket XMI 2.0 UML 1.4.2 Resolved closed
UML14-472 "• value : InstanceSpecification XMI 2.0 UML 1.4.2 Resolved closed
UML14-377 Corrections and improvements to glossary definitions UML 1.5 UML 1.4.2 Resolved closed
UML14-376 The name "required interface" is misleading UML 1.5 UML 1.4.2 Resolved closed
UML14-373 UML 2.0 significant typo - collaboration diagram UML 1.5 UML 1.4.2 Resolved closed
UML14-372 targetScope on StructuralFeature and AssociationEnd UML 1.5 UML 1.4.2 Resolved closed
UML14-375 Specification of parametric models UML 1.5 UML 1.4.2 Resolved closed
UML14-374 Excessive syntactic and semantic overlap between structured Classifiers UML 1.5 UML 1.4.2 Resolved closed
UML14-371 UML Superstructure: 03-08-02 / <> UML 1.5 UML 1.4.2 Resolved closed
UML14-370 ad-03-04-01 Chap 3 p. 151 Table 3/Composite structures: ComplexPort UML 1.5 UML 1.4.2 Resolved closed
UML14-369 ad-03-04-01 Chap3 p.146/Composite structures: Connected elements constraint UML 1.5 UML 1.4.2 Resolved closed
UML14-368 Chap 3 p. 142-143 Figure 3-35 /Composite structures: Port multiplicity UML 1.5 UML 1.4.2 Resolved closed
UML22-1 Semantics of firing compound transitions still appears to be circular UML 1.3 UML 2.2 Resolved closed
UML14-553 Issue 6090 correction RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-543 UML2 Super / Classes / Operation constraints XMI 2.0 UML 1.4.2 Resolved closed
UML14-542 UML2 Super / ordering of association ends XMI 2.0 UML 1.4.2 Resolved closed
UML14-541 Q re Parameter XMI 2.0 UML 1.4.2 Resolved closed
UML14-537 UML2 super/interactions XMI 2.0 UML 1.4.2 Resolved closed
UML14-536 UML 2 Super / Templates / invalid multiplicity XMI 2.0 UML 1.4.2 Resolved closed
UML14-535 UML 2 Super / Profiles / problem with name collisions XMI 2.0 UML 1.4.2 Resolved closed
UML14-548 XMI schema (02) RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-547 Question about Enumeration and EnumerationLiteral XMI 2.0 UML 1.4.2 Resolved closed
UML14-540 UML 2 Super / missing owners of concepts XMI 2.0 UML 1.4.2 Resolved closed
UML14-539 UML 2 Super / state machines / state should be a namespace XMI 2.0 UML 1.4.2 Resolved closed
UML14-538 UML 2 Super/Connector XMI 2.0 UML 1.4.2 Resolved closed
UML14-546 UML2 Super / Common Behavior / Trigger should be a named element XMI 2.0 UML 1.4.2 Resolved closed
UML14-545 UML2 Super / Use cases / navigation from subject to use case XMI 2.0 UML 1.4.2 Resolved closed
UML14-544 UML 2 Super / General / superclass pointers XMI 2.0 UML 1.4.2 Resolved closed
UML14-552 Issue 6094 correction. RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-551 UML 2 Super/Interactions/Need unattached lifelines RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-534 transition is simply never enabled XMI 2.0 UML 1.4.2 Resolved closed
UML14-533 UML Sequence diagram XMI 2.0 UML 1.4.2 Resolved closed
UML14-550 property strings on association ends RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-549 change trigger RAS 2.0b1 UML 1.4.2 Resolved closed
UML14-405 Clarify termination of asynchronous invocations UML 1.5 UML 1.4.2 Resolved closed
UML14-404 Appendix A Diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-403 Section 17 UML 1.5 UML 1.4.2 Resolved closed
UML14-396 Section 8.3.3 Realization UML 1.5 UML 1.4.2 Resolved closed
UML14-395 Section 8.3.1 Component UML 1.5 UML 1.4.2 Resolved closed
UML14-401 Section 14.4 Diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-400 Section 14.4 Diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-394 Section 8.3.1 Component UML 1.5 UML 1.4.2 Resolved closed
UML14-399 Section 14.3.14 Message UML 1.5 UML 1.4.2 Resolved closed
UML14-398 Section 10 Deployments UML 1.5 UML 1.4.2 Resolved closed
UML14-393 Section 8.1 Overview UML 1.5 UML 1.4.2 Resolved closed
UML14-402 Section 14.4 Diagrams (02) UML 1.5 UML 1.4.2 Resolved closed
UML14-397 Section 9.4 Diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-450 UML2 Super/Ports UML 1.5 UML 1.4.2 Resolved closed
UML14-449 UML2 Super/Connector UML 1.5 UML 1.4.2 Resolved closed
UML14-457 UML 2 Super / Activities / association end naming UML 1.5 UML 1.4.2 Resolved closed
UML14-456 UML 2 Super / Activities / inconsistency in representing subsetting UML 1.5 UML 1.4.2 Resolved closed
UML14-454 UML 2 Super/Activities/assocition end specialization consistency UML 1.5 UML 1.4.2 Resolved closed
UML14-452 subsettedProperty->forAll(sp | isDerivedUnion) ? UML 1.5 UML 1.4.2 Resolved closed
UML14-451 UML2 Super/Connector End UML 1.5 UML 1.4.2 Resolved closed
UML14-455 UML 2 Super/Activities/invalid multiplicity 0 UML 1.5 UML 1.4.2 Resolved closed
UML14-447 UML2 Super/Structured Classes UML 1.5 UML 1.4.2 Resolved closed
UML14-453 UML 2 Super/Activities/end naming consistency UML 1.5 UML 1.4.2 Resolved closed
UML14-448 Page 164 - there are two constraints sections for Connector UML 1.5 UML 1.4.2 Resolved closed
UML14-444 UML 2.0 Superstructure Derived Union vs. derivationExpression? UML 1.5 UML 1.4.2 Resolved closed
UML14-443 UML 2.0 Superstructure reccomendation (derived unions) UML 1.3 UML 1.4.2 Resolved closed
UML14-442 UML 2 Super / use cases / incorrect comments in notation section UML 1.5 UML 1.4.2 Resolved closed
UML14-441 Error in definition of PackageMergeKind UML 1.5 UML 1.4.2 Resolved closed
UML14-446 UML2 Super/parts UML 1.5 UML 1.4.2 Resolved closed
UML14-445 UML2 Super/Composite Classes UML 1.5 UML 1.4.2 Resolved closed
UML14-437 section 9 (State Machines) of 3rd revision UML 1.5 UML 1.4.2 Resolved closed
UML14-436 UML 2 Super/Actions/PrimitiveFunction missing properties UML 1.5 UML 1.4.2 Resolved closed
UML14-434 Time trigger notation in state machines UML 1.5 UML 1.4.2 Resolved closed
UML14-433 No way to represent "uninterpreted" actions UML 1.5 UML 1.4.2 Resolved closed
UML14-438 UML 2 Super/Actions/non-existent feature "multiplicity" UML 1.5 UML 1.4.2 Resolved closed
UML14-435 Notation when guards are used in conjunction with triggers in transitions UML 1.5 UML 1.4.2 Resolved closed
UML14-440 UML 2.0 Superstructure 3rd revision - Owner of triggers? UML 1.5 UML 1.4.2 Resolved closed
UML14-439 UML 2 Super/Action/featuringClassifier misinterpreted UML 1.5 UML 1.4.2 Resolved closed
UML14-493 UseCase - Constraint for non-circular include relation XMI 2.0 UML 1.4.2 Resolved closed
UML14-492 What level of MOF 2.0 is the metamodel for UML 2.0? XMI 2.0 UML 1.4.2 Resolved closed
UML14-484 UML 2 Super / Realize keyword-stereotype XMI 2.0 UML 1.4.2 Resolved closed
UML14-483 UML 2 Super / Classes / Properties owned by properties XMI 2.0 UML 1.4.2 Resolved closed
UML14-489 Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 367 XMI 2.0 UML 1.4.2 Resolved closed
UML14-488 Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 366 XMI 2.0 UML 1.4.2 Resolved closed
UML14-487 Inconsistent labeling of tables in Section 12.4, Activities.Diagrams p365 XMI 2.0 UML 1.4.2 Resolved closed
UML14-486 UML 2 Super / Deployments / Invalid cross-references XMI 2.0 UML 1.4.2 Resolved closed
UML14-495 UML 2 Super / use cases / incorrect table title XMI 2.0 UML 1.4.2 Resolved closed
UML14-494 UseCase - Include - Constraint for irreflexivity XMI 2.0 UML 1.4.2 Resolved closed
UML14-485 UML 2 Super / Classes / Dependency should not be abstract XMI 2.0 UML 1.4.2 Resolved closed
UML14-496 UML2 superstructur: actor XMI 2.0 UML 1.4.2 Resolved closed
UML14-491 UML 2 Super / General / specialization labeling convention XMI 2.0 UML 1.4.2 Resolved closed
UML14-490 Typo in Collaboration Diagram figure XMI 2.0 UML 1.4.2 Resolved closed
UML14-386 UML 2 Issue: Connector types UML 1.5 UML 1.4.2 Resolved closed
UML14-385 glossary UML 1.5 UML 1.4.2 Resolved closed
UML14-383 Abandon the OMGS4LMMA UML 1.5 UML 1.4.2 Resolved closed
UML14-382 14.3: StateInvariant and ExecutionOccurrence UML 1.5 UML 1.4.2 Resolved closed
UML14-381 UML 2.0 Superstructure FTF issue - Profiles UML 1.5 UML 1.4.2 Resolved closed
UML14-380 Removal of gratuitous restrictions to software applications UML 1.5 UML 1.4.2 Resolved closed
UML14-388 Section 7.3.1 ElementImport UML 1.5 UML 1.4.2 Resolved closed
UML14-387 UML 2 Issue: Include(s) and Extend(s) UML 1.5 UML 1.4.2 Resolved closed
UML14-379 Diagram Taxonomy corrections UML 1.5 UML 1.4.2 Resolved closed
UML14-378 Inconsistent use of terms "implement" and "realize" UML 1.5 UML 1.4.2 Resolved closed
UML14-392 Section 7.18 Diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-391 Section 7.15.3 Interfaces UML 1.5 UML 1.4.2 Resolved closed
UML14-384 Change 'Part' to 'Role. UML 1.5 UML 1.4.2 Resolved closed
UML14-390 Section 7.13.2 Package Merge UML 1.5 UML 1.4.2 Resolved closed
UML14-389 Section 7.3.5 PackageImport UML 1.5 UML 1.4.2 Resolved closed
UML14-412 concurrent vs. parallel ExpansionRegions UML 1.5 UML 1.4.2 Resolved closed
UML14-411 Use Case Metamodel - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-420 Operation without - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-419 Components and artifacts: Dependency problem - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-416 AcitivityEdge: weight=all vs weight=null - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-415 Large diamond for binary associations legal? - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-418 Guard conditions at fork nodes - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-417 Token flow semantics: Implicit fork and join - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-409 Multiobject in UML2 UML 1.5 UML 1.4.2 Resolved closed
UML14-408 Outputting constants UML 1.5 UML 1.4.2 Resolved closed
UML14-414 Diagrams, Diagrams, Diagrams ... UML 2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-413 Binary associations decorated with large diamonds legal? UML 1.5 UML 1.4.2 Resolved closed
UML14-407 Protocol machines do not subset state invariant UML 1.5 UML 1.4.2 Resolved closed
UML14-406 Conditions for parameter sets (02) UML 1.5 UML 1.4.2 Resolved closed
UML14-410 ActivityFinalNode and running actions - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-518 adopt a single notation to specify text strings used in the notation XMI 2.0 UML 1.4.2 Resolved closed
UML14-517 Appendix A of the superstructure spec XMI 2.0 UML 1.4.2 Resolved closed
UML14-516 UML 2 Super / Activities / Fig.192 constraint duplicated XMI 2.0 UML 1.4.2 Resolved closed
UML14-515 Ambiguous semantics of isStatic - resubmission of issue 4446 XMI 2.0 UML 1.4.2 Resolved closed
UML14-514 UML 2 Super / Interactions / Invalid subsetting for enclosingOperand XMI 2.0 UML 1.4.2 Resolved closed
UML14-513 UML 2 Super / Classes / makesVisible () operation incorrect XMI 2.0 UML 1.4.2 Resolved closed
UML14-512 Super and Infra / Kernel-Classifiers / incorrect hasVisibilityOf definition XMI 2.0 UML 1.4.2 Resolved closed
UML14-526 Operations and derived attributes XMI 2.0 UML 1.4.2 Resolved closed
UML14-525 use of stereotypes XMI 2.0 UML 1.4.2 Resolved closed
UML14-524 UML 2 Super / Appendix A / Typos XMI 2.0 UML 1.4.2 Resolved closed
UML14-523 UML 2 Super/Interactions/Alternative with all false guards XMI 2.0 UML 1.4.2 Resolved closed
UML14-522 UML 2 Super / General / Classes chapter organization XMI 2.0 UML 1.4.2 Resolved closed
UML14-521 UML 2 Super / State machines / incorrect navigation specifications XMI 2.0 UML 1.4.2 Resolved closed
UML14-520 UML 2 Super / General / consistent formatting conventions XMI 2.0 UML 1.4.2 Resolved closed
UML14-519 UML 2 Super / General / Dcoument conventions XMI 2.0 UML 1.4.2 Resolved closed
UML14-528 Activity Diagrams: Relax Traverse-to-Completion semantics XMI 2.0 UML 1.4.2 Resolved closed
UML14-530 UML2 super/Deployments/CommunicationPath XMI 2.0 UML 1.4.2 Resolved closed
UML14-529 State machines / name of transitions association end XMI 2.0 UML 1.4.2 Resolved closed
UML14-532 UML2 Super/Composite Structure XMI 2.0 UML 1.4.2 Resolved closed
UML14-531 UML 1 activities XMI 2.0 UML 1.4.2 Resolved closed
UML14-527 Composite Structures, 03-08-02.pdf XMI 2.0 UML 1.4.2 Resolved closed
UML14-431 Incorrect usage/definition of "emergence" in Common Behavior Chapter UML 1.5 UML 1.4.2 Resolved closed
UML14-427 The node "Order cancel request" that appears in figure 6-86 UML 1.5 UML 1.4.2 Resolved closed
UML14-426 GeneralizationSet Description clarification - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-429 Typos UML 1.5 UML 1.4.2 Resolved closed
UML14-428 Order cancel request UML 1.5 UML 1.4.2 Resolved closed
UML14-423 Package Extensibility <> - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-422 Dependency notation for interfaces - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-421 Inconsistency concerning VisibilityKind - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-424 does "is not instantiable" imply "isAbstract"? - UML2 Superstructure UML 1.5 UML 1.4.2 Resolved closed
UML14-425 Activity nodes and Stereotypes - UML2 Superstructure issue UML 1.5 UML 1.4.2 Resolved closed
UML14-432 Missing actual arguments in submachines states UML 1.5 UML 1.4.2 Resolved closed
UML14-430 /pages 485,487,495/mixed names for state machine diagram UML 1.5 UML 1.4.2 Resolved closed
UML14-511 Ambiguous example of a local action on a Lifeline in Figures 334, 335 XMI 2.0 UML 1.4.2 Resolved closed
UML14-510 ambiguous definition of the scope of a break CombinedFragment XMI 2.0 UML 1.4.2 Resolved closed
UML14-509 UML 2 Super/Interactions/inconsistent spelling for InteractionOperator XMI 2.0 UML 1.4.2 Resolved closed
UML14-502 Ambiguous sentence and typo in description of EventOccurence XMI 2.0 UML 1.4.2 Resolved closed
UML14-501 graphic nodes for state invariant and continuation are not always distingui XMI 2.0 UML 1.4.2 Resolved closed
UML14-498 Ambiguous semantics of isStatic XMI 2.0 UML 1.4.2 Resolved closed
UML14-497 self-activation notation in Sequence diagrams missing XMI 2.0 UML 1.4.2 Resolved closed
UML14-505 UML 2 Super/Interactions/rationale subsections not informative XMI 2.0 UML 1.4.2 Resolved closed
UML14-504 UML 2 Super/Interactions/incorrect grammar for XMI 2.0 UML 1.4.2 Resolved closed
UML14-507 word "execute" in definition of alternative CombinedFragment is ambiguous XMI 2.0 UML 1.4.2 Resolved closed
UML14-506 UML 2 Super/Interactions/Ambiguous description of state invariants XMI 2.0 UML 1.4.2 Resolved closed
UML14-500 UML 2 Super/Interactions/incorrect text and table title for Table 19 XMI 2.0 UML 1.4.2 Resolved closed
UML14-499 UML 2 Super/Interactions/incorrect text before Table 14 XMI 2.0 UML 1.4.2 Resolved closed
UML14-503 UML 2 Super/Interactions/incorrect spelling of EventOccurence XMI 2.0 UML 1.4.2 Resolved closed
UML14-508 text differs from metamodel for critical region InteractionOperator XMI 2.0 UML 1.4.2 Resolved closed
UML14-466 UML 2 Super / state machines / incorrect property redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-465 UML 2 Super / state machines / non-existent property reference UML 1.5 UML 1.4.2 Resolved closed
UML14-462 Ambuiguity in value pin evaluation UML 1.5 UML 1.4.2 Resolved closed
UML14-461 page 136, "BasicComponents", UML 1.5 UML 1.4.2 Resolved closed
UML14-468 UML 2 Super / state machines / non-existent return type UML 1.5 UML 1.4.2 Resolved closed
UML14-467 UML 2 Super / state machines / misplaced operation definition UML 1.5 UML 1.4.2 Resolved closed
UML14-458 UML 2 Super / Activities / subsetting two properties UML 1.5 UML 1.4.2 Resolved closed
UML14-460 Consistent Naming UML 1.5 UML 1.4.2 Resolved closed
UML14-464 UML 2 Super / state machines / oclIsKindOf arguments error UML 1.5 UML 1.4.2 Resolved closed
UML14-459 UML2 Super/Signal UML 1.5 UML 1.4.2 Resolved closed
UML14-463 UML 2 Super/State machines/pseudostate name consistency UML 1.5 UML 1.4.2 Resolved closed
UML14-469 UML 2 Super / use cases / invalid subsetting UML 1.5 UML 1.4.2 Resolved closed
UML14-366 ad-03-04-01 Chap 3 p. 137/Composite structures: Connector multiplicity >2 UML 1.5 UML 1.4.2 Resolved closed
UML14-365 ad-03-04-01 Chap 2 p. 118 Figure 2-15/Components: Wiring notation UML 1.5 UML 1.4.2 Resolved closed
UML14-367 ad-03-04-01 Chap 3 p. 137-138/Composite structures: Connector semantics UML 1.5 UML 1.4.2 Resolved closed
UML14-364 UML 2 Infras./Interactions/ execution occurrence should not be abstract UML 1.5 UML 1.4.2 Resolved closed
UML14-219 Typos UML 1.5 UML 1.4.2 Resolved closed
UML14-225 7.4.1 Multiplicity UML 1.5 UML 1.4.2 Resolved closed
UML14-224 7.3.1 ElementImport UML 1.5 UML 1.4.2 Resolved closed
UML14-218 Clarify that profiles can contain model libraries UML 1.5 UML 1.4.2 Resolved closed
UML14-217 Notation for anonymous instance UML 1.5 UML 1.4.2 Resolved closed
UML14-221 UML Superstructure 03-08-02: Loop node notation missing UML 1.5 UML 1.4.2 Resolved closed
UML14-220 UML Superstructure: 03-08-02 -- typos UML 1.5 UML 1.4.2 Resolved closed
UML14-215 Notation for attributes UML 1.5 UML 1.4.2 Resolved closed
UML14-214 Property string undefined UML 1.5 UML 1.4.2 Resolved closed
UML14-226 InstanceSpecification UML 1.5 UML 1.4.2 Resolved closed
UML14-216 Instantiates stereotype UML 1.5 UML 1.4.2 Resolved closed
UML14-223 No notation defined for suppressing attributes or operations UML 1.5 UML 1.4.2 Resolved closed
UML14-222 Notation mismatch for the realization dependency UML 1.5 UML 1.4.2 Resolved closed
UML14-177 Parameter set corrections 3 UML 1.5 UML 1.4.2 Resolved closed
UML14-181 Streaming UML 1.5 UML 1.4.2 Resolved closed
UML14-180 Parameter set corrections 6 UML 1.5 UML 1.4.2 Resolved closed
UML14-179 Parameter set corrections 5 UML 1.5 UML 1.4.2 Resolved closed
UML14-178 Parameter set corrections 4 UML 1.5 UML 1.4.2 Resolved closed
UML14-332 Outgoing edges of initial nodes UML 1.5 UML 1.4.2 Resolved closed
UML14-331 Port is a Property in XMI UML 1.5 UML 1.4.2 Resolved closed
UML14-326 InformationFlow realization UML 1.5 UML 1.4.2 Resolved closed
UML14-325 Dependency multiplicity to CollaborationOccurrence UML 1.5 UML 1.4.2 Resolved closed
UML14-330 Ports as properties UML 1.5 UML 1.4.2 Resolved closed
UML14-329 partWithPort without ports UML 1.5 UML 1.4.2 Resolved closed
UML14-323 Control pins UML 1.5 UML 1.4.2 Resolved closed
UML14-322 Profiles in fixed repositories UML 1.5 UML 1.4.2 Resolved closed
UML14-328 Association end names and part types UML 1.5 UML 1.4.2 Resolved closed
UML14-327 Deployment location UML 1.5 UML 1.4.2 Resolved closed
UML14-333 Guards on initial nodes UML 1.5 UML 1.4.2 Resolved closed
UML14-324 Control at joins UML 1.5 UML 1.4.2 Resolved closed
UML14-228 7.11.2 Association UML 1.5 UML 1.4.2 Resolved closed
UML14-227 7.10.1 Operation UML 1.5 UML 1.4.2 Resolved closed
UML14-234 UML 2 Super/Metamodel::IntermediateActivities/redundant merge error UML 1.5 UML 1.4.2 Resolved closed
UML14-233 BehaviorStateMachines/missing owningState end name UML 1.5 UML 1.4.2 Resolved closed
UML14-238 UML 2 Super/Metamodel::Kernel::DataTypes/missing renames UML 1.5 UML 1.4.2 Resolved closed
UML14-237 AuxiliaryConstructs::Templates::Operation/extra space UML 1.5 UML 1.4.2 Resolved closed
UML14-232 UML 2 Super/Metamodel::BasicBehaviors/package merge issue UML 1.5 UML 1.4.2 Resolved closed
UML14-231 7.15.3 Interface UML 1.5 UML 1.4.2 Resolved closed
UML14-235 UML 2 Super/Metamodel::Communications/redundant merge error UML 1.5 UML 1.4.2 Resolved closed
UML14-229 7.14.1 Abstraction UML 1.5 UML 1.4.2 Resolved closed
UML14-236 UML 2 Super/Metamodel::Nodes/redundant merge error UML 1.5 UML 1.4.2 Resolved closed
UML14-230 7.14.6 Realization UML 1.5 UML 1.4.2 Resolved closed
UML14-195 Pins on structured nodes 2 UML 1.5 UML 1.4.2 Resolved closed
UML14-194 Pins on structured nodes 1 UML 1.5 UML 1.4.2 Resolved closed
UML14-203 Action packaging UML 1.5 UML 1.4.2 Resolved closed
UML14-202 BroadcastSignalAction UML 1.5 UML 1.4.2 Resolved closed
UML14-196 Time spec text UML 1.5 UML 1.4.2 Resolved closed
UML14-200 Update actions for isUnique UML 1.5 UML 1.4.2 Resolved closed
UML14-193 ExpansionRegion UML 1.5 UML 1.4.2 Resolved closed
UML14-197 Partition semantics UML 1.5 UML 1.4.2 Resolved closed
UML14-198 Activity frame and parameter nodes 1 UML 1.5 UML 1.4.2 Resolved closed
UML14-201 actions on properties that are association ends UML 1.5 UML 1.4.2 Resolved closed
UML14-199 Activity frame and parameter nodes 2 UML 1.5 UML 1.4.2 Resolved closed
UML14-347 Flows across SAN boundaries UML 1.5 UML 1.4.2 Resolved closed
UML14-346 Initial nodes in structured actions UML 1.5 UML 1.4.2 Resolved closed
UML14-345 Parameters in Features and Common Behavior UML 1.5 UML 1.4.2 Resolved closed
UML14-342 Clarify join specs referencing control flow edges UML 1.5 UML 1.4.2 Resolved closed
UML14-341 Combining joined tokens UML 1.5 UML 1.4.2 Resolved closed
UML14-349 AcceptCallAction in SAN UML 1.5 UML 1.4.2 Resolved closed
UML14-348 Terminating a SAN UML 1.5 UML 1.4.2 Resolved closed
UML14-344 Join example UML 1.5 UML 1.4.2 Resolved closed
UML14-343 Clarify join rules UML 1.5 UML 1.4.2 Resolved closed
UML14-336 Side effects of value specifications UML 1.5 UML 1.4.2 Resolved closed
UML14-335 Activity final clarification UML 1.5 UML 1.4.2 Resolved closed
UML14-339 ReadSelfAction with no host UML 1.5 UML 1.4.2 Resolved closed
UML14-338 Decision behaviors on control tokens UML 1.5 UML 1.4.2 Resolved closed
UML14-340 Clarify ReadSelfAction in activity behaviors UML 1.5 UML 1.4.2 Resolved closed
UML14-337 Guard evaluation UML 1.5 UML 1.4.2 Resolved closed
UML14-334 Caption typo UML 1.5 UML 1.4.2 Resolved closed
UML14-291 Confusion regarding XMI for use of stereotypes UML 1.5 UML 1.4.2 Resolved closed
UML14-290 Actors that are outside and inside the system UML 1.5 UML 1.4.2 Resolved closed
UML14-289 UML2 super/pgs.17 + 598/"topLevel" UML 1.5 UML 1.4.2 Resolved closed
UML14-288 Actor UML 1.5 UML 1.4.2 Resolved closed
UML14-287 Multiplicity of Regions owning Transitions UML 1.5 UML 1.4.2 Resolved closed
UML14-286 State list UML 1.5 UML 1.4.2 Resolved closed
UML14-285 UML 2.0 serious layout problems with activity diagrams UML 1.5 UML 1.4.2 Resolved closed
UML14-284 Stereotypes for Actions UML 1.5 UML 1.4.2 Resolved closed
UML14-283 UML Superstructure: 03-08-02 / Typos UML 1.5 UML 1.4.2 Resolved closed
UML14-282 UML 2 Super/Compliance points/confusing and redundant UML 1.5 UML 1.4.2 Resolved closed
UML14-281 UML 2 Super/pg.81/semantics of subsetting-specialization-redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-280 UML 2 Super/pg.379/anyTrigger clarifications UML 1.5 UML 1.4.2 Resolved closed
UML14-279 UML 2 Super/pg. 556/notation for template binding inconsistency UML 1.5 UML 1.4.2 Resolved closed
UML14-278 UML 2 Super/pg. 471/choice pseudostate notation UML 1.5 UML 1.4.2 Resolved closed
UML14-277 UML 2 Super/pg.471/unclear terminate state semantics UML 1.5 UML 1.4.2 Resolved closed
UML14-276 UML 2 Super/pg.519/multiplicity semantics of use case associations UML 1.5 UML 1.4.2 Resolved closed
UML14-295 Question about InterruptibleActivityRegion UML 1.5 UML 1.4.2 Resolved closed
UML14-294 fig 141 p205 and 7.13.2 p101 / just what sort of relationship is < UML 1.5 UML 1.4.2 Resolved closed
UML14-293 Metamodel for applying a stereotype UML 1.5 UML 1.4.2 Resolved closed
UML14-292 Association not affecting ends UML 1.5 UML 1.4.2 Resolved closed
UML14-275 UML 2 Super/pg.427/missing notation description for lifelines UML 1.5 UML 1.4.2 Resolved closed
UML14-274 UML 2 Super/pg.429/incorrect constraint for Message UML 1.5 UML 1.4.2 Resolved closed
UML14-273 UML 2 Super/pg.416/incorrect multiplicities for event occurrence UML 1.5 UML 1.4.2 Resolved closed
UML14-272 UML 2 Super/pg.395/multiple meaning of exception UML 1.5 UML 1.4.2 Resolved closed
UML14-271 UML 2 Super/pg.235/missing semantics of destroy action UML 1.5 UML 1.4.2 Resolved closed
UML14-270 UML 2 Super/pg.130/incorrect stereotype name UML 1.5 UML 1.4.2 Resolved closed
UML14-267 UML 2 Super/pg.109/Permission redundant UML 1.5 UML 1.4.2 Resolved closed
UML14-265 UML 2 Super/pg.64/Classifier redefinition notation UML 1.5 UML 1.4.2 Resolved closed
UML14-266 UML 2 Super/pg.95/attributes in data types clarification UML 1.5 UML 1.4.2 Resolved closed
UML14-268 UML 2 Super/pg.99/misnamed "packageMerge" attribute UML 1.5 UML 1.4.2 Resolved closed
UML14-269 UML 2 Super/pg.130/missing notation explanation UML 1.5 UML 1.4.2 Resolved closed
UML14-264 UML 2 Super/pg.79/underlined operation syntax missing UML 1.5 UML 1.4.2 Resolved closed
UML14-312 PackageMerge (from Kernel) UML 1.5 UML 1.4.2 Resolved closed
UML14-311 Sequence diagram conditions on Message arrows UML 1.5 UML 1.4.2 Resolved closed
UML14-319 UML2 Super/Instances UML 1.5 UML 1.4.2 Resolved closed
UML14-318 UML2 Super/Ports UML 1.5 UML 1.4.2 Resolved closed
UML14-310 Recommendation for InteractionOccurrences UML 1.5 UML 1.4.2 Resolved closed
UML14-309 UML 2 Super / Interactions / No way to model reply messages UML 1.5 UML 1.4.2 Resolved closed
UML14-321 description of Component on page 137 UML 1.5 UML 1.4.2 Resolved closed
UML14-320 Figure 61 UML 1.5 UML 1.4.2 Resolved closed
UML14-313 UML2.super (or infra)/Profiles-Stereotype (18.3.7) UML 1.5 UML 1.4.2 Resolved closed
UML14-317 UML 2 Super/Components & Deployment chapters missing OCL constraints UML 1.5 UML 1.4.2 Resolved closed
UML14-316 UML2 Super/Profiles UML 1.5 UML 1.4.2 Resolved closed
UML14-314 UML2 Super/Composite Structures UML 1.5 UML 1.4.2 Resolved closed
UML14-308 UML Superstructur 03-08-02: Notation for ConditionalNode is missing UML 1.5 UML 1.4.2 Resolved closed
UML14-315 UML2 Super/Kernel::Classifier UML 1.5 UML 1.4.2 Resolved closed
UML14-263 UML 2 Super/pg.78/missing return types syntax UML 1.5 UML 1.4.2 Resolved closed
UML14-262 UML 2 Super/pg.78/operation redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-258 UML 2 Super/Metamodel::UseCases/Extend and Include are not NamedElements UML 1.5 UML 1.4.2 Resolved closed
UML14-257 UML 2 Super/Metamodel/missing namespaces for metaclasses UML 1.5 UML 1.4.2 Resolved closed
UML14-254 UML 2 Super/Metamodel/Mis-named Manifestation class UML 1.5 UML 1.4.2 Resolved closed
UML14-253 UML 2 Super/Metamodel::Templates/missing return type UML 1.5 UML 1.4.2 Resolved closed
UML14-261 UML 2 Super/Spec/completing mandatory sections UML 1.5 UML 1.4.2 Resolved closed
UML14-252 UML 2 Super/Metamodel::CommonBehaviors/redundant class? UML 1.5 UML 1.4.2 Resolved closed
UML14-256 UML 2 Super/Metamodel/missing owners for metaclasses UML 1.5 UML 1.4.2 Resolved closed
UML14-255 UML 2 Super/Metamodel/mis-spelled implementingClassifier" UML 1.5 UML 1.4.2 Resolved closed
UML14-260 UML 2 Super/Metamodel/missing source and target for InformationFlow UML 1.5 UML 1.4.2 Resolved closed
UML14-259 ProtocolStateMachines/ProtocolStateMachine not a type of Feature UML 1.5 UML 1.4.2 Resolved closed
UML14-209 Protocol state machines are not pre/postconditions UML 1.5 UML 1.4.2 Resolved closed
UML14-212 Replace "initial value" with "default value". UML 1.5 UML 1.4.2 Resolved closed
UML14-211 TimeObservationAction can't return values UML 1.5 UML 1.4.2 Resolved closed
UML14-208 Diamond notation for merge junctions UML 1.5 UML 1.4.2 Resolved closed
UML14-207 Activity attributes on Behavior UML 1.5 UML 1.4.2 Resolved closed
UML14-213 Kernel::Classifier missing "attribute" UML 1.5 UML 1.4.2 Resolved closed
UML14-210 Interactions view of state machines/activities UML 1.5 UML 1.4.2 Resolved closed
UML14-206 Concrete Behavior UML 1.5 UML 1.4.2 Resolved closed
UML14-204 Composite structure dependent on Behavior UML 1.5 UML 1.4.2 Resolved closed
UML14-205 Complex port UML 1.5 UML 1.4.2 Resolved closed
UML14-307 UML 2 Super / Interactions / no create message UML 1.5 UML 1.4.2 Resolved closed
UML14-306 UML2 Super / Primitive Types / implementation issue UML 1.5 UML 1.4.2 Resolved closed
UML14-296 UML super/Section 2/Compliance points UML 1.5 UML 1.4.2 Resolved closed
UML14-300 Defenition of redefines????? UML 1.5 UML 1.4.2 Resolved closed
UML14-299 UML 2 super/Composite Classes/Connecting parts of parts UML 1.5 UML 1.4.2 Resolved closed
UML14-303 UML2 Super / association end naming convention UML 1.5 UML 1.4.2 Resolved closed
UML14-302 UML2 Super / Classes/ Incorrect reference to "access" UML 1.5 UML 1.4.2 Resolved closed
UML14-305 UML 2 Super / State machines-CommonBehavior / undefined owner of triggers UML 1.5 UML 1.4.2 Resolved closed
UML14-304 UML2 Super / SimpleTime package / missing multiplicities UML 1.5 UML 1.4.2 Resolved closed
UML14-298 fig236 Datastore example/Datastore should not directly linked with actions UML 1.5 UML 1.4.2 Resolved closed
UML14-297 UML 2 Super/p125 and p126/typos UML 1.5 UML 1.4.2 Resolved closed
UML14-301 What does redefines mean in package extensibility? UML 1.5 UML 1.4.2 Resolved closed
UML14-356 UML 2 Super / Interfaces / Cannot nest classes in interfaces UML 1.5 UML 1.4.2 Resolved closed
UML14-355 UML 2 Super / state machines / restriction on redefining transitions UML 1.5 UML 1.4.2 Resolved closed
UML14-352 Typo on Notation for CombinedFragment? UML 1.5 UML 1.4.2 Resolved closed
UML14-351 Visibility of a Package UML 1.5 UML 1.4.2 Resolved closed
UML14-359 UML 2 Super / Simple Time / incorrect multiplicities UML 1.5 UML 1.4.2 Resolved closed
UML14-358 UML 2 Super / Interface / missing owner of operation UML 1.5 UML 1.4.2 Resolved closed
UML14-361 UML 2 Super / Package Templates / StringExpression inconsistency UML 1.5 UML 1.4.2 Resolved closed
UML14-360 UML 2 Super / Activities / inconsistent naming UML 1.5 UML 1.4.2 Resolved closed
UML14-353 Figure 395 requires a lot more explanation UML 1.5 UML 1.4.2 Resolved closed
UML14-363 UML 2 super / Templates / parameters cannot have names UML 1.5 UML 1.4.2 Resolved closed
UML14-362 UML 2 Super / Deployments / node composition UML 1.5 UML 1.4.2 Resolved closed
UML14-350 Questions about CentralBufferNode semantic UML 1.5 UML 1.4.2 Resolved closed
UML14-354 UML 2 super / state machines / entry and exit actions cannot be redefined UML 1.5 UML 1.4.2 Resolved closed
UML14-357 UML 2 super / Activities / structured activity node contradiction UML 1.5 UML 1.4.2 Resolved closed
UML14-244 UML 2 Infra/Section 5.9/missing merge rules UML 1.5 UML 1.4.2 Resolved closed
UML14-243 UML 2 Super/Metamodel/package merge and visibility UML 1.5 UML 1.4.2 Resolved closed
UML14-247 UML 2 Super/Metamodel::BasicActivities/inGroup problem UML 1.5 UML 1.4.2 Resolved closed
UML14-246 UML 2 Super/Metamodel::StructuredClasses/erroneous association UML 1.5 UML 1.4.2 Resolved closed
UML14-245 UML 2 Super/Package Merge/redefinition rules and standard OO languages UML 1.5 UML 1.4.2 Resolved closed
UML14-241 UML 2 Super/Metamodel::Constructs/inconsistency with Kernel UML 1.5 UML 1.4.2 Resolved closed
UML14-240 UML 2 Super/Metamodel::BasicBehaviors/missing redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-250 UML 2 Super/Package Merge/missing rule for operations UML 1.5 UML 1.4.2 Resolved closed
UML14-249 UML 2 Super/Metamodel::Compliance::L3/Missing merges UML 1.5 UML 1.4.2 Resolved closed
UML14-242 UML 2 Super/Metamodel/merging of non-redefinable model elements UML 1.5 UML 1.4.2 Resolved closed
UML14-239 UML 2 Super/Metamodel::Kernel::Packages/missing redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-248 UML 2 Super/Metamodel::StructuredActivities/double redefinition UML 1.5 UML 1.4.2 Resolved closed
UML14-251 Profile/inability to attach a stereotype to an element UML 1.5 UML 1.4.2 Resolved closed
UML14-191 SendObjectAction UML 1.5 UML 1.4.2 Resolved closed
UML14-190 Clarification of insert UML 1.5 UML 1.4.2 Resolved closed
UML14-185 Colon notation for pins UML 1.5 UML 1.4.2 Resolved closed
UML14-184 Local pre/postcondition example UML 1.5 UML 1.4.2 Resolved closed
UML14-182 Parameter semantics clarification UML 1.5 UML 1.4.2 Resolved closed
UML14-192 ExceptionHandler 1 UML 1.5 UML 1.4.2 Resolved closed
UML14-189 No-token activity termination clarification UML 1.5 UML 1.4.2 Resolved closed
UML14-187 Notation for for global pre/postconditions actions UML 1.5 UML 1.4.2 Resolved closed
UML14-183 Behavior execution instances UML 1.5 UML 1.4.2 Resolved closed
UML14-188 Notation for isSynchronous UML 1.5 UML 1.4.2 Resolved closed
UML14-186 Value Pin notation UML 1.5 UML 1.4.2 Resolved closed
UML14-171 ObjectFlowEffect UML 1.5 UML 1.4.2 Resolved closed
UML14-170 Optional parameters UML 1.5 UML 1.4.2 Resolved closed
UML14-176 Parameter set corrections 2 UML 1.5 UML 1.4.2 Resolved closed
UML14-174 ObjectNode.isUnique UML 1.5 UML 1.4.2 Resolved closed
UML14-173 Reentrancy 3 UML 1.5 UML 1.4.2 Resolved closed
UML14-169 Pin multiplicity UML 1.5 UML 1.4.2 Resolved closed
UML14-175 Parameter set corrections 1 UML 1.5 UML 1.4.2 Resolved closed
UML14-172 ExecutableNode, ControlNode should be abstract UML 1.5 UML 1.4.2 Resolved closed
UML14-133 UML's use of the word "unique" for multiplicity is ambiguous UML 1.5 UML 1.4.2 Resolved closed
UML14-132 UML 2.0 Superstructure: Operation vs. Attribute notation UML 1.5 UML 1.4.2 Resolved closed
UML14-135 The description of DataType is plainly wrong in the specification UML 1.5 UML 1.4.2 Resolved closed
UML14-134 notation for shared aggregation UML 1.5 UML 1.4.2 Resolved closed
UML14-139 Question on Connectors - fig 2-17 UML 1.5 UML 1.4.2 Resolved closed
UML14-138 There appears to be a typo on page 2-148, in section 2.12.2.13 on StubState UML 1.5 UML 1.4.2 Resolved closed
UML14-137 Well-Formedness Rules for Procedure on Common Behavior Package UML 1.5 UML 1.4.2 Resolved closed
UML14-141 An error in Figure 464 UML 1.5 UML 1.4.2 Resolved closed
UML14-140 PackageableElement UML 1.5 UML 1.4.2 Resolved closed
UML14-145 Figure 63 missing notation UML 1.5 UML 1.4.2 Resolved closed
UML14-144 Interface Figure 62 uses wrong notation UML 1.5 UML 1.4.2 Resolved closed
UML14-136 Description of GeneralizationSet UML 1.5 UML 1.4.2 Resolved closed
UML14-142 Section 1.3, ElementImport semantics on page 10 of ad/2003-04-01 UML 1.5 UML 1.4.2 Resolved closed
UML14-143 Obsolete notation used in state machine - transition examples UML 1.5 UML 1.4.2 Resolved closed
UML14-55 Profile Notation UML 1.3 UML 1.4.2 Resolved closed
UML14-54 Appendix A, UML Standard Elements UML 1.3 UML 1.4.2 Resolved closed
UML14-58 Issue: Conflicting WFRs on Transition UML 1.3 UML 1.4.2 Resolved closed
UML14-57 Add Multiplicity to Parameter. UML 1.3 UML 1.4.2 Resolved closed
UML14-56 Events, signals, stimuli, etc. UML 1.3 UML 1.4.2 Resolved closed
UML14-61 Predefined datatypes XMI 1.2 UML 1.4.2 Resolved closed
UML14-60 The definition of Multiplicity in Datatypes does not list the range associa XMI 1.2 UML 1.4.2 Resolved closed
UML14-65 Component notation: logical compartments XMI 1.2 UML 1.4.2 Resolved closed
UML14-64 Exceptions do not correspond to common usage XMI 1.2 UML 1.4.2 Resolved closed
UML14-53 Clarify the origin of an Action in a Collaboration. UML 1.3 UML 1.4.2 Resolved closed
UML14-59 Ambiguous semantics of classifier targetscope XMI 1.2 UML 1.4.2 Resolved closed
UML14-63 Event => Event Specification XMI 1.2 UML 1.4.2 Resolved closed
UML14-62 The text and OCL of rule #5 for Method do not say the same thing. XMI 1.2 UML 1.4.2 Resolved closed
UML14-37 Another State machine issue XMI 1.1 UML 1.4.2 Resolved closed
UML14-36 Data Types Misplaced in the "Physical" Metamodel (uml-rtf) XMI 1.1 UML 1.4.2 Resolved closed
UML14-30 Inheritance violation in "Auxiliary Elements" XMI 1.0 UML 1.4.2 Resolved closed
UML14-33 class EnumerationLiteral issue XMI 1.0 UML 1.4.2 Resolved closed
UML14-35 Operations and Constraints Missing from "Physical" Metamodels XMI 1.1 UML 1.4.2 Resolved closed
UML14-31 Incomplete Inheritance Specification XMI 1.0 UML 1.4.2 Resolved closed
UML14-32 Datatypes: Expression XMI 1.0 UML 1.4.2 Resolved closed
UML14-34 Interfaces on Nodes XMI 1.0 UML 1.4.2 Resolved closed
UML14-38 UML RTF 1.4 Issue: Dynamic concurrency arguments XMI 1.1 UML 1.4.2 Resolved closed
UML14-39 UML RTF 1.4 Issue: Parallel action iteration XMI 1.1 UML 1.4.2 Resolved closed
UML14-168 Pin/parameter matching 4 UML 1.5 UML 1.4.2 Resolved closed
UML14-167 Pin/parameter matching 3 UML 1.5 UML 1.4.2 Resolved closed
UML14-158 Weight=all UML 1.5 UML 1.4.2 Resolved closed
UML14-157 Provide notations for Loop and Conditional UML 1.5 UML 1.4.2 Resolved closed
UML14-163 Multiple outputs of object flow transformations UML 1.5 UML 1.4.2 Resolved closed
UML14-162 Keywords or properties UML 1.5 UML 1.4.2 Resolved closed
UML14-159 Tokens at fork UML 1.5 UML 1.4.2 Resolved closed
UML14-161 ExpansionRegions keywords UML 1.5 UML 1.4.2 Resolved closed
UML14-165 Pin/parameter matching 1 UML 1.5 UML 1.4.2 Resolved closed
UML14-160 ActivityFinalNode UML 1.5 UML 1.4.2 Resolved closed
UML14-166 Pin/parameter matching 2 UML 1.5 UML 1.4.2 Resolved closed
UML14-164 Pins owned twice UML 1.5 UML 1.4.2 Resolved closed
UML14-131 representation of arrays of values in an action language UML 1.5 UML 1.4.2 Resolved closed
UML14-130 2.5.2.29 Node UML 1.4 UML 1.4.2 Resolved closed
UML14-128 2.5.2.15 Dependency UML 1.4 UML 1.4.2 Resolved closed
UML14-123 2.5.2 Abstract Syntax UML 1.4 UML 1.4.2 Resolved closed
UML14-122 Section: 2.5.2.10 Classifier UML 1.4 UML 1.4.2 Resolved closed
UML14-129 2.5.2 Abstract Syntax UML 1.4 UML 1.4.2 Resolved closed
UML14-121 Designates a Generalization (02) UML 1.4 UML 1.4.2 Resolved closed
UML14-125 2.5.2.27 ModelElement UML 1.4 UML 1.4.2 Resolved closed
UML14-126 2.5.2.10 Classifier UML 1.4 UML 1.4.2 Resolved closed
UML14-124 2.5.2.16 Element UML 1.4 UML 1.4.2 Resolved closed
UML14-127 2.5.2 Abstract Syntax UML 1.4 UML 1.4.2 Resolved closed
UML14-82 UML 1.4: ClassifierRole contents problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-81 UML 1.4: Node, Artifact, Package and Model contents problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-89 Suggest that alternate syntax used in section 6.5.5 be adopted thoughout XMI 1.3 UML 1.4.2 Resolved closed
UML14-88 Invalid XMI.link.atts in UML 1.4 DTD XMI 1.3 UML 1.4.2 Resolved closed
UML14-95 UML 1.4.1 should use MOF 1.4 XMI 1.3 UML 1.4.2 Resolved closed
UML14-94 Add action for invoking an activity XMI 1.3 UML 1.4.2 Resolved closed
UML14-84 UML 1.4: Wrong target for StateMachine.top association XMI 1.3 UML 1.4.2 Resolved closed
UML14-83 UML 1.4: AttributeLink containment error XMI 1.3 UML 1.4.2 Resolved closed
UML14-87 Definitions in glossary don't conform to any standard for definitions XMI 1.3 UML 1.4.2 Resolved closed
UML14-86 Composite relationship between Event and StateMachine XMI 1.3 UML 1.4.2 Resolved closed
UML14-92 Simplify inputs/outputs of procedures XMI 1.3 UML 1.4.2 Resolved closed
UML14-91 match/correspond clarfication XMI 1.3 UML 1.4.2 Resolved closed
UML14-93 StartStateMachine clarification XMI 1.3 UML 1.4.2 Resolved closed
UML14-90 Namespace.contents XMI 1.3 UML 1.4.2 Resolved closed
UML14-85 Adding events to the class definition XMI 1.3 UML 1.4.2 Resolved closed
UML14-17 Parametrizable model elements not shown XMI 1.0 UML 1.4.2 Resolved closed
UML14-119 Inconsistency regarding guards on forks XMI 1.3 UML 1.4.2 Resolved closed
UML14-118 spelling of the word Use Case XMI 1.3 UML 1.4.2 Resolved closed
UML14-110 There is an unnecessary condition in rule 1 of the Namespace element XMI 1.3 UML 1.4.2 Resolved closed
UML14-109 Rule 6 of the Method element isn't formulated well XMI 1.3 UML 1.4.2 Resolved closed
UML14-115 There is a misprint in rule 2 of the Object element: “Stimuli” instead of “ XMI 1.3 UML 1.4.2 Resolved closed
UML14-114 There are misprints with numeration of rules of the Instance element XMI 1.3 UML 1.4.2 Resolved closed
UML14-112 there is something wrong with rule 3 of the Trace element XMI 1.3 UML 1.4.2 Resolved closed
UML14-120 The first sentence is not consistent with figure 2-9 on page 2-17 XMI 1.3 UML 1.4.2 Resolved closed
UML14-113 Wrong alphabetical order: DataValue section should be before DestroyAction XMI 1.3 UML 1.4.2 Resolved closed
UML14-111 Add rule to Namespace element XMI 1.3 UML 1.4.2 Resolved closed
UML14-116 There is a misprint in rule 1 of the SubsystemInstance element XMI 1.3 UML 1.4.2 Resolved closed
UML14-117 font sizes XMI 1.3 UML 1.4.2 Resolved closed
UML14-69 Using or implementing an interface of a Subsystem UML 1.4 UML 1.4.2 Resolved closed
UML14-68 XML attribute "isPolymorphic" does not exist in UML 1.3 or UML 1.4 XMI DTD UML 1.4 UML 1.4.2 Resolved closed
UML14-67 Optimize Instance data values XMI 1.2 UML 1.4.2 Resolved closed
UML14-66 Component notation: showing delegation of messages XMI 1.2 UML 1.4.2 Resolved closed
UML14-75 UML 1.4: State containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-74 UML 1.4: Action problem in Collaborations XMI 1.3 UML 1.4.2 Resolved closed
UML14-80 UML 1.4: Event containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-79 UML 1.4: Stimulus containment XMI 1.3 UML 1.4.2 Resolved closed
UML14-77 UML 1.4: Transition containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-76 UML 1.4: ExtensionPoint containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-78 UML 1.4: Feature containment problem XMI 1.3 UML 1.4.2 Resolved closed
UML14-72 Compliance to the UML" pp xxxi -- Editorial? UML 1.4 UML 1.4.2 Resolved closed
UML14-71 Nameclash in UML 1.4 UML 1.4 UML 1.4.2 Resolved closed
UML14-70 Using OCL at the meta-model level UML 1.4 UML 1.4.2 Resolved closed
UML14-73 UML 1.4: Action containment error XMI 1.3 UML 1.4.2 Resolved closed
UML14-19 Guard in current metamodel can be replaced by Constraint with stereotype XMI 1.0 UML 1.4.2 Resolved closed
UML14-18 Need for notation for dealing with evolution of UML models XMI 1.0 UML 1.4.2 Resolved closed
UML14-25 Missing OCL XMI 1.0 UML 1.4.2 Resolved closed
UML14-24 OCL needs to be added XMI 1.0 UML 1.4.2 Resolved closed
UML14-26 ElementOwnership XMI 1.0 UML 1.4.2 Resolved closed
UML14-28 extension to the notation for a transition XMI 1.0 UML 1.4.2 Resolved closed
UML14-23 Page 19 semantic doc. name XMI 1.0 UML 1.4.2 Resolved closed
UML14-22 UML 1.1.section 4.2:editorial XMI 1.0 UML 1.4.2 Resolved closed
UML14-27 User-defined symbols for tagged values and properties XMI 1.0 UML 1.4.2 Resolved closed
UML14-29 Associate a predicate with a state XMI 1.0 UML 1.4.2 Resolved closed
UML14-21 Figure 7 p. 43 of the UML semantics guide XMI 1.0 UML 1.4.2 Resolved closed
UML14-20 AssociationEnd needs ownerScope XMI 1.0 UML 1.4.2 Resolved closed
UML14-151 running a “Check Model” in Rose you get the following errors UML 1.5 UML 1.4.2 Resolved closed
UML14-154 Clarify wording on executable activity nodes UML 1.5 UML 1.4.2 Resolved closed
UML14-153 Outgoing edges from input pins UML 1.5 UML 1.4.2 Resolved closed
UML14-150 UML2 super/pg. 580/Stereotype typo UML 1.5 UML 1.4.2 Resolved closed
UML14-149 UML2 super/pg.470/entry and exit points for composite states UML 1.5 UML 1.4.2 Resolved closed
UML14-148 Multiplicities diagram in section 7.4 UML 1.5 UML 1.4.2 Resolved closed
UML14-156 Action should be concrete UML 1.5 UML 1.4.2 Resolved closed
UML14-155 Edge constraint for control nodes UML 1.5 UML 1.4.2 Resolved closed
UML14-146 Strange notation in Figure UML 1.5 UML 1.4.2 Resolved closed
UML14-152 Variable and Pin multiplicity UML 1.5 UML 1.4.2 Resolved closed
UML14-147 No Glossary in 03-08-02 UML 1.5 UML 1.4.2 Resolved closed
UML14-100 Initial state for composite states - OCL example and missing constraint XMI 1.3 UML 1.4.2 Resolved closed
UML14-99 UML 1.4 - Partition relates to nothing XMI 1.3 UML 1.4.2 Resolved closed
UML14-104 In v1.4, section 3.84.1 the paragraph on semantics XMI 1.3 UML 1.4.2 Resolved closed
UML14-103 Section 2.13.4.3 XMI 1.3 UML 1.4.2 Resolved closed
UML14-101 UML Issue - Inconsistency between UML 1.3 XMI and DTD XMI 1.3 UML 1.4.2 Resolved closed
UML14-107 Section number duplicated XMI 1.3 UML 1.4.2 Resolved closed
UML14-106 Section 3.90.2.2 XMI 1.3 UML 1.4.2 Resolved closed
UML14-97 Well-formedness rules 4 and 6 on 2.12.3.4 PseudoState XMI 1.3 UML 1.4.2 Resolved closed
UML14-96 A_context_raisedSignal XMI 1.3 UML 1.4.2 Resolved closed
UML14-102 How does one indicate the target object for a CallState XMI 1.3 UML 1.4.2 Resolved closed
UML14-105 parameters of object flow states XMI 1.3 UML 1.4.2 Resolved closed
UML14-98 Well-formedness rules for 2.12.3.8 XMI 1.3 UML 1.4.2 Resolved closed
UML14-108 Swap rule 2 and rule 3 of the Binding element XMI 1.3 UML 1.4.2 Resolved closed
UML14-49 MOF rules should disallow certain composition relationships UML 1.3 UML 1.4.2 Resolved closed
UML14-48 Notation for inherited associations UML 1.3 UML 1.4.2 Resolved closed
UML14-52 Conflicting constraint between ActivityGraph and StateMachine. UML 1.3 UML 1.4.2 Resolved closed
UML14-51 Attributes obsolete in UML 1.3 UML 1.3 UML 1.4.2 Resolved closed
UML14-50 Interface of an object UML 1.3 UML 1.4.2 Resolved closed
UML14-46 Why is a StateMachine's top a State instead of a CompositeState? UML 1.3 UML 1.4.2 Resolved closed
UML14-45 UML 1.4 RTF Issue: Multiple languages for uninterpreted strings XMI 1.1 UML 1.4.2 Resolved closed
UML14-42 Efficient diagrammatic notation for Collaboration Specifications XMI 1.1 UML 1.4.2 Resolved closed
UML14-41 Statemachine/state as Namespace XMI 1.1 UML 1.4.2 Resolved closed
UML14-40 UML RTF 1.4 Issue: Missing notation mapping for association in composite XMI 1.1 UML 1.4.2 Resolved closed
UML14-47 Document 99-06-08 - UML Spec UML 1.3 UML 1.4.2 Resolved closed
UML14-43 ClassifierRoles should be independent of specific underlying base Classifi XMI 1.1 UML 1.4.2 Resolved closed
UML14-44 UML 1.4 issue: Top state in activity graphs XMI 1.1 UML 1.4.2 Resolved closed
UML14-7 issues and bugs on the UML 1.4 Draft UML 1.3 UML 1.4 Resolved closed
UML14-6 class TaggedValuewill two association-ends with the same name "stereotype" UML 1.3 UML 1.4 Resolved closed
UML14-14 Figure 2-15 of the uml 1.4 spec UML 1.3 UML 1.4 Resolved closed
UML14-13 page 2-163, the statemachine semantics escription UML 1.3 UML 1.4 Resolved closed
UML14-16 isPolymorphic is never in a diagram UML 1.3 UML 1.4 Resolved closed
UML14-15 well-formedness rule for Package is missing inUML 1.4 UML 1.3 UML 1.4 Resolved closed
UML14-10 it's => its on page 3-150. UML 1.3 UML 1.4 Resolved closed
UML14-9 Wf 2 for AssociationEnd UML 1.3 UML 1.4 Resolved closed
UML14-8 2.9.2 Abstract Syntax UML 1.3 UML 1.4 Resolved closed
UML14-12 Notation example typo in Fig. 3-99 UML 1.3 UML 1.4 Resolved closed
UML14-11 The glossary entry "call" should be "call state". UML 1.3 UML 1.4 Resolved closed
UML14-3 elimination of the Association Class TemplateParameter UML 1.3 UML 1.4 Resolved closed
UML14-2 2) Page 2-49, additional operation #7 for Classifier UML 1.3 UML 1.4 Resolved closed
UML14-5 Remove uses of multiple inheritance from UML meta model UML 1.3 UML 1.4 Resolved closed
UML14-4 Who owns a Comment? UML 1.3 UML 1.4 Resolved closed
UML14-1 Page 2-47, well-formedness rule #2 for Classifier UML 1.3 UML 1.4 Resolved closed
UML15-10 UML2 super/Profile/Unconsistent association extension description UML 1.4.2 UML 1.5 Resolved closed
UML15-12 Correction to 7336 UML 1.4.2 UML 1.5 Resolved closed
UML15-11 Dependency errors UML 1.4.2 UML 1.5 Resolved closed
UML15-9 UML2 super/Profile/Unconsistent Profile extension description UML 1.4.2 UML 1.5 Resolved closed
UML15-8 UML 2 Super Issue re: DI compliance UML 1.4.2 UML 1.5 Resolved closed
UML15-7 UML 2/ Inconsistencies in usage of package merge UML 1.4.2 UML 1.5 Resolved closed
UML15-6 UML 2 Super/Infra: no notation for "isQuery" characteristic of Operations UML 1.4.2 UML 1.5 Resolved closed
UML15-5 UML 2 Super/Infra: return type of an operation UML 1.4.2 UML 1.5 Resolved closed
UML15-4 Need to documetn diagramming conventions for association ends UML 1.4.2 UML 1.5 Resolved closed
UML15-3 Remove Package Templates? Feedback requested UML 1.4.2 UML 1.5 Resolved closed
UML15-2 UML 2 Super/state machines/Maximum one region UML 1.4.2 UML 1.5 Resolved closed
UML15-1 StartOwnedBehaviorAction UML 1.4.2 UML 1.5 Resolved closed
UML2-1 super AND infra / Section 11.8.3 of Infra, 7.13.2 of Super / PackageMerge UML 1.5 UML 2.0 Resolved closed

Issues Descriptions

UML 2 Issue: isUnique

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

    PROBLEM STATEMENT
    "When one or more ends of the association have isUnique=false, it is
    possible to have several links associating the same set of instances."
    (Superstructure, p. 81)

    As Pierre-Alain Muller demonstrated in an informal conversation with Bran
    Selic during a lunch in San Francisco in the last UML Conference (I also was
    taking part in that conversation), isUnique must have the same value for all
    ends in an association.

    This has implications, for example, for the property strings that can be
    placed near the association ends (

    {ordered}

    ,

    {bag}

    ,

    {seq}

    ). According to the
    table in Superstructure, p. 92, if one end is a Set or an OrderedSet, then
    the opposite end must be a Set or an OrderedSet, too; and if one end is a
    Bag or a Sequence, then the opposite end must be a Bag or a Sequence, too.

    PROPOSED SOLUTION
    Explain this in the Spec.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This topic is discussed in detail in DraganMilicev’s paper at http://afrodita.rcub.bg.ac.rs/ dmilicev/pubs/mdd/
    trumlassoc.zip. In the paper he proposes that the collection that provides the value of a property that is an
    association end is derived from the links that instantiate the association as modified by the isUnique marking.
    So, even if there are two links targeting an instance in the extent of the association, if the property is
    marked as unique then there will only be one instance in the collection. This interpretation allows there to
    be associations with mixed unique/nonunique ends. After discussion the FTF thinks that this interpretation
    is in fact the intended interpretation of the current spec, and should be clarified as such.
    Milicev also points out that AssociationClasses make the identity of links visible in the semantics, and in
    contrast to what the spec currently suggests, it is possible to have multiple instances of an AssociationClass
    that associate the same set of end instances, regardless of the uniqueness marking of the ends. This is
    clarified in the current resolution. Milicev proposes adding an isUnique property to AssociationClass to
    give the power to rule out such multiple instances. Adding such a property is outside the scope of UML 2.5.
    This resolution also clarifies that property subsetting applies to property values coerced to sets. Currently
    nonunique B could be marked as subsetting unique A. If B contains the same value twice and A contains it
    once, then that should be legal, even though the size of the value of B is larger than that of A.
    The resolution also accounts for the use of qualifiers, makes some improvements to the definition and use
    of the term “cardinality”, and corrects the semantics of CreateLinkAction to correspond to the clarified
    definition.
    This also resolves issue 5977.

  • Updated: Mon, 9 Jan 2023 12:17 GMT

New proposal for conjugate types for ports

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

    The SoaML submission team understands the concerns about making UML extensions at all, let alone introducing changes too high up in the hierarchy that might introduce additional unintended inheritance issues. But we are also reluctant to submit to the UPMS RFP without addressing the need to distinguish services from requests, and without addressing the usability issues that result from the need to create separate types for both ends of a connector.

    Recall that the problem is that ports appear on two ends of a connector. It is very often the case that consumers and providers can agree on the provided and required interfaces, and the interaction characteristics (protocol) and should therefore be able to use the same type to highlight that agreement. This is not possible with UML2. Ports don't have direction to indicate whether the owning component is using the operations or providing them. So users are forced to create "conjugate" types that flip the usage and realization relationships between classes and interfaces. This is especially troubling for the common simple case where the port is typed by a simple Interface.

    There have been a number of suggestions about how to solve this problem, many involving how ports define provided and required interfaces, and whether they need a type at all. We wanted to solve this problem without making a lot of changes to UML that may have other unintended consequences, or not sufficiently address the issues. So our updated proposal is very simple, and hopefully not something that would in any way effect future changes to UML2.

    We suggest the addition of a new Enumeration called PortDirection which has literals incoming and outgoing. Then add a new ownedAttribute to Port called direction: PortDirection = incoming. This would provide a direction on port that would be used to change how the provided and required interfaces are calculated. If direction=incoming, then the provided interfaces are those realized by the port's type and the required interfaces are those used by its type. If the direction is outgoing, the calculations are reversed: the provided interfaces are those used by the port's type, and the required interfaces are those realized by the port's type. Therefore, provided and required interfaces are calculated from the point of view of the owner of the port based on whether they are using the capabilities defined by the port's type, or providing them.

    This does not provide similar capabilities for things like connected collaborationRole Properties in a Collaboration. These properties are of course not Ports, and there is no specific specialization of Property (i.e., Role) that distinguishes the usage of a property in a collaboration that could specify the direction from other usages of property where direction is not relevant. We will miss that capability, but don't want to expand the scope of the UML change to address it at this time. Rather we'll wait and see if the UML2 RTF comes up with a more general solution that is also consistent with port direction.

    Is this acceptable?

  • Reported: UML 2.1.2 — Thu, 6 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue addresses a widely-recognized fundamental omission from UML. As such it is worthy of making an exception to normal RTF policy of not introducing new features to the language, particularly since the new feature is purely additive.
    But the wording of the proposed change in the UPMS specification is somewhat problematical. Notably the idea of "incoming" and "outgoing" does not sit very comfortably with the notion of a Port being essentially a bidirectional intermediary entity which specifies both provided and required interfaces.
    For this reason we propose a slightly different solution with similar semantic consequences: the introduction of a Boolean property isConjugated (default false) to the metaclass Port. When isConjugated is false, the semantics of Port are what they are today. When isConjugated is true, the calculation of provided and required interfaces from the Port's type is inverted.
    This works nicely when the type of a port is a single interface, because it allows a port that provides one interface and a port that requires one interface both to be simply represented. Today, a simple port that requires one interface has to be typed by a class that requires that interface, which is cumbersome and inconvenient.
    However, the idea of conjugating a port renders problematical the concept of instantiating the port type in the form of "interaction points" as currently specified in chapter 9. Instantiating the same type at both ends of an asymmetrical link is clearly unlikely to work. From a SoaML point of view, the port type represents a protocol, which will be applied differently at each end of the link depending on the sense of isConjugated. Therefore from a UML point of view we propose to delete all text that suggests direct instantiation of port types.
    Finally, it is important for modelers to be able to distinguish conjugated ports in the notation, so we introduce suitable new notation.

  • Updated: Mon, 1 Apr 2019 08:04 GMT

Semantics of Ports in Components and CompositeStructures are incompatible

  • Key: UML22-459
  • Legacy Issue Number: 13140
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In chapter 9 (CompositeStructures) the semantics of ports are given strictly in terms of instantiating the owning classifier and instantiating the ports as “interaction point objects” typed by the type of the port. Yet in chapter 8 (Components), a Component (through its IsIndirectlyInstantiated attribute) may not be instantiated at run time, in which case the inherited semantics of ports and port types cannot apply. The sentence from 8.3.1 “The required and provided interfaces may optionally be organized through ports, these enable the definition of named sets of provided and required interfaces that are typically (but not always) addressed at run-time” clearly states that ports are a way to organize required and provided interfaces of a component at design time, yet this is contradictory to the notion that the provided and required interfaces of a port are derived from its type which is instantiated as interaction point objects. These contradictions should be resolved

  • Reported: UML 2.1.2 — Thu, 4 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Much of this issue is resolved by 13080, in which the text about the interaction point objects being instances of the port types has been deleted.
    The remainder of the issue can be handled by some explanatory text as proposed below.

  • Updated: Mon, 1 Apr 2019 08:04 GMT

Explanation of Observation notation

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

    UML2 Superstructure 2.1.1:Interactions

    In Fig 14.26 there are various time annotations shown which relate to the Simple Time package.

    The notation sections for TimeObservation and DurationObservation read thus:

    TimeObservation: “A time observation is often denoted by a straight line attached to a model element. The observation is given a name that is shown close to the unattached end of the line.”

    DurationObservation: “A duration observation is often denoted by a straight line attached to a model element. The observation is given a name that is shown close to the unattached end of the line.”

    However the notations in Figure 14.26 look like this:

    TimeObservation: “t=now”

    DurationObservation: “d=duration”

    I don’t see how the example notation is consistent with the notation descriptions

  • Reported: UML 2.1 — Fri, 27 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 17841

  • Updated: Sun, 11 Jun 2017 11:36 GMT

Location: 9.6.4 Notation p 128: Confusing indentation

  • Key: UML25-345
  • Legacy Issue Number: 17930
  • Status: closed  
  • Source: Dassault Systemes ( Mr. James L. Logan III)
  • Summary:

    The line

    "[<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’ [‘:’ [<return-type>] [‘[‘ <multiplicity> ‘]’] [‘

    {‘ <oper-property> [‘,’ <oper-property>]* ‘}

    ’]]"

    has its terms defined under the bulleted list after the first un-indented "where", except for "<parameter-list>".

    That term is defined one level too deep, where "<oper-property>" terms are defined.

    The bullet found there (i.e., "<parameter-list> is a list of Parameters of the Operation in the following format:") should become the third bullet in the first level of bullets.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:
  • Updated: Sun, 28 Feb 2016 17:14 GMT

Repr. of applied stereotypes and their properties insufficiently described

  • Key: UML22-307
  • Legacy Issue Number: 10826
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    Issue: UML representation of applied stereotypes and their properties is
    insufficiently described
    Nature: Clarification
    Severity: Significant
    Summary:

    1. In the Superstructure spec 2.1.1, it is not clearly stated what an
    applied stereotype is in terms of metaclasses. The spec talks
    about "instance of a Stereotype", but it fails to sufficiently
    clarify the so-called meta-level crossing, i.e. the fact that an
    instance of the Stereotype metaclass at the same time is a new
    metaclass. The description of Stereotype says in the Semantics
    section: "An instance “S” of Stereotype is a kind of (meta) class
    ". I think "a kind of" as well as putting "(meta)" in parenthesis
    is confusing. I suggest to say: "An instance “S” of the Stereotype
    metaclass is itself a metaclass.". Also, the text currently does
    not describe what the name and particularly the namespace of the
    metaclass corresponding to the instance of the Stereotype
    metaclass would be. Because of the current uncertainty, UML tools
    have taken different (and incompatible) interpretations on how an
    applied stereotype should be represented in terms of UML
    metaclasses.

    2. It is not described currently how any property values of applied
    stereotypes are represented in terms of instances of metaclasses.
    When looking at generated XMI, it seems that this representation
    is quite different from Property metaclass instances that are
    ownedAttributes of user model classes, so there is a need to
    clarify this. Because of the current uncertainty, UML tools have
    taken different (and incompatible) interpretations on how these
    values should be represented in terms of UML

  • Reported: UML 2.1 — Sat, 17 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 11 May 2015 23:49 GMT

Typo in Interaction Example

  • Key: UML25-684
  • Legacy Issue Number: 19348
  • Status: closed  
  • Source: gmail.com ( Pete Karousos)
  • Summary:

    v=mymsg(w=myout:16):96

    // this is a reply message assigning the return value 69 to 'v'

    Either the 96 needs to be a 69 or vice-versa but the two should match.

  • Reported: UML 2.5b1 — Sun, 20 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Thu, 12 Mar 2015 01: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

Type vs. Implementastion class

  • Key: UML14-1046
  • Legacy Issue Number: 1582
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Suggested rewording for the paragraph in Section 5.9.1, pg 35 of the
    Notation Guide, version 1.1. Complete suggested text is availabl ein the issues"s archive

  • Reported: UML 1.1 — Fri, 26 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 04:16 GMT

Section: 7.3.10/Associations

  • Key: UML22-1380
  • Legacy Issue Number: 12383
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    Please explain why constrainedElement has to be an ordered set and not a set

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Duplicate or Merged — UML 2.2
  • Disposition Summary:

    Duplicate

  • Updated: Sun, 8 Mar 2015 21:04 GMT

Compliance ambiguity

  • Key: UML14-1045
  • Legacy Issue Number: 4466
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

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

  • Reported: UML 1.3 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Duplicate or Merged — UML 1.4
  • Disposition Summary:

    duplicate

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

Wording od OCL definition

  • Key: UML14-1044
  • Legacy Issue Number: 2339
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Some minor flaws in the wording of the OCL description within OMG-UML
    version 1.3, Jan. 1999:

      • Section 6.4.4, Type Conformance, page 6-222

    "Each type conforms to its supertype."

    The word "its" implies that there is only one. It would be better if this
    said: "Each type conforms to each of its supertypes."

      • Section 6.4.5, Re-typing or Casting, page 6-223

    "If the actual type of the object is not equal to the type to which
    it is re-typed, the expression is undefined."

  • Reported: UML 1.1 — Tue, 19 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 18:22 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

section 8.3.2, a "Connector"

  • Key: UML2-4
  • Legacy Issue Number: 7851
  • Status: closed  
  • Source: MargullSoft ( Dr. Ulrich Margull)
  • Summary:

    In section 8.3.2, a "Connector" is defined as either a "delegate" or an "assembly" connector. The definition is based on "required port" resp. "provided port". However, these terms are not defined in the document; furthermore, they do not make sense at all. In section 9.3.11, a port is defined to have "provided" and/or "required" interfaces, which are well-defined. However, in the whole document is no definition for a "provided port" or "required port". From my understanding, such a thing does not make sense at all. A port is a point of interaction, and the terms "provided/required port" are non-sense. Please, provide a definition of "provided port" and "required port", or remove the corresponding sections. I hope I could help You with Your great work, Yours, Dr. Uli Margull PS: I came across this topic when working for the AutoSAR standard (car manufacturer and OEMs). They have the same unclear usage of "provided port" and "required port", and looking into the UML standard 2.0 did not help me to resolve this issue.

  • Reported: UML 1.5 — Wed, 13 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.0
  • 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:13 GMT

Property.association

  • Key: UML2-3
  • Legacy Issue Number: 7642
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 12 of the 040814 rev has the association from Property to
    Association as derived:

    memberEnd /association
    Property ----------------------------------> Association

    and it wasn't derived in the FAS. The issues cited are: 6243 and 7365,
    but neither mentions the change. The derivation is not explained in the
    association entry on Property. Is this a metamodel typo?

  • Reported: UML 1.5 — Thu, 19 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 15:13 GMT

Activity Diagrams: Relax Traverse-to-Completion semantics

  • Key: UML2-2
  • Legacy Issue Number: 7222
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In my interpretation of the current semantics description of UML
    activity diagrams (Superstructure, Final Adopted Spec, ptc/03-08-02) I
    have identified some rather unpleasant properties of the current
    traverse-to-completion semantics. The full discussion together with
    examples can be found in the attached .pdf, the short of it is:

    *) the current semantics does not prevent deadlocks (as it is
    supposed to do)

    *) it rather induces deadlocks even in simple examples (e.g. examples
    in the UML spec are wrong)

    *) it makes for a very complex evaluation and introduces unnecessary
    synchronization in the (basically asynchronous) notation of Activiy
    Diagrams.

    I therefore propose to relax the semantics of token flow by dropping
    the constraint that every Action has to accept all tokens for all its
    input pins at once. MergeNodes should als be able to buffer tokens
    until their conditions are satisfied. This is a more natural way of
    interpreting ADs.

  • Reported: UML 1.5 — Mon, 5 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.0
  • Disposition Summary:

    This is a duplicate of issue 7221

  • Updated: Sun, 8 Mar 2015 15:13 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

No unambiguous way in UML 2.4 to serialize StructuredActivityNode

  • Key: UML241-47
  • Legacy Issue Number: 16232
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    We just recently had discussion with Ed about an issue with Activity::node and Activity::group. Both are composite non-derived properties and it causes problems with all StructuredActivityNodes, which are ActivityNodes and ActivityGroups at the same time.
    MagicDraw or Eclipse implementation of UML does not allow to own the same element in two composites , even if owner element is the same.
    Does XMI support that?

    So, ExpansionRegion or any other StructuredActivityNode appears in Activity::group only.

    fUML spec/engine expects to find them in Activity::node , as all owned nodes should be there.

    Any suggestions? Don't you think we should fix that somehow?

  • Reported: UML 2.4 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 15:04 GMT

navigation only possible to generalization but not to specializations of elements

  • Key: UML24-152
  • Legacy Issue Number: 15766
  • Status: closed  
  • Source: Vienna University of Economics and Business ( Bernhard Hoisl)
  • Summary:

    I am using the UML specification very often and I am navigating a lot through specific elements. One thing which bothers me most is that I can only hop to the generalization of elements but not to their specializations. For example for activity diagrams, if I go to Section 12.3.16 CentralBufferNode (p. 360) I know that it is a sub-type of an ObjectNode. But now I have no chance to see which sub-types of a CentralBufferNode exists (e.g. a DataStoreNode). So I have to navigate back to p. 312 to see the dependencies of a CentralBufferNode.

    In my point of view would displaying not only generalizations but also specializations of elements directly at an element's description be a great advantage to the readability of the specification.

    It would certainly be a great surplus to me, maybe others have thought the same way, too.

  • Reported: UML 2.3 — Tue, 19 Oct 2010 04:00 GMT
  • Disposition: Closed; No Change — UML 2.4
  • Disposition Summary:

    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:04 GMT

Japan Superstructure PAS Ballot Comments - comment 9

  • Key: UML23-155
  • Legacy Issue Number: 14266
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GE All the heading should be numbered as subclauses or itemized as lists.

    Follow Directives part2 5.2.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    There are a large number of Bold headings in the document, which are not numbered. Many OMG specs do this, and it was used in ISO/IEC 19501. Changing the spec at this time to give each one of these Bold headers their own subsection number. e.g., sec 7.3.3 has sub headings "Generalization" , "Description" etc., is too large too large an undertaking to incorporate into version 2.3 of UML.
    Revised Text:

    Disposition: Closed, No Change

  • Updated: Sun, 8 Mar 2015 15:01 GMT

New proposal for conjugate types for ports

  • Key: UML23-154
  • Legacy Issue Number: 13081
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The SoaML submission team understands the concerns about making UML extensions at all, let alone introducing changes too high up in the hierarchy that might introduce additional unintended inheritance issues. But we are also reluctant to submit to the UPMS RFP without addressing the need to distinguish services from requests, and without addressing the usability issues that result from the need to create separate types for both ends of a connector.

    Recall that the problem is that ports appear on two ends of a connector. It is very often the case that consumers and providers can agree on the provided and required interfaces, and the interaction characteristics (protocol) and should therefore be able to use the same type to highlight that agreement. This is not possible with UML2. Ports don't have direction to indicate whether the owning component is using the operations or providing them. So users are forced to create "conjugate" types that flip the usage and realization relationships between classes and interfaces. This is especially troubling for the common simple case where the port is typed by a simple Interface.

    There have been a number of suggestions about how to solve this problem, many involving how ports define provided and required interfaces, and whether they need a type at all. We wanted to solve this problem without making a lot of changes to UML that may have other unintended consequences, or not sufficiently address the issues. So our updated proposal is very simple, and hopefully not something that would in any way effect future changes to UML2.

    We suggest the addition of a new Enumeration called PortDirection which has literals incoming and outgoing. Then add a new ownedAttribute to Port called direction: PortDirection = incoming. This would provide a direction on port that would be used to change how the provided and required interfaces are calculated. If direction=incoming, then the provided interfaces are those realized by the port's type and the required interfaces are those used by its type. If the direction is outgoing, the calculations are reversed: the provided interfaces are those used by the port's type, and the required interfaces are those realized by the port's type. Therefore, provided and required interfaces are calculated from the point of view of the owner of the port based on whether they are using the capabilities defined by the port's type, or providing them.

    This does not provide similar capabilities for things like connected collaborationRole Properties in a Collaboration. These properties are of course not Ports, and there is no specific specialization of Property (i.e., Role) that distinguishes the usage of a property in a collaboration that could specify the direction from other usages of property where direction is not relevant. We will miss that capability, but don't want to expand the scope of the UML change to address it at this time. Rather we'll wait and see if the UML2 RTF comes up with a more general solution that is also consistent with port direction.

    Is this acceptable?

  • Reported: UML 2.1.2 — Thu, 6 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This is a verbatim duplicate of 13080 which I will address soon.

    Revised Text:
    None.

    Disposition: Duplicate.

  • Updated: Sun, 8 Mar 2015 15:01 GMT

proper content for Figure 13.8

  • Key: UML23-153
  • Legacy Issue Number: 10083
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The UML 2.1 spec, 06-04-02, has lost the proper content for Figure 13.8, by duplicating the content of Figure 13.7 again and labeling it 13.8. See pages 442 and 443 as paginated in the pdf, 462 and 463 as paginated by Adobe in onscreen display.

    above from the 06-04-02 spec, below from the 05-07-04 spec

  • Reported: UML 2.1 — Wed, 2 Aug 2006 04:00 GMT
  • Disposition: Closed; No Change — UML 2.3
  • Disposition Summary:

    Discussion: Fixed in an earlier release; also duplicate of10469 Revised Text: N/A Disposition: Closed, no change

  • Updated: Sun, 8 Mar 2015 15:01 GMT

Section: 15.3.8

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

    It is unclear what exactly is a path in the context of history pseudo states. For example: "Entry actions of states entered on the path to the state represented by a shallow history are performed." Is it the shortest path? The history path? What happens if the history state isn't the first state after the initial state, but located somewhere in the middle of the statemachine?

  • Reported: UML 2.1.1 — Wed, 2 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • 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 last active state being reactivated (as though a transition is drawn directly from H to the last active substate). It in no way implies a state-by-state approach. (e.g. a path from the initial state to the last active state)

  • Updated: Sun, 8 Mar 2015 15:01 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

7.3.41 Parameter (from Kernel, AssociationClasses)"

  • Key: UML22-1375
  • Legacy Issue Number: 9338
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Please note however, that (as far as I can see) Parameter only occurs in Kernel, NOT in AssociationClasses. So the correct statement would be "Parameter (from Kernel). This might bear a relation to the already existing FTF issue 8117.

  • Reported: UML 2.1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This is an exact duplicate of issue 9337 Revised Text: N/A Disposition: Duplicate

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

UML 2 Super / Activities / missing subsets

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

    Activity::node, Activity::edge, and Activity::group do not subset Namespace::ownedMember, but they should

  • Reported: UML 2.1 — Wed, 30 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

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

Profiles::ObjectNode has wrong default multiplicity

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

    ObjectNode::upper should have default multiplicity unbounded (“*”) in order of object nodes to be multi-valued by default.

    Recommendation:

    Redefine inherited MultiplicityElement::upper to have default “*” in ObjectNode.

  • Reported: UML 2.1 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.1
  • Disposition Summary:

    See issue 8454 for disposition

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

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

InformationFlow cannot have an Activity as source or target

  • Key: UML25-682
  • Legacy Issue Number: 18743
  • Status: closed  
  • Source: Alstom Transport ( Wagner Schalch Mendes)
  • Summary:

    In section 17.2.1 InformationFlow (from InformationFlows) page 621, the first constraint states that "The sources and targets of the information flow can only be one of the following kind: Actor, Node, UseCase, Artifact,
    Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition and InstanceSpecification except
    when its classifier is a relationship (i.e., it represents a link).". Why can't an Activity be the source or target of an InformationFlow, since it is a Behavior as an Use Case?

  • Reported: UML 2.4.1 — Wed, 29 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5b1
  • Disposition Summary:

    duplicate, issue closed

  • Updated: Sat, 7 Mar 2015 04:44 GMT

Location p 162 ParameterSet associationends: Exceptions and parametersets

  • Key: UML25-681
  • Legacy Issue Number: 17928
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Throughout the specification, output parametersets are described as if all (non-optional) output parameters within the set are output. This is not exactly right if the parameterset contains an exception. Please describe how that works and make the document consistent

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5b1
  • Disposition Summary:

    duplicate of 17927, withdrawn and closed

  • Updated: Sat, 7 Mar 2015 04:44 GMT

LiteralReal has no default value. It would make sense if it had a value of 0 as for LiteralInteger.

  • Key: UML23-147
  • Legacy Issue Number: 19293
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    LiteralReal has no default value. It would make sense if it had a value of 0 as for LiteralInteger.

  • Reported: UML 2.2 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Sat, 7 Mar 2015 03:22 GMT

Change syntax of certain pre-defined operations

  • Key: UML14-1043
  • Legacy Issue Number: 3390
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    In the OCL specification, properties of Collections like
    'isEmpty', 'size' etc. are defined as operations with
    pre and postconditions. Their syntax however is as attributes without
    parenthesis.
    For consistency it would be more clear to change the sytax of these
    predefined operations to use parenthesis as in 'isEmpty()', just
    like other operations.
    The same holds for operations on other predefined types like
    Real::floor.

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:21 GMT

Package symbol as a polygon

  • Key: UML14-1042
  • Legacy Issue Number: 2298
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A package is a grouping of model elements. However, the rectangular shape of the package symbol makes it difficult to group model elements that have fixed geometrical position to each-other. In other words, the rectangular package shape often requires to change geometrical position of the model elements that belong to the group. It is almost impossible to use the rectangular package to show overlapping groups of model elements.

    For example, it is difficult to use the rectangular package symbol to show the objects in a class diagram that belong to a certain thread, or to show the use cases in a use case diagram that belong to a certain group.

  • Reported: UML 1.1 — Thu, 7 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

  • Updated: Sat, 7 Mar 2015 03:21 GMT

Profile::references_same_metamodel

  • Key: UML25-680
  • Legacy Issue Number: 18809
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Profile::references_same_metamodel

    All elements imported either as metaclassReferences or through metamodelReferences are members of the same base reference metamodel.

    inv: metamodelReference.importedPackage.elementImport.importedElement.allOwningPackages()->

    union(metaclassReference.importedElement.allOwningPackages() )->notEmpty()

    Surely this OCL is completely wrong, both in its own right, and especially in the light of the following statement:

    Where both a metaclassReference and a metamodelReference are present on a profile, the latter is ignored and only the specific metaclasses are available.

    I’m thinking the right logic would be something like this:

    (metaClassReference->isEmpty() implies metamodelReference.importedPackage.member->forAll( m1, m2 | m1.allOwningPackages().intersection(m2.allOwningPackages())->notEmpty()))

    and

    metaclassReference.importedElement->forAll( m1, m2 | m1.allOwningPackages().intersection(m2.allOwningPackages())->notEmpty())

  • Reported: UML 2.5b1 — Thu, 11 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    duplicate of issue 18806 --withdrawn

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Operation::isConsistentWith()

  • Key: UML25-679
  • Legacy Issue Number: 18807
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    I’m working on a couple of issues that complain that the rules for consistency of operation redefinition are incomplete.

    The current definition is this:

    isConsistentWith(redefinee : RedefinableElement) : Boolean

    {redefines RedefinableElement::isConsistentWith()}

    A redefining operation is consistent with a redefined operation if it has the same number of owned parameters, and the type of each owned parameter conforms to the type of the corresponding redefined parameter. The query isConsistentWith() specifies, for any two Operations in a context in which redefinition is possible, whether redefinition would be consistent in the sense of maintaining type covariance. Other senses of consistency may be required, for example to determine consistency in the sense of contravariance. Users may define alternative queries under names different from isConsistentWith(), as for example, users may define a query named isContravariantWith().

    pre: redefinee.isRedefinitionContextValid(self) body: redefinee.oclIsKindOf(Operation) and

    let op : Operation = redefinee.oclAsType(Operation) in

    self.ownedParameter->size() = op.ownedParameter->size() and

    Sequence

    {1..self.ownedParameter->size()}

    ->

    forAll(i |op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at.type))

    What this does is impose a “covariant” (Eiffel-like) rule on redefinition, but only on the types of the parameters – it ignores their names, multiplicity, ordering, uniqueness, direction or effect.

    The wording that says “Users may define alternative queries under names different from isConsistentWith(),…” seems to me to be unhelpful and misleading. Firstly, UML tools don’t normally provide such capabilities, and secondly, even if they did, the original consistency rule would still be enforced.

    There seem to me to be three approaches here.

    1. Tighten up the covariance rules so that they somehow incorporate names, multiplicity, uniqueness, ordering, direction etc.

    2. Recognize that “in” parameters should be contravariant, “out” and “return” parameters should be covariant, and “inout” parameters invariant, and make rules correspond to that.

    3. Relax things and make them more extensible. Remove the constraints on parameter replacement altogether (simply requiring the same number of parameters) and leave it to profiles to constrain what operation redefinition might mean.

    Given that the semantics for Operation says “In UML, such rules for type conformance are intentionally not specified” (although that sentence was inexplicably truncated between beta and betafinal) I think option 3 is correct.

    Any comments?

  • Reported: UML 2.5b1 — Wed, 10 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    issue withdrawn

  • Updated: Fri, 6 Mar 2015 23:16 GMT

redefined states

  • Key: UML25-678
  • Legacy Issue Number: 18757
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    It seems State can be redefined in one subtype only, because of multiplicity 0..1 of the "state" (see picture attached).
    That prevents from creating two subclasses which redefine the same states in inherited statemachine and our customers report the problem.

    I think, multiplicity should be changed to *.

  • Reported: UML 2.5b1 — Wed, 5 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    duplicate of issue 18455, issue closed by submitter

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Event pools for passive objects?

  • Key: UML25-677
  • Legacy Issue Number: 18755
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There does not seem to be any constraint that prevents a passive object from owning an event pool. Perhaps this is by design, but, if so, it is not clear how such an event pool is serviced. It looks like this should be clarified or perhaps a constraint preventing passive objects from having event pools should be introduced.

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    duplicate of issue 18754

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Who owns MessageEnds?

  • Key: UML25-676
  • Legacy Issue Number: 18734
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    I noticed that the metamodel does not have any composite property typed by MessageEnd.

    Since MessageEnd is a kind of NamedElement, we'd need to have a composite association to subset A_ownedMember_namespace.

  • Reported: UML 2.5b1 — Mon, 27 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 23:16 GMT

UML 2 chapter 17: template model cannot represent templates parameterized by value types

  • Key: UML23-146
  • Legacy Issue Number: 14062
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In a programming language such as C# it is common, in libraries, to create parameterized types such as List<T>, which can be instantiated as List<Foo>, List<int>, List<Boolean> and so on.

    UML templates do not permit the equivalent. The parameters of a template are all instantiated objects of a known concrete metaclass. It is therefore invalid for parameter-kind (17.5.4) to be an abstract metaclass, such as Type. This is a very severe limitation when trying to map UML to C#.

  • Reported: UML 2.2 — Wed, 8 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    withdrawn by submitter, duplicate of 13257

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Instance modeling does not take into account stereotypes properties

  • Key: UML22-1372
  • Legacy Issue Number: 13291
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    Instance modeling does not take into account stereotypes properties.

    Assume I create a stereotype that I apply to some Class. That stereotype adds some property 'p' of type String. Now assume I create an InstanceSpecification of that Class.

    I believe I should be able to create a slot for 'p' and assign some value to it.

    Constraint [1] on InstanceSpecification 7.3.22 seems to restrict this since it mentions that the defining feature of each slot is a structural feature of a classifier of the instance specification. The properties contributed by the stereotype are not considered to be part of the features of the Classifier (assuming the stereotype is applied to a Classifier)

  • Reported: UML 2.1.2 — Thu, 15 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    withdrawn by issue submitter

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Comments owned by Packages (02)

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

    Typo in attributes section of comment: Remove "multiplicity" (red colored) before attribute body.

  • Reported: UML 2.1.2 — Wed, 5 Mar 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Comments owned by Packages

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

    A package can only own packageable elements. That excludes comments. On the other hand the comment definition states: A comment can be owned by any element. That's a contradiction. It's important that packages can own comments. Therefore I propose a change of the package to allow the ownership of comments.

  • Reported: UML 2.1.2 — Wed, 5 Mar 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion: It is not quite right to say that “a package can only own packageable elements”. The spec only says that “Only packageable elements can be owned members of a package.” That is, any owned members of the package, considered as a namespace, must be packageable elements – this is because packagedMember subsets the ownedMember derived union and no other property of Package does. However, a namespace (and hence a package) can have owned elements that are not owned members. In fact, all elements inherit the Element::ownedComment property that subsets ownedElement. For a namespace, ownedMember also subsets ownedElement, so the owned elements of a namespace (and hence a package) include both comments and namespace members. However, while a comment can thus owned by a namespace, it cannot be a member of the namespace, since it is not a named element. Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

section 15.3.14 Transition :: Constraints

  • Key: UML22-1369
  • Legacy Issue Number: 12170
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    Using the 07-02-03, 2.1.1 spec we have the following (pg 569 or 583/732 section 15.3.14 Transition :: Constraints)):
    [5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and ((source.kind <> #junction) and (source.kind <> #join) and (source.kind <> #initial)) implies trigger->isEmpty()

    This OCL erroneously states that Junctions and Joins may have outgoing transitions with triggers. As far as I understand, one can never be waiting in a junction point or join for a trigger to occur.

  • Reported: UML 2.1.2 — Tue, 8 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Regarding the quote on p128

  • Key: UML22-1368
  • Legacy Issue Number: 12169
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    In the 2.1.1 specification (070205):

    Regarding the quote on p128:
    "All redefinitions should be made explicit with the use of a

    {redefines <x>}

    property string. Matching features in subclasses without an explicit redefinition result in a redefinition that need not be shown in the notation. Redefinition prevents inheritance of a redefined element into the redefinition context thereby making the name of the redefined element available for reuse, either for the redefining element, or for some other."

    I interpret the following quote from the UML 2.1.1 spec to mean that when a subclass includes a property whose name is equal to a property in one of its general classes, then it should be treated as a redefinition even if there is no explicit redefinition between those properties in the model.
    This should be clarified in the spec. It is unclear and also includes at least one spelling mistake. Alternatively, we should ban implicit redefinitions and flag them as simple name conflicts.

    Two features of the same kind defined in a class and a superclass (i.e., they are both either structural features or behavioral features) does indeed imply a redefinition and, therefore, must conform to the compatibility constraint on redefinitions.

  • Reported: UML 2.1.2 — Tue, 8 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Section: Composite Structures/Abstract syntax

  • Key: UML22-1367
  • Legacy Issue Number: 11503
  • Status: closed  
  • Source: Validas AG ( Reinhard Jeschull)
  • Summary:

    There are two diagrams on page 164, 'Connectors' and 'The port metaclass'. The two diagrams are the same. Can you send me the picture of this diagram via e-mail? We need it to create a metamodel.

  • Reported: UML 2.1.1 — Thu, 20 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    withdrawn, this issue has been resolved

  • Updated: Fri, 6 Mar 2015 22:56 GMT

ptc/06-01-02:14.3.14, Notation

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

    The following notation expression isn’t well formed:

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

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

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Events

  • Key: UML22-1365
  • Legacy Issue Number: 7638
  • Status: closed  
  • Source: International Business Machines ( Mr. Anders Ek)
  • Summary:

    'Events' are in the spec defined as standalone entities using the Trigger concept. In the ongoing FTF work the relation between event and trigger has been changed and the has been changed and there is now an Event metaclass in addition to the existing Trigger class. However, the text does not give any syntax for defining standalone event and it does not state how to refer to an event defined as a standalone entity from e.g. a transition in a statemachine. So two issues: - syntax for standalone events - clarification the how to refer to standalone events from e.g. transitions in statemachines

  • Reported: UML 2.0 — Wed, 18 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Additional events for Interactions

  • Key: UML22-1364
  • Legacy Issue Number: 7637
  • Status: closed  
  • Source: X-Change Technologies and Klocwork ( Joaquin Miller for Nikolai Mansurov)
  • Summary:

    13.1 Overview of Common Behaviors discusses occurrences for which there is no event in the FAS nor in the proposed revision to triggers and events. Figure 307 - Invocation Domain Model shows occurrences of Start, Termination, Trigger, and CallBehavior events. Figure 308 - Communication Domain Model shows occurrences of Invocation and Receiving events. Figure 309 - Domain Model Showing Request Kinds shows occurrences of SendInvocation, CallInvocation, SendRequest, Call Request, Signal, and Call events. These are all discussed in the text, along with occurrences of change and time events. Figure 310 - Domain Model Showing Event Kinds shows two supertypes, for occurrences of Trigger and Spontaneous events. These are discussed in the text. It appears that AcceptEventAction is intended to be used with any kind of event and AcceptCallAction for call request events. [by Nick:] I've reviewed the effects of the proposed alignment of event/occurences/types on Interactions. I believe, the proposed changes will have a very positive effect indeed on making the new Interactions a better part of the overall spec. I would suggest that we do add more subtypes of event in order to have a better match with Interactions: - CreationEvent - DestructionEvent - ExecutionStartEvent - ExecutionFinishEvent

  • Reported: UML 2.0 — Mon, 16 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Incorrect constraints on Pin and ObjectFlow On Pin

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

    Incorrect constraints on Pin and ObjectFlow On Pin, the constraint isUnique = false introduced by 6090 should be on ObjectNode, and the text should be "Object nodes are not unique typed elements." On ObjectFlow, Constraints (BasicActivities), rule 1 still reflects the time when pins were connected to actions by flows, during the submission process. It should be "Object flows may not have actions at either end.".

  • Reported: UML 2.0 — Sun, 15 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

resolution to issue 6093 removed too much constraint

  • Key: UML22-1362
  • Legacy Issue Number: 7630
  • Status: closed  
  • Source: Universitaet Paderborn ( Jan Hendrik Hausmann)
  • Summary:

    The resolution to issue 6093 removed too much constraint. It should be left in place for decision, merge, and fork nodes.

  • Reported: UML 2.0 — Fri, 13 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 9.3.12

  • Key: UML22-1361
  • Legacy Issue Number: 7613
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The notation for property states that the namestring is as in the Classes chapter, and gives an incorrect chapter number. In fact, the namestring syntax is as for properties in the Classes chapter in Kernel, which should be properly referenced.

  • Reported: UML 2.0 — Tue, 3 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 7.11.4

  • Key: UML22-1360
  • Legacy Issue Number: 7612
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The notation for properties is missing in this section. There are references to examples in other sections, and the notation for AssociationClasses is defined, but there is no notation described for properties

  • Reported: UML 2.0 — Tue, 3 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This is a duplicate of issue 7575

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Notation for property has gone missing

  • Key: UML22-1359
  • Legacy Issue Number: 7575
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Notation for property has gone missing. The notation section merely states that "Notation for properties is defined separately for their use as attributes and association ends." Give details for the namestring for attributes and for association ends (the latter is currently described in the association section, but probably should be described in the property section and referenced from the association section). The namestring for attributes is not described at all.

  • Reported: UML 2.0 — Sun, 11 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

ReadSelfAction

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

    ReadSelfAction has the contraint: "The action must be contained in an activity that has a host classifier." On the other hand the semantic section describes: "For activities that have no other context object, the activity itself is the context object." A ReadSelfAction within an activity without a host classifier object returns the activity object. So the constraint is superfluous.

  • Reported: UML 2.0 — Mon, 5 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This was fixed as part of 7319.

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Attribute scope is of type StructuredActivityNode instead of StructuredActi

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

    Attribute scope is of type StructuredActivityNode instead of StructuredActivityGroup

  • Reported: UML 2.0 — Thu, 1 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 12.3.16

  • Key: UML22-1356
  • Legacy Issue Number: 7440
  • Status: closed  
  • Source: Silogic ( Yves BERNARD)
  • Summary:

    It's explicitly stated that all tokens within the protected node terminate if an exception isn't caught but nothing is written about how the tokens are managed when the exception is caught, except that the handler will provide the output pins of the protected node. It could implicitly indicate that tokens in the protected nodes are terminated in this case also. Is it right ? Is a semantic variation point?

  • Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

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

  • Key: UML22-1355
  • Legacy Issue Number: 7439
  • Status: closed  
  • Source: Silogic ( Yves BERNARD)
  • Summary:

    Constraints #3, #4 and #5, p304: the descriptions of the constraints aren't clear and seem inconsistent. What are the "edges" we're talking about? From inside the activity, inputs pins have only outgoing edges, but from the outside they 've only incomming edges, haven't they?

  • Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 12.3.3

  • Key: UML22-1354
  • Legacy Issue Number: 7438
  • Status: closed  
  • Source: Silogic ( Yves BERNARD)
  • Summary:

    To review the paragraph just below the figure 207. It seems that the name in the circle symbole is the connector name rather that the edge name (cf. figure 208). A connector name is unique, what isn't the case of an edge name.

  • Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Figure 205, p292:

  • Key: UML22-1353
  • Legacy Issue Number: 7437
  • Status: closed  
  • Source: Silogic ( Yves BERNARD)
  • Summary:

    Figure 205, p292: several guard conditions seem misplaced in this diagram (e.g. one of the [else], [cannot reproduce probem], ...)

  • Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Figure 51, p106

  • Key: UML22-1350
  • Legacy Issue Number: 7432
  • Status: closed  
  • Source: Silogic ( Yves BERNARD)
  • Summary:

    Figure 51, p106: the multiplicity of the "mapping" role in the association between Abstraction and Expression isn't consistent with the description of this association in §7.14.1, p107: "The mapping expression is optional and may be omitted...". Shouldn't it be "0..1" rather than "1"?

  • Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This was resolved by the resolution to issue 6926

  • Updated: Fri, 6 Mar 2015 22:55 GMT

ExceptionHandler

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

    ExceptionHandler - Presentation Option The connection between an ExecutableNode and an ExceptionHandler is shown by drawing a “lightning bolt” symbol. This is similar to an interrupting edge for which the same symbol is used. According to Figure 259, an option for notating an interrupting edge is a zig zag adornment on a straight line. I suggest to allow the same notation as a presentation option for the connection between an ExecutableNode and an ExceptionHandlers.

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

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

figure 175

  • Key: UML22-1352
  • Legacy Issue Number: 7436
  • Status: closed  
  • Source: Silogic ( Yves BERNARD)
  • Summary:

    the figure 175 shows a <<merge>> dependency from the IntermediateActivity package to the StructuredActivity package. This isn't consistent with the description of the IntermediateAcitvityPackage, p266.

  • Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This was resolved as part of the resolution to issue 6179 and issue 7436.

  • Updated: Fri, 6 Mar 2015 22:55 GMT

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

  • Key: UML22-1351
  • Legacy Issue Number: 7433
  • Status: closed  
  • Source: Silogic ( Yves BERNARD)
  • Summary:

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

  • Reported: UML 2.0 — Mon, 7 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This misleading example was removed by the resolution to issue 6173.

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 12.3.16 -- Typo

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

    Typo "Multiple exception handlers may may attached to the same protected node, each by its own lightning bolt." should be ("may" occuring twice) "Multiple exception handlers may be attached to the same protected node, each by its own lightning bolt."

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

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Templates, Classifier

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

    Templates, Classifier - OCL errors in constraint "Classifier::isTemplate() : Boolean; isTemplate = TemplatableElement::isTemplate() or general->exists(isTemplate())" should be "context Classifier::isTemplate() : Boolean body: – returns true, if a least one of the parent classifiers (including the current – classfier) is a template result = self.oclAsType(TemplateableElement).isTemplate() or general->exists(isTemplate())"

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

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

ProtocolConformance - inconsistency with Figure 356

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

    ProtocolConformance - inconsistency with Figure 356 On page 473 the spec says: "specificMachine: StateMachine [1] : Specifies the state machine which conforms to the general state machine." If this is correct (which would be consistent with the Description section above), then in Figure 356 +specificMachine should end in StateMachine not in ProtocolStateMachine.

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

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Can connectors co-operate?

  • Key: UML22-1341
  • Legacy Issue Number: 7418
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "A collaboration occurrence indicates a set of roles and connectors that cooperate within the classifier ..." Is it roles that cooperate, or the instances playing those roles? Can connectors co-operate, or do instances playing roles cooperate using connectors?

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

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

ParameterableElement - constraint [2] - error in OCL

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

    ParameterableElement - constraint [2] - error in OCL "ParameterableElement::isTemplateParameter() : Boolean; isTemplateParameter = parameter->notEmpty()" should be ("templateParamter" instead of parameter; general OCL 2.0 syntax) "context ParameterableElement::isTemplateParameter() : Boolean body: result = templateParameter->notEmpty()"

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

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

TemplateableElement - inconsistency

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

    TemplateableElement - inconsistency "• ownedSignature : TemplateSignature[0..1]The optional template signature specifying the formal template parameters. Subsets Element::ownedElement." The name of this association is inconsistent with Figure 427. There it is called "ownedTemplateSignature". See also OCL navigation expression in constraint [2] on the next page.

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

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

TemplateSignature - Typo

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

    TemplateSignature - Typo "• template : TemplateableElementr[1]The element that owns this template signature. Subsets Element::owner." should be (removed 'r' before multiplicity) "• template : TemplateableElement[1]The element that owns this template signature. Subsets Element::owner."

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

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

TemplateSignature - inconsistency

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

    TemplateSignature - inconsistency Section "Description" says: "A TemplateSignature may reference a set of nested template signatures to reflect the hierarchical nature of a template." There is no such association from TemplateSignature to TemplateSignature in Figure 427. I guess that this sentence is a leftover from a former iteration. Suggestion: remove this sentence.

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

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

association "implementingClassifier

  • Key: UML22-1338
  • Legacy Issue Number: 7413
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    The association "implementingClassifier: Classifier [1] References the operations owned by the Interface." The type declaration says the association connects to Classifier, the drawing says it connects to BehavioredClassifer, but the text seems to say it connects to Operations.

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

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Removed text in 9.3.3

  • Key: UML22-1340
  • Legacy Issue Number: 7417
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    This text was removed from the draft adopted text in preparing the final adopted test: "There is some tension here in that we might want to describe also non-observable or structural aspects of a classifier in a collaboration role, which would not work with an interface. Maybe there is a need for a separate role concept? This would be similar to an abstract classifier but saying that this classifier must be realized like an interface?" What gives?

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:55 GMT

${issue.summary}

  • Key: UML22-1339
  • Legacy Issue Number: 7414
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    There will not necessarily be a property implementing the classifier corresponding to the property of the interface." is likely an editorial error

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

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

PrimitiveFunction

  • Key: UML22-1337
  • Legacy Issue Number: 7405
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

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

  • Reported: UML 2.0 — Sat, 29 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

MarshallAction and UnmarshallAction

  • Key: UML22-1336
  • Legacy Issue Number: 7399
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    MarshallAction and UnmarshallAction What can we use in place of the UML 1.5 MarshallAction and UnmarshallAction actions? SendSignalAction marshalls, but AcceptEventAction doesn't

  • Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Constraint 2 of AcceptEventAction - typo

  • Key: UML22-1335
  • Legacy Issue Number: 7396
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    Constraint 2 of AcceptEventAction - typo Constraint 2 of AcceptEventAction should refer to AcceptEventAction, not AcceptCallAction.

  • Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

SAN semantics for starting and stopping

  • Key: UML22-1334
  • Legacy Issue Number: 7395
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    SAN semantics for starting and stopping The SAN semantics for starting and stopping gives only necessary conditions. It should give sufficient conditions

  • Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

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

  • Key: UML22-1333
  • Legacy Issue Number: 7394
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

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

  • Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Activities

  • Key: UML22-1332
  • Legacy Issue Number: 7393
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    Activities should be able to have variables without introducing a structured node containing all the other nodes

  • Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

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

  • Key: UML22-1331
  • Legacy Issue Number: 7378
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    p.352, section 12.3.35. The attribute Parameter.isStream is inappropriate as it creates a mechanism for activities to pass data different from the other behaviors. CommonBehavior specifies that parameters obtain data when a behavior is invoked and generate outputs when a behavior terminates. Behaviors may generate data during the execution of the behavior by signal send and receipts. There is no reason for activities not to use the same mechanism; it is no more difficult to use than the isStream mechanism introduced. Whether outputs are generated during the lifetime of a behavior or upon termination only, and whether inputs are accepted only at the beginning of an execution are properties of the action, not the parameters, and should such be treated.

  • Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:55 GMT

empty sections in activities chapter

  • Key: UML22-1330
  • Legacy Issue Number: 7377
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Throughout the activities chapter there are empty sections (i.e., sections consisting merely of a header). These sections should be removed

  • Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 22:55 GMT

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

  • Key: UML22-1329
  • Legacy Issue Number: 7376
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    p.328, Figure 245, and p.331, Figure 249. The text keeps referring to a "UML 1.5 notation" which is confusing. I believe that this section specifies a presentation option, using a "*" in the top right-hand corner of the icon. This presentation option should be explained, rather than saying, that the "UML 1.5 notation for unlimited dynamicMultiplicity" is used, as the reader will not know what that is without going to UML 1.5. Similarly, p.331 should refer to the presentation option, not to UML 1.5.

  • Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Inappropriate to reference RFP documents

  • Key: UML22-1328
  • Legacy Issue Number: 7374
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    p.290, below figure 203. It is inappropriate to reference RFP documents or any other non-standards. Just delete the reference. Also, that same paragraph contains a typo "Schedule Pat Mod Workflow" should be "Part". Also, p.299, below figure 215.

  • Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

attribute Activity.isSingleExecution

  • Key: UML22-1327
  • Legacy Issue Number: 7373
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The attribute Activity.isSingleExecution creates, for activities, something akin to what the difference is between behavior as BehavioredClassifier.classifierBehavior vs. behavior as method of a behavioral feature. In the former case, there is exactly one execution during the life of the classifier (and the behavior would accept many tokens), while in the latter there is one execution for every invocation. Activity should not confusingly add another means of doing the same thing. At minimum, it should be explained what the effect of this attribute is when dealing with classifier behavior vs. method. In particular, it is very confusing what it would mean to have a behavior that is its own context and uses a separate execution for each token. Further, the definition of the attribute: "If true, tokens from separate invocations of the activity may interact" is completely meaningless as a definition.

  • Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section 9.3.5. (ConnectableElement)

  • Key: UML22-1326
  • Legacy Issue Number: 7371
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Section 9.3.5. (ConnectableElement) speaks in the description section that a connectable element represents a set of instances that are owned by a containing classifier. However, there are connectable elements that represent instances not owned by the classifier (e.g., the ROOM "slide-in capsules") or the instances might be owned by the classifier only indirectly.

  • Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section 9.3.1

  • Key: UML22-1325
  • Legacy Issue Number: 7370
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Section 9.3.1. gives a presentation option to show the constructor for a class graphically, i.e., show an operation associated with a class which is invoked as the constructor function. However, there seems to be no means of associating that graphical depiction of a constructor to an element in the metamodel.

  • Reported: UML 2.0 — Mon, 24 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

typo

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

    Typo error, stereotype instead of tagged value in the following sentence:” Non-normative examples of standard <tagged values> stereotypes that a profile …”

  • Reported: UML 2.0 — Wed, 19 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

typo

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

    Typo error => “The deployment target owns <the> a set of deployments that target it.”

  • Reported: UML 2.0 — Wed, 19 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:55 GMT

component deployment

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

    “A component deployment is the deployment of one or more executable artifacts or artifact instances to a deployment target…” ? Why is it mandatory that an artefact has to be executable to be deployed? Is it not possible to deploy a non-executable file, like a configuration file? Even if a configurable file may be encapsulated in an executable artefact, sometime one configuration file may be used by different executable artefacts.

  • Reported: UML 2.0 — Wed, 19 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

signal

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

    As signal is a kind of message, I propose to replace “A communication path is an association that can only be defined between nodes, to model the exchange of signals and messages between them.” by “A communication path is an association that can only be defined between nodes, to model the exchange of messages between them."

  • Reported: UML 2.0 — Wed, 19 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:55 GMT

association between two Nodes

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

    A communication path is an association between two Nodes, through which Nodes are able to exchange signals and messages.” Signal is a kind of message, so I think this sentence may be simplified by: “A communication path is an association between two Nodes, through which Nodes are able to exchange signals and messages.

  • Reported: UML 2.0 — Wed, 19 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Figure 273 - Arrow direction Figure 273

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

    Figure 273 - Arrow direction Figure 273 - Arrow should point from QuoteResponses to AwardQuote, not from AwardQuote to QuoteResponses

  • Reported: UML 2.0 — Mon, 17 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This is the same issue as issue 7230.

  • Updated: Fri, 6 Mar 2015 22:55 GMT

ParameterSet - Typo

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

    ParameterSet - Typo " parameter : ParameterPin [1..*] Parameters in the parameter set." should probably be " parameter : Parameter[1..*] Parameters in the parameter set."

  • Reported: UML 2.0 — Mon, 17 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

ObjectNode

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

    ObjectNode - modelling of upperBound upperBound is currently an association to ValueSpecification. According to section Semantics, it is either a LiteralInteger or a LiteralNull. The later is used to specify an unbound upper limit. There are two problems with this approach: - one could define a upper bound of "5" which is legal LiteralInteger, but probably not a desired value for the maximum number of tokens allowed in the node - if upperBound had multiplicity "0..1", one would not have to encode the absence of a specific upper bound with a LiteralNull I suggest to model "upperBound" in analogy to "upperBound" from MultiplicityElement (see 7.4.1). - replace upperBound with upperBoundValue as follows: upperBoundValue: LiteralUnlimitedNatural[0..1] and update Figure 187 accordingly - add the following Additional Operation context ObjectNode::upperBound():UnlimitedNatural post: result = if upperBoundValue>isEmpty() then '*' – infinity else upperBoundValue.unlimitedValue() end if - on page 344, replace "The upper bound must be a positive LiteralInteger or a LiteralNull. An upper bound that is a LiteralNull means the upper bound is unlimited." with "An upper bound that is empty means the upper bound is unlimited."

  • Reported: UML 2.0 — Mon, 17 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

ActivityEdge - Typo

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

    ActivityEdge - Typo "Other rules for when tokens may be passed along the edge depend on the kind of edge and characteristics of its source and target."

  • Reported: UML 2.0 — Mon, 17 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

ActivityEdge - Section Semantics - Typo

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

    ActivityEdge - Section Semantics - Typo "See examples in Figure 210." should be "See examples in Figure 213."

  • Reported: UML 2.0 — Mon, 17 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

formal parameter or a return result

  • Key: UML22-1313
  • Legacy Issue Number: 7344
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    There appears to be an inconsistency in the specification as to what it means to be a formal parameter or a return result. Please choose between the following two interpretations: A. A return result is a parameter that is specially indicated to be the return result. All other parameters are formal parameters. B. A return result is any parameter with direction return, out, or inout. A formal parameter is any parameter with direction in or inout. You could view (A) as focusing on the syntactical role the parameters play, while (B) focuses on when they communicate data. The difficulty arises from that the infrastructure and the superstructure have differing machineries of dealing with parameters. This question affects Kernel (BehavioralFeature.parameter) and CommonBehavior (Behavior.parameter)

  • Reported: UML 2.0 — Sun, 16 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

typo p. 149

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

    Typo "A collaboration occurrence relates a feature in its collaboration type to connectable a element in the classifier or operation that owns the collaboration occurrence."

  • Reported: UML 2.0 — Mon, 17 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

association "context"

  • Key: UML22-1312
  • Legacy Issue Number: 7342
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The association "context" is defined as referencing the classifier owning the behavior. However, when behaviors are embedded within other behaviors, such as when a statemachine state owns a transition, this does not work. Instead, derive the context of the behavior in the following way: If the behavior is owned by a BehavioredClassifier, that classifier is the context. Otherwise, follow the chain of ownerships until you reach a BehavioredClassifier. That classifier is the context.

  • Reported: UML 2.0 — Sun, 16 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

behaviors

  • Key: UML22-1311
  • Legacy Issue Number: 7335
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    In all areas of the specification, when behaviors are referenced, it is the abstract metaclass Behavior that is used. This class can then be specialized to any concrete subclass of behavior. The only exception is statemachines, where Activity is referenced. Replace Activity by Behavior as the type of State.doActivity State.entry State.exit Transition.effect

  • Reported: UML 2.0 — Wed, 12 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See resolution to 7319. It replaces Activity with Behavior in state machines.

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Page: 589

  • Key: UML22-1309
  • Legacy Issue Number: 7331
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The bottom of the page says "Note – Short forms of these names should also be defined, e.g. pkg for package." If this is a note to the editor, this either should be done or the note removed. The specification should not say that something "should be done."

  • Reported: UML 2.0 — Sun, 9 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 12.3.20

  • Key: UML22-1308
  • Legacy Issue Number: 7330
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The second paragraph in the description section of ExpansionRegion ends upruptly in mid sentence

  • Reported: UML 2.0 — Sun, 9 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

enumerated type MessageSort

  • Key: UML22-1307
  • Legacy Issue Number: 7328
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The enumerated type MessageSort (used in Message to indicate the kind of communication reflected by the message) has been omitted. The enumeration literals should be synchCall, synchSignal, asynchCall, asynchSignal (see p.428).

  • Reported: UML 2.0 — Sun, 9 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

There is no redefinitionContext established

  • Key: UML22-1310
  • Legacy Issue Number: 7333
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    There is no redefinitionContext established for the redefinable elements of the Activity package. This probably should be the activity itself

  • Reported: UML 2.0 — Wed, 12 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This is resolved by 6185.

  • Updated: Fri, 6 Mar 2015 22:55 GMT

heading of table 19

  • Key: UML22-1306
  • Legacy Issue Number: 7327
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The heading of table 19 is "Graphic nodes and paths included in sequence diagrams" but should be "Graphic nodes and paths included in timing diagrams".

  • Reported: UML 2.0 — Sun, 9 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This issue was resolved by the resolution to issue 6977.

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Notation of ExecutionOccurrence

  • Key: UML22-1305
  • Legacy Issue Number: 7326
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The discussion of the Notation of ExecutionOccurrence speaks of Actions referenced by ExecutionOccurrence, while the meta model shows that ExecutionOccurrenc is related to behavior. Note that if ExecutionOccurrence is related to behavior, it is not possible to show, in an interaction, specific Actions, but only the events that start and end the behavior that contains some actions. However, this is consistent with the spirit of interactions as showing sequences of events, that may derive from actions.

  • Reported: UML 2.0 — Sun, 9 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This is a duplicate of issue 6153

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Section: 15.3.12

  • Key: UML22-1304
  • Legacy Issue Number: 7325
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    This section contains two subsections entitled "Changes from previous UML".

  • Reported: UML 2.0 — Sun, 9 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

introductory text for Property states

  • Key: UML22-1303
  • Legacy Issue Number: 7324
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The introductory text for Property states that "When a property is owned by a class..." where it should say "When a property is owned by a classifier...."

  • Reported: UML 2.0 — Sat, 8 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

notation for statemachine transitions omitted from spec

  • Key: UML22-1301
  • Legacy Issue Number: 7320
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    The notation for statemachine transitions has been omitted from the specification. Add to the notation section for Statemachines::TRansition a description of the surface syntax denoting a transition: A line from the symbol for the source vertex to the symbol denoting the target vertex, and associated with this line is a textual string with the syntax: <transition-text> ::= <trigger> [<guard>][/<action>]; <guard> ::= '[' <expression> ']'; where <trigger> is defined in CommonBehavior::Trigger, <expression> is an expression in some language, and <action> is a behavior in some language.

  • Reported: UML 2.0 — Fri, 7 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

behavior packages (Interactions, Statemachines

  • Key: UML22-1300
  • Legacy Issue Number: 7319
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Several of the behavior packages (Interactions, Statemachines) are dependent on actions, and consequentially, on the activity package. However, they rely only on a very small part of the action model. Primitive, non-structured, actions need to be independent of the activity model. This can be solved by: (a) Create an Actions::Action metaclass that is independent of Activities::Action. In the activity chapter, Activities::Action should subclass this new action. (b) Move Activities::InputPin and Activities::OutputPin into the Actions package, again adding additional features in the Activities package later. (c) Move Figure 178 "Actions" to the Actions package. This would give the two other behavior types independence of activities in a minimal way. Preferably we would also allow connection of actions: (d) Move figure 177 "Flows", minus the ownership by activity to the Actions chapter (it would be best to rename the abstract node names to something less refering to Activities, but that is no big deal). Add that ActivityEdge is owned by Behavior, and specialize that ownership in the Activity package to activities only.

  • Reported: UML 2.0 — Thu, 6 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above first, then continue below

  • Updated: Fri, 6 Mar 2015 22:55 GMT

"Implementation" is ommitted

  • Key: UML22-1302
  • Legacy Issue Number: 7322
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    "Implementation" is ommitted as one of the legal and typical elements in the diagram section of the Classes chapter and should be added, both in the table and the list below. (Note that legality in diagrams is not inheritable, so just because Realization is legal does not mean Implementation is.)

  • Reported: UML 2.0 — Sat, 8 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:55 GMT

InformationItem - Typo

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

    InformationItem - Typo "It is a kind of classifier intended for representing information at a very abstract way, which is cannot be instanciated."

  • Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

ReadLinkObjectEndQualifierAction - errors in OCL

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

    ReadLinkObjectEndQualifierAction - errors in OCL "[3] The ends of the association must not be static. self.qualifier.associationEnd.association.end->forall(oclIsKindOf(NavigableEnd) implies isStatic = #false)" There is not metaclass "NavigableEnd". This should be "[3] The ends of the association must not be static. self.qualifier.associationEnd.association.memberEnd->forAll(isStatic = #false)" ------------------------------------------------------ "[5] The multiplicity of the qualifier attribute is 1..1. self.qualifier.multiplicity.is(1,1)" should be "[5] The multiplicity of the qualifier attribute is 1..1. self.qualifier.lowerBound() = 1 and self.qualifier.upperBound() = 1 ------------------------------------------------------ "[6] The multiplicity of the object input pin is “1..1”. self.object.multiplicity.is(1,1)" "object" does not have a multiplicity. ------------------------------------------------------ "[8] The multiplicity of the result output pin is “1..1”. self.result.multiplicity.is(1,1)" "result" does not have an attribute "multiplicity"

  • Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

StartOwnedBehaviorAction - OCL error in constraint

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

    StartOwnedBehaviorAction - OCL error in constraint [1] "[1] The input pin has no type. self.argument.type->size() = 0" should be "[1] The input pin has no type. self.object.type->size() = 0"

  • Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

ReadLinkObjectEndAction - errors in OCL

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

    ReadLinkObjectEndAction - errors in OCL " [1] The property must be an association end. self.end.association->size = 1" should be " [1] The property must be an association end. self.end.association->size() = 1" -------------------------------------------------- "[3] The ends of the association must not be static. self.end.association.end->forall(oclIsKindOf(NavigableEnd) implies isStatic = #false)" There is not metaclass "NavigableEnd". This should be "[3] The ends of the association must not be static. self.end.association.memberEnd->forAll(isStatic = #false)" -------------------------------------------------- " [5] The multiplicity of the object input pin is “1..1”. self.object.multiplicity.is(1,1)" "object" does not have a multiplicity. -------------------------------------------------- "[7] The multiplicity of the result output pin is 1..1. self.result.multiplicity.is(1,1)" "result" does not have a multiplicity

  • Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

ReplyAction - Typo

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

    ReplyAction - Typo "It is not intended that any profile give any other meaning the the return information."

  • Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

ReplyAction - Inconsistency with Figure 150

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

    ReplyAction - Inconsistency with Figure 150 In page 245, replyValues is defined as follows: "replyValue : OutputPin [0..*] A list of pins containing the reply values of the operation. These values are returned to the caller." This is probably OK, but then, Figure 150 should have an association between ReplyAction and OutputPin, not between ReplyAction and InputPin.

  • Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

AcceptCallEvent - inconsistent multiplicity "• trigger

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

    AcceptCallEvent - inconsistent multiplicity "• trigger: CallTrigger The operation call trigger accepted by the action. " should be "• trigger: CallTrigger[1] The operation call trigger accepted by the action.

  • Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    In AcceptCallAction, Associations, insert multiplicity "[1]" for trigger.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

ReadIsClassifiedObjectAction - OCL errors in constraints

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

    ReadIsClassifiedObjectAction - OCL errors in constraints "[1] The multiplicity of the input pin is 1..1. self.argument.multiplicity.is(1,1)" Probably, it should be self.object instead of self.argument, but then again, self.object does not have a multiplicity. " [2] The input pin has no type. self.argument.type->size() = 0" "self.argument" should be "self.object" "[3] The multiplicity of the output pin is 1..1. self.result.multiplicity.is(1,1)" "self.result" is an OutputPin which does not have a multiplicity.

  • Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

AcceptEventAction - inconsistencies in Semantics and typos

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

    AcceptEventAction - inconsistencies in Semantics and typos "If the event is a SignalEvent, the result token contains a signal object whose reception by the owning object caused the event. Signal objects may be copied in transmission and storage by the owning object, so identity might not be preserved. An action whose event is a signal event is informally called an accept signal action. If the event is a TimeEvent, the result token contains the time at which the event occurred. Such an action is informally called a wait time action. If the event is a ChangeEvent ot a CallEvent, the result is a control token, there are no output pins. See CommonBehavior for a description of Event specifications." - There is no metaclass SignalEvent. Probably, this should be SignalTrigger. - There is no metaclass TimeEvent. Probably, this should be TimeTrigger. - There is no metaclass ChangeEvent. Probably, this should be ChangeTrigger. - There is no metaclass CallEvent. Probably, this should be CallTrigger. Suggestion for editorial change: "If the trigger is a SignalTrigger, the result token contains a signal object whose reception by the owning object caused the event. Signal objects may be copied in transmission and storage by the owning object, so identity might not be preserved. An action whose trigger is a SignalTrigger is informally called an accept signal action. If the trigger is a TimeTrigger, there is exactly one output pin which contains the time at which the event occurred. Such an action is informally called a wait time action. If the trigger is a ChangeTrigger, the result is a control token, there are no output pins. See CommonBehavior for a description of Trigger specifications."

  • Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See resolution to 7399. Suggested editorial change has the same text as the FAS.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

AcceptEventAction - inconsistency

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

    AcceptEventAction - inconsistency " ... then the accept signal action completes and outputs a token describing the event." should be " ... then the accept event action completes and outputs a token describing the event."

  • Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See resolution to 6236.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

AcceptEventAction - inconsistent multiplicities

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

    AcceptEventAction - inconsistent multiplicities "• result: OutputPin [1] Pin holding the event object that has been received. Event objects may be copied in transmission, so identity might not be preserved." Multiplicity should be "0..", not "1", because - in case of an accept signal action (see Semantics on the next page), the output pin holds a signal - in case of an time action (see Semantics on the next page), the output pin holds the time at which the event occured - in case of ChangeTrigger, "... there are no output pins." (see Semantics on the next page) - in case of an AcceptCallEventAction (which is a specialization of AcceptEventAction), the output pins hold 0.. argument values of a call. Thus, the multiplicity "0..*" in Figure 150 is probably correct and the respective multiplicity on page 207 should be updated.

  • Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See resolution to 6236.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Message - inconsistency "Messageident equalling ‘*’

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

    Message - inconsistency "Messageident equalling ‘’ is a shorthand for more complex alternative CombinedInteraction to represent a message of any type. This is to match asterisk triggers in State Machines." Notes: - There is no metaclass CombinedInteraction. This should probably be CombinedFragment. - "asterisk triggers" should probably be "AnyTrigger" - According to 13.3.2, an AnyTrigger is represented with the keyword "all". Shouldn't we replace "" in the grammar on page 430 by "all"? Suggested replacement: "Messageident equalling ‘all’ is a shorthand for more complex alternative CombinedFragment to represent a message of any type. This is to match AnyTriggers in State Machines."

  • Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Message - inconsistency (02)

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

    Message - inconsistency "When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline." Notes: - CallEvent has been replaced by CallTrigger in UML2. - CallAction should probably be CallOperationAction. - A CallEvent (now CallTrigger) has no arguments, but it refers to an operation which has arguments Suggested replacement: "When a Message represents an Operation the arguments of the Message are the arguments of the CallOperationAction on the sending Lifeline and the formal Parameters of the Operation the CallTrigger on the receiving Lifeline refers to."

  • Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This is an exact (word- for-word) duplicate of issue 7287.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Message - inconsistency

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

    Message - inconsistency "When a Message represents an Operation the arguments of the Message are the arguments of the CallAction on the sending Lifeline and the arguments of the CallEvent on the receiving Lifeline." Notes: - CallEvent has been replaced by CallTrigger in UML2. - CallAction should probably be CallOperationAction. - A CallEvent (now CallTrigger) has no arguments, but it refers to an operation which has arguments Suggested replacement: "When a Message represents an Operation the arguments of the Message are the arguments of the CallOperationAction on the sending Lifeline and the formal Parameters of the Operation the CallTrigger on the receiving Lifeline refers to."

  • Reported: UML 2.0 — Sun, 2 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Figure 77

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

    Figure 77 - show the generalization from Realization to Realization (from Kernel) In Figure 77, show that Realization is a specialization of Realization (from Kernel).

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Interface - Typos in Figure 63

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

    Interface - Typos in Figure 63 In Figure 63, - open guillemets should be added to interface IAlaram (see also Issue 6070) - stereotypes <<Interface>> should be changed to <<interface>> - name of right interface should be changed from "sensor" to "ISensor" - in the caption, "Isensor" should be replaced by "ISensor"

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    These issues were resolved by the resolutions to issues 6069 and 6070.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Connector - inconsistency

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

    Connector - inconsistency In order to be consistent with 7.15.3 (Interface) and 13.3.5 (Interface) "At a minimum, the provided interfaces must support a superset of the operations and signals specified in the required interfaces." should be "At a minimum, the provided interfaces must support a superset of the operations and receptions specified in the required interfaces."

  • Reported: UML 2.0 — Wed, 14 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Connector - typo and inconsistency

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

    Connector - typo and inconsistency "A connector consists of at two connector ends, each of which represents the participation of instances of the classifiers typing the connectable elements attached to this end. The set of connector ends is ordered. (Subsets Element.ownedElement.)" should be "A connector consists of at least two connector ends, each of which represents the participation of instances of the classifiers typing the connectable elements attached to this end. The set of connector ends is ordered. (Subsets Element::ownedElement.)" Also, "instances of the classifiers typing the connectable elements attached to this end" is not correct, because ConnectableElement is not a specialization of TypedElement. But all known specializations of ConnectableElement, namely Parameter, Variable, Port, and Property, are (indirect) specializations of TypedElement. I suggest to replace NamedElement in Figure 96 by TypedElement. ConnectableElement then automatically becomes a specialization of both TypedElement and NamedElement.

  • Reported: UML 2.0 — Wed, 14 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

ConnectorEnd - multipliciy of role

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

    ConnectorEnd - multipliciy of role - inconsistency with Figure 96 According to Figure 96, the multiplicity of role is 0..1. Therefore, "• role: ConnectableElement [1] The connectable element attached at this connector end." should be "• role: ConnectableElement [0..1] The connectable element attached at this connector end."

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Connector - inconsistency

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

    Connector - inconsistency According to Figure 96, type has multipliciy 0..1. Therefore, "• type: Association An optional association that specifies the link corresponding to this connector." should be "• type: Association[0..1] An optional association that specifies the link corresponding to this connector

  • Reported: UML 2.0 — Wed, 14 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

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

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

    Typo "A composite structure diagram depicts the internal structure of a classifier, , as well as the use of a collaboration in a collaboration occurrence." should be "A composite structure diagram depicts the internal structure of a classifier, as well as the use of a collaboration in a collaboration occurrence."

  • Reported: UML 2.0 — Wed, 14 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo Section: 12.3.8

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

    Typo "For example, an activity may be have one dimension of partitions for location ..."

  • Reported: UML 2.0 — Mon, 12 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

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

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

    Stereotype - Inconsistency in notation Section "Notation", last sentence: "If multiple stereotypes are applied, the names of the applied stereotypes is shown as a comma-separated list with a pair of guillemets." ==> Example matching with this rule: <<stereotype1, stereotype2,stereotype3>> Section "Presentation Options", first sentence: "If multiple stereotypes are applied to an element, it is possible to show this by enclosing each stereotype name within a pair of guillemets and list them after each other." ==> Example matching with this rule: <<stereotype1>> <<stereotype2>> <<stereotype3>> I suggest to remove the second presentation option. Examples in the spec are always based on the first one.

  • Reported: UML 2.0 — Mon, 12 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Stereotype - typo in OCL

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

    Stereotype - typo in OCL "[2] A concrete Stereotype must directly or indirectly extend a Class. not self.isAbstract implies self.extensionEnd->union(self.parents.extensionEnd)>notEmpty()" should be "[2] A concrete Stereotype must directly or indirectly extend a Class. not self.isAbstract implies self.extensionEnd>union(self.allParents().extensionEnd)->notEmpty()" because parents() only specifies the direct generalization whereas allParents() also includes classes which are indirectly extended

  • Reported: UML 2.0 — Mon, 12 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

ActivityPartition - inconsistencies

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

    ActivityPartition - inconsistencies "• partition : ActivityPartition [0..1] Partition immediately containing the partition. Specialized from ActivityGroup::group." should be "• superPartition : ActivityPartition [0..1] Partition immediately containing the partition. Specialized from ActivityGroup::superGroup." "• superPartition : ActivityPartition [0..1] Partitions immediately containing the partition. Specialized from ActivityGroup::subgroup." should be "• subPartition : ActivityPartition [0..1] Partitions immediately contained in the partition. Specialized from ActivityGroup::subgroup." Figure 183 should also be updated. There, "+subgroup" should be "+subPartition".

  • Reported: UML 2.0 — Mon, 12 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo In section "Description"

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

    Typo In section "Description": "Nodes and edges can belong to more than one group. "
    :

  • Reported: UML 2.0 — Mon, 12 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    In ActivityGroup class, Description, second sentence, insert "one" before "group".

  • Updated: Fri, 6 Mar 2015 22:54 GMT

AddVariableValueAction - OCL in constraint [1] not correct

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

    Here's an annotated copy of constraint [1]:

    let insertAtPins : Collection = self.insertAt in – NOTE: Variable does not have an attibute ordering if self.variable.ordering = #unordered – NOTE: currently, it is "then insertAtPins->size() = 0", but this – is not compatible with the return type. Now, an – empty set is returned instead. then {} else let insertAtPin : InputPin = insertAt->asSequence()>first() in insertAtPins>size() = 1 and insertAtPin.type = UnlimitedNatural – NOTE: an InputPin is not a multiplicity element and insertAtPin.multiplicity.is(1,1)) endif

  • Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Variables have ordering and multiplicity due to resolution of 6090.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Stereotype

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

    "[1] A Stereotype may only generalize or specialize another Stereotype. self.generalization.general->forAll(e | e.oclIsKindOf(Stereotype)) and self.specialization.specific->forAll(e | e.oclIsKindOf(Stereotype))" should be "[1] A Stereotype may only generalize or specialize another Stereotype. self.generalization.general->forAll(e | e.oclIsKindOf(Stereotype)) and self.generalization.specific->forAll(e | e.oclIsKindOf(Stereotype))"

  • Reported: UML 2.0 — Mon, 12 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo, section "Description", paragraph 1

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

    "In addition, because a itself Class is a subtype of an EncapsulatedClassifier, ..."

  • Reported: UML 2.0 — Mon, 22 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

VariableAction - undefined query

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

    isAccessibleBy() in the following constraint is not defined.

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

    Suggestion:

    "[1] The action must be in the scope of the variable. self.variable.scope = self.inStructuredNode"

  • Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

ReadLinkAction - Constraints use deprecated UML elements

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

    The constraints of ReadLinkAction use deprecated UML elements like AssociationEnd and refer to undefined properties like "isNavigable".

    Here's a proposal for updated OCL fragments:

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

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

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

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

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

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

    – NOTE: not clear, what the following OCL fragment specifies. For instance, what is – "oed.end.participant" ? – openend.visibility = #public or self.endData->exists(oed | not oed.end = openend and (host = oed.end.participant or (openend.visibility = #protected and host.allParents()->includes(oed.end.participant))))

  • Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

ReadLinkAction - inconsistency with Figure 147

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

    According to Figure 147, the multiplicity of result is "1", whereas in section "Associations" it is described as result : OutputPin [0..*]

    Multiplicity "1" is probably correct, since one OutputPin is meant to hold a possibly multivalued set of objects.

  • Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    In ReadLinkAction, Associations, change multiplicity of result to "1".

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Variable - Typo in Attributes

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

    scope : StructuredActivityGroup [1]The structured activity group that owns the variable.

    • replace StructuredActivityGroup by StructuredActivityNode - move it from section "Attributes" to section "Associations"
  • Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    In Variable class, Attributes, move entry for scope to Associations section.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

DestroyLinkAction - Semantics based on non existing "settability addOnly"

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

    Section "Semantics" refers to a "settability addOnly" which does not exist in UML 2. (In UML 1.5, there was a "changeability addOnly")

  • Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

MultiplicityElement - section is obsolete

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

    MultiplicityElement - section is obsolete (see also Issue 6090, Issue 6627, Issue 7111)

    Section 11.3.22 is obsolete because - MultiplicityElement as defined in this chapter is never used in generalization hierarchy

    • There are a lot of constraints and operations in this chapter making use of the operation "is(..)" and "compatibleWith(..)" defined for MultiplicityElement in this section, but usually these operations are applied to Pins (InputPins and OutputPins) which are not a specialization of MultiplicityElement
  • Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This is covered by issue 6090.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

LinkEndData - Additional operation not correct

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

    "Additional operations: [1] association operates on LinkAction. It returns the association of the action. association(); association = self.endData->asSequence().first().end.association"

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

    Additional operations

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

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

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

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

    context LinkAction::association():Assocation post: result = endData->asSequence().first().association()

  • Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

LinkEndData - Typo in OCL

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

    Constraint [1] should be changed from self.end.association->size = 1 to self.end.association->size() = 1

  • Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

AddStructuralFeatureValueAction - Settability removeOnly does not exist

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

    The spec says: "The semantics is undefined for adding a new value for a structural feature with settability readOnly or removeOnly after initialization of the owning object."

    StructuralFeature just has a boolean attribute "isReadOnly". There is no such attribute as "settability" or "isRemoveOnly".

  • Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

DestroyObjectAction - inconsistency in constraints

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

    Constraint [1] and [2] use the navigation expression self.input which should be self.target according to Figure 143 and section "Associations".

  • Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

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

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

    Section "Associations" states that the derived association /provided consists (1)of the implemented or realized interfaces of the component union (2) the provided interfaces on any of its realizing classifiers union (3) the types of any of its owned ports.

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

    I suggest to update the definition to:

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

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

    Constraints

    [1] provided = providedInterfaces()

    Additional Operations

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

    context Component::providedInterfaces():Set(Interface) post: result = – the set of interfaces provided by the component itself – self.clientDependency >select(oclIsTypeOf(Implementation) or oclIsTypeOf(Realization)).supplier ->collect(oclIsTypeOf(Interface)) union – the set of interfaces provided by any of its realizing classifiers – self.realization.realizingClassifier.clientDependency ->select(oclIsTypeOf(Implementation) or oclIsTypeOf(Realization)).supplier ->collect(oclIsTypeOf(Interface)) union – the set of interfaces implemented by the type of any of its – owning ports self.ownedPort>select(isService = true).type >select(oclIsTypeOf(Implementation) or oclIsTypeOf(Realization)).supplier ->collect(oclIsTypeOf(Interface)) union – the set of interfaces provided by any of its owned public ports – self.ownedPort>select(isService = true).provided

  • Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo - section Description, first sentence

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

    "... which is in turn is optionally attached in some way ..."

  • Reported: UML 2.0 — Sun, 21 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Manifestation - visual representation should be dashed arrow

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

    The sample diagram in Table 9, 1st row, 2nd column, on page 200 should use a dashed arrow instead of a solid one.

  • Reported: UML 2.0 — Sat, 13 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This issue was resolved by the resolution to issue 6234.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Deployment - keyword <> not introduced

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

    In UML 1.4, the visual representation of a deployment relationship is adorned with the keyword <<deploy>>. I suggest to introduce this is keyword in section "Notation" on page 188. Also, adorn the deployment relationship in Figure 130 on page 188 with <<deploy>>.

    Table 9 on page 199 includes the notation for a deployment dependency including the keyword <<deploy>>, but the depencendy arrow should be drawn with a dashed line.

  • Reported: UML 2.0 — Sat, 13 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

InteractionOccurrence - Syntax rules for name not clear

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

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

    should be changed to

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

    Four paragraphs below, the spec says that the same syntax is used as for Messages. This sentence should be deleted unless the syntax rules are actually updated to reflect the syntax rules of Message names on page 428.

  • Reported: UML 2.0 — Sat, 13 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

DeploymentTarget - Missing OCL expression

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

    The spec says:

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

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

    self.deployment.deployedArtifact->select(da | da.oclIsKindOf(Artifact) )->collect(da | da.oclAsType(Artifact).manifestation.utilizedElement )

  • Reported: UML 2.0 — Sat, 13 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Figure 95

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

    Figure 95 - Property should also specialize from Property (from Kernel).

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Connector - Constraint [3] not necessary ?

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

    It is not clear why Constraint [3] is necessary in addition to Constraint [2].

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Connector - Constraint [2] is inprecise

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

    2] If a connector is attached to a connectable element which has required interfaces, then the connectable elements attached to the other ends must realize interfaces that are compatible with these required interfaces.

    What is the meaning of this constraint ?

    • For each required interface I1 of a port P1 attached to a connector, every other port connected to the same connector must have at least one provided interface which is compatible to I1 ? - For each required interface I1 of a port P1 attached to a connector, there must be at least one other port connected to the to the same connector with at least one provided interface which is compatible to I1 ? - ....
  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

ReadSelfAction - Typos in OCL constraints

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

    Replace "activity()" by "activity" in the OCL expressions of Constraint [1], [2], and [3], i.e.

    [1] The action must be contained in an activity that has a host classifier. self.activity.hostClassifier()->size() = 1

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo

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

    "Every action is ultimately a part of some activity, which is in turn is optionally attached in some way to the specification of a classifier"

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    duplicate of isue # 7119 ...closed

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo

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

    "Every action is ultimately a part of some activity, which is in turn is optionally attached in some way to the specification of a classifier"

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

ReadSelfAction - delete constraint [4]

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

    Constraint [4] is not necessary, because OutputPin is not a specialization of MultiplicityElement - it does not have a multiplicity.

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

TestIdentityAction - additional constraint

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

    Add the following constraint:

    [3] The type of the result is Boolean self.result.type.oclIsTypeOf(Boolean)

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

TestIdentityAction- delete constraint [2]

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

    Constraint [2] is not necessary, because InputPin is not a specialization of MultiplicityElement - it does not have a multiplicity.

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo

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

    "TestIdentifyAction is an action that tests if two values are identical objects.t" (last t after period)

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

DeleteObjectAction - delete constraint [1]

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

    Constraint [1] is not necessary, because InputPin is not a specialization of MultiplicityElement - it does not have a multiplicity.

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

SendSignalAction

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

    SendSignalAction - Matching between arguments and Signal attributes not clear

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

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

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

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

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

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

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

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

    self.argument->forAll(arg | self.signal.attribute->one(attr | attr.name = arg.name and ((attr.type->size() = 1) implies attr.type.conformsTo(arg.type)) ) )

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Delete the following sentence in section "Notation":

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

    Delete the following sentence in section "Notation": "The symbol has a control output only." and replace it with the following constraint in section "Constraints":

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

    self.outgoing->size() <= 1 and self.outgoing->forAll(ae | ae.oclIsKindOf(ControlFlow))

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

CreateObjectAction - delete constraint [4]

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

    Constraint [4] is not necessary, because OutputPin is not a specialization of MultiplicityElement - it does not have a multiplicity.

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo

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

    "Receive signal action" in Figure 165 on p. 256 should be "send signal action".

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    In figure 165 on page 256 replace the phrase word “Receive” by the word “Send”

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Sentence not finished in section "Changes from previous UML"

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

    Sentence not finished in section "Changes from previous UML"

    "In UML 1.x,"

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    On page 186, remove this incomplete phrase from the end of the paragraph.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Collaboration - inconsistency with Figure 99

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

    According to Figure 99, the multiplicity of association end collaborationRole should be "*".

    • collaborationRole: ConnectableElement[*] References connectable elements (possibly owned by other classifiers) which represent roles that instances may play in this collaboration. (Subsets StructuredClassifier.role.)

  • Reported: UML 2.0 — Thu, 4 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo in Figure 124 on page 182

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

    "Manisfestation" should be "Manifestation"

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Duplicate of issue 6204

  • Updated: Fri, 6 Mar 2015 22:54 GMT

StructuredClassifier - Regular expression for namestring too complicated

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

    The regular expression on page 175 {{

    {[ name [‘/’ rolename]] | ‘/’ rolename}

    ‘:’ classifiername [

    {‘,’ classifiername}

    *]} | { name [‘/’ rolename] | ‘/’ rolename}} could be replaced by the following simpler expression name ['/' rolename]} | {'/' rolename [ ':' classifiername

    { ',' classifiername}

    *]

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo

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

    "That is, these model elements are utilized in the construction (or generation) or the artifact."

  • Reported: UML 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

GeneralizationSet - constraints expressed in OCL

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

    GeneralizationSet - constraints expressed in OCL

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

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

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

    let gene = self.generalization in gene->collect(g | g.general->union(g.general->collect(c | c.allParents()>union(c.allChildren())))) ->union(gene>collect(g | g.specific->union(g.specific->collect(c | c.allParents()->union(c.allChildren()))))) ->excludes(powertype)

  • Reported: UML 2.0 — Thu, 4 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

GeneralizationSet - Incorrect Mulitiplicities of associations

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

    GeneralizationSet - Incorrect Mulitiplicities of associations

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

    This should be

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

  • Reported: UML 2.0 — Thu, 4 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

GeneralizationSet - example in section "Semantics" is not clear

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

    GeneralizationSet - example in section "Semantics" is not clear

    Here is the respecitive paragraph with some editorial notes:

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

    "For example, the Bank Account Type classifier could associate with a Generalization relationship r--------------------------GeneralizationSet that has specific classifiers of Checking Account r---------refers to Generalizations with specific and Savings Account. Here, then, Checking Account and Savings Account are instances of Bank Account Type. Furthermore, if the Generalization relationship has a general classifier of Bank Account, then Checking Account and Savings Account are r-------------------------GeneralizationSet also subclasses of Bank Account. Therefore, Checking Account and Savings Account are both instances of Bank Account Type and subclasses of Bank Account. (For more explanation and examples, see Examples in the Generalization section, below.)

  • Reported: UML 2.0 — Thu, 4 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

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

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

    GeneralizationSet - description is confused about the meaning of "specific" and "general"

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

    Here is the respecitive paragraph with some editorial notes:

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

    Each Generalization is a binary relationship that relates a specific Classifier to a more general Classifier (i.e., a subclass). Each i(i.e. a subclass) r------superclass GeneralizationSet defines a particular set of Generalization relationships that describe the way in which a specific Classifier r-----generic (or superclass) may be partitioned. For example, a GeneralizationSet could define a partitioning of the class Person into two subclasses: Male Person and Female Person. Here, the GeneralizationSet would associate two instances of Generalization. Both instances would have Person as the specific classifier, however one Generalization would involve Male Person as the r-----generic general Classifier and the other would involve Female Person as the general classifier. In other words, the class Person can r----specific here be said to be partitioned into two subclasses: Male Person and Female Person. Person could also be partitioned into North American Person, Asian Person, European Person, or something else. This partitioning would define a different GeneralizationSet that would associate with three other Generalization relationships. All three would have Person as the specific Classifier; only the general classifiers would differ: i.e., North AmericanPerson, Asian Person, and European Person. r-----generic r-----specific

  • Reported: UML 2.0 — Thu, 4 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Was resolved as part of Issue No. 5980 (item 4).

  • Updated: Fri, 6 Mar 2015 22:54 GMT

GeneralizationSet - outdated description

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

    On page 121, the spec says:

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

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

    "A GeneralizationSet is an PackageableElement (from Kernel) whose instances define partitioned sets of Generalization relationships."

  • Reported: UML 2.0 — Thu, 4 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Was resolved as part of Issue No. 5980 (item 4).

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Region - Additional structural constraints necessary

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

    Add the toe following query to the section "AdditionalOperations":

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

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

    Add the following constraints to the section "Constraint"

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

    [6] Regions are properly nested not self.allParentRegions()->includes(self)

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Constraint [2], p.70

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

    RedefinableElement::isRedefinitionContexValid(redefinable: RedefinableElement): Boolean; isRedefinitionContextValid = self.redefinitionContext->exists(c | redefinable.redefinitionContext->exists(c | c.allParents()>includes(r)) – ^- should be r, not c )

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

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

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

    In Figure 355 there are three occurences of associaten ends named "redefinitionContext". The multiplicities of each should be 0..1, rather than 1, because State, Transition, and Region can exist without being part of StateMachine and thus without having a redefinition context.

    The multiplicity should also be updated on page 479 for State, on page 498 for Transition, and on page 476 for Region.

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Figure 355 - ownedStateMachine should subset ownedBehavior

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

    The association ownedStateMachine should subset rather than redefine ownedBehavior.

    +ownedStateMachine {subsets ownedBehavior)

    The other end of the association should be +context {redefines context) instead of {subsets redefinitionContext)

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo p 497

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

    Typo

    "As part of the specialization of a class it is desirable also the specialize the behavior definition

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

State - Constraints - errors in OCL and inconsistencies

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

    State - Constraints - errors in OCL and inconsistencies

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

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

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

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

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

    OCL should be isSimple = region->isEmpty()

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

    OCL should be isComposite = region->notEmpty()

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

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

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

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

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

    OCL should be:

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

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

    OCL should be:

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

    Furthermore, this constraint should be moved to 15.3.8, because it is a constraint for PseudoState, not for State.

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Change Constraint [1] to

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

    Change Constraint [1] to

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

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

    Change Constraint [2] to

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

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

    Change Constraint [3] to

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

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

    Change Constraint [4] to

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

    Change Constraint [5] to

    [5] Transitions outgoing pseudostates may not have a trigger. self.source.oclIsKindOf(Pseudostate) implies self.trigger->isEmpty()

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Non-existent property isFinal referenced

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

    Section "State redefinition", first sentence: "A state may be redefined, provided that the value of isFinal is False."

    State does not have a property "isFinal".

  • Reported: UML 2.0 — Fri, 4 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

ownedStateMachine not described correctly

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

    In section "Changes from previous UML" the spec says:

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

    This is not correct, because according to Figure 355 ownedStateMachine is an association between StateMachine and BehavioredClassifier and not between StateMachine and StateMachine.

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Define containingStateMachine() for Vertex

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

    Define containingStateMachine() for Vertex

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

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

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

    {self.container.StateMachine}

    endif endif

    Remove Additional Constraint [3] for StateMachine on page 491.

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

State - Inconsistency

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

    State - Inconsistency

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

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

    dito for deferrableTrigger ==> • deferrableTrigger: Trigger[*] A list of triggers that are candidates to be retained by the state machine if they trigger

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

p.461, first sentence:

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

    p.461, first sentence: "A connection point reference to an entry point can also be visualized using a rectangular symbol as shown in Figure 362."

    Should refer to Figure 360, not 362

    Furthermore, in Figure 360 the example should be "via again", not "via aborted".

  • Reported: UML 2.0 — Mon, 1 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

AssociationClass - Additional Operation [1] should be deleted

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

    "[1] The operation allConnections results in the set of all AssociationEnds of the Association. allConnections : Set ( AssociationEnd ); allConnections = self.end->union ( self.allParents ().end )"

    AssociationEnd does not exist anymore in UML 2.0. This constraint should be deleted.

  • Reported: UML 2.0 — Mon, 1 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

AssociationClass Constraint [1] should be reformulated

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

    Constraint [1] should be reformulated as:

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

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

    [9] children gives the direct specialisations of this classifier

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

    [9] allChildren gives all the directly and indirectly specialized classifiers context Classifier::allChildren():Set(Classifier) result = children->union(children->collect(c | c.allChildren))

  • Reported: UML 2.0 — Mon, 1 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Association - endType should be of type Classifier

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

    Association - endType should be of type Classifier

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

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

    Constraint[3] should be changed accordingly to:

    [3] endType is derived from the types of the member ends. self.endType = self.memberEnd->collect(p | p.classifier)

  • Reported: UML 2.0 — Mon, 1 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Constraints of ConnectionPointReference - OCL not correct

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

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

    should be

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

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

    should be

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

  • Reported: UML 2.0 — Mon, 1 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Stereotype «buildComponent» defined twice, description not clear

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

    Table 25 on p. 593 includes the stereotype «buildComponent», so does table 27 on page 597. «buildComponent» is not used anywhere else in the spec, it has not been used in UML 1.5, and from the description in table 25 it is not clear what this stereotype should be used for.

    Suggestion => remove it from table 25 and from table 27.

  • Reported: UML 2.0 — Mon, 23 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo p 589

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

    Typo

    "UML diagrams may have the following kinds of frame names as part of the heading_._:"

  • Reported: UML 2.0 — Mon, 23 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

ExtensionPoint should be a specialization of Feature (from Kernel)

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

    ExtensionPoint should be a direct specialization of Feature (from Kernel), rather than RefinableElement (from Kernel). Since Feature (from Kernel) also specializes RefinableElement, ExtensionPoint would still be a specialization of RefinableElement.

    This would make the classifier based notation of Figure 408 more obvious. And it would fit better with the constraint

    {subsets feature}

    on +extensionPoint (see Figure 401).

  • Reported: UML 2.0 — Mon, 23 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo p 587

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

    Typo

    "UML diagrams contain_s_ graphical elements (nodes connected by ..."

  • Reported: UML 2.0 — Mon, 23 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

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

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

    The association extensionLocation is defined as follows (page 515):

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

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

    As stated above, "in most practical cases, the extending use case has just a single behevavior fragment". I therefore suggest to change the multiplicity of extensionLocation to 1..1

  • Reported: UML 2.0 — Mon, 23 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Constraint not precise enough

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

    Constraint [1] should be extended s follows (see also second paragraph in the section Notation on page 321)

    [1] A decision node has one incoming edge and at least one outgoing ege. self.incoming->size() = 1 and self.outgoing->size() >= 1

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

    Duplicate with issue 7009.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Unnecessary sentence p 339

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

    Remove the following sentence from section Semantics:

    "No joining of tokens is necessary if there is only one incoming edge, but it is not a useful case."

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Imprecise sentence p 334

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

    "Flow final nodes are introduced to model termination or merging of a flow in an activity." should be "Flow final nodes are introduced to model termination of a flow in an activity." since merging of a flow is handled by Merge Nodes.

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

    In FlowFinalNode, Rationale section, remove "or merging".

  • Updated: Fri, 6 Mar 2015 22:54 GMT

"Joining of tokens" not clear

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

    It is not clear, how different data tokens arriving at a join node are "joined" before they are passed along the outgoing edge. Are they wrapped in an "envelope token" ? Or are they serialized (in arbitrary order ?) and then passed along the outgoing edge ?

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo p 339

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

    Typo

    "Other rules for when tokens may be passed along the outgoing edge depend on the characteristics of the edge and its target."

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo - Missing colon p 302

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

    • outgoing ActivityEdge [0..*] Edges that have the node as source.

    should be

    • outgoing: ActivityEdge [0..*] Edges that have the node as source.

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Constraint not precise enough

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

    Constraint [1] should be extended s follows (see also first sentence in the section Notation on page 339)

    [1] A join node has one outgoing edge and at least one incoming ege. self.incoming->size() >= 1 and self.outgoing->size() = 1

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo p 320

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

    Typo

    "A decision input behavior has one input parameter and one output parameter. The input parameter must be the same as or a supertype of the type of object token coming along the incoming edge. The behavior cannot have side effects. "

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

    In Decision Node class, in constraint [2], insert "of" after supertype.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

No Activity Edges from with equal source and target

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

    The Constraints section of Activity Edge should be extended with:

    [3] Source and target of an activity edge must not be equal source <> target

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

    This is duplicate with 7007.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo p 161

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

    Typo

    ".. of two occurrences of the Sale collaboration, indicated b_e_ the dashed ellipses." => ".. of two occurrences of the Sale collaboration, indicated by the dashed ellipses."

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Another Inconsistency with Figure 100

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

    According to Figure 100, the multiplicity of "roleBinding" is "*". Thus, the second paragraph of section "Associations" should be changed to

    • roleBinding: Dependency[*] A mapping between features of the collaboration type and features of the classifier or operation. This mapping indicates which connectable element of the classifier or operation plays which role(s) in the collaboration. A connectable element may be bound to multiple roles in the same collaboration occurrence (that is, it may play multiple roles).

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

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

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

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

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

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

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

    Constraints

    [3] There is at most one ActivityEdge given a source and a target Activity Node. source.outgoing->select(ae | ae.source = source and ae.target = target)>size() = 1 and target.incoming>select(ae | ae.source = source and ae.target = target)->size() = 1

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Inconsistency between constraint of ControlNode and Semantics of JoinNode

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

    Constraint on ControlNode (p. 317):

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

    Semantics of JoinNode (p. 339):

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

    Item 2.) should be: "2. If all the tokens offered on the incoming edges are data tokens, then only the data tokens are offered on the outgoing edge."

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Inconsistency with Figure 100

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

    According to Figure 100, the multiplicity of "collaborationRole" is "*". Thus, the first paragraph of section "Associations" should be changed to

    • collaborationRole: ConnectableElement[*] References connectable elements (possibly owned by other classifiers) which represent roles that instances may play in this collaboration. (Subsets StructuredClassifier.role.)

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Figure 103 at the wrong place

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

    The section "Presentation Option" including Figure 103 does not fit in the context of section 9.3.1. This section deals with the specialized Class meta-class for Structured Classes, whereas the "Presentation Option" and Figure 103 explain something about relating instance specifications to constructors. This section should either be deleted or moved be moved to another place, i.e. section 7.11, Kernel - the Classes Diagram, or section 7.7, Kernel - the Instance Diagrams.

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Connector - default value für "kind"

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

    On page 143, the spec says: • kind : ConnectorKind =

    {assembly, delegation}

    Indicates the kind of connector.

    This doesn't make sense. "kind" is either "assembly" or "delegation" but not a set consisting of both values. "kind" should either have no default value, or it should be "assembly" or "delegation". • kind : ConnectorKind or • kind : ConnectorKind = assembly or • kind : ConnectorKind = delegation

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo p 137

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

    Typo

    "A component is a substitutable unit that can be replaced at design time or run-time by a component that offers that offers equivalent functionality based on compatibility of its interfaces."

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Missing multiplicities

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

    The multiplicities for the four following associations are missing in section Associations:

    provided: Interface[*] required: Interface[*] realization: Realization[*] ownedMember: PackageableElement[*]

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

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

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

    Typo

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

    Artif_i_act

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

    On page 595 in the entry for “script” of Table 25, replace “Artifiact” with “Artifact”

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Additional Operations specification of NamedElement::allNamespaces()

  • Key: UML22-1189
  • Legacy Issue Number: 6997
  • Status: closed  
  • Source: Unisys ( Terry L. Cowart)
  • Summary:

    The Additional Operations specification of NamedElement::allNamespaces() appears incorrect. The else clause states:

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

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

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

    which would provide access to the query, as well as providing the (apparently intended) recursion.

  • Reported: UML 2.0 — Thu, 19 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

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

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

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

    The use case "Withdraw" should be the including use case. "Card identification" should be the included use case.

  • Reported: UML 2.0 — Sat, 31 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Same issue as 6643

  • Updated: Fri, 6 Mar 2015 22:54 GMT

UseCase - Inconsistencies with Figure 401

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

    UseCase - Inconsistencies with Figure 401

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

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

    and should be

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

    dito for "include" and "extend"

  • Reported: UML 2.0 — Fri, 31 Jan 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

typo

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

    Last sentence on page:

    "..., it is typically defined in the some classifier or package ..."

  • Reported: UML 2.0 — Sat, 31 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Typo in OCL

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

    Typo in OCL

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

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

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

  • Reported: UML 2.0 — Sat, 31 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

UseCase - Extend is not a Namespace

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

    UseCase - Extend is not a Namespace

    See association end +condition of the association between Extend and Constraint: +condition

    {subsets ownedMember}

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

    Extend should either specialize Namespace or the property string of +condition should be changed to

    {subsets ownedElement}: +condition {subsets ownedElement}

  • Reported: UML 2.0 — Sat, 31 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Inconsistent multiplicity

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

    Inconsistent multiplicity

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

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

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

  • Reported: UML 2.0 — Sat, 31 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

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

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

    Inconsistency between Figure 328 and the associations listed in section "Associations".

    If there is an association between MessageEnd and Interaction according to

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

    then it is missing in Figure 328.

  • Reported: UML 2.0 — Fri, 31 Jan 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Wrong association name

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

    lifeline: Lifeline[1] References the Lifeline on which the StateInvariant appears. Specializes InteractionFragment. covered"

    should be

    "covered: Lifeline[1] References the Lifeline on which the StateInvariant appears. Specializes InteractionFragment. covered"

  • Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Constraint [2] - Missing parenthesis in OCL

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

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

    should be

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

    Furthermore, I don't understand why this constraint is necessary, since the multiplicy of 'represents' is exactly 1.

  • Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

type p 419

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

    A GeneralOrdering is shown by a dotted line connected the two Eventoccurrences."

    should be

    "A GeneralOrdering is shown by a dotted line connecting the two Eventoccurrences."

  • Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Inconsistency between section "Associations" and Figure 327

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

    In Figure 327, the association end of the association between Lifeline and Expression is called "discriminator", whereas the respective association belonging to Lifeline is called "selector":

    "selector : Expression[0..1] If the referenced ConnectableElement is multivalued, then this specifies the specific individual part within that set."

  • Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

typo p 340

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

    This case maps to a model containing a a join node with all the incoming ..."

    should be

    "This case maps to a model containing a join node with all the incoming ..."

  • Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

object edges" should be replaced by "object flows

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

    Output pins are object nodes and deliver values to other actions through object edges."

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

    "Output pins are object nodes and deliver values to other actions through object flows."

  • Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

graphic nodes

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

    "The graphic nodes that can be included in structural diagrams are shown in Table 14."

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

    "The graphic nodes that can be included in sequence diagrams are shown in Table 14."

  • Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

typo p 421

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

    "The local attriburte PIN of UserAccepted is declared near the diagram top."

    should be

    "The local attribute PIN of UserAccepted is declared near the diagram top."

  • Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

object edges" sould be replaced by "object flows

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

    They are object nodes and receive values from other actions through object edges."

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

    "They are object nodes and receive values from other actions through object flows."

  • Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    In InputPin class, top section, second sentence, replace the last word with "flows".

  • Updated: Fri, 6 Mar 2015 22:54 GMT

typo p 356

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

    "The name is not restricted, but it is often just shows the type of object or data that flows through the pin."

    should be

    "The name is not restricted, but it often just shows the type of object or data that flows through the pin."

  • Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

typo p 240

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

    "Other rules for when tokens may be passed along the edge depend the kind of edge and characteristics of its source and target."

    should be

    "Other rules for when tokens may be passed along the edge depend on the kind of edge and characteristics of its source and target."

  • Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Duplicate with 7012.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

typo p 420

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

    These attribute definitions may appear near the top of the diagram frame or within note symbols other places in the diagram."

    should be

    "These attribute definitions may appear near the top of the diagram frame or within note symbols at other places in the diagram."

  • Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

typo p 403

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

    We are aware that other parts of the UML languatge definition the term “trace” is used also for other purposes."

    should be

    "We are aware that in other parts of the UML language definition the term “trace” is used also for other purposes."

  • Reported: UML 2.0 — Wed, 28 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Inconsistencies between Figure 43 and the detailled description of Package

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

    Figure 43 includes an association between Package and Type, whose endpoints are "package" and "/ownedClassifier" respectively.

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

    The name of the endpoint in Figure 43 should be "/ownedType", not "/ownedClassifier".

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

    Duplicate of issue 6184.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

The section "Associations (BasicActivities)" is not complete

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

    The section "Associations (BasicActivities)" is not complete because the association between Activity and Action (depicted in Figure 176) is not described.

    The following item should be added to the description:

    • action: Action[0..*] The Actions the Activity is composed of.
  • Reported: UML 2.0 — Mon, 19 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See resolution of 7319. This association is replaced with SequenceNode.

  • Updated: Fri, 6 Mar 2015 22:54 GMT

The query 'hostElement' has some errors

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

    See the comment lines starting with – !! in the following listing:

    – !! on the next line, ModelElement should probably be changed – !! to Element. hostElement() : ModelElement; hostElement = if self.Method->size() > 0 then self.Method else if self.State->size() > 0 then self.State else if self.Transition->size() > 0 then self.Transition else if self.Message->size()>0 then self.Message – !! size should be size() on the next line else if self.Stimulus->size>0 then self.Stimulus endif endif endif – !! should be endif on the next line endi – !! missing endif on this line – !! remove the closing bracket on the next line ]

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Inconsistencies between Figure 3 and the detailled description of package

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

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

    should be

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

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

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

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

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

• /context : Classifier [0..1]

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

    "• /context : Classifier [1] The classifier that owns the behavior of which this action is a part."

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

    "• /context : Classifier [0..1] The classifier that owns the behavior of which this action is a part."

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

    In Action class, Attributes, change multiplicity of /context to [0..1]

  • Updated: Fri, 6 Mar 2015 22:54 GMT

See CommonBehavior for a description of Event specifications

  • Key: UML22-1163
  • Legacy Issue Number: 6682
  • Status: closed  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    The text says "See CommonBehavior for a description of Event specifications."

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

    But we aren't told there or anywhere how to specify an event nor how to specify a type of event.

  • Reported: UML 2.0 — Mon, 8 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above THEN below

  • Updated: Fri, 6 Mar 2015 22:54 GMT

page 95 diagram

  • Key: UML22-1162
  • Legacy Issue Number: 6596
  • Status: closed  
  • Source: no ( Jens Muehlenhoff)
  • Summary:

    On page 95 the diagram shows an assoziation between the class DataType and Property (with name ownedAttribute). This assoziation is'l listet in the assoziation section of the class DataTypes on page 95. Ther is an assoziation with the same name (ownedAttribute) but with a wrong type (Attribute).

  • Reported: UML 2.0 — Mon, 10 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

On templateableElment - additonal features

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

    The query getParameterableElements() returns the set of elements that may be used as the parametered element for a template parameter if this templateable element ???."

    I think the previous sentence is not complete?

  • Reported: UML 2.0 — Mon, 29 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Figure 346 needs updating

  • Key: UML22-1160
  • Legacy Issue Number: 6087
  • Status: closed  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    The Figure 346 on page 443 needs some updating: 1. The collaboration W should be shown as an oval 2. The text inside the right lifeline of sd Q should read “y:superB” (the colon is missing)

  • Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Incorrect mentioning of General Order On p 412

  • Key: UML22-1157
  • Legacy Issue Number: 6081
  • Status: closed  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    Incorrect mentioning of General Order On p 412: The only purpose of gates is to define the source and the target of Messages or General Order relations.

    " or General Order relations” should be removed. This is a reminiscence of an earlier version

  • Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Omission of non-terminal ‘arguments’ (p. 424)

  • Key: UML22-1159
  • Legacy Issue Number: 6085
  • Status: closed  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    In top of p. 424 there is a small textual grammar for a name in an interaction occurrence. There should be one more production defining the non-terminal ‘arguments’ as shown below here: arguments ::= argument [ , arguments]

  • Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Remove occurrences of “TBD”

  • Key: UML22-1158
  • Legacy Issue Number: 6084
  • Status: closed  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    There are a couple of places where the flag “TBD” is still in the document. They should be removed.

    pp. 423, 427,

  • Reported: UML 2.0 — Fri, 29 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Message notation. Incorrect notation in Figure 333 p.414

  • Key: UML22-1153
  • Legacy Issue Number: 6077
  • Status: closed  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    Firstly not even the original (which is in Visio) has the appropriate dashed line of creation (I thought the pdf just had not quite got it right which happens often, but now I checked the original). Secondly the reply messages should have filled arrowheads (again judging from the description of the message notation).

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

    Originally reported by David Fado through Jim Odell.

  • Reported: UML 2.0 — Thu, 28 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This is a subset of the issue described in 6463. - duplicate

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Message End association to Interaction should be removed

  • Key: UML22-1155
  • Legacy Issue Number: 6079
  • Status: closed  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    There is an association in MessageEnd to Interaction (p. 431). This association should have been removed long time ago. It is a reminiscence of an earlier version.

  • Reported: UML 2.0 — Thu, 28 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Strict ordering in Inline Part Decomposition

  • Key: UML22-1154
  • Legacy Issue Number: 6078
  • Status: closed  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    Inline Part Decomposition as shown in Figure 341 p. 433 are practical, but often it is necessary to describe the individual ordering between the events on the different inner lifelines. Often the user will want this ordering to be strict rather than weak.

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

    Originally reported by Ericsson engineer Peter Cigehn.

  • Reported: UML 2.0 — Thu, 28 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

EventOccurrence, multiplicities incorrect in metamodel diagram

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

    The metamodel shown in Figure 328, p. 407 presents the associations from EventOccurrence to ExecutionOccurrence with multiplicity ‘*’. This should be [0..1] as given in the text.

  • Reported: UML 2.0 — Thu, 28 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

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

  • Key: UML22-1152
  • Legacy Issue Number: 6023
  • Status: closed  
  • Source: self ( Steve Hickman)
  • Summary:

    On page 140, the title for Parameter is "Parameter (Collaboration, as specialized)". This doesn't seem correct. The only prior definition of Parameter is on p 50, which is in the Kernel. The only way to "specialize" something appears to be when you want to add relationships to a concept that has been defined in a different package. I believe the more correct label should be "Parameter (from Kernel, as specialized)". Further, the abstract syntax diagram on page 128 should indicate that Parameter comes from the definition in the the Kernel. This may require deriving a new Parameter metaclass from the Kernel Parameter metaclass just so it can also be derived from ConnectableElement.

  • Reported: UML 2.0 — Sun, 27 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

The title of the Property description on page 144

  • Key: UML22-1151
  • Legacy Issue Number: 6022
  • Status: closed  
  • Source: self ( Steve Hickman)
  • Summary:

    The title of the Property description on page 144 says: "Property (from InternalStructures, as specialized)". I believe this should say: "Property (from Kernel, as specialized)".

    Here's why: there is as yet no indication of any kind of relationship between Property as defined as part of the Superstructure Kernel and Property as described in InternalStructures. There are some hints that such a relationship exists, but it isn't clear. Either the relationship should be explicitly stated (ir a relationship exists), or it should be explicitly stated that no such relationship exists.

  • Reported: UML 2.0 — Sun, 27 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

labels for ExecutionOccurrence

  • Key: UML22-1150
  • Legacy Issue Number: 6021
  • Status: closed  
  • Source: self ( Steve Hickman)
  • Summary:

    The labels for ExecutionOccurrence in the diagrams on p 367 & 368 are both in italics, implying that this is an abstract class. However, the description of EventOccurrence on p. 378 doesn't mention anything about being abstract nor are there any classes derived from it anywhere in the spec.

  • Reported: UML 2.0 — Sun, 27 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    resolved, see above

  • Updated: Fri, 6 Mar 2015 22:54 GMT

duration observation" vs DurationObservationAction etc

  • Key: UML22-1149
  • Legacy Issue Number: 6020
  • Status: closed  
  • Source: self ( Steve Hickman)
  • Summary:

    There is some inconsistency in the use of the terms "duration observation" vs. DurationObservationAction and "time observation" vs. TimeObservationAction in the diagrams on the above listed pages. In particular, figure 8-158 states that the visual elements in a Sequence Diagram are "DurationObservation" and "TimeObservation", when in fact they should be "DurationObservationAction" and "DurationObservationAction". The observations only occur when the action is taken - but the representation on the sequence diagram must be the action to be taken, not the effect of it. Compare this to figures on pp 351 & 360.

  • Reported: UML 2.0 — Fri, 25 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Missing sections for for enumeration MessageKind or MessageSor

  • Key: UML22-1148
  • Legacy Issue Number: 6019
  • Status: closed  
  • Source: self ( Steve Hickman)
  • Summary:

    In Chapter 8, you have a section in 8.3 describing the enumeration InteractionOperator. You do not have similar sections for enumeration MessageKind or MessageSort.

  • Reported: UML 2.0 — Thu, 24 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 22:54 GMT

figure 8-137 and 8-139

  • Key: UML22-1147
  • Legacy Issue Number: 6018
  • Status: closed  
  • Source: self ( Steve Hickman)
  • Summary:

    In figure 8-137, EventOccurrence inherits from InteractionFragment which inherits from NamedElement. In figure 8-139, EventOccurrence inherits directly from NamedElement.

    The two figures should be consistent with each other (yes, I know that inheritance is transitive, but it does raise unnecessary questions)

  • Reported: UML 2.0 — Thu, 24 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

CommonBehaviors describes "Operation (from Communications, as specialized)

  • Key: UML22-1146
  • Legacy Issue Number: 6017
  • Status: closed  
  • Source: self ( Steve Hickman)
  • Summary:

    CommonBehaviors describes "Operation (from Communications, as specialized)" on page 354. However, the only other reference to "Operation" in the CommonBehaviors section appears on p 339, where the reference is to "Operation (from Kernel)".

    There's something wrong here.

  • Reported: UML 2.0 — Thu, 24 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

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

  • Key: UML22-1144
  • Legacy Issue Number: 6015
  • Status: closed  
  • Source: self ( Steve Hickman)
  • Summary:

    There appears to be an inconsistency between figure 5.1 on page 179 and figure 7-122 on page 337.

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

    In figure 7.122 IntermediateActions depends only on BasicBehaviors. Although Communications is present in the diagram, there is no indication of a dependency.

  • Reported: UML 2.0 — Thu, 24 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

OpaqueExpression in CommonBehaviors

  • Key: UML22-1143
  • Legacy Issue Number: 6014
  • Status: closed  
  • Source: Honeywell ( Steven Hickman)
  • Summary:

    OpaqueExpression in CommonBehaviors is titled "OpaqueExpression (from BasicBehaviors, specialized)". What does "specialized" mean in this context? There is no indication of inheritance from any other definition of OpaqueExpression.

    NOTE: the word "specialized" is used in the title of a number of concepts - in some cases the concepts are derived from other concepts of the same name from other package. This isn't always the case though.

  • Reported: UML 2.0 — Thu, 24 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:54 GMT

CommonBehaviors

  • Key: UML22-1145
  • Legacy Issue Number: 6016
  • Status: closed  
  • Source: self ( Steve Hickman)
  • Summary:

    CommonBehaviors has a package named "Time" that is referenced in numerous parts of the document.

    The class diagram on page 342 is labelled "SimpleTime". it appears that this should be labelled "Time" to be consistent with the package name.

  • Reported: UML 2.0 — Thu, 24 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above,. resolved

  • Updated: Fri, 6 Mar 2015 22:54 GMT

Output tokens

  • Key: UML22-1142
  • Legacy Issue Number: 8675
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    In: [4] The output tokens are now available Replace ``available'' by ``offered''

  • Reported: UML 2.1 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Duplicate or Merged — UML 2.1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:25 GMT

There is a bug in additional operation 1 of the Namespace element

  • Key: UML14-1041
  • Legacy Issue Number: 5733
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There is a bug in additional operation 1 of the Namespace element. I can suggest the following OCL expression: “contents = self.ownedElement->union(self.ownedElement->select(oe | oe.oclIsKindOf(Namespace)).contents)”.

  • Reported: UML 1.4 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Issue 4848 also raises a similar problem with Namespace.contents

  • Updated: Fri, 6 Mar 2015 21:40 GMT

How to properly designate exception returned from message sent to Java obje

  • Key: UML14-1040
  • Legacy Issue Number: 5433
  • Status: closed  
  • Source: ObjectShare ( Rebecca Wirfs-Broc)
  • Summary:

    I am trying to properly designate an exception returned from a message sent to a Java object.

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

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

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

  • Reported: UML 1.4 — Mon, 17 Jun 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a subset of the issue addressed by issue 7397.

  • Updated: Fri, 6 Mar 2015 21:39 GMT

In 3.23.1 "Notation" (Internationalization issues)

  • Key: UML14-1039
  • Legacy Issue Number: 4120
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    > In 3.23.1 "Notation", it is described that
    > italics are used to represent abstract classes.
    > We don't usally use slanting letters in Japanese.
    > It seems strange. So, I think this should be moved into
    > "Presentaion Options" or "Style Guidelines".
    >
    > In 3.22.4 "Style Guidelines",
    > it is described that uppercase letters are
    > used to represent class names and
    > lowercase letters are used to represent attributes
    > and operation names.
    > Japanese language doesn't have uppercase nor lowercase
    > letters. However, this is "Style Guidelines", so I think
    > this is not a problem, because the specification already
    > says that "Style Guideline" and "Presentation Option" are
    > not mandatory.

  • Reported: UML 1.3 — Sat, 9 Dec 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

No servant with object . minorcode=0 completed=NO

  • Key: UML14-1038
  • Legacy Issue Number: 4060
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I am running a simple program but i am getting the error

    "There is no servant with object . minorcode=0 completed=NO"

    but i am not finding any documentation that explains abt the minorcode=0. it starts from 1. can u please help me out

  • Reported: UML 1.3 — Mon, 20 Nov 2000 05:00 GMT
  • Disposition: Closed; No Change — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

The index shows incorrect section numbering for sections 2.9.4.1 to 2.9.4

  • Key: UML14-1037
  • Legacy Issue Number: 3637
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The index shows incorrect section numbering for sections 2.9.4.1 to 2.9.4.4 as follows:

    2.9.4.25 Object and DataValue . 2-103
    2.9.4.26 Link . . . . . . . . . . 2-104
    2.9.4.27 Signal, Exception and Stimulus . 2-104
    2.9.4.28 Action . . . . . . . . 2-105

    It would appear that the fourth level carries on from 2.9.3.24

  • Reported: UML 1.3 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Setting Action as abstract in UML-MetaModel MDL to correspond to Semantics

  • Key: UML14-1036
  • Legacy Issue Number: 3631
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    The Action ModelElement looks like it is abstract in the Rose MDL
    because the name is in italics.
    However, checking the details tab in Rose shows that it has not been marked
    as abstract.

  • Reported: UML 1.3 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Who owns an Event?

  • Key: UML14-1035
  • Legacy Issue Number: 3558
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    An Event is aggregated by a transition but there seems to be no
    reference to who owns an event.
    If it should reside in a Package the OCL-WellFormedness rule for Package
    should be updated.

  • Reported: UML 1.3 — Thu, 13 Apr 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

UML RTF 1.4 editorial comments (Part 9 - Statechart Diagrams)

  • Key: UML14-1033
  • Legacy Issue Number: 3400
  • Status: closed  
  • Source: Technical Resource Connection ( Brian Cook)
  • Summary:

    Suggestions for the UML Notation Guide, Part 9 - Statechart Diagrams
    1. In Part 9 - Statechart Diagrams:[Proposed changes in red for the
    first 3 suggestions.] "A statechart diagram can be used to describe the
    behavior of instances of a model element such as an object or an
    interaction. Specifically, it describes possible sequences of states and
    actions through which the element instance can proceed during its lifetime
    as a result of reacting to discrete events (e.g., signals, operation
    invocations). " [The idea is that model elements are not dynamic or have
    lifetimes; rather they apply to instances of model elements.]
    2. In 3.74.1: "Typically, it is used for describing the behavior of
    classes instances, but statecharts may also describe the behavior of other
    model entities such as use-cases, actors, subsystems, operations, or
    methods." [A method is an instance of an operation. Therefore, you must have
    implementation level knowledge, in this case, the programming language used,
    to know about a method. This is antithetical to good modeling principles
    which state that a model should be implementation independent.]
    3. In 3.74.3: "That StateMachine may be owned by an instance of a model
    element capable of dynamic behavior, ..."
    4. Event-name or action-label??? 3.75.2 says "Internal transitions
    compartment This compartment holds a list of internal actions or activities
    that are performed while the element is in the state. The notation for such
    each of these list items has the following general format: action-label '/'
    action-expression" and later "The general format for the list item of an
    internal transition is: event-name '(' comma-separated-parameter-list ')'
    '[' guard-condition']' '/'action-expression". Which is to be used? Or is
    action-label the name of the expression: event-name '('
    comma-separated-parameter-list ')' '[' guard-condition']'? Compare this with
    3.78.2 which has " event-signature '[' guard-condition ']' '/'
    action-expression. The event-signature describes an event with its
    arguments: event-name '(' comma-separated-parameter-list ')'"
    5. In 3.75.2: "If the event has parameters, they can be used in the
    action expression through the current event variable." Should it be
    action-expression for consistency?
    6. 3.75.4: "The action expression maps into the ActionSequence and
    Guard for the Transition." Should it be action-expression?
    7. 3.75.4: "The Transition has a trigger Association to the Event." The
    term trigger does not appear to be unambiguously defined. It was previously
    mentioned in the section. " In all other cases, the action label identifies
    the event that triggers the corresponding action expression." Is this
    sufficient? It is not in the glossary.
    8. The use of the term pseudostate is not consistent throughout. In the
    glossary it is "pseudo-state", with a hyphen. In 2.12.2 it is pseudostate.
    9. 3.76.3, Figure 3-63: Passed and Failed are activities and not
    states. Change to the right graphic.
    10. 3.78.1: " A simple transition is a relationship between two states
    indicating that an object in the first state ..." Object should probably be
    instance. (This should be looked at throughout the document.) I suspect this
    opens a can of worms but the definitions, and probably the concepts
    themselves, of instance and object need clarification.
    11. 3.80.4 Figure 3-66: Each of the two diagrams should have a top level
    state around it to keep the rule about not transitioning from a stubbed
    state to an external state. See below. Granted they are implied but we are
    trying to be clear.
    12. 3.80.5: Eliminate the word "elision". It is not a common word plus
    it appears to be misused. "Elision is the omission of sounds, syllables, or
    words in spoken or written discourse
    </lingualinks/library/literacy/glossary/cjJ405/tks2801.htm>." and "The
    omission of a letter or syllable as a means of contraction, generally to
    achieve a uniform metrical pattern, but sometimes to smooth the
    pronunciation; such omissions are marked with an apostrophe <gl-a.html>.
    Specific types of elision include aphaeresis <gl-a.html>, apocope
    <gl-a.html>, syncope <gl-s.html>, synaeresis <gl-s.html> and synaloepha
    <gl-s.html>." Suggest replace with shortcut.
    13. 3.81.2: " represented by a a small white circle" Eliminate one "a".
    14. 3.83.2: " The bound is either a positive integer or a star ('*') for
    unlimited." "Unlimited" should be "any number" and "star" should be
    "asterisk".

  • Reported: UML 1.3 — Thu, 2 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML 1.4 RTF Issue: Namespace notation too specific

  • Key: UML14-1034
  • Legacy Issue Number: 3408
  • Status: closed  
  • Source: ObjectSwitch ( Conrad Bock)
  • Summary:

    Namespace notation too specific

    The model management namespace containment notation (the circled plus
    sign ) should be available on all namespace elements.

  • Reported: UML 1.3 — Wed, 8 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    declined

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 editorial comments (Part 6 - Use Case Diagrams)

  • Key: UML14-1032
  • Legacy Issue Number: 3399
  • Status: closed  
  • Source: Technical Resource Connection ( Brian Cook)
  • Summary:

    Suggestions for the UML Notation Guide, Part 6 - Use Case Diagrams
    1. 3.56.1: Use different class names in the relationships: extend use A
    & B, generalization use C & D, include use E & F for clarity.

  • Reported: UML 1.3 — Thu, 2 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    declined

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 editorial comments (Part 3 - Behavioral Elements)

  • Key: UML14-1031
  • Legacy Issue Number: 3398
  • Status: closed  
  • Source: Technical Resource Connection ( Brian Cook)
  • Summary:

    Part 3 - Behavioral Elements
    1. In 2.8: typo "that is used to model proocesses." Should be
    "processes"
    2. In 2.9.2, Figure 2-15: "Clas" should be "Class"
    3. In 2.9.2, Figure 2-15 and Argument: There is an internal
    inconsistency. The relationship from Argument to Action is diagrammed as a
    composition. The text says: [An argument] "is aggregated within an action."
    Is it aggregation or composition?
    4. Continuing #3: Also the glossary definition of composition ties
    non-fixed multiplicity and coincident lifetimes. Does 0..1 count as
    non-fixed? If so, where is it defined? What does this distinction mean in
    the first place?
    5. In 2.9.2, Instance: "The instance construct defines an entity to
    which a set of operations can be applied ..." Operation should be method.
    Operations exist at the Classifier level; methods are instances of
    operations and exist at the instance (application) level.
    6. In 2.9.2, Instance\Tagged Values\persistent: "Persistence denotes
    the permanence of the state of the instance, marking it as transitory (its
    state is destroyed when the instance is destroyed) or persistent (its state
    is not destroyed when the instance is destroyed)." Seems it should say that
    transitory is the default. Else add transitory as a tagged value.
    7. In 2.9.2, Figure 2-16: Would two refinements be clearer than the two
    associations from Link to Association and LinkEnd to AssociationEnd since
    they are a different levels of abstraction? Also from Instance to
    Classifier? [Should the relationship from Method to Operation in 2.5.2,
    Figure 2-5 also be a refinement?]
    8. In 2.9.2, Figure 2-16: Should the composition relationship from
    Attribute to Classifier also be modeled?
    9. In 2.9.2, Figure 2-16: The element Instance is abstract according to
    the text and should be stereotyped <<abstract>>.
    10. In 2.9.2, Link: "In the metamodel Link is an instance of an
    Association. It has a set of LinkEnds that matches the set of
    AssociationEnds of the Association." In Figure 2-16 LinkEnd to Link is

    {ordered}

    . Should this be consistent with AssociationEnd to Association?

  • Reported: UML 1.3 — Thu, 2 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 editorial comments (Part 2 Diagram Elements)

  • Key: UML14-1030
  • Legacy Issue Number: 3397
  • Status: closed  
  • Source: Technical Resource Connection ( Brian Cook)
  • Summary:

    Part 2 - Diagram Elements
    1. 3.6.4: Title should be 'Examples' for clarity. Or add a subheading
    to communicate that a list of examples follows.
    2. 3.10.3: same as above
    3. 3.10.7: same as above
    4. 3.12: "Examples of such pairs in UML include: Class-Object,
    Association-Link, Parameter-Value, Operation-Call, and so on." Should
    Operation-Call be Operation-Method? 3.59.5 defines a call as procedural.

  • Reported: UML 1.3 — Thu, 2 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML 1.4 RTF Issue: Association generalization has notation but no semantics

  • Key: UML14-1029
  • Legacy Issue Number: 3396
  • Status: closed  
  • Source: ObjectSwitch ( Conrad Bock)
  • Summary:

    Association generalization has notation but no semantics.

    The notation document says:

    [p 3-80] Generalization may be applied to associations as well as
    classes, although the notation may be messy because of the multiple
    lines. An association can be shown as an association class for the
    purpose of attaching generalization arrows.

    But no semantics is defined for association generalization. That's why
    it's on the UML 2.0 roadmap. The above should be removed for 1.4.

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML 1.4 RTF Issue: Ordering of attribute values

  • Key: UML14-1028
  • Legacy Issue Number: 3395
  • Status: closed  
  • Source: ObjectSwitch ( Conrad Bock)
  • Summary:

    Ordering of attribute values

    Link ends can be ordered, by setting the ordering metaattibute of
    AssociationEnd to "ordered". But attribute values currently cannot be
    ordered. The metaclass StructuralFeature should have an ordering
    metaattribute.

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML 1.4 RTF issue: OCL: Unary operator "-" missing

  • Key: UML14-1023
  • Legacy Issue Number: 3386
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The unary prefix operator "-" is missing in the definition of the OCL
    type "Real". It only defines binary "-".

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML 1.4 RTF Issue: Multiple languages for uninterpreted strings

  • Key: UML14-1027
  • Legacy Issue Number: 3394
  • Status: closed  
  • Source: ObjectSwitch ( Conrad Bock)
  • Summary:

    Multiple languages for uninterpreted strings

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

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    duplicate of 3391

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML 1.4 RTF Issue: changeability in associations

  • Key: UML14-1026
  • Legacy Issue Number: 3393
  • Status: closed  
  • Source: ObjectSwitch ( Conrad Bock)
  • Summary:

    Changeability in associations

    Changeability as currently described does not make sense when applied to
    associations. It is summarized as:

    [p 2-21] When placed on a target end, specifies whether an instance of
    the Association may be modified from the source end. Possibilities
    are:

    What does "modified from the source end" mean?

    [p 2-21] frozen - No links may be added after the creation of the
    source object.

    [p 2-57] the link cannot be modified once it has been initialized
    (frozen).

    No links may be added to what? The source/target objects, the link
    itself? See below for the conflicting answers:

    [p 2-21] addOnly - Links may be added at any time from the source
    object, but once created a link may not be removed from the
    source end.

    [p 2-57] new links of the association may be added but not removed or
    altered (addOnly)

    Again, what does it mean to modify an association from "an end"? It
    doesn't mean the objects at the ends, according to this:

    These constraints do not affect the modifiability of the objects
    themselves that are attached to the links. Moreover, t ) the
    classifier, or (a child of) the classifier itself.

    (The second sentence has too many typos to understand).

    Finally, compare the above to:

    An association-end also specifies whether or not an instance playing
    that role in a connection may be replaced by another instance. It may
    state that no constraints exist (changeable), that the link cannot be
    modified once it has been initialized (frozen), or that new links of
    the association may be added but not removed or altered (addOnly).

    The first sentence implies the link is what is frozen, but that isn't
    consistent with the last sentence.

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML 1.4 RTF issue: OCL: grammar is ambigous

  • Key: UML14-1025
  • Legacy Issue Number: 3389
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In OCL versions prior to UML 1.3, type names had to begin with a
    upper-case character. This was changed, and the rules for typeName and
    name are now identical.
    Unfortunately, this introduces an ambiguity into the OCL grammar rule
    pathName.
    pathName := (<typeName> | <name>) ("::" (<typeName> | <name>))*

    This problem could be solved by dropping the distinction between names
    and type name completely. The path name rule could be changed to:
    pathName := <name> ("::" <name>)*

    Now, the problem arises that it is not possible to distinguish between
    property accesses and type literals if they have the same name. For
    example, consider the following UML model:

    • Classes TypeA, typeB, TypeC
    • Association between TypeA and TypeC, association end at TypeC is
      named typeB.
      The expression "typeB" in the context of "TypeA" might either be
      interpreted as a navigation to the association end
      "typeB", and hence result in an object of "TypeC", or as the type
      "typeB".
  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML 1.4 RTF issue: OCL: navigation context in iterate

  • Key: UML14-1024
  • Legacy Issue Number: 3387
  • Status: closed  
  • Source: Anonymous
  • Summary:

    he term "navigation context" is used to denote the
    start of an OCL navigation expression. The standard navigation context
    is "self", or the iterator name in a subexpression
    that is the argument to collection operations like "forAll".

    The standard navigation context in the argument expression of the
    operation "iterate" is not clearly defined in the OCL specification. It
    might either be the iterator or the accumulator.

    Proposed solution:
    Since none of these alternatives is clearly more intuitive than the
    other, we would favour to demand the explicit qualification of the
    navigation context in iterate's argument expression through either the
    iterator or accumulator name or "self".

    It might be noted that similarly, the default navigation context is not
    clear if the operation "forAll" is used with two or more iterators.

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML 1.4 RTF issue: OCL: Iterator declarators

  • Key: UML14-1021
  • Legacy Issue Number: 3384
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The collection operations "iterate", "forAll", "exists",
    "select", "reject", and "collect" can have declarators.
    Declarators should also be allowed for "sortedBy" and "isUnique",
    or, more generally, for all collection operations
    with an OclExpression as parameter. This is not stated clearly stated by
    the specification, though it's propably intended.

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

OCL: Declarators for iterate

  • Key: UML14-1020
  • Legacy Issue Number: 3383
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The declarators for the collection operation "iterate" have a different
    format than those for "forAll" and other operations. The specification´s
    grammar allows only the form used with "forAll". The production rule
    "declarator" should be updated as follows:

    declarator :=
    ( name ("," name)* (":" simpleTypeSpecifier)? "|" ) |
    ( name ":" simpleTypeSpecifier ";" name simpleTypeSpecifier "="
    expression "|" )

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML 1.4 RTF issue: OCL: Precedence of relational operators

  • Key: UML14-1022
  • Legacy Issue Number: 3385
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The OCL specification defines a precedence of "<", ">", "<=" and
    ">=" over "=" and "<>". This is misleading, because the OCL
    grammar does not allow relational expression with more than one
    relational operator, so that expressions like "a>b = c<d" are illegal
    anyway.

    Proposed Solution: Change the precedence rules to define that "<", ">",
    "<=", ">=", "=" and "<>" have the same precedence.

  • Reported: UML 1.2 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

In 2.10.4, semantics of Collaboration, the 1st sentence is confusing

  • Key: UML14-1019
  • Legacy Issue Number: 3378
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In 2.10.4, semantics of Collaboration, the 1st sentence is confusing. It should be "The term instance of a collaboration (also collaboration instance) denotes the set of instances of Classifiers that play roles defined by ClassifierRoles in one specific collaboration specification."

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Page 2-114, 2nd paragraph. It should be collaboration template

  • Key: UML14-1016
  • Legacy Issue Number: 3374
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Page 2-114, 2nd paragraph. It should be collaboration template rather than template collaboration. This distinction is important: a template is not a special form of the templatized model element. (Much like a process description is not a described process or a painted car is not car paint).

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    fixed

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Confusing wording

  • Key: UML14-1015
  • Legacy Issue Number: 3373
  • Status: closed  
  • Source: Anonymous
  • Summary:

    5. In 2.10.2 and 2.10.4, the words "classifier roles", "ClassifierRoles" and "instances of ClassifierRole" are used interchangeably. I suggest to stick to one way of doing it and avoid the others.

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    fixed

  • Updated: Fri, 6 Mar 2015 21:37 GMT

In 2.10.5, you give pattern a non-standard definition

  • Key: UML14-1017
  • Legacy Issue Number: 3375
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In 2.10.5, you give pattern a non-standard definition. A pattern is not a formal template. For any given design pattern, there may be any number of collaboration templates that represent a category of design structures that will be considered pattern instances by experts. So the relationship between design pattern and collaboration template is 1 to n, similar to the relationship between collaboration specification template and collaboration specification.

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Ad 3.69.3. In these paragraphs, it should be "Classifier" rather than "Cla

  • Key: UML14-1018
  • Legacy Issue Number: 3377
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Ad 3.69.3. In these paragraphs, it should be "Classifier" rather than "Class".

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Terminology: Collaboration and Collaboration Template

  • Key: UML14-1010
  • Legacy Issue Number: 3367
  • Status: closed  
  • Source: Anonymous
  • Summary:

    suggest to stick with one consistent terminology and avoid imprecise variations and synonyms.

    2.1 Collaboration should be a shortcut for Collaboration Specification. Frequently, however, it also means Collaboration Instance. Here, I suggest to drop the rather awkward "collaboration (diagram) on a specification level" and make it collaboration specification, etc.

    2.2 IMO, it should be collaboration template rather than template collaboration or parameterized collaboration. First of all, a template collaboration is a collaboration, not a template, so this is confusing. Also, should UML 2.0 solve the template problem in ModelElement, it will be the natural thing anyway.

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

use of the phrase "In the metamodel..." is unclear

  • Key: UML14-1014
  • Legacy Issue Number: 3372
  • Status: closed  
  • Source: Anonymous
  • Summary:

    4. In 2.10.2, the use of the phrase "In the metamodel..." is unclear to me. (It typically starts the second paragraph of a concept definition. Using ClassifierRole as the example, it should be "In a model, an (instance of) ClassifierRole specifies".

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

why is AssociationRole is a subtype of Association?

  • Key: UML14-1013
  • Legacy Issue Number: 3371
  • Status: closed  
  • Source: Anonymous
  • Summary:

    3. It is unclear to me, why AssociationRole is a subtype of Association, and, similarly, why AssociationEndRole is a subtype of AssociationEnd. The resulting recursive relationship suggests that AssociationRoles can serve as the base for further AssociationRoles, the meaning of which is unclear to me. (Some people suggest to have roles of roles, but I think this confuses concepts.)

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

2. In 2.10.1, 3rd paragraph, it should be "OOram", not "OOFRam".

  • Key: UML14-1012
  • Legacy Issue Number: 3370
  • Status: closed  
  • Source: Anonymous
  • Summary:

    2. In 2.10.1, 3rd paragraph, it should be "OOram", not "OOFRam".

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    fixed

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Focus is on 2.10 Collaborations

  • Key: UML14-1011
  • Legacy Issue Number: 3369
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1. I suggest to consistently use "collaboration specification" and "collaboration instance" rather than the awkward "collaboration diagram on an instance or specification level". The use of "collaboration" should probably be discouraged. If it cannot be avoided, it should default to "collaboration specification".

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Design patterns and collaboration templates.

  • Key: UML14-1009
  • Legacy Issue Number: 3366
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The current UML definition of design pattern is oversimplifying the situation. The relationship between a design pattern and collaboration template is 1 to n. For any given design pattern, you can find any number of templates as formal abstract specifications of specific collaboration specifications.

    The structure diagram in the GOF book illustrates one common abstract form of the design pattern, but certainly not the only one. Other variants, typically more complex ones, are hidden in the implementation section. The reason for this: in the opinion of its fathers, design patterns can not be formalized.

    The best way to escape the debate of whether to formalize or not is to distinguish between a non-formalizable pattern and formalizable templates. This is also how people do it in practice, if you take a look at the many different abstract descriptions (= templates) of, say, the Observer pattern.

  • Reported: UML 1.2 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

"Unused" data types

  • Key: UML14-1008
  • Legacy Issue Number: 3325
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    During a discussion of "physical" metamodel (i.e., the MOF-compliant
    metamodel) issues, the following data types defined in the logical
    metamodel Data Types package were identified as unused anywhere else:

    o MessageDirectionKind
    o Time
    o Mapping
    o TypeExpression

    This note responds to an action to search the UML Specification document
    to make sure this is actually true before we consider removing them from
    the logical model. I performed this search by doing using the Acrobat
    "Find" command on the PDF file for the UML Specification, which also
    searches the diagrams.

    o MessageDirectionKind: This data type is actually described in the
    semantics as "no longer used in UML." And, indeed, it appears no where
    in the document outside of the Data Types section, except for the index
    and the parts of the IDL and the physical metamodel generated from the
    Data Types package.

    o Time: This data type is only referenced in the logical metamodel in
    the text of the definition of a TimeExpression: "In the metamodel
    TimeExpression defines a statement which will evaluate to an instance of
    Time when it is evaluated." Thus, this type is not really necessary for
    defining the metamodel, since TimeExpression is not further specified
    (this will probably have to be dealt with as part of the action
    semantics work.) In the IDL, the Time data type is implemented as
    "UmlTime", which is a typedef of float. It appears as Time in the
    physical metamodel.

    o Mapping: This data type is only reference in the logical metamodel in
    the text of the definition of a MappingExpression: "An expression that
    evaluates to a mapping." As with Time, this type is not really necessary
    for defining the metamodel, since the form of its "body" is not further
    specified. It is implemented as a string in the IDL, but has no body
    attribute in the physical metamodel.

    o TypeExpression: This data type appears nowhere else in the Semantics
    chapter than the Data Types section (except for the index). However, in
    Notation Guide states:

    "The type of an attribute is a TypeExpression. It may resolve to a class
    name or it may be complex, such as array[String] of Point. In any case,
    the details of the attribute type expressions are not specified by UML.
    They depend on the expression syntax supported by the particular
    specification or programming language being used."

    Unfortunately, the abstract syntax requires that the type of an
    attribute (or any structural feature) by a classifier (see Section
    2.5.2). There is thus no way to map the notation for an attribute,
    unless the type expression happens to be the name of a classifier. The
    use of a general type expression is desirable, so this should be
    corrected.

    (One possible approach, which would preserve the definition of an
    attribute type as a classifier, would be to make TypeExpression a child
    of Classifier as well as Expression. This could also be useful on
    instance diagrams, since it would allow one to show instances of
    implementation-specific type expressions.)

  • Reported: UML 1.2 — Wed, 16 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Notation for Namespace ownership

  • Key: UML14-1007
  • Legacy Issue Number: 3316
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    The contents of a package (i.e. the ownedElements of the Namespace of
    the the package) can be shown in two different ways: either enclosed by
    the package symbol or attached with the encircled plus sign (figure 3-6
    in the Notation Guide).

    Even though classes are also namespaces, then the same options do not
    apply for them. In fact there is no notation for this at all. It is
    possible to have class boxes enclosed by a class box, but it has another
    mapping than notation elements being enclosed graphically by a package
    symbol: according to 3.47.5 of the Notation Guide "A class box with
    contained class boxes maps into a set of composition associations;".

    One may argue that packages are different from classes, but subsystems
    come close to objects. A Subsystem (in its capacity of being a Package)
    have the two options of showing the contents, i.e. it is possible to
    have class boxes within the Subsystem symbol. The meaning of this should
    be (according to the text on Package) that the classes are defined
    within the Subsystem. However, the Semantics of Subsystem says that "the
    semantics of an instantiable susbsystem is similar to the semantics of a
    composite class", which means that the enclosed class boxes should be
    interpreted in the same way as for class boxes enclosed by a class
    boxes.

    The enhancement of this should be that notation for namespace
    "containment" (ownedElement) and object containment (composition) should
    be clarified and made similar for similar concepts.

  • Reported: UML 1.2 — Fri, 11 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: Typo in state exit

  • Key: UML14-1006
  • Legacy Issue Number: 3297
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    This should refer to "exit" not entry:

    [p 134] An optional action that is executed whenever this state
    is exited regardless of which transition was taken out of the
    state. If defined, entry actions are always executed to
    completion only after all internal activities and transition
    actions have completed execution.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Misleading description of feature inheritance on roles.

  • Key: UML14-1005
  • Legacy Issue Number: 3296
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [p 109, semantics] the former roles may possibly be
    specialized with new features (as classifier roles are also
    generalizable elements).

    The parenthetical remark is misleading. Classifier roles are
    not allowed to have features of their own (see OCL on
    ClassifierRole). They only have links to features, ie,
    instances of the meta-association between ClassifierRole and
    Feature. These links don't automatically inherit to children
    of a ClassifierRole, because inheritance only applies to actual
    features of the role, which it isn't allowed to have. So the
    fact that classifier roles are generalizable elements doesn't
    achieve the inheritance of the links to features. That is a
    behavior introduced by role specialization.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Incorrect example of constraining elements in collaborations.

  • Key: UML14-1001
  • Legacy Issue Number: 3292
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 3-56, p 117 of the collaboration notation, it intended to
    give an example of constraining elements, but it shows
    generalization relationships between roles instead. I thought
    the constraining elements would refer to the base classifiers and
    associations, not the roles. Using generalization links between
    roles has a different semantics than between the base classifiers
    (see Semantics of Collaboration 2, above).

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: Messages do not have signatures

  • Key: UML14-1004
  • Legacy Issue Number: 3295
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [p 126, notation] A signature is a string that indicates the
    name, the arguments, and the return value of an Operation, a
    Message, or a Signal.

    Messages don't have signatures. "Message" can be dropped from
    the above sentence.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: Guard condition in collaborations poorly named.

  • Key: UML14-1003
  • Legacy Issue Number: 3294
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [p 125, notation] predecessor guard-condition
    sequence-expression return-value := message-name
    argument-list

    The descriptions after this imply that "predecessor" and "guard
    condition" are the same:

    [p 125, notation] The meaning is that the Message is not
    enabled until all of the communications whose sequence
    numbers appear in the list have occurred (once the
    communication has occurred the guard remains
    satisfied). Therefore, the guard condition represents a
    synchronization of threads.

    It's confusing the have two names for the same thing. I
    thought on first glance that some bracketed notation as in
    state machine were supported at this position in the label, but
    that is in the recurrence part of sequence expressions.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: Multi-objects in collaborations

  • Key: UML14-1002
  • Legacy Issue Number: 3293
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [p 122] A multi-object symbol maps to a set of Objects that
    together conforms to a ClassifierRole with multiplicity
    "many".

    There is no construct for "set" in UML.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: Duplicate association end names from Constraint.

  • Key: UML14-1000
  • Legacy Issue Number: 3290
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The Constraint meta-type, in the Extension Mechanisms meta-model, has
    two associations with the same association end name on the "opposite"
    ends ("constrainedElement"). Assuming that UML meta-classifiers should
    adhere to the OCL for regular classifiers, then this is ill-formed
    according to OCL 3 of Classifier, p 47:

    [3] No opposite AssociationEnds may have the same name within a Classifier.

    self.oppositeEnds->forAll ( p, q | p.name = q.name implies p = q )

    The same may be true for the Collaboration meta-type (the
    "ownedElement" association end is duplicated), but these two are
    specializations of an association inherited from ModelElement, so
    perhaps that is acceptable.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: Create action in collaborations

  • Key: UML14-999
  • Legacy Issue Number: 3289
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Using a role as the target of a create action does not support
    instantiation of children of the role classifier. [p 2-112
    collaboration semantics].

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: What does it mean for ReturnAction to be synchronous?

  • Key: UML14-998
  • Legacy Issue Number: 3288
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    UML RTF 1.4 Issue: What does it mean for ReturnAction to be synchronous?

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: Action composition meta-modelled improperly:

  • Key: UML14-997
  • Legacy Issue Number: 3287
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Action composition meta-modelled improperly: action sequence
    inherits from action. Should be Gamma's composition model with
    action as a sibling of action sequence.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: Confusing example of sequence diagram

  • Key: UML14-994
  • Legacy Issue Number: 3282
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [p 102, notation] An arrow with the arrowhead pointing to an
    object symbol within the frame of the diagram maps into a
    Stimulus dispatched by a CreateAction

    Figure 3-48 [p 100] shows the above for ob1:C1, and ob2:C2, but
    with lifelines below each one sending messages (eg, to ob2:C2
    and ob4:C4 respectively). Does this mean the constructor of
    the object, that is the object creation method, is sending
    messages? These objects aren't notated as active, so they
    can't send messages on their own. It would be good to explain
    this in the above text.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: Arrowhead semantics in collaboration unclear

  • Key: UML14-993
  • Legacy Issue Number: 3281
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of the stick arrowhead is described as:

    [p 124, notation] Flat flow of control. Each arrow shows the
    progression to the next step in sequence. Normally all of the
    messages are asynchronous.

    [p 128, notation] stick arrowhead: flat flow of control
    (normally asynchronous).

    What is a "flat flow of control"? How is it different than an
    asynchronous operation or signal? It is ambiguous to say that it
    is "normally" asychronous. How does the user tell whether it is
    or isn't in any particular case?

    It is more confusing when compared to the descriptions for
    half-stick:

    [p 124, notation] Asynchronous flow of control. Used instead of
    the stick arrowhead to explicitly show an asynchronous
    communication between two Objects in a procedural sequence.

    [p 128] half stick arrowhead: an asynchronous operation invocation

    How is a "flat flow of control" different from a "procedural
    sequence"?

    This topics has been very confusing for the agent modelers, who
    are using sequence diagrams to model agent protocols.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4: Description of context role, between state machine and model

  • Key: UML14-992
  • Legacy Issue Number: 3280
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Each state machine is owned by exactly one model element.

    The meta-model shows 0..1.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: Flow relationship has the incorrect semantics

  • Key: UML14-996
  • Legacy Issue Number: 3284
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Flow relationship has the incorrect semantics specified for it:

    [p 2-33] It usually connects an activity to or from an object
    flow state, or two object flow states. It can also connect from
    a fork or to a branch.

    Compare:

    <<become>>

    Specifies a Flow relationship, source and target of which
    represent the same instance at different points in time, but
    each with potentially different values, state instance, and
    roles. A Become Dependency from A to B means that instance A
    becomes B with possibly new values, state instance, and roles at
    a different moment in time/space.

    <<copy>

    Specifies a Flow relationship, the source and target of which
    are different instances, but each with the same values, state
    instance, and roles (but a distinct identity). A Copy Dependency
    from A to B means that B is an exact copy of A. Future changes
    in A are not necessarily reflected in B.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: <> keyword/stereotype

  • Key: UML14-995
  • Legacy Issue Number: 3283
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The <<primitive>> keyword/stereotype used in the meta-models of
    the datatype section are not defined. Isn't clear what level the
    datatype meta-model elements are at.

  • Reported: UML 1.2 — Tue, 8 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: Deferred event ambiguity

  • Key: UML14-989
  • Legacy Issue Number: 3277
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What happens when a event is defered in one region, but not another? Is
    it left on the queue accessible to both regions, even if it has already
    been consumed by one of the regions? Semantics says deferred events are
    kept if not used in one of the regions. So if one region uses it, it is
    lost, even if it is deferred in the other region. User cannot use event
    in both regions.

    Reference manual says:

    At the time that an object processes an event, it may be in one or more
    concurrent states. Each state receives a separate copy of the event and
    acts on it independently. Transitions in concurrent states fire
    independently. One substate can change without affecting the others,
    except on a fork or join caused by a complex transition (described
    later).[p 443, Reference Manual]

    and refers to an internal queue of events:

    Deferred events. A list of events whose occurrence in the state
    is postponed until a state in which they are not deferred becomes
    active, at which time they occur and may trigger transitions in
    that state as if they had just occurred. The implementation of
    such deferred events would involve an internal queue of
    events. [p 438]

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: Join in collaboration

  • Key: UML14-988
  • Legacy Issue Number: 3275
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    It is possible to model forks in sequence charts using multiple
    asynchronous messages. However, it is not possible to model
    joins, because return messages are considered activitators, and
    multiple activators are not allowed.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Previously considered for 1.4 and closed w.o. change

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: State constraint on host object

  • Key: UML14-987
  • Legacy Issue Number: 3274
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    States currently do not model the conditions required for an
    object to be in a particular state. A constraint note can be
    linked to a state, but there is no specification of when the
    constraint should be tested. It could be tested when the object
    enters the state, leaves the state, or at any other time. Even if
    this were unambiguous, the consequence of violating the constraint
    is not defined, namely, to transition the machine to a state that
    has a constraint satisfied by the object. This might be modeled
    as a change-event trigger on an exiting transition, but it would
    be redundant with the constraint recorded on the state and with
    triggers on other transitions leaving the state, thereby impairing
    maintainability.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: ownerScope and targetScope

  • Key: UML14-991
  • Legacy Issue Number: 3279
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ownerScope in Feature has the same semantics as targetScope in
    StructureFeature. Aren't they clashing?

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: Guard evaluation for choice points.

  • Key: UML14-990
  • Legacy Issue Number: 3278
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Make guard evaluation procedure for choice points more explicit.
    It is not clear from the specification whether all guards are
    required to be evaluated, even after one is found to be true.
    This affects performance/real time issues even if the guards have
    no side-effects.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

UML RTF 1.4 Issue: Notation for call state

  • Key: UML14-986
  • Legacy Issue Number: 3273
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    It is very common for readers of activity diagrams to look at a
    call state and want to see what type of object is having an
    operation invoked by the action of that state. There is
    currently no adopted notation for this. Notes are too bulky and
    non-standard for this application. Without this notation
    activity diagrams appear non-object-oriented.

  • Reported: UML 1.2 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

State machine name space

  • Key: UML14-985
  • Legacy Issue Number: 3259
  • Status: closed  
  • Source: Anonymous
  • Summary:

    What is the reason that Statemachine and State are not Namespaces. Is it so that names are not supposed to be defined within these, or do names end up in the Namespace of the context model element?

  • Reported: UML 1.2 — Thu, 27 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    duplicate 3341

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Issue Activity Package

  • Key: UML14-984
  • Legacy Issue Number: 3244
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    ISSUE FOR UML, SECTION ActivityGraphs
    -------------------------------------

    Description:
    ------------
    The metaclass ClassifierInState is too limited and can be generalized
    to become more useful. It might show to be completely unneccesary.

    The Definition of ClassifierInSate in UML 1.3 is as follows:

    A classifier-in-state characterizes instances of a given classifier
    that are in a particular state or states. ......
    ClassifierInState is a child of Classifier and may be used in static
    structural models and collaborations (e.g., it can be used to show
    associations that are only relevant when objects of a class are in a
    given state).

    Issue 1:
    This might be a useful concept, but defined in a too limited way.

    Specifying that only instances which fulfil certain condiations
    can be used is meaningful at many places. However, these restrcitions
    are not based only on the state in which the instance is. They can also
    be based on attribute values and link values.
    Therefore the ClassifierInState is too restricted, because the
    condition can only be a (or more) state(s).

    Solution:
    ---------
    Instead I would like to define a metaclass RestrictedClassifier (or
    ConstrainedClassifier) instead of ClassifierInState. The definition should
    be:

    A RestrictedClassifier characterizes instances of a given classifier
    that conform to certain constraints.

    For modeling the restrictions UML already has a perfect metaclass called
    Constraint. A RestrictedClassifier has an association to Constraint with
    multiplicity 1..* (at least one constraint)
    The constraint can either be stated in OCL, which allows one to specify
    generically any restrictions you want (or in any other language).
    OCL allows to check whether an instance is in a certain state by the
    expression "instance.oclInState(statename)", and is therefore able to
    specify at least everything you can specify with ClassifierInState.

    Potentially we could define a stereotype (e.g. <<restriction>>) for this
    kind of Constraint.

  • Reported: UML 1.2 — Mon, 24 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

  • Updated: Fri, 6 Mar 2015 21:37 GMT

ISSUE FOR UML, SECTION ActivityGraphs

  • Key: UML14-983
  • Legacy Issue Number: 3243
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Description:
    ------------
    The metaclass ClassifierInState is unneccesary and can be replaced by
    existing metaclasses.

    Discussion
    -----------
    In a number of cases a specific ClassifierInState is not needed. When e.g.
    a ClassifierRole always has certain restrictions, these restrictions can be
    modeled with a Constraint (stereotypes as <<invariant>>) on the
    ClassifierRole.

    The use of ClassifierInState in activity graphs is to show the output or input
    parameter to actions. The same concept can be modeled in a unified way by
    using existing preconditions and postconditions.

    To denote that an object must be in a state after the action can be modeled
    by a
    <<postcondition>> Constraint attached to the action state.
    To denote that an object must be in a state before the action can be
    modeled by a
    <<precondition>> Constraint attached to the action state.
    An action is a piece of behavior and can have pre- and postconditions attached
    to it. using that, the ClassifierInState might turn out to be superfluous.

    Solution
    --------
    Remove ClassifierInState metaclass and replace it by a description how
    existing
    metaclasses can be used to solve the same modeling problem.

  • Reported: UML 1.2 — Thu, 24 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Shouldn't the UML Package be allowed to own/reference UML 'Instances'?

  • Key: UML14-982
  • Legacy Issue Number: 3241
  • Status: closed  
  • Source: Anonymous
  • Summary:

    We are currently implementing the UML spec into java and have stumbled upon the following problem:
    According to the Model Management package, a UML Package can only own/reference Packages, Classifiers, ..., and Stereotypes.
    My question is, where to put UML 'Instances' (Common Behavior package, p. 2-89) in the model?

    Shouldn't the UML Package (p. 2-173 & 2-175) be allowed to own/reference UML 'Instances'?

  • Reported: UML 1.2 — Thu, 20 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Inheritance of Stereotypes

  • Key: UML14-981
  • Legacy Issue Number: 3210
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: The semantics of inheritance (UML 1.3, ad/99-06-8, p. 60-61) does
    not include Stereotypes as being among the things that a subclass inherits
    from its superclasses.

    Recommendation: Explicitly specify that Stereotypes are inherited.

    Discussion: UML specifies that Constraints are inherited. A Stereotype is
    logically a constraint, and can even formally define Constraints that apply
    to stereotyped ModeledElements. Consider a Class A that is stereotyped S, where C is the Constraint that the Stereotype definition specifies for all ModelElements stereotyped S. Now consider Class B that
    inherits A. It stands to reason that the Constraint C applies to Class B.

  • Reported: UML 1.2 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Why is "FinalState" a separate metaclass ?

  • Key: UML14-980
  • Legacy Issue Number: 3201
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    State Machines:

    Why is "FinalState" a separate metaclass ?

    It seems that a final state can be modeled as a kind of PseudoState
    (with PseudoStateKind = final).

    FinalState has no attributes of its own, and all associations inherited
    from State must be empty for a final state:

    • A final state cannot have an entry action
    • A final state cannot have an exit action
    • A final state cannot have an doActivity
    • A final state cannot have a deferrableEvent
    • A final state cannot have an internalTransition

    Could anybody explain the reason of existence for a FinalState metaclass ?

  • Reported: UML 1.2 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

  • Updated: Fri, 6 Mar 2015 21:37 GMT

OCL: Let-expressions

  • Key: UML14-977
  • Legacy Issue Number: 3148
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    his nice feature provides a useful shortcut for writing complex OCL
    expressions. However, it is under-defined both syntactically and
    semantically.

    Syntactically, why stop at one level, as specified by the grammar
    rule:

    expression := letExpression?
    logicalExpression

    To make the language more orthogonal, that rule should be
    replaced with:

    expression := ( letExpression expression )

    logicalExpression

    which, by the way, ensures the correct precedence and evaluation
    order. The generic form of the let expression is:

    let <variable> = <expression-1> in <expression-2>

    what is not so self-evident, is the following: this fancy syntax
    somehow hides the fact that semantically this is equivalent to the
    lambda-expressions known from functional analysis:

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Invalid OCL expression in initial transition

  • Key: UML14-979
  • Legacy Issue Number: 3153
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    OCL expression is duplicated with errors:

    "self.source.kind = #initial" should be
    "self.source.oclAsType(Pseudostate).kind = #initial"
    "self.StateMachine.top" should be "self.stateMachine.top"
    "self.trigger.operation" should be
    "self.trigger.oclAsType(CallEvent).operation"
    "self.StateMachine.context" should be "self.stateMachine.context"

  • Reported: UML 1.2 — Tue, 21 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

OCL: Samples of invalid typing

  • Key: UML14-978
  • Legacy Issue Number: 3149
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    There are some examples of OCL expressions with type errors.
    For example, in section 7.4.4. there is an OCL expression:

    1 + 'motorcycle'

    of which it is said that it is invalid because type Integer does
    not conform to type String. The conclusion is correct, but the reason
    for the expression above being invalid is entirely different.
    The reason for it is that type String does not confirm to type Real!

    Proposed solution:

    Rephrase the text in the OCL specification. And check other examples.
    ____________________________________________________________________________

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

OCL: class operation has no 'self'

  • Key: UML14-976
  • Legacy Issue Number: 3147
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    There is no 'self' object in preconditions and postconditions
    of class operations. For example the following:

    context X::increaseInstanceCounter()
    post: instanceCounter = instanceCounter@pre+1

    will not work, because "instanceCounter" is only a
    syntactic shortcut for the full form
    "self.instanceCounter", and, as already said, there is no
    valid self in this context.

    We can even allow a little syntactic trick along the lines of OCL
    case-sensitivity: when a class name is on the other end of an
    association, making its 1st letter lowercase actually denotes
    associated instance(s) of this class. Going the other way round, we
    may state that when self is written in a capitalized form Self, it
    actually denotes the context class, not object:

    context X::increaseInstanceCounter()
    post:
    Self.instanceCounter =
    Self.instanceCounter@pre+1

    This point clearly merits a discussion. The good thing is: even if
    the provisions for static class members are included in the OCL
    exactly as suggested above, all existing OCL code will remain
    valid.

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 21:37 GMT

OCL: String literals

  • Key: UML14-975
  • Legacy Issue Number: 3146
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    If, as I was told before, they are supposed to be similar to Java
    strings, the correct rule for string constants will be:

    string := "'" (
    (~["'","\\","\n","\r"] )

    ("
    "
    (
    ["n","t","b","r","f","\\","'","\""]
    ["0"-"7"]
    ( ["0"-"7"] ["0"-"7"]?)?
    )
    )
    )*
    "'"

    Allowing octal escapes only in the ASCII range is not really a part
    of syntax ­ it is a part of OCL semantics, and this is where it
    belongs.

    As a matter of fact, even that is not 100% right ­ because it doesn't
    allow for hexadecimal escape sequences ­ and allows to specify
    only ASCII characters (decimal codes 0..255), while in Java strings
    the hexadecimal escapes can be used to specify any UNICODE
    character.

    I am also wondering, why OCL insists that all strings should be
    ASCII strings? Is there a compelling reason for disallowing
    UNICODE strings (and thus having no support for international
    applications)?

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

OCL: Numeric constants missing

  • Key: UML14-974
  • Legacy Issue Number: 3145
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    The OCL chapter of the UML reference insists that not only there
    is a data type Real, but one can also write constants of this type.
    However, the OCL grammar does not allow for floating-point
    constants.

    To correct that, the rule for numbers:

    number := ["0"-"9"] (["0"-"9"])*

    could be rewritten as:

    number := ["0"-"9"] (["0"-"9"])*
    ( "." ["0"-"9"] (["0"-"9"])* )?
    ( ("e" | "E") ( "+" | "-" )? ["0"-"9"] (["0"-"9"])* )?

    to allow all traditional forms of Real constants, both with decimal
    point and with exponent (and both).

    The one mandatory digit after the decimal point is there on purpose,
    to make sure that in an OCL string like

    1..10

    (which is perfectly legal inside the OCL collection literal) the
    leftmost sub-string '1.' will not be incorrectly recognized as a real
    constant. This little trick allows writing lexical parser for the OCL
    that does not need more than one-character look-ahead.

    Proposed resolution:

    Agreed.
    ______________

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

OCL: Literal collections

  • Key: UML14-973
  • Legacy Issue Number: 3144
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Currently, the syntax for the literal collection allows either a single
    range of values, or a list of individual values:

    literalCollection := collectionKind "

    {" expressionListOrRange? "}

    "

    expressionListOrRange := expression
    ( ( "," expression )+

    ( ".." expression ) )?

    This is too complicated a rule for what could have been
    made much simpler:

    literalCollection := collectionKind "

    {" (collectionItem ("," collectionItem )+)? "}

    "

    collectionItem := expression ( ".." expression )?

    Which would also allow more general types of literal collections,
    like in:

    Set

    { 0..2, 3, 4, 5..15 }

    And is just as easy to parse.

    Proposed resolution:

    This is more generic and should be includes in the OCL grammar.
    grammar is ok.

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

OCL: Enumeration types inconsistent with UML metamodel

  • Key: UML14-972
  • Legacy Issue Number: 3143
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Enumerations are Datatypes in UML and have a name. They can be shown
    with the notation of a class. In the attribute box, the possible values
    of the enumeration are written. In fact these names are class
    constants (class-scopes frozen attribute) for the enumeration type.
    If we use this UML definition in OCL, the logical way to
    refer to them will be as class attributes, for which there is already a
    defined notation in OCL (Classname.attributeName):

    When we have Datatype named Sex with values 'female' or 'male'
    they can be used as follows:

    context Person inv:
    sex = Sex.male

    Also the enumeration type has a name, therefore the "var :
    enum

    { …}

    " type declaration in OCL is superfluous. We can use
    the typename instead: "var : EnumTypeName".
    A logical consequence of this is that the special notation for
    enumerations will disappear completely and only the above syntax is allowed.

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

OCL: Enumeration types

  • Key: UML14-971
  • Legacy Issue Number: 3142
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    When an enumeration constant is used, it has to be preceded by the
    hash '#' sign. While this is not strictly necessary, it certainly
    makes parsing easier and, therefore, can stand as it is.

    However, the need for the same hash characters in the definition of
    the enumeration types, like in

    enum

    { #male, #female }

    is what the OCL grammar currently requires ­ and in this context
    the hash characters should probably be abolished, because:

    • Their presence does not give anything significant to user
      because name conflicts can't happen inside the enumeration type
      definition. Everything inside the curly brackets {} is enumeration
      constants.
    • Normally, one can try to copy-paste some text between UML and OCL
      parts of the class model. This is made a bit tricky, because UML and
      OCL use
      different syntax for the enumeration types. It would
      be nice of OCL could adopt the UML syntax.
  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

OCL: Feature calls on default target

  • Key: UML14-970
  • Legacy Issue Number: 3141
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    The rule for non-terminal primaryExpression should be
    changed from

    primaryExpression := literalCollection

    literal
    pathName
    timeExpression? qualifier?
    featureCallParameters?
    "(" expression ")"
    ifExpression

    to

    primaryExpression := literalCollection

    literal
    featureCall
    "(" expression ")"
    ifExpression

    for two reasons:

    • It will become shorter
    • It describes what is going on more carefully ­ since
      what happens is exactly the feature call on the default
      object (self).

    Proposed sulution:

    Needs to be checked in detail to see what the consequences of this
    change are.

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

OCL: Are keywords reserved or not

  • Key: UML14-967
  • Legacy Issue Number: 3138
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Although the OCL specifies a respectable set of keywords (like
    "and", "if", etc.) the OCL reference says nothing about whether
    they are reserved or not. Clearly, a software designer is completely
    free to specify the class with an attribute called "if". Or, more
    probably, "context". Or any other OCL keyword. How, then, to
    parse an OCL constraint like:

    context if : X inv:
    if.then->size()>=else->size()

    (where if is used instead of self to designate the object an
    invariant is applied to, and then and else are its associations).

    Clearly, reserving keywords is a bad idea. The rule, which seems
    to work well (and has been tried in many real programming
    languages over decades) is:

    An identifier is recognized as a keyword if and only if it is
    encountered in a context where this keyword can legally
    appear.

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

OCL: Consistency in grammar description

  • Key: UML14-966
  • Legacy Issue Number: 3137
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Some non-terminals are enclosed in angle brackets <>,
    and others are not. This would not have been a big problem, if not for the
    fact that enclosing non-terminals in angle brackets is a technique from
    the original BNF specification format. So, we should either use it
    consistently for all non-terminals ­ or not use it at all.

    Proposed resolution:

    make the grammar description consistent.

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

"Physical" Metamodel References in Diagrams (uml-rtf)

  • Key: UML14-965
  • Legacy Issue Number: 3125
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The UML Specification contains UML diagrams of the "physical" metamodel, but
    the diagrams do not show which association ends have corresponding
    references. Using a UML facility requires knowing exactly where references
    occur, so showing references in diagrams is important.

    Recommendation: Make references explicit in the UML diagrams of the
    "Physical Metamodel". We can do this by showing each reference as an
    attribute with a stereotype of <<reference>>.

  • Reported: UML 1.2 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

textual syntax cannot deal with identical class names in different package

  • Key: UML14-969
  • Legacy Issue Number: 3140
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    We can imagine packages
    Package1 and Package2, both containing the class X, but we
    are free to use scope resolution to refer to these two different
    classes as Package1::X and Package2::X.

    However, we then should also be able to specify constraints on
    these classes. To do so, the context definition should allow the
    fully scoped class name to be used, like in

    context Package1::X inv: …

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

OCL: Class context specification grammar incomplete

  • Key: UML14-968
  • Legacy Issue Number: 3139
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    The text of the OCL specification says, that both following forms
    are allowed:

    context Company
    inv : self.numberOfEmployees > 50

    and

    context c : Company
    inv : c.numberOfEmployees > 50

    However, the OCL grammar does not allow the 2nd form.
    To allow the 2nd form, the rule

    classifierContext := <typeName>

    Should be changed to

    classifierContext := ( name ":" )?
    <typeName>

  • Reported: UML 1.2 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

"Physical" Metamodel References (uml-rtf)

  • Key: UML14-964
  • Legacy Issue Number: 3124
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    UML's "physical" metamodels need to be more careful about which association
    ends have corresponding references. In places where an association end can
    relate one element to another element imported from another model, it is
    generally best to not have a reference on the inverse end. Note that
    "reference" is a MOF concept. The lack of a reference does not affect
    whether an association end is navigable. It does affect whether a link can
    be in a different MOF package extent (this is a MOF constraint). If both
    sides of an association have references, then related objects are forced to
    reside in the same package extent, which prevents the federation of UML
    facilities.

    An important aspect of interoperability comes from federation: UML
    facilities having links to other UML facilities. The overuse of references
    prevents use of such links in places where they should be allowed.

  • Reported: UML 1.2 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Precise "Physical" Metamodels Missing from Specification (uml-rtf

  • Key: UML14-963
  • Legacy Issue Number: 3122
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    There is no XMI-based XML rendering of the UML metamodels in the UML 1.3
    Specification. The "physical" metamodels must be precisely described using
    the MOF Model document type in order to maximize tool interoperability
    across vendors and to enable extension of the metamodels by others. This
    has been done in MOF 1.3, in the initial CWM submission and in other OMG
    submissions, thereby providing definitive metamodels with complete
    machine-readable clarity.

    Recommendation: Put an XML rendering of UML metamodels in the UML 1.4
    specification based on the MOF Model DTD.

  • Reported: UML 1.2 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Language Name (uml-rtf)

  • Key: UML14-962
  • Legacy Issue Number: 3121
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    In order to maximize tool interoperability, the language names provided in
    UML Expressions should follow a consistent naming pattern. No such pattern
    is given by the UML Specification.

    Recommendation: Add the following simple statement after the predefined
    language names (a list of one) given in the description of Expression. Note
    that the following naming practice has a president. It is recommended in
    the ANSI/ISO C++ standard for language names used for external linkage:

  • Reported: UML 1.2 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

OCL Error

  • Key: UML14-961
  • Legacy Issue Number: 3098
  • Status: closed  
  • Source: Anonymous
  • Summary:

    sUnique for Collections is defined as follows:
    >>
    >>collection->isUnique(expr : OclExpression) : Boolean
    >> post: result = collection->collect(expr)->forAll(e1,e2 | e1<>e2)
    >>
    >>Unfortunately, if the collection is not empty, this expression
    >>always evaluates to false. This is due to the fact that in a
    >>forAll over two iterators, both iterate over the full collection.
    >>Therefor, for each element in the collectionen , there is a
    >>step where both itereters point to this element, but at this
    >>point, e1 <> e2 evaluates to false.
    >>
    >>My suggestion for the definition of isUnique would be as follows:
    >>
    >>collection->isUnique(expr : OclExpression) : Boolean
    >> post:
    >> let res = collection->collect(expr) in
    >> result = res->forAll(e $|$ res->count(e) = 1)
    >>
    >>This expression states, that each element in the collection 'res'
    >>appears exactly once, i.e. is unique.

  • Reported: UML 1.2 — Tue, 7 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Use of interfaces in associations

  • Key: UML14-960
  • Legacy Issue Number: 2921
  • Status: closed  
  • Source: University of Frankfurt ( Thomas Behrens)
  • Summary:

    The issue / problem relates to the use of interfaces in associations, i.e.
    the "type" association in the meta model between AssociationEnd and
    Classifier.

    Besides the use of a syntactical interface specification, I use the
    interfaces as well as the location to provide semantics, using OCL.

    OCL provides a well-defined way to navigate along association ends. Where
    actually interfaces would provide the semantic context for association ends,
    I have to refrain from specifiying those on the interface, but have to defer
    this association to the realizing class.

    As an alternative it is possible to provide getter and setter operations
    providing access to the association ends in the deferred implementation. But
    this presents two other problems:
    a) this public (as no other ones are allowed) operation on the interface
    will need to be realized any realizing class (and I do not always want to
    compromise this information)
    b) the return value of the operation (in case of a multiplicity > 1) will
    not per se have the same OCL "accessibility" as an association end;
    furthermore tools - at this point in time - provide significant better
    control in terms of verification for associations than for operation
    parameters / return values.

  • Reported: UML 1.2 — Mon, 27 Sep 1999 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Generalization should be meta-metamodel element

  • Key: UML14-959
  • Legacy Issue Number: 2850
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML 1.3 Metamodel Semantics

    Generalization should be meta-metamodel element

    It is a generally accepted fact that generalization is a second order
    relation, ie, a relation whose elements (instances) are pairs of
    types (classifiers, or whatever). Associations, by contrast, are
    first order: their elements are tuples of objects (individuals,
    etc.).

    UML is based on a four-layer metamodel structure, including metamodel
    and meta-metamodel layers. Why, then, do Generalization and
    Association appear on the same layer, namely the metamodel? Much more
    troublesome: How can they be specializations of the same
    generalization, namely Relationship? Together with the defined
    implication of generalization: "The more specific element is fully
    consistent with the more general element (it has all of its
    properties, members, and relationships) ..." [UML 1.3, sect. 2.5.2]
    this leads to a paradox, because generalization itself would be
    inherited. The paradox would be avoided, however, if generalization
    were a relation of the meta-metalayer.

  • Reported: UML 1.2 — Fri, 13 Aug 1999 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

  • Updated: Fri, 6 Mar 2015 21:37 GMT

role concept in UML remains rather vague

  • Key: UML14-958
  • Legacy Issue Number: 2837
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Roles play a dual role in UML. On one hand, a role is the name of an association end [UML, § 2.5.2] and thus nothing more than the name of place of a relation. On the other hand, UML has a notion of roles specified in the context of collaborations [UML, 2.10]. This notion conflicts with the first one since a single role of the collaboration may have different role names assigned by the different associations it participates in. In other words, the associations of a collaboration may assign different role names to their ends (and thus, to the classifiers at the ends) than assigned by the collaboration directly, potentially leading to a clash of role names.

    Overall, the specification of the role concept in UML remains rather vague. It seems that classifier roles only indirectly specify the base classifiers whose instances can play the roles: "In fact, since an instance may originate from several classifiers (multiple classification), a classifier role may have several base classifiers." (but where are these specified?) and "However, since the only requirement on conforming instances is that they must have attribute values corresponding to the attributes specified by the classifier role, and must participate in links corresponding to the association roles connected to the classifier role, they may be instances of any classifier meeting this requirement." [UML, 2.10.4]. And finally "Note that the base classifiers of the specialized roles are not necessarily specializations of the base classifiers of the parent"s roles; it is enough that they contain all the required features." This is certainly a very unusual feature in a typed language such as UML.

    So what are roles? It seems that in UML they are not types (or classifiers), but a positive definition (other than the equally vague glossary entry) would seem imperative!

  • Reported: UML 1.2 — Wed, 11 Aug 1999 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 21:37 GMT

OCL issue

  • Key: UML14-957
  • Legacy Issue Number: 2786
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Descriptor:
    symbols such as +, - or * in the name of a feature in Ocl expressions
    are not allowed.

  • Reported: UML 1.1 — Wed, 30 Jun 1999 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Strange GENERAl USE RESTRICTION

  • Key: UML14-956
  • Legacy Issue Number: 2626
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: "The owners of the copyright in the UML specification version 1.2 [sic, in
    1.3alpha5] hereby grant you a [...] license [...] to create and distribute
    software which is based upon the UML specifications [...]

    Software developed under the terms of this license must include a complete
    implementation of the current version of this specification [...]"

    This appears to say that any UML-based CASE tool must implement the whole
    of the standard. Since as far as I"m aware no existing tool, including
    Rational Rose, comes even close to doing this, should not the restriction
    be changed? (I do not suggest that it should be enforced!)

  • Reported: UML 1.1 — Mon, 3 May 1999 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Error in the third postcondition for String::concat on page 6-31

  • Key: UML14-955
  • Legacy Issue Number: 2573
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There seems to be an error in the third postcondition for String::concat on page 6-31. It says:

    post: result.substring(string.size + 1, string2.size) = string2

    It should read:

    post: result.substring(string.size + 1, string.size + string2.size) = string2

  • Reported: UML 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

The not-equals operator, "<>",

  • Key: UML14-954
  • Legacy Issue Number: 2572
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The not-equals operator, "<>", seems to be listed for Enumerations, but not for Reals (page 6-27), Integers (p 6-29), Booleans (p 6-31) or Strings (p 6-30), even though it seems to be used in many places elsewhere in the specification.

    All the other operators seem to be there (equality, less than, etc.), so I think this one should be as well (although you can simulate it using "not").

    Note that inequality is defined for OclAny, but then so is equality.

  • Reported: UML 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Divide operator is incorrect

  • Key: UML14-953
  • Legacy Issue Number: 2571
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Under the "Real" type on page 6-29, the divide operator is incorrectly
    written as an asterisk instead of a forward slash.

    I am not sure if this is just a typo, computer glitch, or error in translating the document to Acrobat format or something weird like that.

  • Reported: UML 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

pages 6-28 to 6-29 of OCL documentation

  • Key: UML14-952
  • Legacy Issue Number: 2570
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: pages 6-28 to 6-29 of OCL documentation

    Trivial point - For consistency, the Real operators +, -, * and / should take a parameter called r2, not r1. This seems to be the convention used elsewhere throughout the document, and makes the point that they are the second real number in the expression.

  • Reported: UML 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

page 6-10 of OCL documentation for 1.3alphaR5

  • Key: UML14-951
  • Legacy Issue Number: 2569
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: page 6-10 of OCL documentation for 1.3alphaR5

    I notice that not equals <>, the pathname operator :: and the @pre operator are not listed in the precedence table, and so I guess, technically, their precedence is undefined.

    You could also put parentheses at the top of the table as well, of course, to make that table more complete and stand-alone. Parentheses would then not need to be described in a sentence following the list.

  • Reported: UML 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

The second postcondition on Integer::div is incorrect

  • Key: UML14-948
  • Legacy Issue Number: 2566
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The second postcondition on Integer::div is incorrect. It currently reads:

    i.div( i2 : Integer) : Integer

    The number of times that i2 fits completely within i.

    post: result * i2 <= i
    post: result * (i2 + 1) > i

  • Reported: UML 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

The postcondition seems to be incorrect for sequence::subSequence

  • Key: UML14-950
  • Legacy Issue Number: 2568
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The postcondition seems to be incorrect for sequence::subSequence. It currently reads:

    sequence->subSequence(lower : Integer, upper : Integer) : Sequence(T)

    The sub-sequence of sequence starting at element number lower, up to and including element number upper.

    post: if sequence->size < upper then
    result = Undefined
    else
    result->size = upper - lower + 1 and
    Sequence

    {lower..upper}

    ->forAll( index |
    result->at(index - lower + 1) =
    sequence->at(lower + index - 1))
    endif

    The indexing is incorrect.

  • Reported: UML 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

The postcondition on set::collect seems to be incorrect

  • Key: UML14-949
  • Legacy Issue Number: 2567
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The postcondition on set::collect seems to be incorrect. It currently reads:

    set->collect(expression : OclExpression) : Bag(expression.oclType)

    The Bag of elements that results from applying expr to every member of set.

    post: result = set->iterate(elem; acc : Bag(T) = Bag{} | acc->including(expr) )

    The type of acc is wrong, and it should read:

    post: result = set->iterate(elem; acc : Bag(expression.oclType) = Bag{} | acc->including(expr) )

    Note that the same goes for Bag::collect on page 6-41.

  • Reported: UML 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

(Minor) Activity diagram change recommendation

  • Key: UML14-947
  • Legacy Issue Number: 2546
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I know it"s late in the game, but in my use of activity diagrams for
    modeling algorithms, a minor change has become apparent. Specifically, it
    is possible to have objects "flow" from one activity state to another, but
    it is not possible to show a persistent object which is modified by some
    activity states and used by others. I therefore recommend the following change:

    Activity states be able to depend on objects with stereotypes for <<use>>
    and <<modify>>. In this case, control flow among the activity states must
    be shown since the "data object" does not flow between activity states but
    exists in an enclosing structural context.

  • Reported: UML 1.1 — Tue, 16 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

OCL Standard package

  • Key: UML14-946
  • Legacy Issue Number: 2544
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: resolving the issue of extensibility of OCL (like adding an operation to a
    predefined
    OCL type) I have written a new section in the OCL chapter. It describes
    the
    existence of a default package in each UML model, containing the predefined
    OCL
    types. I have chosen to name this package "UML_OCL" (or StandardOCL, ...).

    Typically, the modeler will define its own OCL package (named e.g. MyOCL),
    import
    the standard OCL package (import UML_OCL) and extend the predefined OCL
    types
    to his/her liking. A like approach is taken in Catalysis.

  • Reported: UML 1.1 — Tue, 16 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

There is an association between between Constraint and ModelElement

  • Key: UML14-945
  • Legacy Issue Number: 2510
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The end of the association which is opossite to ModelElement is named as "stereotypeConstraint". I sugesst to rename it to "constraint" or "elementConstraint".
    The name "stereotypeConstraint" is somewhat misleading. issue from Constantine Plotnikov (cap@novosoft.nsc.ru)

  • Reported: UML 1.1 — Thu, 4 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

OCL should allow one constraint to reference another

  • Key: UML14-944
  • Legacy Issue Number: 2305
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OCL should allow one constraint to reference another (e.g. by name) to avoid
    redundancy in a specifiation and errors related to maintenance of separate constraints
    that should be the same.

  • Reported: UML 1.1 — Fri, 15 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

  • Updated: Fri, 6 Mar 2015 21:36 GMT

action state symbol/state symbol difficult to distinguish when drawn by ha

  • Key: UML14-941
  • Legacy Issue Number: 2293
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Summary: The action state symbol and the state symbol differ only in the convexity of their vertical sides. Therefore, it is difficult to distinguish between them, if the diagram is drawn by hand. The symbols have different semantics and both of them can appear in a single diagram (activity diagram). Therefore, it is necessary to clearly distinguish between the symbol for the state and the symbol for the action state.

  • Reported: UML 1.1 — Wed, 6 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    Previously considered for 1.4 and closed w.o. change

  • Updated: Fri, 6 Mar 2015 21:36 GMT

UML Semantics, OMG-UML V1.2 Use Cases July 1998, page 2-99

  • Key: UML14-940
  • Legacy Issue Number: 2292
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the current version of UML, use cases must not have associations to other use cases specifying the same entity. Use cases can exchange messages only with actors and not with each-other. UML use cases are always initiated by a signal from the actor.

    However, there are use cases that are initiated by a system if a specific condition is met. Example: in the well-known ATM machine example the use case "dispense cash" is initiated by the system, if the customer request was evaluated as valid. The use case "dispense cash" is not initiated by the (user) actor. In other words, the use case "dispense cash" receives a message or signal from the other use case specifying the same system. Therefore, the association between use cases must exist.

    Solution: Allow associations between use cases specifying the same entity.

  • Reported: UML 1.1 — Wed, 6 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 21:36 GMT

UML has symbol for multiobject, not for multi-instances of other classifie

  • Key: UML14-943
  • Legacy Issue Number: 2295
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML has a symbol for multiobject. However, UML does not have any specific symbol for multiple instances of a component, node, subsystem, interface, actor, use case and collaboration. Adding these symbols to UML will maintain symmetry and therefore, simplicity of the notation.

  • Reported: UML 1.1 — Wed, 6 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    declined

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Dependencies (and other relationships) with role ends

  • Key: UML14-942
  • Legacy Issue Number: 2294
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Dependency relationship in UML does not have role ends, similar to the association ends that associations have. Therefore, it is not possible to specify, for example, that:

    1. an entity depends on an ordered set of other entities.
    2. an entity depends on a specified number of instances of other entities
    3. the roles of the entities that participate in the dependency. Dependency imply the entity roles "client" and "supplier". However, I often came across situations where I needed to specify more concrete roles than "client" and "supplier". In cases I came across, replacing dependencies by associations was not a convenient solution.

  • Reported: UML 1.1 — Wed, 6 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Add Responsibilities as a new metatype

  • Key: UML14-939
  • Legacy Issue Number: 2284
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I would again propose that Responsibilities are added as a new metatype.
    After all Relationship is about to be added in Version 1.3 so I would
    suggest respectfully that the easy addition of one metaclass (Responsibility)
    and two metalevel association relationships (from Classifier to
    Responsibility and from Responsibility to Feature) would be highly
    beneficial and very easily changed in the metamodel. Notational support
    is no problem since (as I have discussed with Grady) is just the addition
    of a new box under the class icon.

  • Reported: UML 1.1 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

On aggregation. The white diamond name should be "shareable"

  • Key: UML14-935
  • Legacy Issue Number: 2280
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On aggregation. The white diamond name should be "shareable"
    not "shared" because it really indicates the ability to be shared not
    the notion that it IS necessarily shared.
    submit: Submit Issue Report

  • Reported: UML 1.1 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Metamodel and semantics for aggregations

  • Key: UML14-934
  • Legacy Issue Number: 2279
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The metamodel and semantics for aggregations is still causing me
    much concern. Primarily, it is stated that black diamond (composition)
    must have linked lifetimes and dependencies between part and whole.
    This means that the parts are NOT separable from the whole. It also states
    that whilst there is only one owner that owner may be changed. This means
    that the parts MUST BE separable from the whole. This is a contradiction.

  • Reported: UML 1.1 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Interface issue

  • Key: UML14-938
  • Legacy Issue Number: 2283
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Interface is a kind ofclassifier and therefore has features - but it
    supposedly only has operations

  • Reported: UML 1.1 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Only single stereotyping is supported

  • Key: UML14-937
  • Legacy Issue Number: 2282
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Only single stereotyping is supported. Multiple partitioning and
    therefore multiple partitioning would be usefully and easily added

  • Reported: UML 1.1 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Use of black diamond in the metamodel

  • Key: UML14-936
  • Legacy Issue Number: 2281
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Use of black diamond (even when semantics are pinned down) in the metamodel e.g. Classifier
    as a composition of Feature is not convincing. The ideas of lifetime
    interlinking seems not necessarily to be the case for many of the metamodel
    uses of black diamond. Similarly for Transition as a composition of
    Guards in the STD.

  • Reported: UML 1.1 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Some attributes can be expressed in OCL

  • Key: UML14-933
  • Legacy Issue Number: 2074
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: At several places in the UML metamodel there are attributes of type
    "...Expression". Some of these might be specified in OCL. This should be
    stated in the metamodel. The OCL specification should expicitly describe the
    meaning and context of such an OCL expresion.
    Examples are:
    Action: attribute target : ObjectSetExpression
    Argument: attribute value : Expression
    ChangeEvent: attribute changeExpression : BooleanExpression

    Especially the last one should be expressable in OCL, since it is
    a Boolean Expression.

  • Reported: UML 1.1 — Tue, 13 Oct 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Widen the naming characteristics

  • Key: UML14-932
  • Legacy Issue Number: 2073
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The OCL prescribes certain characteristics of names of classes,
    attributes, etc. Clas anmes must start with uppercase, attributes
    start with lowercase, etc.
    It would be more flexible if these restrictions could be widened.

  • Reported: UML 1.1 — Tue, 13 Oct 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

BooleanExpression written in OCL or some other language?

  • Key: UML14-931
  • Legacy Issue Number: 2071
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the current metamodel, it is not unambiguously defined whether
    a BooleanExpression is written in OCL or in some other language.
    With tool vendors developing OCL tools, it is important to be able
    to state exactly whether an Expression is written in OCL or not.

  • Reported: UML 1.1 — Tue, 13 Oct 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Infix operator use should be clarified

  • Key: UML14-927
  • Legacy Issue Number: 2018
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Infix operators like "+" and "<" etc. are defined for built-in OCL types.
    It is not explained whether you can
    use these for user defined types. The proposal is to allow infix notation
    for all of the
    operators defined in OCL for used-defined types as well. If someone
    defines the operation
    "+(p : Person)"
    on type Person, this can be used in OCL by
    somePerson + anotherPerson.
    instead of just by
    somePerson.+(anotherPerson)
    The OCL specification is not clear whether this is allowed or not.

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Generalized change events

  • Key: UML14-930
  • Legacy Issue Number: 2024
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The expressive power of change-events is limited. We are writing a
    specification that is much simpler if we can trigger transitions under a
    circumstance like the following:

    "P has just become true and it is not the case that Q has just
    become true"

    There"s no way to say that with a change-event. Instead we have to write a
    somewhat obscure sequence of transitions that defines a program to calculate
    this.

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

There are issues that make OCL hard to formalize--document ad/98-10-01

  • Key: UML14-929
  • Legacy Issue Number: 2022
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are a number of issues that make OCL hard to formalize. The attached
    document is a draft of a research into formalizing UML/OCL. It contains
    a number of issues on OCL. Instead of making all of these into separate
    issues, the document is attached and all problems described in there are
    hereby submitted as one (rather big) issue. This document will be posted as ad/98-10-01 on the OMG document server

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue 2013.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Definition of OclAny leads to problems when formalizing OCL

  • Key: UML14-928
  • Legacy Issue Number: 2021
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OclAny is essentially a type of all types. In particular,
    section 5.13 of the OCL specification implies that Set(OclAny)
    is a subtype of OclAny, from which a version of the Russell
    Paradox promptly follows.

    This needs to be clarified/resolved in the specification

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Common operations should be added to collection types in OCL

  • Key: UML14-924
  • Legacy Issue Number: 2015
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A number of common operations should be added to the collection
    types in OCL. These are:

    Collection(T) :
    any( <boolean-expression> ) : T
    returns any element which satisfies <boolean-expression>
    one( <boolean-expression> ) : Boolean
    returns true if thee is exactly one element that satisfies
    <boolean-expression>
    theOne( <boolean-expression> ) : T
    returns the single element which satisfies <boolean-expression>

    and maybe others as well.

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 21:36 GMT

Add OCL operation to refer to all new instances created during operation

  • Key: UML14-923
  • Legacy Issue Number: 2014
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no simple way currently in OCL to refer in a postcondition to the
    new instances created
    during the operation. The current solution is:
    Person.allIstances - Person.allInstances@pre
    Since this is commonly used, a simper way to denote this will be
    bened=ficial.
    We propose to add an operation "new" or "created" to OclType, which can ony
    be used
    in postconditions and has the meaning describd above. We can then write:
    Person.new or Person.created

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Need well defined way to extend OCL

  • Key: UML14-922
  • Legacy Issue Number: 2013
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Because no predefined set of operations will cover all cases needed in
    practical situations it s important that there is a well-defined way
    to extend OCL.

    It is possible to define all predefined OCL types within one predefined UML
    package
    end define package extension mechanisms to add extensions to OCL.
    The current OCL specification doesn"t disallow that, but it should
    be explained explicitly how this can be done.

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Set of allInstances should be referrable by the class name

  • Key: UML14-926
  • Legacy Issue Number: 2017
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: ances of a class, as
    in "Person.allInstances". It is quite common in many area"s to use the
    class name for this collection.
    To get the size of the collection of persons we now need to write:
    Person.alllnstances->size"
    With the proposes change we can write:
    Person->size
    which is a shorthand for the use of allInstances.

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Add "Let"-like construct to OCL

  • Key: UML14-925
  • Legacy Issue Number: 2016
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Currently if a sub-expression within an OCL expression is
    used twice or more, you need to spell it out each time. This
    is cumbersone, eror-prone and it also disguises to the reader
    of the constraint that these sub-expressions are in fact identical.

    The proposal is to add a construct to OCL, that allows one
    to define a variable which holds the value of such a sub-expression.

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue 1788.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Synchronous request

  • Key: UML14-919
  • Legacy Issue Number: 2006
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: synchronous request is defined as a request where the client object
    pauses to wait for completion of the request.

    1) My understanding of CORBA is that a request is only synchronous
    with respect to a given thread. Is this true?

    • So, does the sending client truly pause to wait for results?
    • Or is it just a thread of that client that pauses for results?

    Deferred synchronous request (mentioned on p.78) has not been
    defined.

  • Reported: UML 1.1 — Mon, 28 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Previously considered for 1.4 and closed w.o. change

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Notation says swimlanes are packages

  • Key: UML14-921
  • Legacy Issue Number: 2012
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The notation guide has a couple descriptions of swimlanes as
    packages, even though swimlanes are not mapped to packages.
    References:

    If an object lifeline is not shown, then some object within the
    swimlane package is responsible for the action, but the object
    is not shown. [p 127, section 10.5.2, Notation, or p 130 in UML
    1.2]

    Actions may be organized into swimlanes. Swimlanes are a kind of
    package used to organize responsibility for activities within a
    class. [p 125, section 10.4.2, Notation, or p 128 in UML
    1.2]

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

ModelElement to Partition multiplicity should be many

  • Key: UML14-920
  • Legacy Issue Number: 2011
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Partitions in various activity models may reuse the same model
    element. So the multiplicity of the association from
    ModelElement to Partition should be *.

    Comments:

    Proposal: Change multiplicity of association from ModelElement to Partition
    from 0..1 to * [p 121, Figure 22, Activity Model, Semantics,
    or p134 in UML 1.2].

  • Reported: UML 1.1 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Asynchronous action

  • Key: UML14-918
  • Legacy Issue Number: 2004
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: An asynchronous action is defined as a request where the sending object does not pause to wait for results. Synonym: asynchronous request [OMA].

    1) What results?
    In the OMA v3 (June 13 1995), it is said on p. 78 that
    an asynchronous request has no response (hence no results).
    So, soes "results" means "response", or something else ?

    2) The OMA speaks also of a deferred synchronous request –
    proceed after sending request; claim reply later).
    The synonym used is confusing since the OMA has a concept of
    deferred synchronous request in which the sending object does
    not pause to wait for results (proceed after sending request;
    claim reply later).

    3) In fact, my understanding is that the sending object does not
    even pause to wait for the receiving object to be notified of
    the request. The definition is silent about this.

  • Reported: UML 1.1 — Mon, 28 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Previously considered for 1.4 and closed w.o. change

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Not instantiable

  • Key: UML14-917
  • Legacy Issue Number: 2001
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There does not appear to be a definition of "instantiable."

    If "not instantiable" means can not have instances in a model, then some
    model elements should be instantiable, which are currently specified to
    be not instantiable.

    If "not instantiable" means can not have instances in a running system,
    but may have instances in a model, then this should be made clear.

  • Reported: UML 1.1 — Sat, 26 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

UML RTF Issue: Normative MOF-Compatible version of UML

  • Key: UML14-916
  • Legacy Issue Number: 1999
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML RTF Issue: Normative MOF-Compatible version of UML
    Severity: Critical

    1) The UML RTF must produce a normative version of UML which is MOF-compatible.
    2) This normative representation should be in Rose (or equivalent) and SMIF
    form in the event that a SMIF submission is adopted.
    3) In the event that XMI is adopted as the SMIF technology, the normative XMI
    form of UML is a generated XMI document and DTD.

  • Reported: UML 1.1 — Tue, 29 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Core package-backbone diagram

  • Key: UML14-915
  • Legacy Issue Number: 1995
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The "Core Package-Backbone" diagram shows, on the Association
    between Classifer and StructuralFeature, that the "feature"
    AssociationEnd is ordered. Ordering is neither wanted nor
    feasible for this end. What ordering would be applied to the
    set of Attributes that given Class or DataType types? The order
    in which they are defined is the only conceivable ordering, which
    doesn"t seem very valuable.

  • Reported: UML 1.1 — Thu, 24 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Issue: Missing role names

  • Key: UML14-912
  • Legacy Issue Number: 1990
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Severity: Minor
    Issue: missing role names

    Very few of the association roles have names, which are needed for model
    interchange.
    Here is the convention being considered in XMI for providing those names.
    1) Start with the role name.
    2) If the role name is missing, use the association name
    3) If the association name is missing or a generated name (see xmi6), use the
    class name
    4) If the name is a duplicate, use the Class name appended with a number,
    counting up from 2.

  • Reported: UML 1.1 — Tue, 22 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3 physical model.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Issue: Inheritance inconsistencies

  • Key: UML14-911
  • Legacy Issue Number: 1989
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here"s issue xmi4, which was generated by questions arising during work on the
    XMI SMIF submission. Numbers refer to the UML 1.1 semantics document.

    Severity: Clarification
    Issue: inheritance inconsistencies
    1) The semantics document shows Component inheriting from Classifier on page 4,
    however the definition on page 45 indicates that it inherits from Class.
    2) The semantics document shows Node inheriting from Classifier on page 44,
    however the definition on page 45 indicates that it inherits from Class.
    3) The diagram on page 121 shows ActivityState inheriting from SimpleState, but
    the description on page 122 indicates that it inherits from SubmachineState.
    4) Figure 8 on page 44 shows Comment as a subclass of ModelElement. The text
    on page 44 states Comment is a subclass of ViewElement.

  • Reported: UML 1.1 — Tue, 22 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Inconsistencies corrected in UML 1.3. (Mostly redundant with issue 1953.)

  • Updated: Fri, 6 Mar 2015 21:36 GMT

MOF does not support association attributes in metamodels.

  • Key: UML14-914
  • Legacy Issue Number: 1992
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Severity: Minor
    MOF does not support association attributes in metamodels.
    The following relationships have association attributes:
    1) Namespace contains ModelElement (ElementOwnership), p16
    2) ModelElement presents ViewElement (Presentation), p44
    3) Package contains ModelElement (ElementReference), p129

    Please describe the proposed MOF mapping if the association attributes are to
    be retained in UML.

  • Reported: UML 1.1 — Tue, 22 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue 1955.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

issue: Missing association names

  • Key: UML14-913
  • Legacy Issue Number: 1991
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Severity: Minor
    Issue: missing association names

    Most of the associations are missing names, which are useful for model
    interchange.
    Here is the convention being considered in XMI for providing those names.
    1) Identify the names of the classes on each end.
    2) The "first" class is the one with the name that is lexigraphically first.
    3) Concatenate the two class names together, separated by an underscore (_)
    character. First_Second.
    4) Duplicates have a number appended, starting with 2.

    An example association name is Method_Operation (and not Operation_Method).

  • Reported: UML 1.1 — Tue, 22 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3 physical model.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Issue: Action does not define attributes

  • Key: UML14-910
  • Legacy Issue Number: 1988
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here"s issue xmi3, which was generated by questions arising during work on the
    XMI SMIF submission. Numbers refer to the UML 1.1 semantics document.

    Severity: Clarification
    Issue: Action does not define attributes
    The textual description of Action on page 68 does not defne all of the
    attributes in the diagram on page 67.

  • Reported: UML 1.1 — Tue, 22 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarifed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Issue: Name attribute inheritance

  • Key: UML14-909
  • Legacy Issue Number: 1987
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here"s issue xmi2, which was generated by questions arising during work on the
    XMI SMIF submission. Numbers refer to the UML 1.1 semantics document.

    Severity: Clarification
    Issue: Name attribute inheritance
    Please clarify that the Name attribute is inherited from ModelElement and not
    redefined in these cases.
    1) Parameter on page 27
    2) Feature on page 23
    3) BehavioralFeature on page 20
    4) Association on page 17

    If Name is redefined, the diagrams should include them.

  • Reported: UML 1.1 — Tue, 22 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3 physical model.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Issue: abstract class inconsistencies

  • Key: UML14-908
  • Legacy Issue Number: 1986
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here"s issue xmi1, which was generated by questions arising during work on the
    XMI SMIF submission. Numbers refer to the UML 1.1 semantics document.

    Severity: Clarification
    Issue: abstract class inconsistencies
    1) Figure 13 on page 67 shows the Action class as concrete. The text on page
    70 says Action is abstract.
    2) Figure 14 on page 67 shows Instance as a concrete class. The text on page 70
    says Instance is abstract.

  • Reported: UML 1.1 — Tue, 22 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3 physical model.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Figure 2-18 : redundant attributes

  • Key: UML14-907
  • Legacy Issue Number: 1966
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: n figure 2-18 an Action has the attribute isAsynchronous and the specialization of Action, CallAction has the attribute mode:SynchronousKind. SynchronousKind is either: sk_synchronous or sk_asynchronous. This seems redundant.

    Also the isAsynchronous flag is explained nowhere but it is used on page 2-84 as an attribute of Signal although it does not appear to be a member of Signal.

  • Reported: UML 1.1 — Wed, 16 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

UML Semantics (page 109)

  • Key: UML14-906
  • Legacy Issue Number: 1956
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: One improperly phrased rule in the UML Semantics manual (page
    109):
    >
    > "The set of transitions that will fire is the maximal
    set that
    > satisfies the following conditions..." (italics added)
    >
    > Clearly, this should say a, not the. There may be more than
    one such maximal set.

  • Reported: UML 1.1 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Association attributes

  • Key: UML14-905
  • Legacy Issue Number: 1955
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: association attributes
    The MOF does not support association attributes in metamodels.
    The following relationships have association attributes:
    1) Namespace contains ModelElement (ElementOwnership)
    2) ModelElement presents ViewElement (Presentation) [removed in uml 1.2]
    3) Package contains ModelElement (ElementReference)

  • Reported: UML 1.1 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

missing association names

  • Key: UML14-904
  • Legacy Issue Number: 1954
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: missing association names
    1) Very few of the associations have names, a required property of MOF metamodels. Naming metamodel relationships also enhances model interchange.
    2) Many of the role names of associationEnds are missing.
    3) The role name of Operation->Method is missing.
    4) Missing role name: Classifier<-Parameter, p16
    5) Missing role name: Binding->ModelElement, p43
    6) Missing role name: Node->Component, p44
    7) Missing role name: ModelElement<-Component, p44
    8) Missing role name: Enumeration<-EnumerationLiteral, p60
    9) Missing role name: MultiplicityRange->Multiplicity, p60
    10) Missing role name: Parameter->Signal, p66
    11) Missing role name: Action->ActionSequence, p67
    12) Missing role name: Request->Action, p67
    13) Missing role name: Argument->Action, p67
    14) Missing role name: Most of the associations, Fig 14, p67
    15) Missing role name: Most of the associations, Fig 15, p81
    16) Missing role name: Classifier->Instance, p90
    17) Missing role name: Most of the associations, Figs 17 and 18, p98
    18) Missing role name: Most of the associations, Fig 22, p121
    19) Missing role name: ModelElement->Package, p129

  • Reported: UML 1.1 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Issue: inheritance inconsistencies

  • Key: UML14-903
  • Legacy Issue Number: 1953
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: inheritance inconsistencies
    1) The semantics document shows Component inheriting from Classifier on page 4, however the definition on page 45 indicates that it inherits from Class.
    2) The semantics document shows Node inheriting from Classifier on page 44, however the definition on page 45 indicates that it inherits from Class.
    3) The diagram on page 121 shows ActivityState inheriting from SimpleState, but the description on page 122 indicates that it inherits from SubmachineState.

  • Reported: UML 1.1 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Inconsistencies corrected in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Diagram missing attributes

  • Key: UML14-902
  • Legacy Issue Number: 1952
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: Diagram missing attributes
    1) The attributes of Action on page 68 do not include all of the attributes in the diagram on page 67.
    2) The attributes of BehavioralFeature includes Name in the text on page 20, but is not in the diagram on page 16.
    3) The attributes of Feature includes Name in the text on page 23, but is not in the diagram on page 16.
    4) The attributes of Parameter includes Name in the text on page 27, but is not in the diagram on page 16.

  • Reported: UML 1.1 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Are subsystems instantiable?

  • Key: UML14-900
  • Legacy Issue Number: 1945
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The semantics document is contradictory on whether subsystems
    are instantiable. Comments: If a classsifier is instantiable, it should be allowed to have
    methods to implement calls to its operations at runtime. In
    the case of subsystems, this may just translate to operation
    calls on it contained objects. If subsystems are not supposed
    to have behavior of their own, then they should not be
    instantiable.

  • Reported: UML 1.1 — Fri, 11 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Abstract class inconsistencies

  • Key: UML14-901
  • Legacy Issue Number: 1951
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: abstract class inconsistencies
    1) Figure 13 on page 67 shows the Action class as concrete. The text on page 70 says Action is abstract.
    2) Figure 14 on page 67 shows Instance as a concrete class. The text on page 70 says Instance is abstract.
    3) Figure 8 on page 44 shows Comment as a subclass of ModelElement. The text on page 44 states Comment is a subclass of ViewElement.

  • Reported: UML 1.1 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Inconsistencies corrected in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Associations as parts of a composite.

  • Key: UML14-899
  • Legacy Issue Number: 1943
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The notation says that associations may be parts of composites:

    The parts of a composition may include classes and
    associations. The meaning of an association in a composition
    is that any tuple of objects connected by a single link must
    all belong to the same container object. [p62, section 5.26.1
    Notation, UML 1.1, or p65, section 3.42.1 in UML 1.2]

    The above meaning of association as part is not recorded in the
    semantics.

    In any case, the definition prevents associations from having
    parts themselves. When an association has parts, some parts must
    be associations that connect to objects outside the containing
    association. See Bock & Odell in JOOP, Vol 11, No 5, September
    1998, also at:

  • Reported: UML 1.1 — Thu, 10 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Section 5.17 of Notation Guide: No mapping is given

  • Key: UML14-898
  • Legacy Issue Number: 1940
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In Section 5.17 of the Notation Guide, the notation for an object is
    described as allowing the inclusion of particular states that the object
    is in, but no mapping is given. The obvious mapping is to use a
    ClassifierInState construct from activity modeling as a classifier of
    such an Object, but the well-formedness rule for Object on page 76 of
    the Semantics requires that all classifiers of Objects be Classes.
    A ClassifierInState is a kind of Classifier, but NOT a kind of Class, so
    its use is prevented in the metamodel.

  • Reported: UML 1.1 — Wed, 9 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Notation section describing activity states needed

  • Key: UML14-896
  • Legacy Issue Number: 1921
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no description of what an activity state should look like. The specification needs a notation section describing activity states.

  • Reported: UML 1.1 — Tue, 1 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with 1051.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Existance of classes in classes

  • Key: UML14-897
  • Legacy Issue Number: 1939
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The UML Semantics Guide 1.1 (top of p.37) says "...a class acts as a namespace for contained classes...". But the UML Notation Guide 1.1 (p. 23) only says "The name of a class has scope within the package in which it is declared...", i.e. it only speaks to classes that are directly contained in packages and is silent on the existence of classes within classes (Java"s "inner classes", or "nested classes" in C++) or how to represent them.

  • Reported: UML 1.1 — Tue, 8 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

States leading to joins in activity models

  • Key: UML14-895
  • Legacy Issue Number: 1890
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The semantics has the following statement regarding states leading
    to joins:

    If the ObjectFlowState leads into a join pseudostate, then the
    ObjectFlowState remains activated until the other predecessors
    of the join have completed [end of first paragraph of semantics of
    ObjectFlowState, p 139, UML Semantics 1.2].

    This behavior applies to all states leading to a join in
    an activity model, because of regions already exist implicitly when
    using joins in activity models.

  • Reported: UML 1.1 — Wed, 26 Aug 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Activities operate by and on objects

  • Key: UML14-894
  • Legacy Issue Number: 1888
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The notation document says regarding object flow:

    Activities operate by and on objects. Two kinds of relationships
    can be shown: 1) The kinds of objects that have primary
    responsibility for performing an action and 2) the other objects
    whose values are used or determined by the action. These are
    modeled as messages sent between the object owning the activity
    model and the objects that are input or output by the actions in
    the model. [section 3.80.1, p 130 Notation 1.2]

    Presumably the activity model doesn"t tell the objects being passed

  • Reported: UML 1.1 — Wed, 26 Aug 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:36 GMT

ClassifierInState does not satisfy one of its stated usages

  • Key: UML14-893
  • Legacy Issue Number: 1887
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: ClassifierInState does not satisfy one of its stated usages, namely
    to be used as input to an action. This would require that it have
    all the attributes and associations of its corresponding classifier.

  • Reported: UML 1.1 — Wed, 26 Aug 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Witdrawn by submitter.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Rules 3 and 4 for Transitions in state machines should be limited

  • Key: UML14-892
  • Legacy Issue Number: 1886
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Rules 3 and 4 for Transitions in state machines should be limited
    to state machines, because these rules are overridden in the first
    rule for PseudoState in activity models. See Rule 3 and 4
    Transitions in State Machines: [p 118, UML 1.2 Semantics], and
    Rule 1 of PseudoState in Activity Models: [p 138 UML 1.2,
    Semantics].

  • Reported: UML 1.1 — Wed, 26 Aug 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

UML Semantics, section Common behavior

  • Key: UML14-891
  • Legacy Issue Number: 1815
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Attribute "body" of Metaclass "UninterpretedAction" is redundant to
    attribute "script" of Metaclass "Action"

  • Reported: UML 1.1 — Thu, 13 Aug 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Notion of "conceptual" or "specification-only" not supported

  • Key: UML14-890
  • Legacy Issue Number: 1789
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Currently UML fails to support the notion of "conceptual" or
    "specification-only" features, i.e. features introduced only for the
    purposes of defining pre/postconditions and other constraints.

    This is extremely important to anyone doing formal class specifications
    from which we hope to generate code (e.g. us) and should be an easy matter
    to resolve.

  • Reported: UML 1.1 — Mon, 10 Aug 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

OCL should allow the use of "let" expressions

  • Key: UML14-889
  • Legacy Issue Number: 1781
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OCL should allow the use of "let" expressions (for the sake of
    readability).

    Note: The lack of a "let" feature is also mentioned in the abstract for
    a paper on OCL at
    http://www.it.brighton.ac.uk/staff/Stuart.Kent/publications/UML98.html
    along with a number of other issues:

    "Specifically, the paper suggests that: the concept of flattening
    collections of collections is unnecessary, state models should be
    connectable to class models, defining object creation should be made more
    convenient, OCL should be based on a 2-valued logic, set subtraction
    should be covered more fully, and a "let" feature should be introduced."

  • Reported: UML 1.1 — Thu, 6 Aug 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue# 1689.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Text on page 2-49 section 2.2

  • Key: UML14-888
  • Legacy Issue Number: 1710
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In figure 2-13 Comment is a specialization of ModelElement. Yet the text on page 2-49 section 2.6.2 says that "Comment is a subclass of ViewElement." Also it mentions it has an association with a set of model elements. Presumably it would have a text attribute to hold the comment as well.

  • Reported: UML 1.1 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Text in Figure 2.13.7.1 ActivityState seems to be incorrect

  • Key: UML14-887
  • Legacy Issue Number: 1709
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In Figure 2.1 ActivityState is a specialization of SimpleState yet the text on page 2-135 in section 2.13.7.1 says "ActivityState is a SubmachineState". The text seems correct, ActivityState should be a specialization of SubmachineState.

  • Reported: UML 1.1 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with #928.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Need to have relative precedence and, or, xor

  • Key: UML14-886
  • Legacy Issue Number: 1695
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: You really need to have some relative precedence among
    and, or, xor and implies to have any hope of usefulness from these
    operators.
    You should also separate out the precedence of = and <> from the other
    comparisons

  • Reported: UML 1.1 — Fri, 17 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Need way to approximate comparisons

  • Key: UML14-885
  • Legacy Issue Number: 1694
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: You"ll need some ways to do approximate comparisions
    if you want reals to be useful in practical specifications.

  • Reported: UML 1.1 — Fri, 17 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Change events issue

  • Key: UML14-882
  • Legacy Issue Number: 1689
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Change events should be generalizable. For example, a traffic light
    changing to any color is a more general event than a change of that
    traffic light to Red only. If the second event happens, then the
    first must have happened also. A state machine with a trigger event
    on the first event will transition if the second event occurs.

    The semantics document says that an event can trigger transitions which
    have a more general event [p 113, UML 1.1 Semantics].

    Comments:

    This is close to issue # 29, "Events should be generalizable
    elements", which Rumbaugh filed and withdrew. His reasoning is that
    signals are generalizable and event are just pointers to them, so it
    is not necessary for events to be generalizable. In fact, events are
    more than pointers to signals, as shown in the event meta-model
    [figure 18, page 98, of UML 1.1 Semantics]. Events also cover call
    events, time events, and change events.

  • Reported: UML 1.1 — Fri, 17 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Collection operation size not defined for infinite collections

  • Key: UML14-881
  • Legacy Issue Number: 1687
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is not specified what the result is of the expression
    Integer.allInstances->size,
    neither of Real.allInstances->size. This needs to be added to the OCL
    Specification.

  • Reported: UML 1.1 — Wed, 15 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

pre value of object

  • Key: UML14-884
  • Legacy Issue Number: 1693
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Why can"t one ask for the @pre value of a object that has
    been destroyed during execution? Logically there"s no reason to prohibit
    this.

  • Reported: UML 1.1 — Fri, 17 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

It"s mistake to automatically flatten collections of collections

  • Key: UML14-883
  • Legacy Issue Number: 1691
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It"s a mistake to automatically flatten collections of
    collections. This is noncompositional in that Set

    {1,2}

    means something
    different when it"s in one context (another set, say) than it means
    everywhere else.

  • Reported: UML 1.1 — Fri, 17 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

States of an object not referenceable from OCL expression

  • Key: UML14-880
  • Legacy Issue Number: 1678
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The states of an object, as specified in its state machine, are not
    directly referenceablle from within
    an OCL expression. In many cases it is very useful to be able to use them
    in invariants, and especially
    in pre- and postconditions.
    Currently, we can define a so-called state attribue, which enumerates the
    states, or alternatively we can
    define a boolean attribute for each state. This allows one to reference
    states, but this is specific for
    the chosen implementation of states. This is undesireable. Being able to
    directly refer to the abstract
    states from the state machine is much easier, since it allows specifying
    constraints independent of
    the implementation of states.
    Proposal
    Define an extra standard OCL operation on OclAny called "oclIsInState", or
    "oclInState" which takes a state name as
    a parameter, and results in true if the object is within the specified
    state. This solution adds the
    desired functionality without altering the syntax of OCL.

  • Reported: UML 1.1 — Tue, 14 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Implicit transitive import between packages

  • Key: UML14-879
  • Legacy Issue Number: 1664
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implicit transitive import between packages is destructive for encapsulation management. "package Users import package TapeRecorder that import package integratedCircuit implies that package Users sees every public components of integratedCircuit". I suggest that imports becomes not transitive, so that import dependencies must be explicitely declared, or deduced from package aggregation.

  • Reported: UML 1.1 — Fri, 10 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Protocol state diagrams issue

  • Key: UML14-878
  • Legacy Issue Number: 1663
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML still does not develop the meaning and the semantics of protocol state diagrams. Protocol state diagrams are close to be supported by the UML metamodel, which still requires some smooth evolutions.
    In a protocol state diagram, a transition related to an operation expresses that the operation can be invoked under the origin state and the "guard" condition, and that under these preliminary context, the operation invocation will lead to the destination state, under a certain post-condition.
    A protocol state diagram can be entirely transformed into pre and post conditions for the involved methods.
    There is a need to add post-condition to transitions for protocol state diagram.
    Suggestion : add a new aggregation from transition to "Guard", called post.

  • Reported: UML 1.1 — Fri, 10 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Changes to figure 15 and description of ClassifierRole on page 82

  • Key: UML14-877
  • Legacy Issue Number: 1651
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Figure 15 on page 81 shows that a ClassifierRole has a single base Classifier.
    However, an Instance may have multiple Classifiers (see Figure 14 on p. 67).
    Indeed, the Notation Guide gives a notation for showing an Object having
    multiple Classes (on p. 46) and maps this notation to an Object within an
    object or class diagram, but to a ClassifierRole on a collaboration diagram.
    To support this notation, and to be consistant with the ability of Instances
    to have multiple Classifiers, a ClassifierRole should be able to have
    multiple base Classifiers.

    This requires a change to the multiplicity of the appropriate association
    in Figure 15 as well as updates to the ClassifierRole description on p. 82
    and the well-formedness rules for ClassifierRile on p. 84. (Actually, I think
    only the words in the WF rules need to change – the current OCL rules will
    accomodate the change in multiplicity of "base".)

  • Reported: UML 1.1 — Thu, 9 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Semantics for dynamic invocation of concurrent activity models are missing

  • Key: UML14-876
  • Legacy Issue Number: 1637
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Semantics for dynamic invocation of concurrent activity models are
    missing in the current UML version.

  • Reported: UML 1.1 — Mon, 6 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Collection type within OCL missing

  • Key: UML14-875
  • Legacy Issue Number: 1636
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no collection type within OCL that corresponds to the UML notion
    of an ordered list without duplicates [UML Notation Guide, ad/97-08-05, p.
    53, definition of "ordered"], i.e. an "ordered set".

  • Reported: UML 1.1 — Thu, 2 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Operation asSequence Issue

  • Key: UML14-874
  • Legacy Issue Number: 1635
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The operation asSequence is defined to return
    "A Sequence that contains all the elements from set, in random order."

    This probably should read "arbitrary order" since we are not promising to
    apply a "random number generator."

  • Reported: UML 1.1 — Thu, 2 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:36 GMT

No discription of the association between Classifier and Parameter is give

  • Key: UML14-873
  • Legacy Issue Number: 1634
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: No discription of the association between Classifier and Parameter is given.
    The indicates that the association (with the implicit name of parameter)
    is a set. It should also be noted that it is ordered.

  • Reported: UML 1.1 — Thu, 2 Jul 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Stereotypes on Dependency, page 43 of V 1.1 (figure 7)

  • Key: UML14-872
  • Legacy Issue Number: 1579
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are four stereotypes shown on Dependency on page 43 of V1.1 (Figure 7).
    Trace, Refinement, Binding and Usage
    These are shown as peers but are in fact representative of two very different
    types of partition.
    My proposal is to remove Usage as a subtype of Dependency. We could than add
    a new abstract type Relationship to model runtime relationships, with Associaton
    and Usage as subtypes. There should be no connection between Relationship
    and Dependency.

  • Reported: UML 1.1 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with 1227.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Reflexive association in section 5.20.2

  • Key: UML14-871
  • Legacy Issue Number: 1515
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In section 5.20.1, a "reflexive association" is defined as an association
    from a class to itself. This is consistent with the terminology as
    generally used in the field.

    However, in section 5.20.2, a reflexive association appears to be defined
    as one that has links from an object to to itself.

    This second defintion is not industry standard (including some of the
    amigos work), appears to conflict with 5.20.1 and somewhat misapplied. The contingent existence of an
    object-to-self link should not be changing the characterization of the
    association. A reflexive assocation need not require a reflexive link.

  • Reported: UML 1.1 — Wed, 10 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

The class "Subsystem" inherits from "GeneralizedElement" twice

  • Key: UML14-870
  • Legacy Issue Number: 1510
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The class "Subsystem" inherits from "GeneralizedElement" twice:

    SubSystem->Package->GeneralizableElement
    SubSystem->Classifier->GeneralizableElement

    The only functionality it adds to Package is the ability to add operations at the Subsystem level as indicated by the statement below:

    "In the metamodel Subsystem is a subclass of both Package and Classifier, whose Features are all Operations."

    I would recommend simplification of the class hierarchy by merging "Subsystem" into "Package" and deriving "Package" from "Classifier":

    Package->Classifier->GeneralizableElement

    The attibute "isInstantiable" of Subsystem can be moved up to Package.

  • Reported: UML 1.1 — Sat, 6 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Class "Model" is too prescriptive

  • Key: UML14-869
  • Legacy Issue Number: 1509
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: "Different Models can be defined for the same modeled system, specifying it from different viewpoints, like a logical model, a design model, a use-case model, etc."

    This statement is too prescriptive in suggesting that the modeled system should be partitioned into a logical model, a use case model, etc. The user may wish to partition the system using some other criteria, for example on functional lines, and may wish to "package" all the views for a particular function or facility within a single package. The partitioning suggested above can be easily obtained by using UML Packages named "Logical Model", "Use-Case Model" etc. Also note that class "Model" adds no attributes or associations to its superclass - it simply suggests a groping concept.

    Hence I recommend complete elimination of class "Model". The modeled system is simply a hierarchy of "Packages".

  • Reported: UML 1.1 — Mon, 15 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Clarify how types of attributes and parameters should be instantiated

  • Key: UML14-868
  • Legacy Issue Number: 1508
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is not very clear how types of attributes and parameters should be instantiated. For example, consider the following C++ methods:

    void Draw(Window win);
    void Draw(Window* win);
    void Draw(Window& win);

    In all three cases the name of the parameter is "win". The types are "Window", "Window*" and "Window&" respectively. How can these types be modeled? In the first case I can imagine creating a link between the parameter "win" and the Classifier "Window". But what about the remaining two cases?

    UML 1.0 represented attribute and parameter types by simple uninterpretted strings. This allowed user to specify any complex language expression for types. I would prefer that this mechanism be reintroduced. The current mechanism may be left in place in case users or tools like to specify tighter bindings to Classifier instances.

  • Reported: UML 1.1 — Sat, 6 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Merge "Class" and "Interface" into one class

  • Key: UML14-867
  • Legacy Issue Number: 1507
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Specifying "Interface" and "Class" as seperate metamodel classes has practical ramifications for UML tools. During analysis/design, a developer may start out by specifying a class, but then decide that it should be an interface. The reverse is also possible. This switching, from Class to Interface, or vice versa, would be very easy if "Interface" is merged into "Class" and the two concepts are distiguished by a stereotype called "interface". This recommendation is also supported by the fact that indeed the notation distinguishes the two concepts by a stereotype called "interface".

  • Reported: UML 1.1 — Sat, 6 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Withdrawn by submitter.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

UML 1.1 issue on Associations

  • Key: UML14-866
  • Legacy Issue Number: 1506
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The semantics of Navigation with Nary associations is not clear. For example, If we have three Classes C1, C2, C3 linked with a ternary association.
    If this ternary association is navigable to C3 : what does it means?? Does C1 and C2 instances may access to C3 linked instances through this association?
    Then if the ternary association is navigable to C2 and to C3. Is this legal? What does it means? Does C1 instances may access to C2 and C3 instances? Does C2 instances may access to C3 instances and C3 instances may access to C2 instances?
    Some clarification is needed there.
    I imagin that Navigability makes sense in binary association, but do not make much sense with Nary associations.

  • Reported: UML 1.1 — Fri, 5 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Extension Point

  • Key: UML14-865
  • Legacy Issue Number: 1406
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here is the new proposal for the definition of extension points.

    Extension point – a named location in the behavior specified by a
    Classifier. An extension point might either be before or after an
    Activity or an Action in an ActionSequence, or be a State. It is used
    for specifying where additional behavior may be added, e.g. by being
    referenced by an Extends relationship.

  • Reported: UML 1.1 — Mon, 1 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Specification for method in a derived class

  • Key: UML14-864
  • Legacy Issue Number: 1402
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is unclear whether a specification for a method in a derived class should be an operation in the base class, or if the operation is redeclared and it is the derived class"s instance of the operation that is the specification.
    The text on p36 ("Each method implements an operation declared in the class or inherited from an ancestor...the same operation may not be
    declared more than once in a full class descriptor") suggests that it is illegal to redeclare the operation in the derived class and we must have the former interpretation. However this is not enforced by the Classifier constraint [1] on page 29. If this is really what is desired, then the constraint should be self.allFeatures... instead of self.feature...

    This interpretation causes operations and methods to behave like C++ rather than Java. An operation has on

  • Reported: UML 1.1 — Mon, 1 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

State diagrams: action expressions

  • Key: UML14-863
  • Legacy Issue Number: 1400
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is there any reason why UML1.1 specifies different syntax for showing an
    action in response to an event, depending on whether the event is internal
    (NG 9.2.2) or external (NG 9.5.2)?

    And in the latter case, what is the point of the caret? For example, 9.5.2
    seems to suggest that we should probably write (yes, I"m hedging, because
    it isn"t completely clear there what can be in an action expression, or
    indeed what the overall syntax of a transition string is intended to be)

  • Reported: UML 1.1 — Mon, 25 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Responsibilities hardly figure in these documents

  • Key: UML14-860
  • Legacy Issue Number: 1391
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 3. Another major concern is the way that Responsibilities hardly figure in these
    documents. They are shown as a tagged value of Classifier and that is all.
    On page 156 a responsibility is defined as a contract. This is incorrect.
    The two are linked but in no-one"s responsibility and contract model
    (e.g. Wirfs-Brock, Meyer) are the two the same.
    Responsibilities are not even in the Index.
    I believe that a standard metamodel should be equally usable for a
    responsibility-driven modelling approach as for a use case or data driven
    approach. The lack of good support for responsibilities (which is not that
    hard - we have done it in OML as an extension of UML - see paper in <<UML>>"98
    Conference proceedings) is a significant drawback to the adoption of UML
    by organizations using any type of responsibility-driven method.

  • Reported: UML 1.1 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Permit multiple stereotyping on relationship

  • Key: UML14-862
  • Legacy Issue Number: 1393
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 5. Finally, a suggestion. In OML (see e.g. JOOP, May 1998) we found it useful
    to permit multiple stereotyping on relationships. In UML, as I understand it,
    there is a restriction that only a single stereotype can be used at any
    one time. Whilst care must be taken in multiple stereotyping, I would suggest
    that for predefined stereotypes there should be no problem and recommend
    UML consider permitting multiple stereotypes.

  • Reported: UML 1.1 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined

  • Updated: Fri, 6 Mar 2015 21:35 GMT

General recommended use of UML

  • Key: UML14-861
  • Legacy Issue Number: 1392
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 4. Whilst there is no statement explicitly, it is clear that the general
    recommended use of UML associations is as bidirectionality for the default.
    It has been shown by many that such an assumption is not in line with
    good OO modelling and indeed violates encapsulation: a key tenet of OT.
    The notation similarly supports such an interpretation and, furthermore,
    mandates the decision on directionality immediately since there is no
    way to sketch in a relationship whose direction is to be decided (TBD) later.

  • Reported: UML 1.1 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Aggregation is poorly defined

  • Key: UML14-858
  • Legacy Issue Number: 1389
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. Aggregation is poorly defined. It is not clear whether it is meant to be
    configurational and/or invariant (reading different parts of the documents
    give different signals). Instead it concentrates on lifetime dependency
    and unique connections. I believe it is intended to be invariant but not
    necessarily configurational. Firstly, that definition needs tightening and,
    to me and Jim Odell, being configurational seems to be a prime requirement
    for aggregation. Without it we really have a membership (yet still whole-part)
    relationship.
    Secondly, whatever the definition decided upon, its use in the metamodel must
    be clear and clean. At present, I believe many of the "black diamonds" in the
    metamodel really are not strong aggregations (whichever definition I try
    to use).

  • Reported: UML 1.1 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

"Inheritance" connection used is a generalization relationship

  • Key: UML14-859
  • Legacy Issue Number: 1390
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. In the same vein, it is clear that the "inheritance" connection used
    in all parts of the metamodel is in
    fact a generalization relationship. I believe this to be the best choice.
    However, I would ask whether ALL of the generalization relationships in the
    metamodel really do fulfil the criterion of generalization i.e. we can
    say yes to the question "is the subclass A KIND OF the superclass?".
    My biggest query here, which I have asked many times, is "Is a Generalizable
    Element a kind of Namespace?" as shown in Figure 6 of semantics document.
    Grady"s answer to me was "the simple reason is that superclasses form
    a namespace". Forming a namespace sounds to me like aggregation or
    membership and not generalization.

  • Reported: UML 1.1 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 98: arrowhead issue

  • Key: UML14-857
  • Legacy Issue Number: 1379
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 98 Filled arrowheads, stick arrowheads are dangerously close. For
    instance, Powerpoint only offers the filled and in other situations this
    would double for the stick arrowhead. In other words, too much semantic stress on
    arrowhead shape when many common tools like Powerpoint can"t differentiate.
    [Powerpoint is a simple example. I have watched tool vendors and publishers take
    a diagram like this and replace with their own versions of a black/white;
    open/closed arrowhead and accidentally transform the meaning. Even from
    UML generalization to stick arrowhead for dependency is not that hard -
    I"ve seen it done!]

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 94 --editorial

  • Key: UML14-856
  • Legacy Issue Number: 1378
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 94 I am unconvinced about class roles and association roles (bottom half)
    and this text seems to have been pasted in from elsewhere

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 82: Add explanation

  • Key: UML14-855
  • Legacy Issue Number: 1377
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 82 Why do some arrows have solid heads and yet on the previous page they
    were open both to left and to right? An explanation of these
    notational elements must be added to page 81/2

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 80: Confusion with headings

  • Key: UML14-854
  • Legacy Issue Number: 1376
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 80. I still get confused with the headings here. Interaction diagrams is
    a collective name which includes both sequence diagrams and collaboration
    diagrams. So the heading for section 7 of Sequence diagrams seems wrong
    because it is low level followed by a high level heading of Kinds of
    Interaction Diagrams.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 72: Example needs rejigging

  • Key: UML14-852
  • Legacy Issue Number: 1374
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 72 If Class C - Class B relationship is instantiates, then surely
    Class C should be Object C. A consequence of this is that the <<calls>>
    is now wrong because it needs to be between 2 classes. Example needs
    rejigging.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Consdered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 71: Distinction between Dependency and Association

  • Key: UML14-851
  • Legacy Issue Number: 1373
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 71 I don"t find a clear distinction between Dependency (especially
    its <<uses>> stereotype) and Association. Since all OO is to do with
    Client-server relationships, these must all be Dependencies thus eliminating
    the need for Association!!?? My answer is that they are equivalent but with a
    different focus, an association describing the static architecture and a uses
    the dynamic (message-passing) topology – see Henderson-Sellers, Feb 1998, JOOP

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 67: Why is discriminator not discussed in terms of power types?

  • Key: UML14-849
  • Legacy Issue Number: 1371
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 67 Why is discriminator no longer discussed in terms of power types?
    If correct, that was neat (in the previous version)

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 68 overlapping

  • Key: UML14-850
  • Legacy Issue Number: 1372
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 68 overlapping/disjoint. This relates to whether the subsets overlap
    or not; in other words, whether an individual instance can belong to more
    than one of the subclasses. At present it implies there are classes,
    subclasses and subsubclasses. Suggest reworing (for both overlapping
    and disjoint) as
    ...may be an instance of ...
    rather than
    ... may be descended from ...
    Typo: descendant (-ant not -ent by the way)

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 79: Poor choice of arrowhead

  • Key: UML14-853
  • Legacy Issue Number: 1375
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 79 The <<uses>> relationship is a poor choice of arrowhead, since the
    white arrowhead is a generalization-style. What is needed is something
    more reminiscent of either association, or, probably better, dependency. So
    an open arrowhead, possibly even with dotted line as in Dependency
    stereotyped with <<uses>> in static diagrams might be better.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Consdered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 52 figure 20

  • Key: UML14-846
  • Legacy Issue Number: 1368
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 52 Figure 20. In the recursive association on Job,
    how does the Job play the role of boss or worker?

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos on pages 24, 40, and 50

  • Key: UML14-845
  • Legacy Issue Number: 1367
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 24 line -3 Typo Being should be Begin
    Page 40 Arrowhead wrong <<bind>> is a stereotyped dependency. Open
    arrowhead needed

    Page 50 Section 5.20.2 para 2 l1. Typo Un should be In and para 3 l1
    hasn"t association role now been changed to association end?
    (see p52 in Semantics doc)

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 58: Add index entry

  • Key: UML14-848
  • Legacy Issue Number: 1370
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 58 I had difficulty in finding Qualifier in the metamodel of
    the Semantics document (it isn"t in the index – suggest adding index entry)

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Rebuild index on each release.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 57: mathematical issue

  • Key: UML14-847
  • Legacy Issue Number: 1369
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 57 Mathematically .. cannot be identical to 0..*. Since * is a "wild
    card" value, then it could be say 1. So the first would be 1..1 and the
    second 0..1 i.e. different

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 35/6: Why are attributes and association not inherited?

  • Key: UML14-844
  • Legacy Issue Number: 1366
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 3. Why are attributes and associations not inherited? (The diagram is
    confusing since elements:Collection is not inherited yet appears to be).
    This odd sort of inheritance is stressed again in connection with
    Interfaces on page 36 and again on page 37 (last line).
    If Types can have attributes (presumably logical attributes) then surely
    the ImplementationClass needs to know about these to map into physical
    attributes or methods in its implementation.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 35/6: Use of word type is confusing

  • Key: UML14-843
  • Legacy Issue Number: 1365
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. The use of the word Type here is confusing. In previous versions it
    was used as approximately the same as Interface as in: "the Class
    realizes/implements the Type". Here it seems to be a synonym for
    Role as in OOram (or OPEN). Why not just call it Role, for that is
    what it seems to be – a type of dynamic classification.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 30: Class scope attribute underlined

  • Key: UML14-841
  • Legacy Issue Number: 1363
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 30 Class-scope attributes underlined. I think users will find this totally
    obtuse. For consistency one really should underline object attributes.
    I understand that they are more common but ...
    Users will also find the explanation here arcane and contrived.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 29: Protected member

  • Key: UML14-840
  • Legacy Issue Number: 1362
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 29 Protected visibility only has meaning in context of inheritance.
    Fromoutside a protected member is essentially a private (i.e. encapsulated)
    one.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 35/6 : Stereotypes

  • Key: UML14-842
  • Legacy Issue Number: 1364
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 35/6 I have a number of problems here.
    1. Stereotypes are merely a subclassing or specialization mechanism
    (Notation doc, p20, l2). Agreed. The question is whether Type and
    ImplementationClass are really subtypes of Class. This I doubt.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 26: rename reponsibilities, rules, modification histories etc.

  • Key: UML14-839
  • Legacy Issue Number: 1361
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 26 line -6 responsibilities, rules, modification histories etc.
    These are collectively called traits in OML. A useful way of describing
    them which we recommend to you.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 24 Section 5.4.3 para 1: missing compartments

  • Key: UML14-838
  • Legacy Issue Number: 1360
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 24 Section 5.4.3 para 1 re missing compartments. This will be
    confusing to users when boxes are absent with no obvious clue as to
    which it is that is present. This is much more important for novices;
    experts will cope.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 24: add link to Interface

  • Key: UML14-837
  • Legacy Issue Number: 1358
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 23 notation and page 16 semantics say Interface is subtype of
    Classifier. Yet on page 24 Semantics it is stated that a Classifier
    realizes the Interface. Since both are true, perhaps a link should be
    made somewhere to give the complete picture.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 13: Packages are GeneralizableElements

  • Key: UML14-835
  • Legacy Issue Number: 1356
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 13 Packages are GeneralizableElements. I understand they can be
    inherited, yet I am not sure what that may mean, especially with
    respect to protected status
    This seems to be using C++ syntax at too high a level of abstraction

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarifed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 11: Operation-Call

  • Key: UML14-834
  • Legacy Issue Number: 1355
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 11 line -9 Operation-Call. I don"t find this (a) intuitive and
    (b) in the metamodel. A Method implements an Operation and a call is the
    dynamic activation of an operation – is it really an instance of an
    Operation? Surely Operation-Call should read Operation-Method.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 20: Section 4.3.1 could be misleading

  • Key: UML14-836
  • Legacy Issue Number: 1357
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 20 I think Section 4.3.1 could be misleading since we are talking
    of the subclasses at the *meta*level. Saying it "represents a subclass
    of an existing modelling element" could be (erroneously) interpreted
    at the model, rather than the metamodel, level. This is particularly
    likely since the description is part of the Notation doc. Had it been
    part of the Semantics doc, its context there would have not led to any
    problems.

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Editorials on pages iv, v, 3, and 4

  • Key: UML14-833
  • Legacy Issue Number: 1354
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page iv and v Section 7 and 7.2 and 10 and 10.2 have same names. This is not
    normal practice

    Page 3 line -9 no dangling lines – agreed re final diagram but may be
    needed as interim state

    Page 4 para 2 Two options equivalent. Yes, except for discriminants when
    joining together all paths would be wrong

  • Reported: UML 1.1 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos on page 90, 151 plus errors in page numbering

  • Key: UML14-832
  • Legacy Issue Number: 1351
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 90 line 1 typo Ref to Figure 15 should be to Figure 16 presumably
    Page 151 Typo dependency line 2 will affect should be may affect

    Page 161 Lots of errors on pages numbers e.g. Dependency should be
    22, 31, 43, 44, 141; Mapping 60 etc.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 143: "uses" as a stereotype on Generalization

  • Key: UML14-831
  • Legacy Issue Number: 1350
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 143 <<uses>> as a stereotype on Generalization. It is also an important
    stereotype on Dependency.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 143: uses is a stereotyped dependency

  • Key: UML14-830
  • Legacy Issue Number: 1349
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 143 Uses is a stereotyped Dependency (Notation page 71) and so should
    be added to list in Semantics document here on page 143 and also on page 50

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 136: Model package relationship

  • Key: UML14-829
  • Legacy Issue Number: 1348
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 136 Model - Package relationship (in diagram) should not be
    aggregation but generalization (according to page 129, Figure 23)

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 98: Transition is an aggregation of guards

  • Key: UML14-828
  • Legacy Issue Number: 1347
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 98 Transition is an aggregation of guards. Surely, the guard
    governs whether a transition takes place, it is not an integral part of
    it. Similarly, I don"t believe that a State is made up of (i.e.
    composite aggregation) Transitions!

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Uses and extends not types of generalization

  • Key: UML14-827
  • Legacy Issue Number: 1346
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 93 Lots will argue, as do I and Rumbaugh in JOOP some years ago, that
    uses and extends are NOT types of generalization. They do not have
    substitutability in the sense of a generalization hierarchy for Classes,
    for instance.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 93: use case

  • Key: UML14-826
  • Legacy Issue Number: 1345
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 93 Is Use Case really a composite aggregation of attributes and
    operations – surely not?

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Discussion on Collaborations and Interactions is confusing

  • Key: UML14-824
  • Legacy Issue Number: 1343
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 86 et seq. I find the discussion on Collaborations and Interactions etc.
    confusing. It seems to be inconsistent. On page 86 we have Collaboration is
    at a higher level than Interaction and Collaboration is an aggregate of
    Interactions. Whilst in the Notation Guide (see also Fowler and Scott,
    p103-110) Interaction diagrams are at a higher abstraction level than
    Collaboration diagrams (page 80 of Notation guide)

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    considered and declined

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos on pages 55 and 62

  • Key: UML14-823
  • Legacy Issue Number: 1342
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 55 Typo line -4 base Class Specifies (not Species)

    Page 62 Typo line -3 String not Sting

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 93: Is Namespace really aggregeation of use cases?

  • Key: UML14-825
  • Legacy Issue Number: 1344
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 93 Is a Namespace really an aggregation of use cases? I thought a
    namespace could be at the class level whereas use cases often involve
    very many classes.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 50 Table 3 "refinement"

  • Key: UML14-822
  • Legacy Issue Number: 1341
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 50 Table 3 <<refinement>> should be added as a stereotype of Dependency.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 47: Dependency is a unidirectional, client-server

  • Key: UML14-818
  • Legacy Issue Number: 1337
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 47 Dependency is clearly a unidirectional, client-server relationship.
    Usage, as a stereotype of Dependency, similar. But I don"t get the same
    feel for Trace and, to a lesser degree, Refinement. Indeed, trace seems
    to negate some of the properties of Dependency - a bad practice as
    Brachman pointed out many years ago. For example, Trace has no
    directionality yet it inherits unidirectionality from Dependency which it must
    therefore cancel/negate.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue# 1227.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 45 dependency lines 2/3 between model elements not instances?

  • Key: UML14-817
  • Legacy Issue Number: 1336
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 45 Dependency lines 2/3 between model elements not instances. Really?
    But A <<uses>>B is a client-server at instance level also, where
    <<uses>> is a stereotyped Dependency. Why is this discrimination between
    class/type versus instance applied here so explicitly. (BTW I have been
    trying to elucidate the connection between Dependency and Association as
    raised in OTUG by Bob Martin and others. My answer is in my JOOP
    column of Feb 98. I have constructed an interesting and progressive metamodel
    for relationships including aggregation-type ones which seems to make overall
    sense).

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 50: should stereotypes be defined at the subclass level?

  • Key: UML14-820
  • Legacy Issue Number: 1339
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 50 Dependency has 4 subtypes (refinement, trace, binding, usage) and
    (page 50 semantics) 10 or so stereotypes. Each of these stereotypes
    can be applied to each of the 4 subtypes. Are all combinations valid?
    If not, some of the stereotypes should be defined at the subclass level, not
    as stereotypes of the superclass, Dependency.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with #1227

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 50: "instance" should be changed to "instatiate"

  • Key: UML14-819
  • Legacy Issue Number: 1338
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 50 We have <<instance>> and on page 71 notation doc <<instantiates>>.
    I understand from Cris Kobryn that this will be fixed and both will be
    changed to <<instantiate>> [comment included here for completeness only]

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 50: table 3 component

  • Key: UML14-821
  • Legacy Issue Number: 1340
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 50 Table 3 Component. Stereotype <<friend>>. Elsewhere the document says
    this is a stereotype of <<using>>

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 38 para 2 line 3, one of its containers is deleted

  • Key: UML14-814
  • Legacy Issue Number: 1333
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 38 para 2 line -3 one of its containers is deleted.
    Bad choice of word (container). Containment is a relationship which is NOT
    related to aggregation. This para discusses aggregation and should not therefore
    discuss containment (see Winston et al., 1987, Odell, 1994,
    Henderson-Sellers, 1997).

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 35 Diagram (02)

  • Key: UML14-813
  • Legacy Issue Number: 1332
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 35 Diagram. Is a Class really a composite aggregation of model eleemnts.
    I guess the answer is yes since it inherits from Namespace. However, as
    I am challenging the Generalizable Element/Namespace inheritance, this might
    have repercussions here.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 35 -Diagram

  • Key: UML14-812
  • Legacy Issue Number: 1331
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 35 line beneath diagram A class declares a collection of methods,
    operations and attributes. Since methods implement operations, then this is
    confusing concepts at two different levels which elsewhere are cleanly
    separated into the internal/external dichotomy which objects need to support
    (and which in general in UML is much improved)

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Class to be defined as an intension

  • Key: UML14-811
  • Legacy Issue Number: 1330
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 20 Class. A class is a description of a set ...
    This is a definition of class as an extension. We also need class to be
    defined as an intension (Odell and de Champeaux also stress this).

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Aggregation of class?

  • Key: UML14-816
  • Legacy Issue Number: 1335
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 45 Component. Is it really a class – or perhaps an aggregation of classes?

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 40 table 2 Model Element class

  • Key: UML14-815
  • Legacy Issue Number: 1334
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 40 Table 2 Model Element Class. Surely the stereotype of inherits is
    incorrect here. It is not correct according to the Appendix.
    Also <<thread>> for Generalization is not defined – page 143. Is it correct?

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed is UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

How to stop an interface realizing a Data Type ?

  • Key: UML14-810
  • Legacy Issue Number: 1329
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 20 line -2 "may realize zero or more interfaces". Where is this shown in
    the metamodel? Answer is recursively on page 16. But how to you stop an
    Interface realizing a DataType, for instance?

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Why does GeneralizableElement inherit from Namespace?

  • Key: UML14-809
  • Legacy Issue Number: 1328
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 17 Figure 6 Why does GeneralizableElement inherit from Namespace? This is
    a question to which I really would appreciate an answer. I asked Grady but
    got an unconvincing answer (see General point 2 above). The white triangled
    arrowhead indicates generalization i.e. knowledge representation and/or
    subtyping. I don"t see how a GeneralizableElement is a kind of Namespace.
    I see that a Namespace would include (containment or maybe even aggregation) a
    Generalizable Element but ...

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 16 lost fact that Class realizes an interface

  • Key: UML14-806
  • Legacy Issue Number: 1325
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 16 Lost the fact that Class realizes an Interface although I think this
    may just have been moved to Classifier realizes an Interface. But this is
    no longer explicit.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Page 16 ---editorial (Element Ownership)

  • Key: UML14-808
  • Legacy Issue Number: 1327
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 16 Isn"t Element Ownership an Association Class - in which case the
    joining line should be dotted.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Is name space really a *composite aggregation* of model elements?

  • Key: UML14-807
  • Legacy Issue Number: 1326
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 16 Is a namespace really a composite aggregation of model elements?

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Interface must also have features

  • Key: UML14-805
  • Legacy Issue Number: 1324
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 16 If Classifiers have features (e.g. attributes and methods) then an
    Interface must also have features since it is a kind of Classifier. Yet,
    on page 24, it is stated that an Interface has operations only; on page 37
    Notation document it clearly states Interface "lacks attributes". If this is
    done by an OCL constraint, then we have a negation of properties of the
    subtype which Brachman points out to be dangerous.

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Why is Classifier an Aggregate of Features?

  • Key: UML14-804
  • Legacy Issue Number: 1323
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 16 Why is Classifier an Aggregate of Features (black diamond). It also
    needs a name; and is it really invariant? (Or, more broadly, does it have
    the properties of a composite aggregation - but see General Concern 1
    above)

  • Reported: UML 1.1 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Collaboration as a Classifier

  • Key: UML14-803
  • Legacy Issue Number: 1309
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It appears very useful to make Collaboration a subtype of Classifier or
    GeneralizableElement (instead of just Namespace). This would allow
    refinement of Collaborations using the standard UML refinement
    mechanisms.

  • Reported: UML 1.1 — Tue, 5 May 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Interfaces and support classes

  • Key: UML14-802
  • Legacy Issue Number: 1290
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: in UML I"m missing a specified way (e.g. a class stereotype) to
    support the paradigm of "interfaces and support classes". I think it
    would be a convienient way to specify the interfaces which are offered
    by a class like methods and properties:

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

    SomeContainer
    <<implementation Class>>

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

    interface IIndexAccess
    interface IEnumerationAccess
    interface ISomewhatOther

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

    property PropA
    property PropB

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

    The other thing annoying for me is the definition of aggregation. My
    understanding of aggregation ist that the aggregating object offers
    the interfaces of the aggregated objects as they where it"s own (for
    the outer view). The definition of UML seems to be only a "containing"
    relationship.

  • Reported: UML 1.1 — Wed, 29 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

UML Semantics, p 81, 145

  • Key: UML14-801
  • Legacy Issue Number: 1248
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Semantics introduces AssociationRole and AssociationEndRole wich inherits from the original Association and AssociationEnd (p81). Unfortunately, the xxxRole have a mandatory xxx as a "base" (multiplicity 1). I believe this is a bug, since it forces you to create an explicit association between the Classifiers, even for a

    {global}

    link, etc. Suggested correction: make the base optional (multiplicity 0,1) for AssociationEndRole with constraint base, local, global, self or parameter; make it optional too for related AssociationRole; leave it as is (mandatory) for ClassifierRole. Make it mandatory through OCL constraints for other AssociationEndRoles and AssociationRoles.

  • Reported: UML 1.1 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue# 1019.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

UseCaseInstance badly defined

  • Key: UML14-798
  • Legacy Issue Number: 1235
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UseCaseInstance inherits from Instance, which inherits from
    ModelElement.
    Since a UseCaseInstance has no attributes and relationships defined, it
    has
    only those inherited, which are: name, the set of attribute slots and
    the
    link to a Classifier. Therefore, the statement "An explicitly described
    UseCaseInstance is called a scenario" (Semantics pg. 91) has no
    meaning,since
    there is no way to describe a UseCaseInstance by means of anything else
    than
    its UseCase.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Extension/recommendation needed for inner/outer transitions

  • Key: UML14-800
  • Legacy Issue Number: 1237
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: An extension (or at least a recomendation) must be done in order to be
    able
    to express that a transition between two substates of the *same*
    CompositeSate crosses or not the boundary of the CompositeSate. If the
    transition crosses the boundary of the CompositeState, the
    CompositeState is
    re-entered: the exit+entry actions are re-executed, while if the
    transition
    does not cross the boundary.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Notation for state machine inheritance

  • Key: UML14-799
  • Legacy Issue Number: 1236
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation for state machine inheritance is defined in Semantics (pg.
    116)
    instead of Notation.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    UML 1.3: Clarified that notational example in Semantics is non-normative.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Collaboration showing instances

  • Key: UML14-793
  • Legacy Issue Number: 1230
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If "an Interaction specifies messages sent between instances" (pg. 83)
    where
    are the instances on the diagram on page 81?
    I think a clear distinction between the meta-levels should be made. If
    Collaborations show ClassifierRoles and AssociationRoles (see fig. 15
    pg.
    81), the text should not imply that they show Instances and Links. The
    concepts are distinct, since they are modeled through two different
    classes
    in the metamodel.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Inconsistency between stereotype tables

  • Key: UML14-792
  • Legacy Issue Number: 1229
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are inconsistencies between the tables containing stereotypes (at
    the
    end of each chapter) and Appendix A: <<inherits>> is a stereotype of a
    Class
    or of a Generalization; <<metaclass>> is a stereotype of a Constraint or
    of
    a Classifier; <<thread>> is a stereotype of Generalization or of
    Classifier.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Multiple transitions from initial states should be allowed

  • Key: UML14-796
  • Legacy Issue Number: 1233
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Maybe it would be useful to allow multiple transitions leaving an
    initial
    pseudostate (or multiple initial pseudostates), corresponding to
    multiple
    constructors of a class.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Modeling of guards

  • Key: UML14-795
  • Legacy Issue Number: 1232
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Guard is a class, but it could have been modeled as an attribute in
    Transition, with the type BooleanExpression.
    If it is left as a stand-alone class, it doesn"t have to inherit from
    ModelElement, especially since ModelElement has many associations, and
    Guard
    doesn"t use them at all. In fact this is more or less the case with many
    other descendants from ModelElement (for example, an Association doesn"t
    use
    the following associations inherited from ModelElement: behavior
    (towards
    StateMachine), collaboration (towards Collaboration) ).

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Collaboration::constrainingElement semantics

  • Key: UML14-794
  • Legacy Issue Number: 1231
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Collaboration::constrainingElement doesn"t have a clear semantics.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Semantics of terminate transitions

  • Key: UML14-797
  • Legacy Issue Number: 1234
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The semantics of terminate transitions leaving a CompositeState with
    sub-regions is defined in Notation pg. 105. It should be in Semantics,
    though.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Stereotypes for superclasses do not apply to superclasses

  • Key: UML14-790
  • Legacy Issue Number: 1227
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are a lot of stereotypes defined for Dependency, but which can
    apply
    only to some subclasses of Dependency. Example: <<call>> or <<becomes>>
    which certainly cannot apply to a Binding.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Inconsistent use of stereotypes, tagged values, and metamodel

  • Key: UML14-789
  • Legacy Issue Number: 1226
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The use of stereotypes, tagged values and metamodel subclassing is not
    consistent in the metamodel. For instance, subclassing is used when
    defining
    the states specific to Activity Models, though the subclasses
    (ActivityState, ActionState) have no specific attributes and could have
    been
    stereotypes. The same with the subclasses of Action. Both approaches are
    correct, but since the two mechanisms are not orthogonal, there should
    be
    stated explicitly when to use one and when to use the other.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Class WFR (01)

  • Key: UML14-788
  • Legacy Issue Number: 1224
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Correct WFR Class [1] pg. 29: m.specification ham multiplicity 1 so no
    "includes" is needed.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue 864.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Modeling of realization/specification

  • Key: UML14-787
  • Legacy Issue Number: 1223
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Most of the relationships drawn on UML diagrams are modeled in the
    metamodel as classes (ex: Association, Dependency and Generalization
    with
    their possible subclasses).
    The relationship between a classifier and the classifier(s) that it
    implements is modeled by an (auto)association of Classifier
    (realization/specification, from Semantics, Fig.5 pg. 16), although it
    has
    a representation on UML class diagrams.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Stereotype modeled in two ways

  • Key: UML14-791
  • Legacy Issue Number: 1228
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The concept of stereotype is modeled in two ways in the metamodel: as a
    class (Stereotype in the Extension Mechanisms package) and as a
    stereotype
    of Classifier, called <<stereotype>>.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

GeneralizableElement should not inherit from Namespace

  • Key: UML14-786
  • Legacy Issue Number: 1222
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: GeneralizableElement inherits from Namespace (Semantics, Fig. 5 pg.
    16).
    This is not right because the property of an element of being
    generalizable
    and the property of being a namespace for other elements owned by it are
    orthogonal

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Syntax for Sequence Expressions inconsistently used

  • Key: UML14-785
  • Legacy Issue Number: 1221
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 8.9.2 pg. 99 defines the syntax for Sequence Expressions which
    is
    different from the one used in Fig. 40 pg. 97

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Threads of control in Collaboration Diagrams

  • Key: UML14-784
  • Legacy Issue Number: 1220
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 8.9.2 pg. 99 defines the syntax for Sequence Expressions,
    using
    names to differentiate between threads of control. These names do not
    map
    into anything in the metamodel.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Control Flow types not modeled

  • Key: UML14-783
  • Legacy Issue Number: 1219
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 8.9.2 pg. 98 defines at least three kinds of Control Flow Type
    that have no mapping defined. In fact the metamodel does not support
    them,
    and besides that, they are ambiguous. The meaning of "flat flow of
    control"?
    should be explained in the document.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

RaiseAction and TimingMark are not defined

  • Key: UML14-782
  • Legacy Issue Number: 1218
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 9.5.4 pg. 112. RaiseAction and TimingMark do not exist in UML.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Mapping of concurrent subregions

  • Key: UML14-781
  • Legacy Issue Number: 1217
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 9.3.4 pg. 108. Each concurrent subregion map into a
    CompositeState?

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

"do" action not supported

  • Key: UML14-780
  • Legacy Issue Number: 1216
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 9.2.4 pg. 106,104: "An internal action string with the name
    "do"
    maps into the invocation of a nested state-machine."
    My understanding is that this means that the state containing the "do"
    action is a SubmachineState with a separated State Diagram, drawn
    elsewhere.
    If this is the case, it should be stated more explicitly in the Notation
    document.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Notation for iteration in sequence diagram

  • Key: UML14-779
  • Legacy Issue Number: 1215
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 7.5.3 pg. 86. The notation for iteration is not clearly
    defined.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

"derived" not defined

  • Key: UML14-778
  • Legacy Issue Number: 1214
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 5.30.5 pg. 74. Where is "derived" defined?

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

WFR for bound elements missing

  • Key: UML14-775
  • Legacy Issue Number: 1211
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 5.12.3 pg. 41. "Note that a bound element is fully specified
    by
    its template, therefore its content may not be extended [...]". This is
    a
    semantic rule that is important enough to be stated in the Semantics
    document (and not in Notation) and it should be a WFR.
    In fact, the contents of a bound element (definable in terms of its
    template with some replacements) is not defined formally at all.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with #1016.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

The meta-type of template parameters

  • Key: UML14-774
  • Legacy Issue Number: 1210
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is not specified what is the meta-type of the template parameters
    that
    are exemplified in Notation, Fig. 14 pg. 40. T is a Class? k:integer
    maps to
    a Parameter object? And what can be the (meta)types of the actual
    parameters
    that can replace the template parameters. Some Well-Formedness Rules
    would
    be welcome.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue# 1016.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Dependency wrongly mapped

  • Key: UML14-773
  • Legacy Issue Number: 1208
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 5.10.4 pg. 38 says that <--- maps to a <<uses>> Dependency. In
    fact
    it should map to a Usage (subclass of Dependency) and not to a <<uses>>
    Dependency, which is a stereotype for relationships between use-cases.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

<>, <>, <>, <>, not well supported

  • Key: UML14-777
  • Legacy Issue Number: 1213
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 5.27.2 pg. 65 says that <<local>>, <<parameter>>, <<global>>,
    <<self>> are LinkEnd stereotypes, when they are in fact constraints.
    Moreover, <<local>>, <<parameter>>, <<global>> and <<self>> are not
    well
    supported by the metamodel, because a Link has a unary association to an
    Association, and a <<local>>, <<parameter>>, <<global>> and <<self>>
    Link do
    not refer to any association.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Namespace in case of containment

  • Key: UML14-776
  • Legacy Issue Number: 1212
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Does the containment of a class symbol within another class symbol mean
    also that the namespace of the contained is the container?
    If not, a notation for the namespace-containment relationship must be
    given.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Package importing transitive

  • Key: UML14-772
  • Legacy Issue Number: 1207
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Package importing is transitive (Semantics/Package pg. 135). But the
    definition of UML uses importing not in a transitive way. For example,
    there
    are defined the following import relationships: AuxiliaryElements --->
    Core,
    Core ---> DataTypes and AuxiliaryElements ---> DataTypes.
    The renamig (aliasing) rule also confilcts with the transitive import:
    a
    module can be imported through multiple paths, therefore the model
    elements
    from a module can be imported repeatedly, possibly under different
    names.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    considered and declined

  • Updated: Fri, 6 Mar 2015 21:35 GMT

"invoked" not defined

  • Key: UML14-771
  • Legacy Issue Number: 1206
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Semantics/ObjectFlowState[1,2] pg. 124 uses "invoked" which is not
    defined.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Bad example for LCA, main source, main target

  • Key: UML14-770
  • Legacy Issue Number: 1205
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In example 2 pg. 114, according to the definition of LCA, main source,
    main
    target, LCA(t)=s, main source(t)=region 1 of s, main target(t)=region 2
    of
    s. Text says all of them are s.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Transition WFR badly written

  • Key: UML14-769
  • Legacy Issue Number: 1204
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Rules Transition [6] and [7] pg. 105-106 should be rewritten. One of
    the
    problems with them is:

    In rule Transition [6] pg. 105-106, the fact that the originating
    regions
    of a group of transitions entering a fork pseudostate should be
    orthogonal
    is not caught. A configuration like:
    state A with subregions B and C, b1 substate of B and transitions t1
    and t2 both exiting b1 and entering the same join state
    satisfies the constraint, although it is clearly wrong.

    The same problem appears for rule [7] pg. 106, for fork pseudostates.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Entry/Exit actions execution order

  • Key: UML14-768
  • Legacy Issue Number: 1203
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The order in which the entry/exit actions are executed when entering /
    exiting a substate of a composite state is not given. The semantics is
    probably that the entry actions are executed sequentially from outer to
    inner states, and the exit actions are executed viceversa, but it should
    be
    stated explicitly.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

CompositeStates with non-composite subregions allowed

  • Key: UML14-767
  • Legacy Issue Number: 1202
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A CompositeState with isConcurent=TRUE should have only CompositeStates
    as
    substates (at least this is the only example explained in the
    documents).
    This is a Well-Formedness Rule missing from Semantics.
    If this is not the case, then a semantics for the other cases (cases of
    CompositeStates with substates that are not sub-regions) should be
    explained.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Message::base undefined

  • Key: UML14-766
  • Legacy Issue Number: 1201
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What is "base" used in Semantics/Message pg. 83.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

AssociationEnd-AssociationEndRole inconsistencies

  • Key: UML14-765
  • Legacy Issue Number: 1200
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Can there be inconsistencies between an AssociationEndRole and its base
    AssociationEnd, such as: an AssociationEndRole having a different name,
    multiplicity, changeability status or ordering status compared to its
    base?
    If not, this should be a Well-Formedness Rule (even if an informal
    one).

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Argument::type not defined

  • Key: UML14-764
  • Legacy Issue Number: 1199
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Argument::type used in Semantics/CallAction [1] pg. 74 is not defined.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Defined in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

WFR for instance links

  • Key: UML14-762
  • Legacy Issue Number: 1197
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Rule Instance[2] pg. 74 does not take into account the direction of
    association, and therefore is incorrect. The rule should have referred
    to
    LinkEnds and AssociationEnds, and not to Links and Associations.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Well-formedness Rules for Action::actualArguments

  • Key: UML14-761
  • Legacy Issue Number: 1196
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Since request and actualArguments are defined in Action, why the
    Well-Formedness Rules concerning these associations are defined only for
    CallAction and SendAction. At least LocalInvocation should have the same
    WFR.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

CallAction::request

  • Key: UML14-760
  • Legacy Issue Number: 1195
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Semantics/CallAction [1] pg. 74 should read "request" instead of
    "message"
    in the OCL rule.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

CallAction::isAsynchronous and CallAction::mode

  • Key: UML14-759
  • Legacy Issue Number: 1194
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CallAction has both "isAsynchronous" and "mode:

    {sync, async}

    ".
    Redundancy.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

MessageInstance not used

  • Key: UML14-763
  • Legacy Issue Number: 1198
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: MessageInstance is an Instance of a Message? In which notation is it
    used?

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Node and Component parent

  • Key: UML14-754
  • Legacy Issue Number: 1188
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Node and Component are subclasses of Class or Classifier? Inconsistency
    between the diagram and the text: Semantics pg. 44 - 46.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Qualifier badly modeled

  • Key: UML14-753
  • Legacy Issue Number: 1187
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A qualifier should be modeled as a (in) Parameter and not as an
    Attribute
    (see fig. 6 pg 17). An Attribute has an ownerScope, a visibility, a
    changeability and a targetScope that are not characteristics for a
    qualifier. A Parameter instead has exactly what is needed for modeling a
    qualifier.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Action::isAsynchronous and Action::script not defined

  • Key: UML14-758
  • Legacy Issue Number: 1193
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Semantics Fig. 13 pg. 67 shows the attributes Action::isAsynchronous
    and
    Action::script, that are not defined(explained) in the text.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Defined in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Signal::isAsynchronous and Signal::direction not defined

  • Key: UML14-757
  • Legacy Issue Number: 1192
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Well-Formedness Rule Signal [1] pg. 76 refers to "isAsynchronous" and
    "direction" that are not defined anywhere.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Request"s parents

  • Key: UML14-756
  • Legacy Issue Number: 1191
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Request is a subclass of BehavioralFeature or ModelElement?
    Inconsistency
    between the diagram and the text: Semantics pg. 66/72. Also, it should
    be
    abstract (shown in italics).

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    considered and declined

  • Updated: Fri, 6 Mar 2015 21:35 GMT

"implementation" association not defined

  • Key: UML14-755
  • Legacy Issue Number: 1190
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The "implementation" association between Component and ModelElement
    (Semantics, pg. 44) is not explained.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Signature conflicts across an inheritance hierarchy

  • Key: UML14-752
  • Legacy Issue Number: 1186
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If in a multiple inheritance graph we have an operation defined in two
    different ancestors of a class, the model is ill formed, although such a
    situation is very likely to happen in real life.
    Proposal: adopt a more relaxed semantics such as that of C++ or Eiffel
    for
    such a situation.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Exotic uses of generalization

  • Key: UML14-751
  • Legacy Issue Number: 1185
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Semantics allows exotic usages of generalization, such as between two
    Associations, without saying what it means, and without giving a
    notation
    for it.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue 1184.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Set of inheritable features not defined

  • Key: UML14-750
  • Legacy Issue Number: 1184
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In Semantics/Inheritance pg. 34 it is stated that "Each kind of
    generalizable element has a set of inheritable features", without saying
    which are those features for each kind of generalizable element. Note
    that
    they are different: for a Package, the ownedElements are inherited,
    while
    for a Classifier they are not. The set of inheritable features should be
    defined for each descendent from GeneralizableElement.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Correspondence between operation and method (02)

  • Key: UML14-749
  • Legacy Issue Number: 1183
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation states that a Class(ifier) can have at most one implementation
    for a given Operation. Although this can be inferred from the Semantics
    document, it should be stated explicitly in the Semantics document.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Correspondence between operation and method

  • Key: UML14-748
  • Legacy Issue Number: 1182
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Semantics Method [1-3] pg. 32 implies that a method can have more than
    one
    specification (self.specification is a collection type, since it is
    applied
    the operation "forAll").
    Everywhere else (including the abstract syntax on p. 16) it is shown
    that a
    method implements exactly one operation.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Signature conflicts not well defined (02)

  • Key: UML14-744
  • Legacy Issue Number: 1177
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Semantics, Feature::name page 23 asserts that the name of a feature
    must be
    unique within a Class(ifier). Contradiction with the Well-Formedness
    Rules
    on page 29.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Features and ownedElements (2)

  • Key: UML14-743
  • Legacy Issue Number: 1176
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The visibility of an "ownedElement" in Namespace is modeled as an
    attribute
    of the association class ElementOwnership, while the visibility of a
    Feature
    in a Classifier is modeled as an attribute in the target class Feature.
    Inconsistent use of the modeling concepts.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

"feature" defined twice

  • Key: UML14-742
  • Legacy Issue Number: 1174
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The "feature" association of Classifier is defined twice, the first
    time
    towards Feature, and then towards StructuralFeature (fig. 5, Core
    Package-Backbone).

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue 847

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Use of language-dependant type expressions

  • Key: UML14-747
  • Legacy Issue Number: 1181
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: An attribute or parameter has a type in Semantics, which is a
    Classifier
    (Semantics, Fig. 5 pg. 16). But Notation uses a "language-dependent"
    expression to specify a type (Notation pg. 30, see the explanations for
    "type-expression"). If the Semantics is right, we have no need for type
    expressions, since a Classifier always has a name.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    resolved in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Return types for BehavioralFeatures

  • Key: UML14-746
  • Legacy Issue Number: 1180
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: No mapping for the return type used for operations in Notation pg. 32.
    The
    correct mapping is probably into a anonymous parameter of the operation
    in
    question, with the kind "return".
    There is also no notation for operations with multiple "return"
    parameters.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Package importing not well supported

  • Key: UML14-745
  • Legacy Issue Number: 1178
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 134 is stated that "When an element is referenced by a package
    it
    extends the namespace of that package". This assertion is not supported
    by
    the metamodel and the Well-Formedness Rules (see the fact that the
    association between ModelElement and Namespace has "1" multiplicity),
    and it
    conflicts with WFR StructuralFeature [1] pg 34 which does not allow any
    kind
    of importing.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

UML Semantics 1.1, p26, Operation::isPolymorphic

  • Key: UML14-739
  • Legacy Issue Number: 1165
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML Semantics 1.1, p26, Operation::isPolymorphic
    Nothing says that isPolymorphic=TRUE is the default. In the NG, p19, §4.2.2 says "to specify a value of false you omit the name completely".

    This implies that all operations are not polymorphic by default, and that you must write

    {polymorphic}

    explicitly on all polymorphic operations.

  • Reported: UML 1.1 — Wed, 22 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Features and ownedElements (1)

  • Key: UML14-741
  • Legacy Issue Number: 1172
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The fact that the owned Features of a Classifier are not accessed by Classifier::ownedElement but rather by the
    Classifier::feature should be stated explicitly by the Semantics document.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Signature conflicts not well defined

  • Key: UML14-740
  • Legacy Issue Number: 1171
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Parameter::kind is taken into account for differentiating between the
    signatures of two BehavioralFeatures
    (BehavioralFeature::hasSameSignature,
    Semantics pg.29). This may cause signature conflict problems.
    For example we have two operations:
    oper( in i:integer )
    oper( out i:integer )
    in a class, their signatures will not be signaled as conflicting,
    although
    they should.

  • Reported: UML 1.1 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

OCL Specification 1.1, section 8

  • Key: UML14-738
  • Legacy Issue Number: 1110
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The syntax specification does not include the
    extended syntax for the Iterate operation.

    xxx->iterate(x;acc=0|acc=acc+x.assets)
    ^^^^^^

    Proposed Resolution : include this in the grammar for the syntax
    Revised Text :

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

OCL specification 1.1, p. 14, 5.13, example

  • Key: UML14-737
  • Legacy Issue Number: 1109
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Why mention "Car" as a subtype of Transport when it is not used
    in the example?

    Proposed Resolution : remove the reference to Car in the sentence.
    Revised Text : change text as suggested above
    Actions taken:

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

OCL specification 1.1, p. 15, 5.14, second last paragraph

  • Key: UML14-736
  • Legacy Issue Number: 1108
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Spelling: takes -> taken
    Could be rewritten as:
    "When the pre-value of a property evaluates to an object..."

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

OCL specification 1.1, p. 32

  • Key: UML14-733
  • Legacy Issue Number: 1104
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The EBNF-construction "+" is not explained.
    add to explanation: "+" means one or more time

    A number of brackets have been lost in the definitions for
    typeName, name and number:
    number := ["0"-"9"] ( ["0"-"9"] )*

    there is no way to specify a float literal (3.14)

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

OCL specification 1.1, p. 10, 5.4.3, example 3

  • Key: UML14-732
  • Legacy Issue Number: 1103
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Since both expressions start in the same object and one
    person can"t have both a wife and a husband, the expression will
    never give the result true, only false or undefined

    Here one could instead use the syntax of example 1:
    self.wife->nonempty implies self.wife.sex = #female and
    self.husband->nonempty implies self.husband.sex = #male

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

OCL specification 1.1, p. 24, 7.1.7

  • Key: UML14-735
  • Legacy Issue Number: 1107
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: New or simpler/shorter post conditions:
    b or b2 – post: not ((not b) and (not b2))
    b xor b2 – post: not (b=b2) (replaces previous post)
    b implies b2 – post: (not b) or b2 (replaces prevoius post)

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

OCL specification 1.1, p. 30, 7.2.4

  • Key: UML14-734
  • Legacy Issue Number: 1105
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sequence->prepend
    Correct explanation:
    The sequence consisting of /object/ followed by all
    elements in /sequence/

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

OCL specification 1.1, section 7.2.2

  • Key: UML14-731
  • Legacy Issue Number: 1102
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The definition of the select and reject operations
    for Set"s is erroneous.

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with issue 1102.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Definition of select and reject operations for Set"s is erranious

  • Key: UML14-730
  • Legacy Issue Number: 1101
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It reads:

    set->select(expr : OclExpression ) : Set( expr.type )
    set->reject(expr : OclExpression ) : Set( expr.type )

    It should read:

    set->select(expr : OclExpression ) : Set( T )
    set->reject(expr : OclExpression ) : Set( T )

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Difference between methods, attributes and operations not clear

  • Key: UML14-729
  • Legacy Issue Number: 1100
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Normally methods, attributes and operations can be easily told from each
    other:

    Person.attribute
    Person.method(arg1..argn) alt Person.method()
    Person->Operation(arg1..argn) alt Person->Operation

    There is however a situation where it is not possible to tell the
    difference:

    Imagine a shoe-shop with a class Shoe, and the attribute size.

    you would imagine that the following

    Shoe.allInstances->select(size > 10)

    would give you a set of all the shoes with size bigger than 10, but it
    could just as well be interpreted as the set of all shoes since an object is a set of size 1.

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Editorial issue: OCL spec 1.1, section 6.3, example 2, last row

  • Key: UML14-728
  • Legacy Issue Number: 1099
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OCL Specification 1.1, section 6.3, example 2, last row:

    reads:
    self.employee->forAll(Person p|p.forename = "Jack")

    should read:
    self.employee->forAll(p : Person|p.forename = "Jack")

  • Reported: UML 1.1 — Thu, 26 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

UML 1.1 Semantics, section 8.2, page 66

  • Key: UML14-727
  • Legacy Issue Number: 1098
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Semantics (ch. 8.2, p66, Figure 12) says that Signal is a GeneralizableElement and has Parameter(s). Multiple inheritance or repeated inheritance are not forbidden.

    2/ The Notation Guide (ch. 9.5.2, p111) says that an event has the following form: event-name "(" parameter "," ... ")" This means that the order of parameters is meaningful and implies that parameters must match the formal parameters declared in signals.

  • Reported: UML 1.1 — Wed, 25 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Contents of section "Control Icons" is vague

  • Key: UML14-726
  • Legacy Issue Number: 1097
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The section "Control Icons" in the chapter "Activity Diagrams"
    does not follow the layout of the rest of the chapter, and the contents
    of the section is (intentionally?) vague. The most important issues,
    however, are: figure 58 is incorrect, and the text describing the
    control icon stereotypes is inconsistent with the activity model
    semantics. The mapping section also contains some peculiarities: signal
    sending should not be a RaiseAction but a SendAction, and the dummy
    state introduced for the join Pseudostate makes no sense. This entire
    section should be corrected and strengthened, and control icons put into
    a context.

  • Reported: UML 1.1 — Wed, 25 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with activity diagram rework.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Missing sentence

  • Key: UML14-723
  • Legacy Issue Number: 1061
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation Guide p. 35. Chapter 5.9.4 Mapping (fourth row): There
    needs to be a sentence about the Realizes relationship (the dashed
    generalization arrow) before "This symbol..." to have a correct
    reference of "This symbol".

  • Reported: UML 1.1 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Editorial error in Semantics

  • Key: UML14-722
  • Legacy Issue Number: 1060
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Semantics p.25: The Method attribute body:
    "...proceduralExpression..." should be "procedureExpression"

  • Reported: UML 1.1 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Missing word - editorial

  • Key: UML14-725
  • Legacy Issue Number: 1063
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: n Semanticsp. 120 +8. Unfinished sentence. "...invoke actions
    and then wait for their."

  • Reported: UML 1.1 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Procedure undefined

  • Key: UML14-724
  • Legacy Issue Number: 1062
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In Semantics p. 62, ProcedureExpression mentions "Procedure"
    (both italics and bold). Is Procedure defined at all?
    Resolutio

  • Reported: UML 1.1 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

ActionState implicit deferring of events

  • Key: UML14-721
  • Legacy Issue Number: 1059
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: y interpretation of ActionState is that no events received
    during its execution are deferred, hence they will be lost unless they
    are explicitly deferred.

    This means that if I want to defer all signals (which IMHO is the
    default behavior for ActionState) I have to explicitly use the /defer
    notation, which may result in enormous overhead and large symbols!

  • Reported: UML 1.1 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

internalTransition

  • Key: UML14-720
  • Legacy Issue Number: 1058
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation Guide, p. 106, 9.2.4 Mapping says "Any other internal
    action maps into an internal Association" should be "... into an
    internalTransition ...".
    The internalTransition is described in Semantics, p. 101.

  • Reported: UML 1.1 — Tue, 17 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Deep History Vertex

  • Key: UML14-718
  • Legacy Issue Number: 1053
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 111 SG (deepHistory) "A composite state can have at most one history
    vertex."

    This should be "A composite state can have at most one DEEP history vertex."

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

deferredEvent mentioned twice in Abstract Syntax

  • Key: UML14-719
  • Legacy Issue Number: 1057
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Semantics p. 101: The State Assciation deferredEvent is listed
    twice with different explanations.

  • Reported: UML 1.1 — Tue, 17 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant (duplicates 860).

  • Updated: Fri, 6 Mar 2015 21:35 GMT

No mapping for send/receive time in Sequence Diagram

  • Key: UML14-713
  • Legacy Issue Number: 1048
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 87 NG "A message may have a sending time and a receiving time."

    This is not specified in the SG.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Inconsistent definition of extends relationship

  • Key: UML14-717
  • Legacy Issue Number: 1052
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 95 SG 4th par. "extends relationship includes both a condition for the
    extension and a reference to an extension point".

    This is not defined in the model.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    UML 1.3: Extend relationship updated.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

No mapping for TimingMark in Sequence Diagram

  • Key: UML14-715
  • Legacy Issue Number: 1050
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 112 NG "A transition time label on a transition maps into a TimingMark
    attached to the Transition".

    TimingMark is not defined in the SG.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

No mapping for "transition string"

  • Key: UML14-714
  • Legacy Issue Number: 1049
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 113 NG (Complex Transitions)

    The "transition string" is not mapped.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

No notation for ActivityState

  • Key: UML14-716
  • Legacy Issue Number: 1051
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 121 NG (Notation Activity Diagrams)

    There is no notation for the model element "ActivityState".

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant: already fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Inconsistent constraint for discriminator

  • Key: UML14-709
  • Legacy Issue Number: 1044
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 68 NG "The discriminator must be unique among the attributes and
    association roles of the given super-class."

    This is not specified in the SG.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Missing notation for templates

  • Key: UML14-708
  • Legacy Issue Number: 1043
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 39 NG (notation for template) "A small dashed rectangle is superimposed
    on the upper right-hand corner of the rectangle for the class (or to the
    symbol for another modeling element)."

    What about templates that have no symbol of their own, such as operations?

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    considered and declined

  • Updated: Fri, 6 Mar 2015 21:35 GMT

No mapping for swimlanes in Sequence Diagram

  • Key: UML14-712
  • Legacy Issue Number: 1047
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 80 NG (Notation for Sequence Diagram) "Objects can be grouped into
    "swimlanes" on a diagram."

    These swimlanes are not mapped and there is nothing in the SG to map them to.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Property "derived" not defined

  • Key: UML14-711
  • Legacy Issue Number: 1046
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 73 NG "The presence of a derived adornment (a leading "/" on the symbol
    name) on a symbol maps into the setting of the "derived" property of the
    corresponding Element."

    The "derived" property is not defined in the SG.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Interface specifier not mapped

  • Key: UML14-710
  • Legacy Issue Number: 1045
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 54 NG the "interface specifier" is defined but not mapped.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Well-formedness rules only expressed in English

  • Key: UML14-705
  • Legacy Issue Number: 1040
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The following well-formdness rules in the SG are only expressed in English.
    Whether the OCL was intentionally left out or not, is unclear:

    • p. 27, Association[3]
    • p. 75, Instance[6]
    • p. 104 Guard[1]
    • p. 124 ActivityModel[2]
    • p. 125 PseudoState[2]
  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Well-formedness rules missing

  • Key: UML14-704
  • Legacy Issue Number: 1039
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On p. 11 of the SG it is stated that "* Well-Formedness Rules: The static
    semantics of EACH construct in UML, except for multiplicity and ordering
    constraints, are defined as a set of invariants of an instance of the
    metaclass."

    And

    "The statement "No extra well-formedness rules" means that all current static
    semantics are expressed in the superclasses together with the multiplicity
    and type information expressed in the diagrams."

    Yet, the following model elements don"t have well-formdness rules, but this is
    not explicitly specified. (see corresponding archive file).

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Confusing text

  • Key: UML14-707
  • Legacy Issue Number: 1042
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 36 NG "A class symbol (...) maps into a Class with no stereotype. This
    symbol is normally used between a class and an interface (...)"

    There seems to be something missing, because the sentence starting with
    "this symbol" doesn"t make any sense in this context.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Missing mapping for directed constraint

  • Key: UML14-706
  • Legacy Issue Number: 1041
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 17 NG "For two graphical symbols (such as two classes or two associations):
    The constraint is shown as a dashed arrow from one element to the other
    element labeled by the constraint string (in braces). The direction of the
    arrow is relevant information within the constraint."

    and on p. 18:

    "A constraint string attached to a dashed arrow maps into a constraint
    attached to the two elements corresponding to the symbols connected by the
    arrow."

    Since the direction of the arrow is relevant: how is this direction mapped?

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Inconsistent definition of stereotype "thread"

  • Key: UML14-703
  • Legacy Issue Number: 1038
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 143 SG Stereotype <<thread>> is listed to apply to Classifier, but the
    description says "is also an active class". So it should apply to Class.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Stereotypes applied to more than one ModelElement

  • Key: UML14-700
  • Legacy Issue Number: 1035
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 140 SG Several stereotypes apply to more than 1 ModelElement: create,
    destroy, metaclass and powertype.

    This is inconsistent with p. 54, fig. 9: Stereotype has a "baseClass"
    attribute which contains the name of exactly 1 ModelElement.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

English contradicts OCL in rule for CompositeState

  • Key: UML14-699
  • Legacy Issue Number: 1034
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 104 SG Well-Formedness rule CompositeState[4] states:

    "There have to be at least two composite substates in a concurrent composite
    state"

    (self.isConcurrent) implies
    (self.subState->select (v | v.oclIsKindOf(CompositeState))->size <= 2)

    Clearly "<=" should be ">=".

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Misleading name Link.linkRole

  • Key: UML14-698
  • Legacy Issue Number: 1033
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 67 SG Fig. 14. Link.linkRole is an inconsistent name for an association
    with class LinkEnd. It should be named "Link.linkEnd".

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Enumeration OperationDirectionKind obsolete

  • Key: UML14-697
  • Legacy Issue Number: 1032
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 62 SG The enumeration OperationDirectionKind is defined, but this
    enumeration is not used anywhere. So either it can be left out or it should
    be used.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Inconsistent definition of stereotype " process"

  • Key: UML14-702
  • Legacy Issue Number: 1037
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 143 SG Stereotype <<process>> is listed to apply to Classifier, but the
    description says "is also an active class". So it should apply to Class.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Inconsistent definition of enumeration

  • Key: UML14-701
  • Legacy Issue Number: 1036
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 140 SG "enumeration" is listed as stereotype, but it"s defined as a
    distinct ModelElement on p. 60.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

ordered missing for Constraint.constrainedStereotype

  • Key: UML14-696
  • Legacy Issue Number: 1031
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On p. 54 SG the association Constraint.constraindStereotype is defined as:

    "An ordered list of stereotypes subject to the constraint".

    The "ordered" property is not in fig. 9.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Inconsistent definition of stereotype "friend"

  • Key: UML14-695
  • Legacy Issue Number: 1030
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 50 SG <<friend>> is defined to be a stereotype for Component. On p. 142
    it is defined as a stereotype of Dependency.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Inconsistent definition of stereotype "thread"

  • Key: UML14-694
  • Legacy Issue Number: 1029
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 40 SG <<thread>> is defined to be a stereotype for Generalization.
    On p. 144 it is defined as a stereotype of Classifier.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Wrong aggregation kind for templates

  • Key: UML14-693
  • Legacy Issue Number: 1028
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 43 SG In fig. 7, Binding.argument is composite, while
    ModelElement.templateParameter is not. This seems to be an error, as is
    indicated by the text on p. 49:

    "A further consequence is that a template must own a fragment of the model".

    ModelElement.templateParameter should be composite, Binding.argument should
    not be composite.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Inconsistent attachment of Activity Diagram

  • Key: UML14-689
  • Legacy Issue Number: 1024
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 121 NG "The entire activity diagram is attached (through the model) to a
    class or to the implementation of an operation or a use case."

    • How can an activity diagram be attached to THE IMPLEMENTATION of
      an operation or use case?
    • This attachement is different from the one in the SG, p.124:
      "[1] An ActivityModel specifies the dynamics of a
      Package, or (ii) a Classifier (including UseCase), or (iii) a
      BehavioralFeature."
  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Method visibility

  • Key: UML14-692
  • Legacy Issue Number: 1027
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 36 SG "The concept of visibility is not relevant for methods".

    Then why is visibility an attribute of Method and is there even a rule on
    p. 32 of the SG that states:

    "[3] The visibility of the Method should be the same as for the realized
    Operations."

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Feature.owner must be optional

  • Key: UML14-691
  • Legacy Issue Number: 1026
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 16 SG Feature.owner is a mandatory association to Classifier. Attribute,
    derived from Feature, can also be used as qualifier of an AssociationEnd.
    Such an attribute is not owned by a Classifier, but is owned by the
    association end.

    Conclusion: Feature.owner should be optional.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Extension points of operations not defined

  • Key: UML14-690
  • Legacy Issue Number: 1025
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 36 SG "An operation may have a set of extension points".

    This is not defined in the model.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    UML 1.3 clarification: Extension points only apply to use cases.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Inconsistent definition of state machine attachment

  • Key: UML14-688
  • Legacy Issue Number: 1023
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 103 NG "A state machine is attached to a class or a method"

    This is more restrictive than the SG, p. 104:

    "A StateMachine is aggregated within either a classifier or a behavioral
    feature".

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Inconsistent format of signal/event

  • Key: UML14-687
  • Legacy Issue Number: 1022
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 109 NG "A signal or call event can be defined using the following format:
    event-name "(" comma-separated-parameter-list ")"
    A parameter has the format: parameter-name ":" type-expression"

    This is inconsistent with fig 41, p. 104 and fig 43, p. 107 and
    section 9.5.3 which only show the name of the parameter, not
    its type.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

More arrow types than message kinds

  • Key: UML14-686
  • Legacy Issue Number: 1021
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 98 NG On this page, THREE kinds of arrows are defined for messages.
    However, the SG on p. 69 defines only TWO values of the attribute "mode"
    of CallAction: synchronous and asynchronous.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Attachment of message in Sequence Diagram

  • Key: UML14-684
  • Legacy Issue Number: 1019
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 83 NG "unless the correct AssociationRole can be determined from a
    complementary collaboration diagram or other means, the Message must be
    attached to a dummy AssociationRole implied between the two ClassifierRoles
    for lack of complete information."

    This conflicts with fig. 15 on p. 81 of the SG: a Message is NOT connected to
    an AssocationRole.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Inconsistent mapping of labels in Sequence Diagram

  • Key: UML14-685
  • Legacy Issue Number: 1020
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 83 NG "A timing label placed on the level of an arrow endpoint maps into
    the name of the corresponding Message."

    This contradicts the statement on p. 85 of the NG:

    "The arrow is labeled with the name of the message (operation or signal) and
    its argument values."

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:35 GMT

UML 1.0: "role" should be "end"

  • Key: UML14-682
  • Legacy Issue Number: 1017
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 50 NG "The end of an association where it connects to a class is called
    an association role". The word "role" must be "end".

    UML

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.0: Template example cannot be representaed in model

  • Key: UML14-681
  • Legacy Issue Number: 1016
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 40 NG The example in fig. 14 can not be represented in the model. The
    template parameter "k:Integer" refers to the multiplicity "k" of the
    composition association to "T". To be more precise: it refers to the
    attribute "multiplicity" of AssociationEnd. But this contradicts fig. 7 on
    p. 43 of the SG. A template parameter is there defined to be a reference to
    a ModelElement. Referring to an attribute of a ModelElement is not possible.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.0: Unknown model element "Qualifier"

  • Key: UML14-683
  • Legacy Issue Number: 1018
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 59 NG "The presence of a qualifier box on an end of an association path
    maps into a Qualifier on the corresponding Association Role." There is no
    model element named "Qualifier" in the SG.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.0: Inconsistent name of stereotype "import"

  • Key: UML14-680
  • Legacy Issue Number: 1015
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 44 NG Defines the <<imports>> Dependency. On p. 45 NG and p. 142 SG it
    is named <<import>> (without the trailing "s").

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.0: multiplicity "unspecified" not possible

  • Key: UML14-679
  • Legacy Issue Number: 1014
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 53 NG "In an incomplete model the multiplicity may be unspecified in the
    model itself". This contradicts the definition of Multiplicity in the SG p. 60,
    where Multiplicity is defines as ONE or more ranges. "Unspecified" cannot be
    represented.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered but declined.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Inconsistent name space rules

  • Key: UML14-676
  • Legacy Issue Number: 1011
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The NG and SG have slightly different name space rules for Packages:

    On p. 23 the NG states:

    "The name of a class has scope within the package in which it is declared and
    the name must be unique (among class names) within its package."

    The "among class names" implies that the name need NOT be unique among other
    names in the Package. This contradicts rule[2] of Package on p. 131 of the
    SG:

    "No referenced element (excluding Association) may have the same name or
    alias as any element owned by the Package or one of its supertypes."

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.0: instances

  • Key: UML14-675
  • Legacy Issue Number: 1010
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The NG and the SG are inconsistent on where Instances my be defined:

    On p. 22 the NG states:

    "Note that a "class" diagram may also contain interfaces, packages,
    relationships, and even instances, such as objects and links."

    and:

    "If a diagram is part of a package, then its contents map into elements
    in the same package."

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.0: Stereotype "uses" applied to more than one class

  • Key: UML14-678
  • Legacy Issue Number: 1013
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On p. 38, 71 NG <<uses>> is a stereotype of Dependency. On p. 144 SG <<uses>>
    is a stereotype of Generalization. A stereotype can be applied to only one
    ModelElement, according to its definition on p. 55, SG.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Inconsistent name for stereotype implementationClass

  • Key: UML14-677
  • Legacy Issue Number: 1012
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 35 NG Stereotype <<implementation class>> contradicts p. 142 SG where
    the same stereotype is written as <<implementationClass>>.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.0: Tagged value "location"

  • Key: UML14-673
  • Legacy Issue Number: 1008
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On p. 144 of the SG, the predefined tagged value "location" is specified:
    Applied to Classifier: "Location denotes that the classifier is a part of
    the given component." This seems to be the same as the association
    ModelElement.implementation, although the definition of that association
    is missing (it is in fig. 8, but not in the list of associations of
    ModelElement on p. 46).

    Applied to Component: "Location denotes that the component resides on given
    node." This is almost the same as the definition of the association
    Component.deployment on p. 45: "The set of Nodes the Component is residing on."

    Information should either be represented as an association in the metamodel
    or as a predefined tagged value, but not both.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.0: Inconsistent mapping of interface circles

  • Key: UML14-672
  • Legacy Issue Number: 1007
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The NG is inconsistent in the way "interface circles" are mapped.
    On p. 138 it says "Interface circles attached to the component symbol by
    solid lines map into supports Dependencies to Interfaces."

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.0: Attachment of messages in Collaboration Diagrams

  • Key: UML14-669
  • Legacy Issue Number: 1004
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 98 of the NG:

    "A message flow is shown as a labeled arrow placed near a link. The
    meaning is that the link is used to transport or otherwise implement the
    delivery of the message to the target object."

    However, attachment of a message to an AssociationRole is not possible in
    the model.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant with 1019.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.0: Node/Component Instances not defined

  • Key: UML14-671
  • Legacy Issue Number: 1006
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the NG, the Deployment Diagram is defined to contain Node and Component
    INSTANCES. But these model elements do not exist according to the SG.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Merged with #1006.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.0: No notation for ModelElement.implementation etc.

  • Key: UML14-670
  • Legacy Issue Number: 1005
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no notation for the associations ModelElement.implementation
    and Component.deployment, both defined in Figure 8 on p. 44 of the SG.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.0: Inconsistent arrow heads for dependencies

  • Key: UML14-674
  • Legacy Issue Number: 1009
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p. 21 NG fig. 6 The <<calls>> dependency should use stick arrow i.s.o. a
    filled solid arrow head. The remainder of the NG uses stick arrow heads
    for Dependencies.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.o: Qualified things in Collaborations

  • Key: UML14-666
  • Legacy Issue Number: 1001
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The diagram on p. 90 of the NG contains some items that cannot be represented
    in the model:
    The lines from "wire" to "left" and "right" look like an instance of
    a qualified association. There is no such thing in the SG.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.0: Collaborations not well defined

  • Key: UML14-665
  • Legacy Issue Number: 1000
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Collaborations, especially Collaboration Digarams, are not defined very well,
    given the following quotes:

    The SG states on p. 86:
    "A collaboration may be presented at two different levels: specification
    level or instance level. A diagram presenting the collaboration at the
    specification level will show classifier roles and association roles, while
    a diagram at the instance level will present instances and links conforming
    to the roles in the collaboration."

    So, according to the SG, there are TWO kinds of collaboration diagrams: one
    containing ClassifierRoles and one containing Instances.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.0: No notation for ClassifierRole.availableFeature

  • Key: UML14-668
  • Legacy Issue Number: 1003
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no notation for the meta-association
    ClassifierRole.availableFeature (on p. 94 of the SG).

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.0: Collaborations and Association (role)

  • Key: UML14-667
  • Legacy Issue Number: 1002
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On p. 97 the NG defines how to map nested "things" in a collaboration diagram:
    "A nested object symbol (active or not) maps into a Classifierrole that has
    a composition association to the roles corresponding to its contents, as
    described under Composition."

    But, according to the SG on p. 81, fig. 15, a collaboration should contain
    AssociationRoles, not plain Associations.

  • Reported: UML 1.1 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

CallEvent: operation label in figure 18 is not present

  • Key: UML14-664
  • Legacy Issue Number: 990
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 17 ) The CallEvent descriptive text in the State Machines package
    > indicates the presence of the "operation" association with the
    > Operation class. An association between these two classes is shown in
    > Fig 18, but the "operation" label is not present.
    >

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Signal label in figure 18 is not present

  • Key: UML14-663
  • Legacy Issue Number: 989
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 16 ) The SIgnalEvent descriptive text in the State Machines package
    > indicates the presence of the "signal" association with the Signal
    > class. An association between these two classes is shown in Fig 18,
    > but the "signal" label is not present.
    >

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Figure 15, AssociationRole class issue

  • Key: UML14-662
  • Legacy Issue Number: 988
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 15) In FIgure 15, the AssociationRole class has the "multiplicity"
    > attribute; the type is not given there nor in the text description of
    > this class. Presumably, it is the Multiplicity type, since that is
    > the type of the corresponding attribute in the ClassifierRole class.

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Description of ActionSequence indicates that it is composition of Actions

  • Key: UML14-659
  • Legacy Issue Number: 985
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 12) The description of ActionSequence is "In the metamodel an
    > ActionSequence is an aggregation of Actions". The diagram indicates
    > that it is a composition of Actions.

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

ActionSequence class issue

  • Key: UML14-658
  • Legacy Issue Number: 984
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 11) The ActionSequence class (Common Behavioral ELements Package)
    > would seem to be an ordered relation, but the figure which illustrates
    > it (Fig 13) does not indicate this. Neither does the description,
    > even though it explicitly says that the "action" association is "A
    > sequence of Actions performed sequentially as an atomic unit".

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Collaboration package: constrainingElement aggregation misdrawn

  • Key: UML14-661
  • Legacy Issue Number: 987
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 14) Also in the Collaboration package, the "constrainingElement"
    > aggregation is misdrawn in Figure 15. It shows up normally in the
    > Rose MDL file from Rational.

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Collaborations package--editorial

  • Key: UML14-660
  • Legacy Issue Number: 986
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 3) In the Collaborations package, Figure 15, there is a "

    {or}

    "
    > particle floating near the Collaboration class. It is unclear what it
    > means or to what it applies.

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Reception class has wrong attribute

  • Key: UML14-657
  • Legacy Issue Number: 983
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 10) THe Reception Class (also in the Common Behavioral package)
    > description indicates that the type of the "specification" attribute
    > is an Expression. Figure 12 indicates that this attribute is of the
    > Uninterpreted type.

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Figure 12 shows no attributes for exceptions

  • Key: UML14-656
  • Legacy Issue Number: 982
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 9) The description of the Exception indicates that it has an attribute
    > called "body", which is "A description of the Exception in a format
    > not defined by UML". However, Figure 12 shows no attributes for
    > Exceptions.

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Behavioral Features called context

  • Key: UML14-655
  • Legacy Issue Number: 981
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 8) The Common Behavioral Element Package defines the Exception and
    > indicates that it has an association called "behavioralFeature" which
    > is "The set of BehavioralFeatures that raise the exception". Figure
    > 12 calls this association the "context".

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Request class is not an abstract class as indicated

  • Key: UML14-654
  • Legacy Issue Number: 980
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 6) The Request class is indicated as being an abstract class in the
    > description of the Behavioral common elements package, but it is not
    > indicated as abstract in the diagram (Figure 13).

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Action class is no abstract class as indicated

  • Key: UML14-653
  • Legacy Issue Number: 979
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 6) The Action class is indicated as being an abstract class in the
    > description of the Behavioral common elements package, but it is not
    > indicated as abstract in the diagram (Figure 13).

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Description of ViewElement indicates that it is subclass of Element

  • Key: UML14-652
  • Legacy Issue Number: 978
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 5) The description of ViewElement indicates that it is a subclass of
    > Element. Figure 8 does not show it as a subclass of anything. This
    > would be OK if the derivation of ViewElement were shown someplace
    > else, but I can find it in no other place. Furthermore, it is shown
    > as an abstract class, but I can find no classes which are derived from
    > it.

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Inconsistency of UML metamodel

  • Key: UML14-647
  • Legacy Issue Number: 973
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The mentioned "inconsistency" was found on page 35 and 37 of the
    Semantics Specification v1.1
    On page 37 two diagrams lack multiplicity on composite associations.
    On page 35 the diagram does not make clear which multiplicity is for
    Association - Class
    On page 35 all composite associations lack multiplicity

  • Reported: UML 1.1 — Sun, 8 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant (duplicates 950; mistaken submitter id).

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Node class shown as subclass of classifier

  • Key: UML14-649
  • Legacy Issue Number: 975
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2) The description of the Node class says: "In the metamodel a Node is
    > a subclass of Class..." However, in Figure 8, it is shown as a
    > subclass of a Classifier.

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Node class issue (01)

  • Key: UML14-648
  • Legacy Issue Number: 974
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1) The Node class (in the Auxiliary Elements package) has an
    > aggregation to the Component class. The description of the Node in
    > the text talks about as the "component" association. However, the
    > "component" name does not occur on the Component end of the
    > aggregation in the diagram.(Figure 8).

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant (duplicates 850).

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Comment class shown as subclass of ModelElement class

  • Key: UML14-651
  • Legacy Issue Number: 977
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 4) The Comment class (again in the Auxiliary Package) description
    > indicates that it is a subclass of the ViewElement. The diagram
    > (Figure 8 again) shows it as a subclass of the ModelElement class.

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Description of component shown as subclass of class

  • Key: UML14-650
  • Legacy Issue Number: 976
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 3) Like the Node, the description of the Component in the Auxiliary
    > Package indicates that it is a subclass of Class. Figure 8 shows it
    > as a subclass of the Classifier.

  • Reported: UML 1.1 — Fri, 27 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML Notation Guide, boolean properties

  • Key: UML14-645
  • Legacy Issue Number: 954
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: §5.5.1 says that you can show properties betwen braces and that a boolean
    property can be displayed without its value (meaning true).

    1) examples are

    {leaf}

    and

    {abstract}

    , which are isLeaf and isAbstract in
    the metamodel. Since all boolean properties are called isXxxx, I suggest to
    add an explicit rule in §5.5.1 stating that a property isXxxx=true is
    displayed simply as

    {xxxx}

    2) I suggest to add a shortcut for false properties as well. May be
    {§xxxx}, or {xxxx}

    ... some character not too overloaded by UML and
    programming languages anyway (# ~ ! - ...)

  • Reported: UML 1.1 — Fri, 20 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    considered and declined

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML Notation Guide, association ends

  • Key: UML14-644
  • Legacy Issue Number: 953
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML Notation Guide

    I did not find in §5.21 any notation to represent
    AssociationEnd::targetScope. To be consistent with the notation of
    attributes and operations or methods, I suggest that the role name can be
    underlined to show that "targetScope=classifier".

  • Reported: UML 1.1 — Fri, 20 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Association between Method and Operation

  • Key: UML14-646
  • Legacy Issue Number: 955
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Figure 5 (Core Package-backbone) of the UML Semantics suggests that _1
    (one)_ Operation is the specification of * (none-to-many) Methods.

    P25, the text on Method says that "a Method is a declaration of a named
    piece of behavior in a Classifier and realizes one or a set of Operations
    of the Classifier". This suggests (or is it just unclear?) that several
    Operations may be linked (implemented?) by the same method.

    I do not understand this, or what I understand is not consistent.

  • Reported: UML 1.1 — Wed, 18 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Clarified in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML stereotypes

  • Key: UML14-643
  • Legacy Issue Number: 952
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML Semantics:
    I think that the attribute Stereotype::baseClass could (should, IMhO) be
    replaced by a second association between Stereotype and ModelElement, with

    {targetScope=Classifier}

    on the ModelElement end (presentation: role name
    underlined).
    This would represent better the two links side by side: the "meta" link and
    its instances.

  • Reported: UML 1.1 — Fri, 20 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML potential inconsistency about stereotypes

  • Key: UML14-642
  • Legacy Issue Number: 951
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Stereotype]stereotype*---*extendedElement[ModelElement]

    so: many-to-many.

    The text, in §ModelElement(as extended)/Associations/stereotype (p54 in my
    copy) says "Designates at most one stereotype..."

    so: one-to-many.

    Unless I misunderstood something, this is not consistent. Otherwise, a
    better explanation is needed.

  • Reported: UML 1.1 — Fri, 20 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Inconsistency of UML metamodel

  • Key: UML14-641
  • Legacy Issue Number: 950
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Semantics Specification v1.1
    On page 37 two diagrams lack multiplicity on composite associations.
    On page 35 the diagram does not make clear which multiplicity is for
    Association - Class
    On page 35 all composite associations lack multiplicity

  • Reported: UML 1.1 — Sun, 8 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    considered and declined

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Parameters/Attributes need Specification Classifiers

  • Key: UML14-640
  • Legacy Issue Number: 938
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: AssociationEnds have onr type, but may have many specifiers. These specifiers limit the setof operations that may be used on the actual classifiers at that end. In several senses, attributes are parallel to AssociationEnds. Often they are freely diagrammed interchangeably. It appears that if an associationEnd is diagrammed as an attribute, the specifiers would be lost. This breaks the symmetry between associationEnds and attributes

  • Reported: UML 1.1 — Wed, 4 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    considered and declined

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Predefined LinkEnd constraints issue

  • Key: UML14-639
  • Legacy Issue Number: 937
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Summary: Predefined LinkEnd constraints (or properties – it is unclear) used in Collaboration diagrams and indicated in Notation Guide 8.10 (new, transient, destroyed) are shown as stereotypes in Notation 8.4.2 page 92. In addition, they are not indicated at all in the Semantics document. These constraints/properties also apply to the Object names in Collaboration.

  • Reported: UML 1.1 — Tue, 3 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Predefined LinkEnd constraints shown as stereotypes in Notation Guide

  • Key: UML14-638
  • Legacy Issue Number: 936
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Summary: Predefined LinkEnd constraints used in Collaboration diagrams and defined in Semantics A.3 (association, global, local, parameter, self) are shown as stereotypes in Notation Guide (e.g., 8.2.3 diagram) and sometimes as constraints (e.g., 8.7.3 diagram).

  • Reported: UML 1.1 — Tue, 3 Feb 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

diagram fragment at start of Model section on page 136

  • Key: UML14-636
  • Legacy Issue Number: 930
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The diagram fragement at the start of the Model section on page 136 of the
    Semantics document incorrectly shows the Model metaclass as having a
    composition association with the Package metaclass. Instead, the Model
    metaclass should be a subclass of Package, as shown in Figure 23 (p. 129).

  • Reported: UML 1.1 — Fri, 23 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

No notation defined in the Notation Guide

  • Key: UML14-635
  • Legacy Issue Number: 929
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no notation defined in the Notation Guide mapping to the
    ActivityState metaclass defined on page 122 of the Semantics document.

  • Reported: UML 1.1 — Fri, 23 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    UML 1.3: Notation defined for SubactivityState.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

ActivityState in Figure 22

  • Key: UML14-634
  • Legacy Issue Number: 928
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Figure 22 of the Semantics document (p. 121) incorrectly shows
    ActivityState as a subclass of SimpleState. It should be a subclass of
    SubmachineState, as stated on page 122.

  • Reported: UML 1.1 — Fri, 23 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    UML 1.3: Renamed ActivityState to SubactivityState and updated relevant semantics.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

well-formedness rules for BehavioralFeature

  • Key: UML14-633
  • Legacy Issue Number: 927
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should the well-formedness rules for BehavioralFeature (Semantics, p. 28)
    include a rule restricting a beahvioral feature to contain only one
    parameter of kind "return"?

  • Reported: UML 1.1 — Fri, 23 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Figure 8 (Semantics, p. 44)

  • Key: UML14-637
  • Legacy Issue Number: 931
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Semantics document states that "a Component is a subclass of Class" (p.
    45) and "a Node is a subclass of Class" (p. 46). However, Figure 8
    (Semantics, p.44) shows both Component and Node as subclasses of
    Classifier. Further, the Notation Guide states that "A component symbol
    maps into a <<component>> stereotype of a Class or Object" and similarly
    for a node symbol. My understanding is that the text of the Semantics
    document is correct, and the diagram and Notation Guide should be changed
    to conform to this.

  • Reported: UML 1.1 — Fri, 23 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Figure 5 Semantics document (p. 16)

  • Key: UML14-630
  • Legacy Issue Number: 924
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Figure 5 of the Semantics document (page 16) shows the type of the
    "specification" attribute of class "Operation" to be "uninterpretted". On
    pacge 26 it is said to be an "Expression". Change this to "uninterpretted"
    on page 26.

  • Reported: UML 1.1 — Fri, 23 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Second para, Section 5.16.1: conflict with statement on p 141

  • Key: UML14-629
  • Legacy Issue Number: 923
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The first sentence of the second paragraph of Section 5.16.1 of the
    Notation Guide (page 44) states "Note that an imports dependency does not
    modify the namespace of the client or in any other way automatically create
    references..." This seems to conflict with the statement on page 141 of the
    Semantics document that the "public contents of the target package [of an
    imports dependency] are added to the namespace of the source package".

  • Reported: UML 1.1 — Fri, 23 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Well-formedness rulw [2] for Class (Semantics, p. 27-28)

  • Key: UML14-632
  • Legacy Issue Number: 926
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Well-formedness rule [2] for Class (Semantics, p. 29) and rule [1] for
    Package (p.131) do not allow Signals (which, according to Figure 12 on page
    66 are generalizable elements but NOT classifiers) to be contained in
    classes or packages. The rules for Class and Package should be updated to
    allow this.

  • Reported: UML 1.1 — Fri, 23 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Well-formedness rule [4] for Association

  • Key: UML14-631
  • Legacy Issue Number: 925
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Well-formedness rule [4] for Association (Semantics, pp. 27-28) states that
    "The connected Classifiers of the AssociationEnds should be included in the
    Namespace of the Association." However, rule [2] for Class (p. 29) and rule
    [1] for Package (p. 131) indicates that these namespace elements may
    contain associations, but NOT association ends. The rules for Class and
    Pachakge should be changed to allow them to contain association ends.

  • Reported: UML 1.1 — Fri, 23 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Section 5.16.1--editorial

  • Key: UML14-628
  • Legacy Issue Number: 922
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the first line of Section 5.16.1 of of the Notation Guide (page 44), the
    stereotype "<<imports>>" should be "<<import>>" (no "s").

  • Reported: UML 1.1 — Fri, 23 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 53 UML semantics: base class of TaggedValue not shown

  • Key: UML14-627
  • Legacy Issue Number: 883
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 53 of UML 1.1 Semantics, the base class of TaggedValue is not
    shown. It is assumed to be ModelElement, based upon the description
    on pg. 25 of ModelElement.

  • Reported: UML 1.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3: TaggedValue a subclass of ModelElement.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Missing role descriptions

  • Key: UML14-624
  • Legacy Issue Number: 880
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 20 of UML 1.1 Semantics, BehavioralFeature describes a "parameters"
    association but figure 5 on pg. 16 shows the same association as "parameter".

    On pg. 21 of UML 1.1 Semantics, Classifier does not describe a "associationEnd"
    association but figure 6 on pg. 17 does show "associationEnd".

  • Reported: UML 1.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

ModelElement Associations (02)

  • Key: UML14-623
  • Legacy Issue Number: 879
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 17 of UML 1.1 Semantics, figure 6 shows the "provision" role from
    ModelElement to Dependency with multiplicity "*". The description on
    pg. 25 for ModelElement refers to "a" Dependency. This would imply
    a multiplicity of "1" rather than "*".

  • Reported: UML 1.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3: Renamed role and corrected description.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 44 UML 1.1 Semantics, figure 8: no base class for ViewElement

  • Key: UML14-626
  • Legacy Issue Number: 882
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 44 of UML 1.1 Semantics, figure 8 does not show the base class
    for ViewElement. Based upon the description on pg. 22, it is assumed
    to be Element.

  • Reported: UML 1.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3: Presentation Element is a subclass of Element,

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 44 UML 1.1 Semantics, figure 8: no component role name

  • Key: UML14-625
  • Legacy Issue Number: 881
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 44 of UML 1.1 Semantics, figure 8 does not show the "component"
    role name from Node to Component although this is described on pg. 46.

  • Reported: UML 1.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant (duplicates 850).

  • Updated: Fri, 6 Mar 2015 21:34 GMT

ModelElement Associations (01)

  • Key: UML14-622
  • Legacy Issue Number: 876
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 17 of UML 1.1 Semantics, figure 6 shows the "requirement" role from
    ModelElement to Dependency with multiplicity "*". The description on
    pg. 25 for ModelElement refers to "a" Dependency. This would imply
    a multiplicity of "1" rather than "*".

  • Reported: UML 1.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

ElementOwnership subclass of ModelElement?

  • Key: UML14-621
  • Legacy Issue Number: 875
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 16 of UML 1.1 Semantics, figure 5 does not indicate whether
    ElementOwnership is a subclass of any other class. By implication
    on pg. 25, it must be a subclass of ModelElement.

  • Reported: UML 1.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Package dependencies (08)

  • Key: UML14-619
  • Legacy Issue Number: 873
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages
    A dependency from Core to Data Types is not shown although this
    is implied by the diagram on pg.. 121.

  • Reported: UML 1.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Package dependencies (07)

  • Key: UML14-618
  • Legacy Issue Number: 872
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages
    A dependency from State Machines to Core is not shown although this
    is implied by the diagram on pg.. 121.

  • Reported: UML 1.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Package dependencies (09)

  • Key: UML14-620
  • Legacy Issue Number: 874
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages
    A dependency from Data Types to Core is not shown although this
    is implied by the diagram on pg.. 81.

  • Reported: UML 1.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Package dependencies (06)

  • Key: UML14-617
  • Legacy Issue Number: 871
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages
    A dependency from Use Cases to Core is not shown although this
    is implied by the diagram on pg.. 90.

  • Reported: UML 1.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Package dependencies (05)

  • Key: UML14-616
  • Legacy Issue Number: 869
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages
    A dependency from Collaborations to Core is not shown although this
    is implied by the diagram on pg.. 81.

  • Reported: UML 1.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Package dependencies (01)

  • Key: UML14-613
  • Legacy Issue Number: 866
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages

    A dependency from Foundation to Behavioral Elements is not shown
    although this is implied by the diagram on pg.. 121.

  • Reported: UML 1.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    considered and declined

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.1 bug

  • Key: UML14-612
  • Legacy Issue Number: 864
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"ve just noticed a well-formedness rules for parameters which seems
    incorrect:
    "An interface cannot be used as the type of a parameter".
    It"s not clear how UML can be used to represent COM or Java if this
    is the case.

  • Reported: UML 1.1 — Sun, 4 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Package dependencies (03)

  • Key: UML14-615
  • Legacy Issue Number: 868
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages

    A dependency from Data Types to Core is not shown although this
    is implied by the diagram on pg.. 60.

  • Reported: UML 1.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    considered and declined

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Package dependencies (02)

  • Key: UML14-614
  • Legacy Issue Number: 867
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg.. 9, figure 2 of UML 1.1 Semantics: Foundation Packages
    A dependency from Model Management to Core is not shown although this
    is implied by the diagram on pg.. 129.

  • Reported: UML 1.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 10 UML 1.1 Semantics, duplicate entries listed

  • Key: UML14-609
  • Legacy Issue Number: 860
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 10 of UML 1.1 Semantics, the State class lists duplicate
    entries for the deferredEvent association.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 98 of UML 1.1 Semantics, figure 18 (02)

  • Key: UML14-608
  • Legacy Issue Number: 859
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 98 of UML 1.1 Semantics, figure 18 does not label the
    operation role from CallEvent to Operation as described on pg. 99.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML 1.1 Semantics: Partition (pp.121 123)

  • Key: UML14-611
  • Legacy Issue Number: 862
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Partitioning according to various criteria is not possible.

  • Reported: UML 1.1 — Mon, 5 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    considered and declined

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 102 of UML 1.1, StateVertex class misses description

  • Key: UML14-610
  • Legacy Issue Number: 861
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 102 of UML 1.1, the StateVertex class does not describe
    the parent association from StateVertex to CompositeStates
    shown in figure 17 on pg. 98.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 98 of UML 1.1 Semantics, figure 18

  • Key: UML14-607
  • Legacy Issue Number: 858
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 98 of UML 1.1 Semantics, figure 18 does not label the
    signal role from SignalEvent to Signal as described on pg. 101.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 98 of UML 1.1 Semantics, figure 17 (04)

  • Key: UML14-606
  • Legacy Issue Number: 857
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 98 of UML 1.1 Semantics, figure 17 shows the role
    internalTransition from State to Transition as being on the State end when
    pg. 101 shows it as being on the Transition end.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 98 of UML 1.1 Semantics, figure 17 (03)

  • Key: UML14-605
  • Legacy Issue Number: 856
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 98 of UML 1.1 Semantics, figure 17 ActionSequence and
    Action are not shown "(from CommonBehavior)".

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 98 of UML 1.1 Semantics, figure 17 (02)

  • Key: UML14-604
  • Legacy Issue Number: 855
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 98 of UML 1.1 Semantics, figure 17 CompositeState does
    not show "isRegion: Boolean" attribute described on pg. 98.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 98 of UML 1.1 Semantics, figure 17 (01)

  • Key: UML14-603
  • Legacy Issue Number: 854
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 98 of UML 1.1 Semantics, figure 17 shows the role from
    CompositeState to StateVertex as "substate" while pg. 99
    shows it as "substates".

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 43 of UML Semantics, figure 7

  • Key: UML14-598
  • Legacy Issue Number: 849
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 43 of UML 1.1 Semantics, figure 7 does not show that
    Dependency is "(from Core)".

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 43 UML 1.1 Semantics, figure 7 --editorial

  • Key: UML14-597
  • Legacy Issue Number: 848
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 43 of UML 1.1 Semantics, figure 7 shows a relationship
    labeled subDependencies when pg. 45 shows it as subDependency.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 46 of UML 1.1 Semantics, description of associations for ModelElement

  • Key: UML14-600
  • Legacy Issue Number: 851
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 46 of UML 1.1 Semantics, the description of the associations
    for ModelElement does not describe the "template" association.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3: Added description of ModelElement::template association.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 44 UML 1.1 Semantics, figure 8

  • Key: UML14-599
  • Legacy Issue Number: 850
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 44 of UML 1.1 Semantics, figure 8 does not label the target
    end of the aggregation from Node to Component as "component" even
    though pg. 46 does describe it as such.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 47 of UML 1.1 Semantics, description of ViewElement

  • Key: UML14-602
  • Legacy Issue Number: 853
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 47 of of UML 1.1 Semantics, the description of ViewElement
    does not describe the "model" association.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3: Added PresentationElement:subject relationship.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 47 of UML 1.1 Semantics, description of Refinement

  • Key: UML14-601
  • Legacy Issue Number: 852
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 47 of UML 1.1 Semantics, the description of Refinement shows
    "mapping" as an association when it should be an attribute.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 16 of UML Semantics, figure 5

  • Key: UML14-596
  • Legacy Issue Number: 847
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 16 of UML 1.1 Semantics, figure 5 shows a
    <Classifier>type--feature<StructuralFeature> association
    which conflicts with the <Classifier>owner--feature<Feature>
    aggregation. Note the duplicate role names for feature. I
    presume the first association is a
    duplicate.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3. Removed rolename "feature" on Classifier--StructuralFeature and removed ordering.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 62---editorial

  • Key: UML14-595
  • Legacy Issue Number: 846
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 62, in String, the word "Sting" should be "String".

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.2

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 62 "PseudostateKind"--editorial

  • Key: UML14-594
  • Legacy Issue Number: 845
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 62, in PseudostateKind, the word VisibilityKind should be replaced
    with PseudostateKind.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant (duplicates 820).

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 61: CallConcurrencyKind and EventOriginKind not defined

  • Key: UML14-592
  • Legacy Issue Number: 843
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 61, neither "CallConcurrencyKind" nor "EventOriginKind" is
    defined, although both exist on the diagram on pg 60.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Redundant (duplicates 818 & 819).

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 61 "EnumerationLiteral"--editorial

  • Key: UML14-593
  • Legacy Issue Number: 844
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 61, in EnumerationLiteral, the phrase "that but can be" should
    be "that can be".

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 50 table 3: Dependency Model elements (02)

  • Key: UML14-587
  • Legacy Issue Number: 838
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Dependency model element does not show <<friend>>
    stereotype but this is shown in A.1 for Dependency.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.2

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 50 table 3: Dependency model element

  • Key: UML14-586
  • Legacy Issue Number: 837
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Dependency model element shows <<deletion>> stereotype
    but <<deletion>> is not shown in A.1 for Dependency.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.2

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 60 figure 10: Data types

  • Key: UML14-591
  • Legacy Issue Number: 842
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 60, figure 10: Data Types

    A "Float" class is not shown although it is discussed in the description
    of Geometry on pg. 61. Is Float a data type?

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.2

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 9 figure 2: foundation packages

  • Key: UML14-590
  • Legacy Issue Number: 841
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A dependency from Data Types to Core is not shown although this
    is implied by the existence of a generalization from elements in
    Data Types to the Data type element in Core.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    clarified in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 137 table 6: Model management - Standard Elements

  • Key: UML14-589
  • Legacy Issue Number: 840
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 137, table 6: Model Management - Standard Elements

    Package model element does not show <<toplevelPackage>>
    stereotype but this is shown in A.1 for Package.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.2

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 50 table 3: Component model element

  • Key: UML14-588
  • Legacy Issue Number: 839
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Component model element does not show location for tagged
    values but this is shown in A.2 for Component

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.2

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 50 table 3: Auxiliary Elements-Standard Elements (Component model ele

  • Key: UML14-585
  • Legacy Issue Number: 836
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On pg. 50, table 3: Auxiliary Elements - Standard Elements

    Component model element shows <<friend>> stereotype
    but <<friend>> is not shown in A.1 for Component.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.2

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 40 table2: Generalization model element

  • Key: UML14-584
  • Legacy Issue Number: 834
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Generalization model element does not show <<inherits>>
    or <<extends>> stereotypes but these are shown in A.1
    for Generalization.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

page 40 table2: Classifier model element

  • Key: UML14-583
  • Legacy Issue Number: 833
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Classifier model element does not show <<metaclass>>,
    <<powertype>>, and <<thread>> stereotypes but these
    are shown in A.1 for Classifier.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 40 table 2:Constraints Model

  • Key: UML14-582
  • Legacy Issue Number: 832
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Constraints model element shows <<metaclass>> stereotype
    but <<metaclass>> is not show in A.1 for Constraints.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 40, table 2: Core - Standard Elements

  • Key: UML14-581
  • Legacy Issue Number: 831
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Class model element shows <<inherits>> stereotype
    but <<inherits>> is not shown in A.1 for Class.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 54 - ConstrainedStereotype

  • Key: UML14-580
  • Legacy Issue Number: 830
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This association is a means to define constraints to particular stereotypes, generally defined by the User. If we want to be able to let the user define constraints for every model elements, the constraint should have a " baseClass " attribute, or a specific kind of stereotype should be defined, which name is " default " or " base ", and which is the root of the stereotype inheritance tree In that case, defining a constraint for that stereotype means that a constraint for the associated metaclass is defined.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    considered and declined

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 39 - ModelElement/Dependency associations

  • Key: UML14-579
  • Legacy Issue Number: 829
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 13 - Page 39 : The ModelElement/Dependency associations are inconsistent with the others diagrams (cardinalities, role names)

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3: Dependency relationships updated.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 16- The association from parameter to classifier has a 1-1 cardinalit

  • Key: UML14-578
  • Legacy Issue Number: 828
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 12 - Page 16 : The association from parameter to Classifier has a 1-1 cardinality. 0..1 is more appropriate, because an incomplete defined parameter (during analysis, for example) may not have a defined type.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 121 - Partition has no parent class

  • Key: UML14-577
  • Legacy Issue Number: 827
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 10 - Page 121 : Partition has no parent class.
    It must be more clearly stated that classes having no Parent class inherit by defaut from the "Element" Class.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 98: ActionSequence has no parent class

  • Key: UML14-576
  • Legacy Issue Number: 826
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: ActionSequence has no parent class.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    no action needed, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 60 - GraphicMarker

  • Key: UML14-572
  • Legacy Issue Number: 822
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 5 - The " GraphicMarker " has a so vague definition, that no exchange can be provided between case tools. The same applies for every graphical features. This needs at least more explainations. May be, is it considered that the interpretations relies on each tool, or that more detail will come in the file exchange format??

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 35/37 - AssociationRole

  • Key: UML14-574
  • Legacy Issue Number: 824
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 35 and 37

    7 - In the diagram, the AssociationRole class appears. Its name is " AssociationEnd ".

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.2

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 60 - MultiplicityRange

  • Key: UML14-573
  • Legacy Issue Number: 823
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 6 - " MultiplicityRange " : what is the rule for representing the " * " value by an integer ?

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    UML 1.3: Multiplicity definition updated.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 81: message has no parent class

  • Key: UML14-575
  • Legacy Issue Number: 825
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 81: message has no parent class

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 60 - visibilityKind

  • Key: UML14-571
  • Legacy Issue Number: 821
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 4 - The enumaration " visibilityKind " has not any " default " visibility, such as in Java. We could think about adding such property to UML.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered but declined.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

page 60 - EventOriginKind

  • Key: UML14-569
  • Legacy Issue Number: 819
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2 - The enumeration " EventOriginKind " is not described.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

page 60 - CallConcurrencyKind

  • Key: UML14-568
  • Legacy Issue Number: 818
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1- The enumeration " CallConcurrencyKind " is not described.

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.3

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Page 60 - PseudostateKind

  • Key: UML14-570
  • Legacy Issue Number: 820
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 3 - The enumeration " PseudostateKind " is described, but the description refers (by error) to VisibilityKind (page 62)

  • Reported: UML 1.1 — Fri, 2 Jan 1998 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    fixed in UML 1.2

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML Documentation--Typos (05)

  • Key: UML14-564
  • Legacy Issue Number: 794
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 9
    4.3 Comparing UML to other modeling languages
    paragraph 5: reads "...as they previous knew..." but should read
    "...previously..."

  • Reported: UML 1.1 — Wed, 3 Dec 1997 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML Documentation--Typos (06)

  • Key: UML14-565
  • Legacy Issue Number: 795
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 14
    5.2 UML 1.0 - 1.1 and the UML partners
    paragraph *: Microsoft - the last sentence ends in two periods (..)
    instead of one

  • Reported: UML 1.1 — Wed, 3 Dec 1997 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML Documentation--Typos (07)

  • Key: UML14-566
  • Legacy Issue Number: 796
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: General
    Inconsistent use of "OOAD" and "OOA&D"

  • Reported: UML 1.1 — Wed, 3 Dec 1997 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Error on association owners

  • Key: UML14-567
  • Legacy Issue Number: 815
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The following constraint on associations :

    self.allConnections->forAll (r | self.namespace.allContents->includes
    (r.type) )

    seems incorrect to me :
    This basically restrict associations between classifiers in the same
    namespace. ==> you can not create an association between classes of
    different packages ?

  • Reported: UML 1.1 — Tue, 23 Dec 1997 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Considered and declined.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML Documentation--Typos (03)

  • Key: UML14-562
  • Legacy Issue Number: 792
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML Summary, v 1.1: Page 7
    4.1.1 UML-Defining Artifacts - UML Extensions
    paragraph 3: UML Variant - reads "...It can specializes the UML
    metamodel..." but should read "...specialize..."

  • Reported: UML 1.1 — Wed, 3 Dec 1997 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML Documentation--Typos (02)

  • Key: UML14-561
  • Legacy Issue Number: 791
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML Summary, v 1.1: Page 3
    3. Goals of the UML
    paragraph 10, last line: reads "...directly by he standard..." but
    should read "...the..."

  • Reported: UML 1.1 — Wed, 3 Dec 1997 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML Documentation-Typos (01)

  • Key: UML14-560
  • Legacy Issue Number: 790
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 1
    1. Preface
    paragraph 4: UML Notation Guide - reads "...defines notion and provides
    supporting examples..." but presumably should read "...notation..."

  • Reported: UML 1.1 — Wed, 3 Dec 1997 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

UML Documentation--Typos (04)

  • Key: UML14-563
  • Legacy Issue Number: 793
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 8
    4.2 Outside the scope of the UML
    paragraph 2: Tools - reads "...not an tool interface..." but should read
    "...a..."

  • Reported: UML 1.1 — Wed, 3 Dec 1997 05:00 GMT
  • Disposition: Resolved — UML 1.2
  • Disposition Summary:

    Fixed in UML 1.2.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Problems with OCL definition of Package::makesVisible

  • Key: UML25-672
  • Legacy Issue Number: 19069
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    Looking at the UML2.5 specification draft (I have the document UML25AfterBallot9.pdf - not sure if this is the newest one)
    I see problems with definition of Package::makesVisible - which is expressed in OCL.:

    makesVisible(el : NamedElement) : Boolean
    The query makesVisible() defines whether a Package makes an element visible outside itself. Elements with no visibility and elements with public visibility are made visible.
    pre: member->includes(el)
    body: ownedMember->includes(el) or
    (elementImport->select(ei|ei.importedElement = VisibilityKind::public)>collect(importedElement.oclAsType(NamedElement))>includes(el)) or
    (packageImport->select(visibility = VisibilityKind::public)>collect(importedPackage.member>includes(el))->notEmpty())

    Actually those problems carry on from the previous versions of UML;
    but since in previous versions even the OCL syntax was wrong (carried over from the pre-OCL2.0 times)
    I assumed this section is old/abandoned and did not pay much attention to it.

    But now with UML2.5 somebody took it seriously to update the syntax of the OCLs (kudos for that brave soul ), so we have an updated variant.
    But while the raw syntax problems were fixed, semantic problems were carried form the old revision verbatim.
    If we are updating OCLs anyway, I think it would be a good time to also correct those.

    So here goes:

    --------------------------------------------------------------------------------
    Problem #1

    the following comparison is nonsensical (the case handling ElementImports, line #2 of the body):

    ei.importedElement = VisibilityKind::public

    The OCL here tries to compare the model element (at the end of ElementImport relationship) with the enumeration literal - VisibilityKind::public, which is not what we want
    I think this passage should be restated as follows:

    ei.visibility= VisibilityKind::public

    i.e. we want to test whether element import has visibility set to public, just as in the other case - with package imports - one line below.

    Also the whole case handling element imports could be rewritten to simplify it:
    elementImport->exists(ei|ei.visibility = VisibilityKind::public and ei.importedElement = el)
    This does not change the semantics, but is much better readable/understandable: we are iterating through all (public) element imports
    checking whether imported element matches the element el.

    --------------------------------------------------------------------------------
    Problem #2
    the case handling package imports (line #3 of the body) is also borked:

    packageImport->select(visibility = VisibilityKind::public)>collect(importedPackage.member>includes(el))->notEmpty()

    Here the first part of the expression is OK; we take all package import relationships and filter them - accept only public ones:

    packageImport->select(visibility = VisibilityKind::public)
    But the next part again makes no sense

    ...>collect(importedPackage.member>includes(el))->notEmpty()
    here expression part

    importedPackage.member->includes(el)

    produces a boolean - whether element el is included among the members of the package being imported.
    So the result of the expression part

    ...>collect(importedPackage.member>includes(el))...
    is a collection of booleans (of the form:

    {false, false, true, false, true}

    ),
    where each boolean signifies whether element is among the members of each particular imported package.

    Then it makes no sense to test that for emptiness:

    ->notEmpty()
    this produces true if there is at least one item (does not matter true, or false) in that bag of booleans.
    So that part produces true if there is at least 1 public package import ( it does not matter what package is imported).

    I think this passage should be restated as follows:

    packageImport->select(visibility = VisibilityKind::public)>exists(importedPackage.member>includes(el))
    I.e. we are iterating through all (public) package imports and checking whether element el appears among members
    of at least one of the imported packages.

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

    So the final OCL of makesVisible could be (also getting rid of some unnecessary parentheses, and further simplification):

    pre: member->includes(el)
    body:
    ownedMember->includes(el) or
    elementImport->exists(ei|ei.visibility = VisibilityKind::public and ei.importedElement = el) or
    packageImport->exists(pi|pi.visibility = VisibilityKind::public and pi.importedPackage.member->includes(el))

  • Reported: UML 2.5b1 — Wed, 25 Sep 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

an instance spec should be a legitimate value of a property typed by a classifier

  • Key: UML25-671
  • Legacy Issue Number: 17565
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    To put it simply, I'm saying this:

    The spec should clearly state that an instance spec is a legitimate value
    of a property typed by a classifier.
    The spec should make sure that the abstract syntax operations &
    constraints involving all kinds of UML classifiers & instance
    specifications work according to the above.

    The UML spec tacitly agrees with this as shown in several examples:

    Figure 7.54 in UML 2.4.1, page 82.
    Figures 9.31, 9.32, 9.33 in UML Simplification Revised August draft, p. 143

  • Reported: UML 2.4.1 — Mon, 27 Aug 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    A legitimate value of a property (actually a Slot) is an InstanceValue, which is what is depicted by figures 9.32 and
    9.33.
    Disposition: Closed - No Change

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

A comment is a specialization of Element

  • Key: UML25-668
  • Legacy Issue Number: 17530
  • Status: closed  
  • Source: me.com ( Carlos Prado)
  • Summary:

    In the section diagram is specified that a Comment is a specialization of Element but in the definition of Comment says that Comment have no Generalizations

  • Reported: UML 2.4.1 — Thu, 26 Jul 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

Surplus classifier field serialized in Superstructure.xmi

  • Key: UML25-667
  • Legacy Issue Number: 17507
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    I've encountered one slight problem in the superstructure XMI file of UML2.4.1 .

    I've grabbed the ptc/2010-11-18 revision of Superstructure.xmi from here:
    http://www.omg.org/spec/UML/2.4.1/

    On examining I see that all enumeration literals contain classifier="..." field serialized; e.g.:
    > <ownedLiteral xmi:type="uml:EnumerationLiteral"
    > xmi:id="Activities-CompleteActivities-ObjectNodeOrderingKind-unordered" name="unordered"
    > classifier="Activities-CompleteActivities-ObjectNodeOrderingKind">
    There are ~62 such places in Superstructure.xmi (I've not looked into Infrastructure.xmi, but I
    think there will also be cases like this)

    Classifier metaproperty of EnumerationLiteral metaclass is derived in UML2.4.1 - per Figure 7.13 and
    chapter 7.3.17
    (EnumerationLiteral::classifier redefines the original InstanceSpecification::classifier, which is
    not derived).

    Since derived fields are not usually serialized by XMI production rules (unless this is overridden,
    which seems not to be the case),
    I think these fields should be cleaned out.

  • Reported: UML 2.4.1 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

Attribute is represented by Property

  • Key: UML25-670
  • Legacy Issue Number: 17550
  • Status: closed  
  • Source: gmail.com ( Hongwei Ma)
  • Summary:

    In the "Description" section, it stated that "Attributes of a class are represented by instances of Property that are owned by the class".
    Expected:
    "Attributes of a class are represented by Properties that are owned by the class".

    In page 43: it is stated that "an association end owned by a class is also an attribute".

    In page 36, memberEnd: Property[2..*] indicated that association end is Property.

    In all, I think Attribute is Property, only if the Property is owned by a class.
    It is confusing to mention instance in this context.

  • Reported: UML 2.4.1 — Sat, 11 Aug 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

Operation "isConsistentWith" is not overridden for any RedefinableElement

  • Key: UML25-669
  • Legacy Issue Number: 17547
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    The operation "isConsistentWith" is not overridden for any RedefinableElement in this chapter. Hence the contraint expression "A redefining element must be consistent with each redefined element." (from RedefinableElement) evaluates to false for any instance.

    Please add an operation for ObjectNode at least.

  • Reported: UML 2.4.1 — Thu, 9 Aug 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

Question About Arrows In Communication Diagramms

  • Key: UML25-664
  • Legacy Issue Number: 17398
  • Status: closed  
  • Source: Anonymous
  • Summary:

    wonder about the arrows used in communication diagramms (superstructure
    spec, Page 524).
    Do they indicate the type of message - as it is with sequence diagramms
    (sync, async) - or do they indicate the direction of message only.
    I didn't find a statement in the superstructure spec and several UML related
    books offered different oppinions.

  • Reported: UML 2.4.1 — Tue, 29 May 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Communication diagram can have replies shown, because it can represent any message. There is only the solid arrow
    style in communication diagrams.
    Disposition: Closed - No Change

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

Constraint [1] uses undefined attribute "ownedAttribute

  • Key: UML25-663
  • Legacy Issue Number: 17366
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    An Actor doesn't have an attribute named "ownedAttribute".

  • Reported: UML 2.4.1 — Mon, 14 May 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

Inconsistency: CentralBufferNode (ch .12.3.16) and fig. 12.15

  • Key: UML25-662
  • Legacy Issue Number: 17333
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    Figure 12.15 (on page 370) shows a DataStoreNode (which is a subclass of CentralBufferNode) that is conntected to an action ("Assign Employee").
    But in the description of CentralBufferNode (p. 361) it says: "They do not connect directly to actions".

  • Reported: UML 2.4.1 — Tue, 24 Apr 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue is obsolete. The description of CentralBufferNode in UML 2.5 no longer contains the sentence “They do
    not connect directly to actions.” (This sentence was intended to mean that ContralBufferNodes are not composed with
    Actions the way Pins are, not that they could not be connected by flows to Actions. But it was admittedly confusing.)
    Disposition: Closed - No Change

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

missing words in section 14.1

  • Key: UML25-665
  • Legacy Issue Number: 17461
  • Status: closed  
  • Source: gmail.com ( Nicolas Bros)
  • Summary:

    This sentence is apparently missing words:
    "through
    interactions in the form of <?????> (e.g., sequence diagrams or similar notations)"

  • Reported: UML 2.4.1 — Thu, 28 Jun 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This is now clause 17.1.1 of UML 2.5. Change “through interactions in the form of (e.g., sequence diagrams
    or similar notations).” to “through interactions in the form of sequence diagrams or similar notations

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

Incomplete sentence

  • Key: UML25-673
  • Legacy Issue Number: 19419
  • Status: closed  
  • Source: toshiba-tsip.com ( VIRESH MOHAN)
  • Summary:

    In Section 9.6.3 Operations block, there is an incomplete sentence in one of the paragraphs.
    "
    Different type-conformance systems adopt different schemes for how the types of parameters and results may vary when an Operation is redefined in a specialization. When the type may not vary, it is called invariance. When the parameter type may be specialized in a specialized type, it is called covariance. When the parameter type may be generalized in a specialized type, it is called contravariance. In UML, s"

    As you can see the last sentence in the above paragraph is incomplete.

  • Reported: UML 2.5b1 — Tue, 20 May 2014 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

DurationObservation#event should be ordered

  • Key: UML25-666
  • Legacy Issue Number: 17466
  • Status: closed  
  • Source: gmail.com ( Nicolas Bros)
  • Summary:

    The UML spec says: "The value of firstEvent[i] is related to event[i]"

    So the "event" feature of DurationObservation should be ordered since the order is significant: we need to refer to it by index.

  • Reported: UML 2.4.1 — Thu, 5 Jul 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed. While this is a metamodel change, it is necessary for the semantics to make sense.

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

LifeLine instead of Lifeline

  • Key: UML25-661
  • Legacy Issue Number: 17328
  • Status: closed  
  • Source: 1s.fr ( YuGiOhJCJ)
  • Summary:

    You wrote "lifeline: LifeLine[0..*]" at page 495 but you should write "lifeline: Lifeline[0..*]".
    The "L" must be in lowercase because it is the correct name of the class that represents a lifeline (as you can see at the 14.3.17 section and in the class diagram at page 475).

  • Reported: UML 2.4.1 — Mon, 23 Apr 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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 Super/Templates/Inconsistent organization

  • Key: UML25-607
  • Legacy Issue Number: 7831
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The section describing Templates is organized in a completely different way than all the other chapters in the spec. It should be made consistent with the rest of the spec

  • Reported: UML 1.4.2 — Fri, 1 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

UML 2 Superstructure -Incompatible use of term link

  • Key: UML25-606
  • Legacy Issue Number: 7825
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The Semantics of Association says:

    "An association declares that there can be links between instances of the
    associated types. A link is a tuple with one value for
    each end of the assocaition, where each value is an instance of the type of
    the end."

    but in Semantics of Connector the spec states:

    "Specifies a link that enables communication between two or more instances.
    This link may be an instance of an association, or
    it may represent the possibility of the instances being able to communicate
    because their identities are known by virtue of
    being passed in as parameters, held in variables or slots, or because the
    communicating instances are the same instance."

    The small issue is that link is used in incompatible ways which is
    confusing. The bigger issue is that Connectors may be typed by Associations
    and even if there is no actual type, one is "inferred". I would have thought
    that an instance of a Connector (a link) typed by an Association would have
    to be an Association Instance; one possible interpretation of this is that
    an instance of a Connector is only an Association Instance if it has a
    "non-inferred" type, although the value of "inferring" a type seems dubious
    if that is the case. The spec should clarify the situation.

  • Reported: UML 1.4.2 — Thu, 30 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.0 Issue: Semantics of Provided and Required Interfaces

  • Key: UML25-604
  • Legacy Issue Number: 7779
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In your presentation in Bertinoro you had
    a figure representing the mapping of the classic 'lollipop-notation' for
    provided and required interfaces into stereotyped dependencies between
    the port and the interfaces. I would like to propose that a similar
    picture be included in the specification to make the intent of the
    specification clearer. A good place for this figure would probably be
    9.3.11, Notation, just after Figure 110 (based on ptc/03-08-02).

  • Reported: UML 1.4.2 — 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

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

9.3.11 Port (from Ports)

  • Key: UML25-615
  • Legacy Issue Number: 7858
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A. All associations here are defined without multiplicity

    the multiplicity is given in the syntax diagram as * so [*] should be added to the text spec.

    B. redefinedPort : Port – subsets Element.redefinedElement.
    Element does not have member ‘redefinedElement’, must changed to be RedefinableElement::redefinedElement or (better yet) Property::redefinedProperty

  • Reported: UML 1.4.2 — Thu, 14 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

.3.44 Property (from Kernel)

  • Key: UML25-614
  • Legacy Issue Number: 7857
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Attribute:

    isReadOnly : Boolean

    This is redundant. Superclass of Property – StructuralFeature (from Kernel) has the same attribute with same default value. I think member isReadOnly can be inherited from StructuralFeature, and no needs define it in the Property.

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 15781

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

UML2 super/CommonBehavior/Opaque behavior : bad OO modelling

  • Key: UML25-610
  • Legacy Issue Number: 7850
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    When we see the attributes of OpaqueBehavior :
    • body : String [1..*] Specifies the behavior in one or more languages.
    • language : String [*] Languages the body strings use in the same order as
    the body strings.

    We can state that this is bad modelling practice : two attributes are sets,
    which elements have to be related 2 by 2 according to an ordering rule. This
    is even bad database modeling practice (violation of the 1st normal form
    rule).

    Proposition :
    Create an additional class "Language expression", having 2 attributes :
    Language and Body, and relate it to "OpaqueBehavior" instead of these two
    guilty attributes.

  • Reported: UML 1.4.2 — Wed, 13 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    The proposed change may be better OO modeling practice, but it would cause a significant backward incompatibility
    for model interchange. Note that the patter of parallel body and language attributes is used not only for OpaqueBehavior,
    but also for OpaqueExpression and OpaqueAction. The cost of making such a change in all these cases does
    not seem worth the benefit of a marginal improvement in modeling practice.
    Disposition: Closed - No Change

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

7.3.24 Interface (from Interfaces)

  • Key: UML25-611
  • Legacy Issue Number: 7854
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A.

    Association:

    redefinedInterface : Interface – subsets Element :: redefinedElement

    Element does not have member redefinedElement. Must be: “RedefinableElement :: redefinedElement”.
    Or better yet, change to “Classifier :: redefinedClassifier”.

    B.

    Association:

    ownedAttribute : Property – subsets Namespace.ownedMember and Classifier.feature

    instead of Classifier.feature, ownedAttribute subsets Classifier.attribute. See Figure 9 where Classifier.attribute:Property is annotated as

    {subsets feature}

  • Reported: UML 1.4.2 — Thu, 14 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

UML 2 Superstructure - cross-hair notation for nested classes

  • Key: UML25-605
  • Legacy Issue Number: 7784
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The cross-hair notation is specified as an alternate notation for showing
    the containment of classifiers in packages, but there is no mention of the
    use of this notation for nesting classifiers within classes - this notation
    was present in UML 1.4 and so for backwards compatibility reasons should be
    in 2.0 also. I also note that the cross-hair notation does not appear in the
    diagrams section of Classes.

  • Reported: UML 1.4.2 — Fri, 24 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

9.3.6 Connector (from InternalStructures)

  • Key: UML25-612
  • Legacy Issue Number: 7855
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Association

    redefinedConnector : Connector [0..*] – subsets Element.redefinedElement

    Element has no redefinedElement association. Change to RedefinableElement::redefinedElement

  • Reported: UML 1.4.2 — Thu, 14 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

8.3.1 Component (from BasicComponents, PackagingComponents)

  • Key: UML25-613
  • Legacy Issue Number: 7856
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Association:

    ownedMember : PackageableElement [*]

    Conflicts with Namespace :: ownedMember. Perhaps add a word about redefine?

  • Reported: UML 1.4.2 — Thu, 14 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

UML 2.3: Transitions outgoing junction vertexes should be allowed to have triggers

  • Key: UML25-630
  • Legacy Issue Number: 16581
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The Superstructure 2.3 mentions (15.3.14, page 573) a constraint for transitions:

    “Transitions outgoing pseudo states may not have a trigger (except for those coming out of the initial pseudo state).”

    I think this constraint is too limiting.

    First of all, it is not observed even in the specification:

    On page 546 it says about state lists (15.3.9, page 546):

    “Multiple trigger-free and effect-free transitions originating on a set of states and targeting a junction vertex with a single

    outgoing transition may be presented as a state symbol with a list of the state names and an outgoing transition symbol

    corresponding to the outgoing transition from the junction.”

    Conclusion:

    1) the transition from each of the states in the list cannot have a trigger

    2) the constraint says, that the transition from a junction vertex also cannot have a trigger

    ==> the transitions out of state lists cannot have triggers

    However In figure 15.27 and 15.28 such triggers are shown (e, f, logCard, logVerify).

    Second and more importantly, the described situation of “multiple transitions originating on a set of states and targeting a junction vertex” is quite common and therefore should be allowed, whether or not the modeler wants to use state lists.

    Suggestion

    Transitions from junction vertexes should be an exception to the constraint above. So the constraint on transitions needs to be reformulated:

    Page 573: “Transitions outgoing pseudo states may not have a trigger (except for those coming out of the initial or of junction pseudo states).”

    Then another constraint needs to be added

    Page 573: “The outgoing transitions of a junction pseudo state may have triggers only, when the incoming transitions originate from states and don’t have triggers.”

  • Reported: UML 2.4.1 — Tue, 4 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Adding triggers to transitions emanating from junction points would contradict the fundamental run-to-completion
    semantics of UML. This would require the execution of a compound transition chain, which is executed in a single
    run-to-completion step by definition, to stop in “mid-stream” at the junction pseudostate to await the arrival of new
    events.
    There is nothing in UML preventing transitions emanating from different source states to converge on a common join
    point (that is what junction points are for), which I think is the capability that the submitter is really asking for. It
    is indeed a very common situation. These transitions may have different triggers or, quite often the same trigger.
    In the latter case, AND ONLY IN THAT CASE, it is possible to use the state-list notation. However, in that case,
    the common trigger is used for the originating “transition” that goes to the common junction point (“transition” is in
    quotes here, because it is really just a notational shortcut for the multiple transitions that share the same trigger but
    originate from different states). From there onwards, it is possible to have different outgoing transitions with different
    guards (but not different triggers) and different effect behaviors.
    Note that neither figure 15.27 nor figure 15.28 are examples of the case where a common junction point is the target
    of the “transition” originating from a state list (instead, they terminate on a State).
    Disposition: Closed - No Change

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

inconsistent Generalization subsections in spec format

  • Key: UML25-622
  • Legacy Issue Number: 7875
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Reviewing of the new "generalization" subsections in the UML 2 spec, some are pointing down the inheritance hiearchy and some are pointing up.

    Section 6.5.1 Specification format says these sections are supposed to list the direct generalizations of a concept (see page 14, all the concepts "immediately above" in the hierarchy), yet I find many examples where metaclasses listed in Generalization subsections are the specializations of the concept.

    For example, Section 7.3.3 for Association correctly lists Classifier among its Generalizations, but 7.3.6 BehavioredClassifier(from Interfaces) lists BehavioredClassifier(from BasicBehaviors) thereby pointing down the hierarchy.

    Other examples are too numerous to list. The issue reported below may be another instance of this broader issue.

  • Reported: UML 1.4.2 — Tue, 19 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

notational standard for {subsets x} in textual contexts

  • Key: UML25-621
  • Legacy Issue Number: 7865
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The text of the UML 2 Finalized Superstructure spec randomly uses dots and doubled-colons, as separator characters, in specifying the metaattribute of a metaassociation end,

    {subsets <x>}


    It also randomly uses or does not use (a) capitalization, as in 'Subsets' and 'subsets', and (b) curly braces. These issues may seem trivial to some human readers but are of consequence wrt any attempt to programmatically navigate structured text..

    Details:

    The dot sometimes used as a navigation path separator, as is correct for OCL, and in other contexts the UML namespace separator, the double-colon, is used.

    Instances of the usage of the dot are at 7.3.5 BehavioralFeature, Association, ownedParameter (which also shows random variation, in not including the curly braces that sometimes set off the subsets property in the textual spec), and of the doubled-colons, at 17.2.1 InformationFlow, Associations target:NamedElement[ ]

    {Subsets DirectedRelationship::target}

    which also shows the occasional use of the curly braces.

    It seems that, since subsets is a relationship between the sets of instances that can qualify for occupying an end of an association, the dot notation, which is used for instance navigation in OCL and in familiar OO programming languages, is correct.

    Another reason for thinking the dot is correct is that the namespace separator implies that the named association end is part of the namespace of the Classifier at the other end, and that seems to imply that the end is navigable. There are some instances in the spec where the namespace separator is used, but wrt a non-navigable end.

    Question:
    what is the "standard" notation in the context of text outside of diagrams?
    Proposal:
    Revise the notation section for Association to make it explicit that the notational standards given there apply in both diagrams and text, and revise the text for consistency. The problem may be that the notational standard does not say whether it applies to text, diagrams, or both.

  • Reported: UML 1.4.2 — Fri, 15 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

15.3.11 State (from BehaviorStateMachines, ProtocolStateMachines)

  • Key: UML25-629
  • Legacy Issue Number: 7862
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1. Attributes:

    /isComposite

    /isSimple

    /isSubmachineState

    defined without a type ( it must be Boolean).

    2. Associations:

    redefinedState : State [0..1]

    Must be subsets RedefinableElement::redefinedElement.

    3.

    region : Region [*] – subsets ownedMember

    Must be “subsets Namespace::ownedMember”.

    4.

    /redefinitionContext : Classifier [1]

    This member must redefine RedefinableElement::redefinitionContext (they have different multiplicity).

    5.

    region : Region [0..1]

    Second member named ‘region’ with another multiplicity and different semantic.

    6. I think some associations must subset members from parents, but this is not present in spec. I think this chapter needs review.

  • Reported: XMI 1.0 — Tue, 31 Aug 1999 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

"Class" should read "Classifier" in Generalization subsection for Behaviore

  • Key: UML25-623
  • Legacy Issue Number: 7876
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Reference to the October 2005 UML 2 Superstructure Specification as delivered out of the FTF.

    Issue name: "Class" should read "Classifier" in Generalization subsection for BehavioredClassifier.

    Description:

    BehavioredClassifier text specification on page 468 lists generalization as Class (from Kernel)

    However, the syntax diagram Figure 311 on page 459 shows the generalization of BehavioredClassifer as Classifier(from Kernel)

    Figure 314 shows Class as a specialization, not a generalization, for Behaviored Classifier.

    I suspect 'Generalization Class (from Kernel)' on page 468 is an error in the text and it should read 'Generalization Classifier' (from Kernel).

  • Reported: UML 1.4.2 — Tue, 19 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

15.3.14 Transition (from BehaviorStateMachines)

  • Key: UML25-620
  • Legacy Issue Number: 7864
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1. Association:

    /redefinitionContext : Classifier [1]

    Must redefine RedefinableElement::redefinitionContext (different multiplicity).

    2.

    container [1]

    Defined without type (but (wonder?) with multiplicity!). J

    3.

    Generalizations: from NamedElement (from Kernel, Dependencies) and from RedefinableElement (from Kernel).

    But RedefinableElement inherited from NamedElement. What deep sense of this double inheritance from NamedElement?

  • Reported: XMI 1.0 — Tue, 7 Sep 1999 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

15.3.10 Region (from BehaviorStateMachines)

  • Key: UML25-619
  • Legacy Issue Number: 7863
  • Status: closed  
  • Source: Anonymous
  • Summary:

    15.3.10 Region (from BehaviorStateMachines)

    Association:

    /redefinitionContext : Classifier [1]

    Must redefine RedefinableElement::redefinitionContext (they have different multiplicity).

  • Reported: UML 1.4.2 — Thu, 14 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

UML2 Super / Templates / ordering of subExpressions

  • Key: UML25-626
  • Legacy Issue Number: 7882
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    StringExpression:subExpression should be ordered

  • Reported: UML 1.4.2 — Wed, 27 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Actually, it seems that ordering was incorrectly applied to the opposite property StringExpression:: owning-
    Expression instead of StringExpression::subExpression. This should be corrected.

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

15.3.16 Vertex (from BehaviorStateMachines)

  • Key: UML25-617
  • Legacy Issue Number: 7860
  • Status: closed  
  • Source: Anonymous
  • Summary:

    15.3.16 Vertex (from BehaviorStateMachines)

    Associations:

    container : Region [0..1] – subsets Element::owner

    This is a mistake, because Element::owner is already subsetted in parent of Vertex – NamedElement::namespace.

    Must be “subsets NamedElement::namespace”

  • Reported: UML 1.4.2 — Thu, 14 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

Artifact (from Artifacts)

  • Key: UML25-616
  • Legacy Issue Number: 7859
  • Status: closed  
  • Source: Anonymous
  • Summary:

    P#224 – Figure 127 – Artifact (from Artifacts)

    P#769 – Figure 467 – Artifact (from Artifacts)

    Must be “Artifact (from Artifacts, Nodes)” because there is no “Artifact (from Artifacts)” in this document.

  • Reported: UML 1.4.2 — Thu, 14 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

UML 2 Super/ Classes / issue with Property::isComposite

  • Key: UML25-625
  • Legacy Issue Number: 7881
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There is a serious inconcistency in the specification with respect to Property::isComposite.

    In the description of Association, it states that "Composition is represented by the isComposite attribute on the part end of the association being set to true".

    But in the discussion of structured classifier parts or the discussion of profile extensions it implies the opposite. isComposite should be true for the end that is owned by the whole.

    This will have a serious impact on interchange (among other things) if different implementations put the "black diamond" on different ends of the composition...

  • Reported: UML 1.4.2 — Tue, 26 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

15.3.8 Pseudostate (from BehaviorStateMachines)

  • Key: UML25-618
  • Legacy Issue Number: 7861
  • Status: closed  
  • Source: Anonymous
  • Summary:

    15.3.8 Pseudostate (from BehaviorStateMachines)

    Associations:

    stateMachine : Statemachine [0..1] – subsets Element::owner

    Like above: must be “subsets Vertex::container”.
    Type of stateMachine must be StateMachine (letter ‘M’ must be capital).

  • Reported: UML 1.4.2 — Thu, 14 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

Modeling sent messages in State Machines

  • Key: UML25-675
  • Legacy Issue Number: 15145
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Adrian Noguero)
  • Summary:

    Currently it is not possible to define formally in a state machine diagram that a behavior linked to a transition/state triggers a message to be sent through a port.
    I think that being able to formally describe this would in fact make this kind of diagrams very valuable for compositional verification of state machine diagrams. See "Towards the Compositional Verification of Real-Time UML Designs" by Holger Giese et al. for reference

  • Reported: UML 2.3b1 — Wed, 24 Mar 2010 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue is not entirely clear, but it would seem that the desired capability is available by using an InvocationAction
    with onPort, as now described more fully in the UML 2.5 beta specification in Subclause 16.3.3, under “Invocation
    Actions and Ports”.
    Disposition: Closed - No Change

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

TestIdentityAction for datatypes

  • Key: UML25-674
  • Legacy Issue Number: 14989
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In UML, TestIdentityAction does not currently apply to datatypes. The
    introduction and description of TestIdentityAction say
    "TestIdentifyAction is an action that tests if two values are identical
    objects. This action returns true if the two input values are the same
    identity, false if they are not." Data type values are not objects and
    do not have identity (that is, you cannot tell one data type value from
    another).

    If it is decided that the execution engine should not reflect the above
    semantics, the semantics of TestIdentityAction needs to be extended for
    unstructured datatype values to test whether the values are the same.
    For structured values, such as strings, the values and their contents
    would need to be the same, recursively if they contain more datatype
    values.

  • Reported: FUML 1.0b2 — Tue, 19 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue is obsolete. The specification of the semantics of TestIdentityAction in the UML 2.5 beta specification, in
    Subclause 16.4.3, under “Test Identity Actions”, covers the testing of instances of data types.
    Disposition: Closed - No Change

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

Behavior should be derived from Classifier, not Class

  • Key: UML25-660
  • Legacy Issue Number: 17289
  • Status: closed  
  • Source: rvirzi.com ( Raymond Virzi)
  • Summary:

    My previous submission has been resolved. Apparently, the UML spec provides an exception clause in the definition of the /context field to allow the context classifier to propagate downward to sub state machines. I do not know how to find and close the original issue so I'm mentioning it here.

    That said, the semantic issue I raise I believe is still present and is illustrated precisely by the need for that exception clause in the /context field definition. I'd like to propose a much simpler solution.

    A UML Behavior describes the dynamic behavior of its context classifier. All attributes and operations that it class during its execution should come from the context classifier. There is no need for the Behavior to own attributes and operations on its own, and I would like to suggest deriving Behavior directly from Classifier rather than from Class in section 13.3.2. I have not investigated the full impact of such a change, but I believe it would not have any significant impact and would improve the semantic integrity of the model.

    A simple example is that a Behavior has a specification which could be, for example, a call to an Operation. Although the Operation belongs to a Class (its context), would would argue that the Operation is itself a Class?

  • Reported: UML 2.4.1 — Sun, 1 Apr 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The proposed change would actually have a significant impact on both the abstract syntax and semantics of Behavior.
    A Behavior may be standalone with no context classifier, in which case it may be useful for the Behavior to have its
    own structural and/or behavioral features. And, even if the Behavior has a context, the features of the Behavior may
    be different than those of the context classifier, relating, for example, to the execution of the Behavior itself rather than
    the state of the context object of the execution, particularly if the execution is asynchronous.
    Disposition: Closed - No Change

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

Package merge on Class metatype causes semantic issues - particularly with state machine context

  • Key: UML25-659
  • Legacy Issue Number: 17283
  • Status: closed  
  • Source: rvirzi.com ( Raymond Virzi)
  • Summary:

    I recently wrote a code generator for my UML tool for state machines. One of the properties of a state machine is called /context, which is the Class that has the state machine as its Classifier Behavior (if any exists). When I created a submachine state, the /context field of the state machine inside the submachine state was listing the parent state machine as its /context, rather than the class owning the parent state machine. This does not make semantic sense, because the purpose of the context field is the allow the state machine to have access to the methods and data of the class that implements the state machine behavior.

    The UML spec says that to find the /context of a state machine, you must travel up the Owner tree until you hit the first Behaviored Classifier. My UML tool vendor pointed out to me that a State Machine is classified as a behaviored Classifier so it qualifies. That did not make sense to me because a State Machine is classified as a Behavior. How can a Behavior also be a class that owns a behavior?

    After checking the UML spec further, I discovered that a Behavior, and therefore a State Machine, is derived from Class (Kernel), which is not a Behaviored Classifier. However, after all the packages are merged, Class (Kernel) gets merged with Class (Communications), which is a Behaviored Classifier, and the merge rules allow the class
    hierarchy to be merged together. I confirmed this anomaly was present in the merged XMI files at OMG website.

    I believe this problem is unique to Class metatype. If you look at Annex F of the UML spec, it shows the complex class hierarchy associated with Classifiers from various packages prior to merging. There are three merge increments for Class in three different places on the tree. These are even called out explicitly in the diagram. You
    can see how the inheritance tree would be changed dramatically when these three Class increments are merged together. All other cases where the metatype increments are merged do not change the structure
    of the inheritance tree. The Class metatype is unique in this respect.

    I thought about a solution and I believe there is an easy fix to this problem. It requires replacing the Class (Communicatoins) increment with a new metatype called BehavioredClass, and replacing the Class (StructuredClasses) increment with the already existing
    EncapsulatedClassifier. After this change, a BehavioredClass would be both a Class (Kernel) and a BehavioredClassifier, as is already illustrated in 13.3.8 but would now be more intuitive. Component would now inherit from Class (Kernel) and EncapsulatedClassifier (Ports). Node would inherit directly from EncapsulatedClassifier, thus preserving the pre-merge idea that Node's should not have data and methods associated with them (as with Class (Kernel)). This is another currently odd outcome of merging the packages together.

    Because Class (Kernel) is a concrete metatype (and therefore shows up in modeling tools), you would need to make BehavioredClass concrete also. Modelers would have to expose it and I think this would be an improvement. I've always felt that active classes (like OS tasks) and
    non-active classes (data and methods only) are such distinct object types that they should have separate representations. The elimination of the Class (StructuredClasses) increment would also prevent the
    merge from adding ports to the generic concept of a Class, which is also desirable since ports are not useful without the ability to represent internal structure.

    After that modification, there are other modifications that would naturally follow. The one I can see is that the isActive attribute of Class would now be a derived attribute which is set to true for classes that inherit BehavioredClass and false otherwise. With this change, in the fully merged UML package, a StateMachine would be derived from Class with only the Kernel attributes. It would no longer falsely inherit from BehavioredClassifier. A whole bunch of other inherited properties that make no sense would also go away.

  • Reported: UML 2.4.1 — Thu, 29 Mar 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

Error in UML diagrams?

  • Key: UML25-648
  • Legacy Issue Number: 16724
  • Status: closed  
  • Source: University of Vienna/Austrian Academy of Sciences ( Georg Lönger)
  • Summary:

    If I am not mistaken, there is an error in several UML diagrams.

    Let me start with page 14, figure 7.3: The name of the package on the left side is "Constructs", but it probably should read "Core", shouldn't it?

    This UML diagram seems to be depicted several times in the document cited, which is why the situation is the same in the following places: page 27, second figure; page 29, figure 9.1; page 91, figure 10.1; page 103, figure 11.1.

    Also, on page 162, section 11.9.2, subsection titled "Notation", second bullet point, it reads: "If the members of the package are shown within the large rectangle, then the name of the package should be placed within the tab." This would have to be implemented in the UML diagram(s) referred to above (now, the name "Constructs", that is to be corrected by "Core", is within the rectangle instead of within the tab).

    I would be very glad to receive some feedback on my remarks.

  • Reported: UML 2.4.1 — Fri, 25 Nov 2011 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

Suggestions for editorial changes

  • Key: UML25-647
  • Legacy Issue Number: 16723
  • Status: closed  
  • Source: University of Vienna/Austrian Academy of Sciences ( Georg Lönger)
  • Summary:

    Reading the document cited, I noticed some editorial errors. Thus, below you will find some suggestions for editorial changes.

    • Page 23, Section 8.3.2, first sentence: Instead of "are enumerated", it should probably read "is enumerated".
    • Page 48, section 9.8.3, subsection titled "Associations": Instead of "owning expression. Subsets", it should probably read "owning expression subsets".
    • Page 96, section 10.2.1, subsection titled "Semantics", second paragraph, first sentence: Instead of "features on another class", it should probably read "features of another class".
    • Page 98, section 10.2.5, subsection titled "Attributes", last bullet point, last sentence: Instead of "Default value", it should read "The default value".
    • Page 111, section 11.3.1, first paragraph, second and third sentences: A space character is missing between the two sentences.
    • Page 113, section 11.3.1, subsection titled "Semantics", sixth paragraph, first sentence: Instead of "characterized", it should read "characterizes".
    • Page 151, section 11.7.5, subsection titled "Examples": Instead of "imported WebShop", it should read "imported to WebShop".
    • Page 154, section 11.8.2, subsection titled "Constraints". Instead of "n operation", it should read "An operation".
    • Page 173, section 12, second paragraph, fifth paragraph: Instead of "profile?s", it should read "profile's".
    • Page 173, section 12, first numbered paragraph, last sentence: Instead of "more constraining", it should read "more constraining than".
    • Page 178, section 12.1.2, subsection titled "Semantics", first paragraph, last sentence: Instead of "at most", it should (probably?) read "at least".
    • Page 186, section 12.1.7, subsection titled "Semantics", last paragraph on page, last sentence: Instead of "and or", it should read "and/or".
    • Page 191, section 12.1.8, subsection titled "Semantics", first paragraph, fourth and fifth sentences: There seems to be a mistake on the boundary between the two sentences ("all its nested and imported."); probably, something is missing at the end of the fourth sentence after "imported".
    • Page 194, section 12.1.9, subsection titled "Semantics", third paragraph on page, second sentence: Instead of "theses stereotypes", it should read "these sstereotypes".
    • Page 194, section 12.1.9, subsection titled "Notation", third paragraph, first sentence: Instead of "stereotype?s", it should read "stereotype's".
    • Page 195, section 12.1.9, subsection titled "Presentation Options", first sentence on page: Instead of "may shown", it should read "may be shown".
    • Page 196, section 12.1.9, subsection titled "Examples", last paragraph on page, second sentence: Before "isRequired", opening quotation marks are missing.
  • Reported: UML 2.4.1 — Fri, 25 Nov 2011 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

how to instantiate associations between stereotypes

  • Key: UML25-654
  • Legacy Issue Number: 17160
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML says: ” Stereotypes can participate in binary associations. The opposite class can be another stereotype, a non-stereotype class that is owned by a profile, or a metaclass of the reference metamodel.”

    How are instances of these stereotypes and associations to be serialized?

    For example, look at SysML1.3 in which the stereotype ValueType has an association named A_valueType_unit to the stereotype Unit.

    How is a SysML 1.3 model supposed to instantiate this? There will be an element representing the stereotype instance of this form:

    <sysml:ValueType xmi:id="id1" base_DataType="id2" unit="id3"/>

    What should id3 be the identity of? Presumably the target stereotype instance? Or the model element to which the target stereotype instance is applied?

    Is such an association allowed to be a composition? If so what would be the deletion semantics?

    Also, would we really expect to see any elements of this form?

    <sysml: A_valueType_unit xmi:id="id4" valueType="id1" unit="id5"/>?

    The following sentence: “For these associations there must be a property owned by the Stereotype to navigate to the opposite class. Where the opposite class is not a stereotype, the opposite property must be owned by the Association itself rather than the other class/metaclass” appears to imply that we would never see such an element, but I don’t know of any statement to confirm this

  • Reported: UML 2.4.1 — Thu, 23 Feb 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clarify non-trivial aspects of associations defined in the context of a profile:
    • Serializing instances of associations is optional for XMI.
    • Associations can be composite or not.
    • Clarify the kinds of Types allowed to be defined or imported in a Profile.
    • Instances of stereotypes are owned by the link instance of the composite association corresponding to
    the mapping of the stereotype extension.
    • Fix the incorrect reference to section 14.3 of the MOF Core spec to 14.4 instead.
    Note that clause 12 lacks a notation for instances of Profile-defined Classes, DataTypes and Associations.
    Specifying such notation is a separate issue.

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

Core package caption wrong

  • Key: UML25-653
  • Legacy Issue Number: 17131
  • Status: closed  
  • Source: gmail.com ( Jair Humberto)
  • Summary:

    The caption of the first package(left) of the figure 7.3 is not wrong? The correct should not be Core(instead Construct)? That figure had me confused at the beginning

  • Reported: UML 2.4.1 — Thu, 16 Feb 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

Add an example for the lifeline head shape

  • Key: UML25-658
  • Legacy Issue Number: 17268
  • Status: closed  
  • Source: 1s.fr ( YuGiOhJCJ)
  • Summary:

    It is written that the Lifeline head has a shape that is based on the classifier for the part that this lifeline represents.

    I think you want to tell that we can have a "stick man", if the lifeline represents an Actor.

    It should be good to show an example for a lifeline that represents an Actor (it was the case in UML 1.3 at page 343, Figure 3-48).

  • Reported: UML 2.4.1 — Thu, 22 Mar 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 11068

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

color of the notation is specified

  • Key: UML25-657
  • Legacy Issue Number: 17266
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the UML spec there are several places where the color of the notation is specified. For example, the composition diamond is specified as black, the state machines junction ball is specified as black, and the lost/found message is specified as black, and the information identifier is a black triangle.

    Similarly there are few cases where white and grey are specified.

    This is overly limiting, some tools use a solid color for the items specified as black, or let the user select the color (usually selecting the same as the line color). It would not be good to limit the representation to only black color, as that would invalidate most PowerPoint and several tools.

    Please change the color black to “solid” or “filled with the line color” and change “white” to “hollow” or “un-filled”.

    For grey/gray it should be “a distinguishable value between the solid and the hollow”

  • Reported: UML 2.4.1 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Put some clarification into “How to read this specification”.

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

The property “packagedElement: PackageableElement [*]” is not a derived property and should not be prefixed with "/"

  • Key: UML25-656
  • Legacy Issue Number: 17202
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I probably discovered a little error in the UML 2.4.1 Superstructure Specification on page 109 in section “Associations” (from Chapter “7.3.38 Package (from Kernel)”):

    The property “packagedElement: PackageableElement [*]” is not a derived property and should therefore not be prefixed with a ‘/’.

  • Reported: UML 2.4.1 — Tue, 28 Feb 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

Opposite ends of derived unions should be derived unions

  • Key: UML25-655
  • Legacy Issue Number: 17172
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Action::inputPin and Action::outputPin are both derived unions. Both also have opposite association owned ends that are not derived. While I don't think the metamodel is actually incorrect, those owned ends are implicitly derived unions too. So I think it would make more sense to make that explicit.

    I've just picked two examples, however I believe there are more in the specification.

  • Reported: UML 2.4.1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The FTF agrees that the other ends ought to be derived unions. Because all cases of this are associationowned
    ends, this does not affect serialization. There are ten cases of this in the metamodel, which are the
    opposite ends for:
    DirectedRelationship::source
    DirectedRelationship::target
    Classifier::attribute
    StructuredClassifier::role
    Action::input
    Action::output
    RedefinableElement::redefinedElement
    RedefinableElement::redefinitionContext
    Namespace::member
    Relationship::relatedElement

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

Use of term "locus of control"

  • Key: UML25-651
  • Legacy Issue Number: 16946
  • Status: closed  
  • Source: Technion, Israel Institute of Technology ( Arieh Bibliowicz)
  • Summary:

    In the semantics of activity, it is written "A token contains an object, datum, or locus of control, and is present in the activity diagram at a particular node." The term "locus of control" seems strange, and I think it should be "focus of control".

  • Reported: UML 2.4.1 — Mon, 9 Jan 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

V2.4.1 from 11-08-05 on page 14 in Figure 7.3

  • Key: UML25-650
  • Legacy Issue Number: 16875
  • Status: closed  
  • Source: softenvironment.ch ( Peter Hirzel)
  • Summary:

    In V2.4.1 from 11-08-05 on page 14 in Figure 7.3 – „The Core packages“ the outer package is named „Constructs“. Is that correct or should it be called “Core”?

  • Reported: UML 2.4.1 — Wed, 2 Nov 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

default is wrong

  • Key: UML25-646
  • Legacy Issue Number: 16656
  • Status: closed  
  • Source: gmail.com ( Ooki Kawai)
  • Summary:

    Section [notation] there is a wrong description. [* default is

    {incomplete, disjoint}

    ] is wrong, isn't it? [* default is

    {incomplete, overlapping}

    ] is correct, maybe. Because, [Attributes] says isDisjoint that's default value is false

  • Reported: UML 2.4.1 — Wed, 9 Nov 2011 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

V2.4.1 from 11-08-05 on page 14 in Figure 7.3

  • Key: UML25-645
  • Legacy Issue Number: 16651
  • Status: closed  
  • Source: softenvironment.ch ( Peter Hirzel)
  • Summary:

    In V2.4.1 from 11-08-05 on page 14 in Figure 7.3 – „The Core packages“ the outer package is named „Constructs“. Is that correct or should it be called “Core”?

  • Reported: UML 2.4.1 — Wed, 2 Nov 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

Reference in index to item that does not exist in contents

  • Key: UML25-649
  • Legacy Issue Number: 16725
  • Status: closed  
  • Source: Technion, Israel Institute of Technology ( Arieh Bibliowicz)
  • Summary:

    In the internet I found a reference to something called a "SynchState" for state machines. I searched the UM Superstructure but didn't find this defined there, although there is an index entry for it.
    Either the index entry is irrelevant or the state was omitted from the document

  • Reported: UML 2.4.1 — Sun, 27 Nov 2011 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

incorrect upper value of coveredBy of Lifeline

  • Key: UML25-652
  • Legacy Issue Number: 17127
  • Status: closed  
  • Source: web.de ( Matthias Schoettle)
  • Summary:

    "coveredBy : InteractionFragment" is stated with a multiplicity of "[0..1]" although in the comment it says "References the InteractionFragments" and the machine readable XMI file of the superstructure has "*" as the value of the upper value of the coveredBy attribute.

  • Reported: UML 2.4.1 — Fri, 10 Feb 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

ChangeEvent association mismatch

  • Key: UML25-632
  • Legacy Issue Number: 16590
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

    ChangeEvent has defined association changeExpression:Expression[1], but the figure 13.12 depicts the association toward UML::Classes::Kernel::ValueSpecification.

  • Reported: UML 2.4.1 — Tue, 11 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

EnumerationLiterals in the XMI

  • Key: UML25-631
  • Legacy Issue Number: 16584
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The EnumerationLiterals in the XMI include values for the ‘classifier’ property which is redefined to be derived in the metamodel.

    Even if not derived it would be the inverse of the owning composition so should not be serialized.

  • Reported: UML 2.4.1 — Thu, 6 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

"A_realization_abstraction_component" is useless

  • Key: UML25-635
  • Legacy Issue Number: 16635
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    In Figure 8.2, A_realization_abstraction_component appears over Component - ComponentRealization composition line. But this name (association name?) is not used anywhere.

  • Reported: UML 2.4.1 — Thu, 27 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

Subpart I and II are missing in Bookmarks

  • Key: UML25-634
  • Legacy Issue Number: 16634
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    In Adobe Acrobat Reader, there are no "Subpart I" and "Subpart II" whereas there are "Subpart III" and "Subpart IV" .
    This seems inconsistent

  • Reported: UML 2.4.1 — Thu, 27 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

default value of ClassifierTemplateParameter#allowSubstitutable is "..."

  • Key: UML25-644
  • Legacy Issue Number: 16650
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    In Figure 17.13, the default value of ClassifierTemplateParameter#allowSubstitution is truncated to "...".

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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 15.2 does not include TransitionKind

  • Key: UML25-643
  • Legacy Issue Number: 16647
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    enumeration TransitionKind should appear in Figure 15.2.

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

role "interval" appears "interva"

  • Key: UML25-640
  • Legacy Issue Number: 16644
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    Two association ends "interval" are hidden by class "Interval" and the last letters ("l") are not displayed.

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..."

  • Key: UML25-639
  • Legacy Issue Number: 16643
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    "nonuni..." must be appeared as "nonunique"

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

misspelling: io-oargument

  • Key: UML25-642
  • Legacy Issue Number: 16646
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    It seems that "io-oargument" is misspelling of "io-argument".

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..."

  • Key: UML25-641
  • Legacy Issue Number: 16645
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    "nonuni..." must be appeared as "nonunique"

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

RedefinableElement (from Kernel) is preferable

  • Key: UML25-636
  • Legacy Issue Number: 16638
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    In Figure 12.4, RedefinableElement has no note "(from Kernel)". I think all classes that do not belong to BasicActivities should be noted as "(from SomePackage)" within class compartment.

  • Reported: UML 2.4.1 — Thu, 27 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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 Superstructure Specification

  • Key: UML25-633
  • Legacy Issue Number: 16596
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

    Abstraction class has defined association "mappings" of type Expression, but on page 35, figure 7.15 depicts Abstraction with the association of type OpaqueExpression.

  • Reported: UML 2.4.1 — Fri, 14 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

poor figure resolution and a misspelling: fal...( false )

  • Key: UML25-637
  • Legacy Issue Number: 16639
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    Figure 12.21 blurs. In additon, the default value of LoopNode#isTestedFirst looks "fal...". (I suppose "false").

  • Reported: UML 2.4.1 — Thu, 27 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

{ordered} is rather far from +bodyOutput

  • Key: UML25-638
  • Legacy Issue Number: 16642
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    In Figure 12.22, there is "

    {ordered}" near role "+clause". I think {ordered}

    must be located near +bodyOutput, rather than +clause.

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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 Super and Infra/ defualt property of Parameter::effect

  • Key: UML25-601
  • Legacy Issue Number: 7758
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    I think it makes sense that the default value of Parameter::effect be 'read' (currently it is not specified).

  • Reported: UML 1.4.2 — Sun, 19 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    There is no need for any default value because Parameter::effect is 0..1.
    Disposition: Closed - No Change

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

Associations between interfaces

  • Key: UML25-602
  • Legacy Issue Number: 7777
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The caption of Figure 63 of the FAS (Figure 56 of the 040814 PDF) shows
    an association between example interfaces IAlarm, ISensor, and has this
    caption:

    IAlarm is the required interface for any classifier implementing
    Isensor; conversely, Isensor is the required interface for any
    classifier implementing IAlarm.

    The text description says:

    A set of interfaces constituting a protocol may be depicted as
    interfaces with associations between them

    Is this just notation, or are associations really in the model?

    • If it is just notation, what is the model?
    • If it is the model, isn't it overly restrictive? The modeler's
      intention might be that these are both required interfaces,
      declaring that the two support classes will include an association
      between them. I thought interface were extended in UML 2 to include
      associations generally.
  • Reported: UML 1.4.2 — Fri, 27 Aug 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

Association notation for properties does not allow representation of aggregation

  • Key: UML25-499
  • Legacy Issue Number: 18466
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML 2.5 issue.

    There is a sentence in 9.5.4: “In a Classifier, an attribute may also be shown using association notation, with no adornments at the tail of the arrow.” This does not allow the use of diamond notation to represent properties that are aggregations or compositions.

  • Reported: UML 2.5b1 — Wed, 20 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This is independent of issue 15237, which complains about the very existence of this notation. If the notation
    is to remain, at least it needs to be comprehensibly defined.

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

UML2.5 issue: incorrect use of oclKindOf()->notEmpty()

  • Key: UML25-498
  • Legacy Issue Number: 18465
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There is a systematic error in the OCL in Clause 17. There are many erroneous expressions of the form x.oclIsKindOf(T)->notEmpty(). These are apparently intended to mean x.oclIsKindOf(T), i.e. a Boolean-valued test that x has the type T or a subtype.

    The fact that the ->notEmpty() happens to pass the syntax checking is an unfortunate and misleading “feature” of OCL. Semantically, all of these expressions in their current form will evaluate to true, whatever their arguments.

    I found these constraints all to have the problem:

    all_lifelines

    interaction_uses_share_lifeline

    selector_int_or_string

    sending_receiving_message_event

    signature_is_signal

    signature_is_operation_request

    signature_is_operation_reply

  • Reported: UML 2.5b1 — Wed, 20 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Change the OCL productions to replace:
    x.oclIsKindOf(T)->notEmpty()
    by:
    x.oclIsKindOf(T)

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

wrong multiplicity of redefining states

  • Key: UML25-497
  • Legacy Issue Number: 18455
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    UML spec, Figure 15.3 shows that multiplicity of redefining state is 0..1 which automatically means that it is impossible to have two or more subclasses which redefine the same state in their statemachines.

    It should be fixed to state [0..*] I believe

  • Reported: UML 2.5b1 — Thu, 14 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Change the appropriate association end multiplicities from [0..1] to [0..*].

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

Keywords are inconsistently defined and applied

  • Key: UML25-496
  • Legacy Issue Number: 18454
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The word “keyword” is used inconsistently throughout the spec. It is defined in Annex C, which clearly says that keywords are always enclosed in guillemets, and lists the keywords that appear in the spec. Non-stereotype keyword are currently all defined starting with lower case, while standard stereotypes (also listed in Annex C and counting as keywords) use upper case.

    However:

    1. Several keywords defined in the spec are missing from Annex C: bind, collaboration, complete, disjoint, parallel, iterative, stream and flow.

    2. Several references in the spec to standard stereotypes use lower case and should use upper: derive, refine, trace

    3. In 7.7.5 instantiate is described and lower-cased as a keyword when it should be referred to as a standard stereotype in upper case

    4. 9.2.4 states that the standard notation for classifiers “shows the metaclass in guillemets”. This is not true: almost all classifiers define a lower-case keyword for their notation, such as interface; sometimes the keyword is different from the metaclass name, e.g. primitive.

    5. Notwithstanding the above, the notations for Collaboration, Class and StateMachine explicitly and inconsistently use the metaclass name with uppercase. In the case of Collaboration (11.7.4) and Class (11.4.4), Annex C is missing the keyword; in the case of StateMachine, Annex C shows it as statemachine.

    6. Some words are described as keywords when they are not. Clause 13: all, at, after, when; clause 14: via, protocol; clause 17: sd, self, out, strict

    7. Annex C itself uses the phrase ‘the keyword “trace”’ when it should surely say ‘the keyword «Trace»’.

  • Reported: UML 2.5b1 — Thu, 14 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There are many problems with keywords in Annex C and throughout the spec.
    (1) can be resolved by including appropriate definitions in Annex C.
    (2) can be resolved by correcting the references where they occur.
    For (3) a separate issue will be raised against clause 7.
    (4) can be resolved by altering 9.2.4 to refer to the keyword rather than the metaclass.
    (5) can be resolved by correcting the references to refer to the lower case name. (6) can be resolved by either rewriting to avoid the need for any terminology, or by using other terminology:
    “textual annotation” when the word is in curly brackets. Note that the BNF convention is to specify terminal
    symbols using single quotes; we should do the same in the specification text.
    (7) can be resolved as suggested.
    There are several words listed in the table in Annex C that are not keywords. Especially, compartment
    headers are not keywords (as they do not appear in guillemets) and should be removed from the table. This
    is a change from earlier versions of UML which were unclear and inconsistent about compartment naming.
    The notation placement “between braces” is contradictory with “Keywords are always enclosed in guillemets”.
    There are several related issues that can be merged with this one: 18113 is covered by 2. 18114 points out
    that «create»is a keyword as well as a standard stereotype. In fact «create»is not introduced anywhere in
    the spec as a keyword, and its definition as given in Annex C does not make sense because it cannot be
    represented in the abstract syntax. So the keyword can be deleted from the table. 11683 is rendered obsolete
    by the fact that

    {abstract}

    is correctly no longer described as a keyword.
    9125 is resolved by the points above.
    15756 is resolved by (1).
    15419 is resolved in the same way as 18114.
    Note also that issue 18112 removes all standard stereotypes from Annex C, so they are no longer defined as
    keywords.
    The resolution also corrects miscellaneous errors in Table C.1.

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

InformationFlow::sources_and_target_kind

  • Key: UML25-487
  • Legacy Issue Number: 18415
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The OCL doesn't match the description - no check is made of the
    InstanceSpecification classifier. (This constraint could probably
    be split in two and the type test separated as an operation.)

  • Reported: UML 2.5b1 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Note this change resolves both issues 18415 (which corrects the OCL) and 18690 (which adds Behaviors to
    the list of allowed types). The latter is merged with 18415 since both affect the same text allowing for a less
    confusing statement of their combined resolutions.
    In contrast to the 18415 issue summary, the OCL does check for InstanceSpecification, but it doesn’t not
    do so completely. The check that a source or target that is an InstanceSpecification is not a link is missing.
    These checks are added in the update OCL below.

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

UML2.5 issue: clause 7.7.5 does not correctly refer to Instantiate stereotype

  • Key: UML25-494
  • Legacy Issue Number: 18450
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In 7.7.5 «instantiate» is described and lower-cased as though it were a keyword. It sort of implies that Instantiate is a subclass of Dependency.

    In fact «Instantiate» is a standard stereotype. It should be referred to using upper case, and the text should explain that it is a standard stereotype applied to a Usage. The figure and caption will need changing.

    (Note: this example is also the topic of issue 17804, which is a separate matter about the direction of the arrow.)

  • Reported: UML 2.5b1 — Wed, 13 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

UML 2.5 - clause 14 does not put Examples at the correct heading level

  • Key: UML25-493
  • Legacy Issue Number: 18448
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    All the other clauses have Examples at the same level as Notation, Semantics etc. Clause 14 does not do this.

    14.3.4 defines the notation

    {final}

    in the Examples section: notation should be defined in the Notation section and exemplified in the Examples section.

  • Reported: UML 2.5b1 — Wed, 13 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 12380

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

Table C.1 apply

  • Key: UML25-489
  • Legacy Issue Number: 18417
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The semantics of apply refer to 'importedProfile'. There is no
    such property. I'm not entirely sure why there's any OCL at all
    as the keyword is just used with the ProfileApplication diagram
    edge itself.

  • Reported: UML 2.5b1 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18124

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

Metaclass operations incomplete

  • Key: UML25-488
  • Legacy Issue Number: 18416
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The operations listed for each metaclass should give the uniqueness
    and ordering of all their parameters, including return type. For
    example, NamedElement::getAllNamespaces() is actually ordered. In
    addition, operation redefinitions should be given, for example,
    Package::mustBeOwned().

  • Reported: UML 2.5b1 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Enhance the generator to produce annotations such as ordered, nonunique for all operation parameters and
    results with non-default values for isOrdered and isUnique in the generated Classifier Descriptions.
    Enhance the generator to produce annotations such as redefines op() for all operation redefinitions in the
    generated Classifier Descriptions.

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

UML2.5 issue: clause 10 Signal and Reception

  • Key: UML25-492
  • Legacy Issue Number: 18444
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The sentence in 10.3.3 “The receiving object handles Signals as specified by its Receptions” should read “The receiving object handles Signals as specified by clause 13.3”. The current sentence seems to imply that a Reception is needed to receive a Signal which is actually not the case,

  • Reported: UML 2.5b1 — Tue, 12 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    do as proposed

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

Conflict in use of unlimited natural

  • Key: UML25-491
  • Legacy Issue Number: 18442
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Section 7.3.32 states in its Notation subsection that an asterisk denotes "unlimited (and not infinity)". Section 7.3.33 states that an asterisk represents "the unlimited (or infinite) upper bound". That one is infinite and the other not seems a contradiction

  • Reported: UML 2.4.1 — Mon, 11 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18096

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

UML 2.5: ActivityPartition::represents keywords

  • Key: UML25-495
  • Legacy Issue Number: 18452
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The keywords «attribute» and «class» are part of the notation for ActivityPartition (examples in 15.70 and 15.72) but are not specified in the notation and should be. They do appear in Annex C.

  • Reported: UML 2.5b1 — Wed, 13 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The notation used in the example diagrams in Figures 15.70 and 15.72 is not consistent with the notation
    as specified in Subclause 15.6.4, which defines no such keywords. The figures also use underlining of
    ActivityPartition names, which is not specified, either.

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

UML 2.5 FTF - Clause 17 Interactions, Section 17.2.3 Semantics, subsection Interaction

  • Key: UML25-490
  • Legacy Issue Number: 18419
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    First sentence of fourth paragraph says:

    The invalid set of traces is associated only with the use of a Negative CombinedInteraction.

    But it ought to say:

    The invalid set of traces is associated only with the use of a Negative CombinedFragment.

  • Reported: UML 2.5b1 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Apply the solution proposed in the issue’s summary.

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

Classifier::hasVisibilityOf(...)

  • Key: UML25-486
  • Legacy Issue Number: 18414
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Classifier::hasVisibilityOf(...)
    The description doesn't match the OCL.

  • Reported: UML 2.5b1 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18177

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

Two entries

  • Key: UML25-485
  • Legacy Issue Number: 18408
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    UML 2.4.1 and UML 2.5 beta1 specs incorrectly show TWO entry behaviors on state, when only one is allowed in metamodel.
    Figure 14.5 State with compartments

  • Reported: UML 2.5b1 — Mon, 4 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 16111

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

About UseCase description

  • Key: UML25-519
  • Legacy Issue Number: 18726
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The description of a UseCase is: “A UseCase specifies a set of actions performed by its subject, which yields an observable result that is of value for one or more Actors or other stakeholders of the subject.”.

    However, UseCase may have no subjects. What happen in that case?

  • Reported: UML 2.5b1 — Tue, 21 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clause 18 is inconsistent in using “subject” in the singular in many places. Clarify that a UseCase may refer
    to many subjects or none.

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

Annex B summary table

  • Key: UML25-518
  • Legacy Issue Number: 18717
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    It would probably help implementers of Annex B if it had something like the tables in BPMN's DI that show example graphics, the metaclasses involved, and some notes on how they're used, see the BPMN spec (http://www.omg.org/spec/BPMN/2.0/PDF), starting at Table 12.8 (Depiction Resolution for Loop Compensation Marker) in Section 12.3 (Notational Depiction Library and Abstract Element Resolutions).

  • Reported: UML 2.5b1 — Wed, 15 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue is addressed by adding a table to the end of Annex B. This table shows example UML notations,
    and how they are represented in DI. The table refers the clauses and their figures, as well as Annex B clauses.

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

actors of a use case express the requirements of its subject(s) regarding its/their environment.

  • Key: UML25-529
  • Legacy Issue Number: 18760
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Quoted from §18.1.3, p686: “An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging
    signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an
    associated UseCase. Actors may represent roles played by human users, external hardware, or other systems.”

    There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about “actor’s needs/requirements” in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment.

  • Reported: UML 2.5b1 — Thu, 6 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Delete the contentious sentence (not actually mentioned in the issue, but the earlier sentence in 18.1.1 which
    talks about the “needs” of Actors) which adds no value to the spec.

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

UML: Parameter Direction and Effect

  • Key: UML25-528
  • Legacy Issue Number: 18759
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The rules on Parameter Direction and Effect, seem overly weak.

    It doesn't seem to make sense to have a formal "inout" to also have the formal effect "delete", because it would be clearer to say "in"

    It doesn't seem to make sense to a formal "inout" to also have the formal effect "create", because it would be clearer to say "out"

    And Conrad says:
    Seems like we could change the modeling constraints to prevent inouts for create and delete, if we didn't mind the backward incompatibility.

    But Ed Seidewitz says
    The object passed out in on inout parameter doesn't have to be the same one that was passed in.

    For a "create" effect, the text says "Objects passed out of executions of the behavior as values of the parameter do not exist before those executions start." It doesn't say anything about objects passed in. Therefore, you could pass a non-null value into an inout parameter with the "create" effect, as long as the object passed out is a different, new object.

    The wording for "delete" is a little less clear, but I think it is reasonable to assume that it means that the object passed in on an inout parameter is destroyed, but that some other object could be passed out.

    Indeed, conceptually, an inout parameter could conceptually be both "delete" AND "create", meaning you pass in an object that gets destroyed and then get out a newly created object. However, the abstract syntax only allows at most one effect on a parameter

    So, we have at least different suggestions for changes to this material.

  • Reported: UML 2.5b1 — Wed, 5 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17891

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

UML 2.5 Issue: specification for qualified association ends is in wrong clause

  • Key: UML25-523
  • Legacy Issue Number: 18750
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The specification and examples for qualified association ends is currently in clause 9 but really ought to be in clause 11, where it should take into account the specification of multiplicity for association ends marked as unique.

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Move the text fragments to the right place. The comment about unique ends has already been taken into
    account in 11.5.3.

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

UML 2.5 class_name

  • Key: UML25-522
  • Legacy Issue Number: 18748
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    In section 17.3.4 <class_name> appears on the right hand side of the BNF but it is not defined in any other BNF statement. This is the only place in the spec where <class_name> appears. <class-name> appears in the text following the BNF. <class_name> in the BNF should be changed to <class-name>.

    Recommend that we add the following statement to the BNF

    <class-name>::=<Variable> | <Parameter> | <Property>

  • Reported: UML 2.5b1 — Mon, 3 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The Interactions working group agreed during the Berlin meeting that class_name is not optimal. In fact,
    the non-terminal symbol class_name does not reflect what it actually represents, i.e., the name of the Type
    that the ConnectableElement, which is represented by the Lifeline, is typed with.
    In addition, the font style of the non-terminal symbols has to be set to italics.

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

Event pools for passive objects

  • Key: UML25-526
  • Legacy Issue Number: 18754
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There does not seem to be any constraint that prevents a passive object from owning an event pool. Perhaps this is by design, but, if so, it is not clear how such an event pool is serviced. It looks like this should be clarified or perhaps a constraint preventing passive objects from having event pools should be introduced.

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Currently, the only constraint related to Class:isActive is the passive_class constraint that “Only an active Class may
    own Receptions and have a classifierBehavior.” This means that a passive class may still have ownedBehaviors (including
    methods of operations), and these may service the event pool of instances of the class. (Note also that a passive
    object may receive Signal instances into its event pool, even though its Class does not have receptions.)
    Disposition: Closed - No Change

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

Behavior after exceptions are encountered

  • Key: UML25-525
  • Legacy Issue Number: 18753
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the discussion of OpaqueBehaviors in caluse 13, it is mentioned that a Behavior may be "abandoned" after it has raised an exception. The semantics of "abandonment" following exceptions are not defined, except (it seems) for the specific case of ExecutableNodes in activities.

    So, is there something general that we can say in Common Behaviors about the state of a Behavior after it has encountered an exception? For example, in case of a state machine: is it meaningful for the state machine to handle an exception event after it has encountered an exception? (if so, what state is it in following an exception?)

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue is referencing the following sentence in Subclause 13.2.3: “A FunctionBehavior may raise exceptions
    for certain input values, in which case the computation is abandoned.” It is rather odd to only mention
    exceptions in the specific case of FunctionBehaviors, since exceptions can potentially be raised by any kind
    of Behavior. This would be better explained more generally.

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

UseCases editorial change

  • Key: UML25-521
  • Legacy Issue Number: 18730
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In the sentence “The individual fragments are executed as the corresponding ExtensionPoints of the extending UseCase are reached”, “extending” should read “extended”.

  • Reported: UML 2.5b1 — Thu, 23 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    indeed it should

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

The current criteria used in UML for BehavioralFeature::isDistinguishable() is insufficient in practice

  • Key: UML25-520
  • Legacy Issue Number: 18727
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The current criteria only looks at the ordered collection of owned parameter types as a key for distinguishing behavioral features.
    For example, it means that, for UML, the following pairs of operations of the same name are not distinguishable:

    // difference in the parameter direction
    op1(String)
    op1():String

    // difference in the parameter effect
    op2(update String)
    op2(delete String)

    // difference in the parameter exception
    op3(Throwable)
    op3() throws Throwable

    // difference in the parameter collection characteristics
    op4(Set(String))
    op4(String[1])

    This means that UML is not able to represent some well-known programming languages where the above characteristics contribute to the signature of distinguishable operations (e.g., C, C++, Java, C#, …)

    This can be easily fixed.

    In the OCL for BehavioralFeature::isDistinguishableFrom(), replace:

    ...>isUnique(ownedParameter>collect(type))

    With:

    …>isUnique(ownedParameter>collect(p|Tuple

    {name=p.name, type=p.type,effect=p.effect,direction=p.direction,isException=p.isException,isStream=p.isStream,isOrdered=p.isOrdered,isUnique=p.isUnique,lower=p.lower,upper=p.upper}

    ))

    Since BehavioralFeature::ownedParameter is an ordered collection, the current definition constructs an ordered collection of the owned parameter types as a key for distinguishing BehavioralFeatures.

  • Reported: UML 2.5b1 — Wed, 22 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Clarify that stereotypes can be applied to UML DI

  • Key: UML25-517
  • Legacy Issue Number: 18715
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [From Ed S in http://www.omg.org/archives/uml25-ftf/msg00357.html] Perhaps we can clarify this by simply adding some text to Annex B explicitly saying that stereotypes can be applied to UML DI elements and that a conforming tool is to interpret such stereotype application per 12.3.3 – that is, with the MOF equivalent semantics and XMI serialization. This would simply become part of the requirement for UML diagram interchange conformance. It seems like a useful capability to me.

  • Reported: UML 2.5b1 — Tue, 14 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    clarify as suggested

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

UML2.5 clause 17 keyword inconsistency

  • Key: UML25-516
  • Legacy Issue Number: 18702
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The notation for ConsiderIgnoreFragment incorrectly refers to ‘consider’ and ‘ignore’ as keywords. These should be fixed in a similar manner to issue 18454.

  • Reported: UML 2.5b1 — Wed, 8 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Completion events disambiguation

  • Key: UML25-524
  • Legacy Issue Number: 18752
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Section 13.2.3 (Behaviors) refers to a "completion event" for Behaviors as does the StateMachines section. It appears that these are different two concepts that share the same name; the former seems to represent the termination of a Behavior whereas the latter specifies completion of one or more behaviors associated with a State (possibly one with multiple Regions). To avoid confusion between the two concepts, it would be useful to provide a clear specification of what is meant by a "completion event" in the CommonBehaviors semantics description. Also, it might be useful to choose a different name for this type of completion event to avoid confusion with the one in state machines (that particular term has been around since the original version of UML, so changing it would probably be more confusing).

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

UML 2.5: Clarification of semantics for CreateLinkAction and DestroyLinkAction

  • Key: UML25-527
  • Legacy Issue Number: 18756
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Semantics for DestroyLinkAction, and possibly CreateLinkAction, need clarification for the case of hybrid associations, i.e. associations which mix unique and non-unique ends. For example, what does DestroyLinkAction do for the case of a unique end where one or more other ends are non-unique and there is more than one outgoing link for the same value at the unique end?

  • Reported: UML 2.5b1 — Wed, 5 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 9013

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

UML 2.5 FTF Receptions may not have a method

  • Key: UML25-530
  • Legacy Issue Number: 18777
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    According to the semantics of reception it seems that there should be a constraint implying that no method is specified for a reception.

    context Reception
    inv: self.method->isEmpty()

    What do you think?

  • Reported: UML 2.5b1 — Wed, 12 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Or Pre-conditions appears limiting

  • Key: UML25-414
  • Legacy Issue Number: 18049
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “The behaviors of a UseCase can be described by a set of Behaviors (through its ownedBehavior relationship), such as Interactions, Activities, and StateMachines, or by pre-conditions and post-conditions...”

    [AC] The “or” in “ or by pre-conditions and post-conditions” is ambiguous, because it can be interpreted as an XOR, while it is not exclusive. In fact, but several lines below, it is correctly stated that “These descriptions can be combined”. I suggest to remove the “or”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Clarification meaning of not part of the subject

  • Key: UML25-417
  • Legacy Issue Number: 18053
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. “

    [AC] In my opinion, this is ambiguous, and could be replaced with “in the sense that, in a specific modeling context, an instance of the Actor is not a part of the instance of the subject of an associated UseCase”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The offending sentence is unclear, and the concept of “external” is vague and dubious. Better clarity can be
    achieved by removing it altogether.

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

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Point to Figures to help explain subject vs owner

  • Key: UML25-416
  • Legacy Issue Number: 18051
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Although the owning Classifier typically represents the subject to which the owned UseCases apply, this is not necessarily the case.”

    [AC] I would add: “as is shown in Figures 18.10 and 18.11”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Initiating ? Interacting with

  • Key: UML25-415
  • Legacy Issue Number: 18050
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “When a UseCase has an association to an Actor with a multiplicity that is greater than one at the Actor end, it means that more than one Actor instance is involved in initiating the UseCase.”

    [AC] I would delete the term “initiating”, because it is wrong. Not only [may] a use case may be time-triggered, but the multiplicity may be >1 even if an instance of actor initiates the use case, then another instance is involved.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

18.1.3 Semantics Use Case and Actors Extends P. 687 - Omitted conditions are true

  • Key: UML25-420
  • Legacy Issue Number: 18058
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    current text: ”If the condition of the Extend is true at the time the first ExtensionPoint is reached during the execution…

    As it is unclear whether an omitted condition is true, clarify the situation by explicitly handing it. Replace the start of this paragraph with "If the condition of the Extend is missing or evaluates to true at the time the first ExtensionPoint is reached during the execution…”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the proposal.

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

18.1.3 Semantics Use Case and Actors Extends P. 687 - Easy

  • Key: UML25-419
  • Legacy Issue Number: 18057
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Therefore, it is not easy to capture its structure accurately or generally by a formal model.”

    [AC] I would say “it is not possible”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Delete the whole sentence, which adds no value to what can be deduced from the preceding sentence

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

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Additional behavior vs Additional use case

  • Key: UML25-418
  • Legacy Issue Number: 18055
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Extend is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in a UseCase.”

    [AC] According to the metamodel, if I'm not wrong, this should be “in one or more UseCases”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Location: 18.1.4 Notation P. 688 - Point to diagram

  • Key: UML25-422
  • Legacy Issue Number: 18063
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “The subject for a set of UseCases (sometimes called a system boundary) may be shown as a rectangle with its name (and associated keywords and stereotypes) in the top-left corner, with the UseCase ellipses visually located inside this rectangle.”
    [
    AC] I would add at the end “as shown in figure 18-2”.

    General note: the numeric ordering of figures should be aligned with the sequence in which they are referenced in the text.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the proposal in the first paragraph of the issue, using text to clarify that the figure is an example, and
    explain what kind of subject is shown in the example.
    The numeric ordering of figures is by editorial policy the order in which they appear, and that will not be
    changed regardless of how they are referenced

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

18.1.3 Semantics Use Case and Actors Extends P. 687 - Clarify role of owner

  • Key: UML25-421
  • Legacy Issue Number: 18061
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Include is a DirectedRelationship between two UseCases, indicating that the behavior of the included UseCase (the addition) is inserted into the behavior of the including UseCase (the includingCase). It is also a kind of NamedElement so that it can have a name in the context of its owning UseCase.”

    [AC] I would add at the end “(the includingCase)”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    accept the proposal

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

State Machine Package--Compliance

  • Key: UML25-574
  • Legacy Issue Number: 7555
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    Please accept the following as an Issue for the UML 2 FTF.

    State Machine Package--Compliance

    Compliance with the state machine package is too onerous for
    many vendors.

    There is no need-for many of us-to include choice points, entry
    points, and other elements.

    An suggested layering would consist of:
    Layer 1: Initial pseudo states, states, final states, events, transitions.
    Layer 2: Stuff required to support hierarchy
    Layer 3: Stuff required to support orthogonal regions.
    Layer 4: All the rest.

  • Reported: RAS 2.0b1 — Thu, 1 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

Actions need to be independent from Activities

  • Key: UML25-573
  • Legacy Issue Number: 7552
  • Status: closed  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    If we take Activity as fundamental, and consider that we can't specify something that happens with Action alone, shouldn't we remove the first sentence of the second paragraph of 11 Actions : 11.1 Overview : Basic Concepts:

    "An action is the fundamental unit of behavior specification."

  • Reported: RAS 2.0b1 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    An action is fundamental in that the behavior of an Activity is built up from Actions. An Activity does
    not have any behavior on its own. Actions can also be used to specify behavior within the context of an
    Interaction.
    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

Composite structures/contradictory constraint on connector

  • Key: UML25-566
  • Legacy Issue Number: 7431
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    We read as a constraint for connector (composite structure)

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

    And Commponents::Connector provides the following constraint:
    [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.

    Both are in contradiction.

    Proposed correction:

    Ditch CompositeStructure::Connector constraint [2]

  • Reported: RAS 2.0b1 — Wed, 2 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

UML 2 Super/Interfaces

  • Key: UML25-568
  • Legacy Issue Number: 7441
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02 Figure 63 - firstly there ar a couple of typoes. The interface
    stereotype on IAlarm is missing <<, and sensor should be ISensor. More
    serious are the implications of the caption - "IAlarm is the required
    interface for any classifier implementing Isensor;
    conversely, Isensor is the required interface for any classifier
    implementing
    IAlarm."

    To me the caption sounds wrong but at the very least more explanation is
    needed. Firstly, does having the association to the interface imply that a
    usage dependency is required to ISensor from any class that implements
    IAlarm? If so a constraint is needed to enforce that. Secondly, isn't such a
    usage dependency redundant, given that its existence is implied from the
    presence of the association?

  • Reported: RAS 2.0b1 — 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

Issue in UML 2 CombinedFragment class

  • Key: UML25-571
  • Legacy Issue Number: 7450
  • Status: closed  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    It is not possible to represent atomic message sending

  • Reported: RAS 2.0b1 — Wed, 9 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

Issue in UML 2 Message class

  • Key: UML25-570
  • Legacy Issue Number: 7449
  • Status: closed  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    It is possible that the sendEvent and the ReceiveEvent are on the same Lifeline but it is not possible to specify whether the sender will receive a copy of the Message.

  • Reported: RAS 2.0b1 — Wed, 9 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

Issue in UML 2 Message class

  • Key: UML25-569
  • Legacy Issue Number: 7448
  • Status: closed  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    The signature of the Message class is said to be of type NamedElement but such class allows for instance to write the qualifiedName and the visibility (see p. 11) and we do not know exactly what these two features offer here.

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    UML 2.5 message notation was clarified considerably.
    Disposition: Closed - No Change

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

Issue in UML 2 Gate class

  • Key: UML25-572
  • Legacy Issue Number: 7452
  • Status: closed  
  • Source: Independent ( Marc-Philippe Huget)
  • Summary:

    It is not possible to write which InteractionFragment is addressed with a formal Gate

  • Reported: RAS 2.0b1 — Wed, 9 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    Already addressed by clarification of gate matching rules in UML 2.5
    Disposition: Closed - No Change

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

Interactions needs to fix Gate name Distinguishability rules

  • Key: UML25-503
  • Legacy Issue Number: 18528
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The isDistingishableFrom() operation of NamedElement needs to be
    overridden for Gate class to cover the case of when the gate is used as
    a formalGate of an Interaction. The association end formalGate subsets
    ownedElement, and since the Gate name attribute is optional, it is
    allowed to have two formal gates without an explicit name, but having
    derived names which are distinct.

    Even though the gate matching rules do not use this operation, we need
    to override it to avoid problems.

    In addition to this fix, there is a also need to add constraints to the
    gate names used for Gates for the gate matching rules to work properly.
    In particular, there are cases in use of gates which require distinction
    for the gate matching rules to work.

    Thus there is still a need to add new constraints on gate Names (explicit
    or derived).

    Because Gates which do not have an explicity name attribute have derived
    names, any constraint must include the possibility of these derived
    names.

    There is an explicit operation getGateName() on Gate class which returns
    the name of the gate which is to be used in the gate matching rules. If
    a gate does not have an explicit name attribute, a gate name is derived
    from the name of the message the gate is attached to , and the direction
    of the message with respect to the gate (e.g, foo_in, foo_out). The
    direction "in" or "out" is considered with respect to the outer perimeter
    of the interaction fragment that the gate is attached to.

    UML 2.5 added Gate matching rules in OCL, using this getGateName()
    operation, however there are currently no gate name distinguishably
    constraints in the spec. Two gates in the same container may have
    duplicate derived names, just because they are attached to two different
    messages, with the same direction, which happen to have the same name.
    There are cases when the gate matching rules will not work unless at
    least one of these gates needs includes an explicit name attribute value
    contrived to avoid the collision of the getGateNames() operation.

    The association end formalGates of Interaction subset ownedMember, and,
    as already stated above, we have to override the isDistinguisableFrom()
    operator for gate class. However, If there were two formal Gates with
    the same gate name in an interaction, the gate matching rules would
    become invalid.

    The association ends actualGates of InteractionUse, and cFragmentGates
    of CombinedFragment, both subset ownedElement, not ownedMember. So they
    no not need to obey the isDistinguisableFrom test. However, even though
    not required for the UML namespace Rules, actual Gates for an
    InteractionUse should have distinguishable gate names, in order for the
    gate matching rules to work.

    For the same reason, If a cFragmentGate is outside the CombinedFragment,
    then it must be distinguishable from other outer cFragmentGates of that
    same CombinedFragment.

    For the same reason, any two inner cFragmentGates associated with the
    same InteractionOperator of a CombinedFragment must have distinguished
    gate names.

    Thus we need to add a set of four constraints (one for each kind of gate)
    to the Gate class. Adding these four constraints will ensure that the
    gate matching rules work correctly.

    Proposed Change:

    Override the isDistinguishableFrom() operation of Gate to always return
    true.

    Add the following four new constraints to the Gate class. These rely on
    the four existing boolean operators of the Gate class which are used to
    determine in which of the four contexts of association that the gate is
    an instance of.

    formal_gate_distinguishable
    isFormal() implies <test that no other formal
    gate of the parent Interaction returns the same getGateName() as returned
    for self>

    actual_gate_distinguishable
    isActual() implies <test that no other actual
    gate of the parent InteractionUse returns the same getGateName() as
    returned for self>

    outside_cf_gate_distinguishable
    isOutsideCF() implies <test that no other
    outside cf gate of the parent CombinedFragment returns the same
    getGateName() as returned for self>

    inside_cf_gate_distinguishable
    isInsideCF() implies <test that no other
    inside cf gate attached to a message with its other end in the same
    InteractionOperator as self returns the same getGateName() as returned
    for self>

    I leave the detailed OCL for the actual OCL to include within the < >
    for the actual resolution of this issue.

  • Reported: UML 2.5b1 — Tue, 5 Mar 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Override the isDistinguishableFrom() operation of Gate to always return true.
    Fix a problem in the isInnerCF operation, to fix the other End Gate situation.
    Add the following four new constraints to the Gate class. These rely on the four existing boolean operators
    of the Gate class which are used to determine in which of the four contexts of association that the gate is an
    instance of.
    formal_gate_distinguishable isFormal() implies <test that no other formal gate of the parent Interaction
    returns the same getGateName() as returned for self>
    actual_gate_distinguishable isActual() implies <test that no other actual gate of the parent InteractionUse
    returns the same getGateName() as returned for self>
    outside_cf_gate_distinguishable isOutsideCF() implies <test that no other outside cf gate of the parent CombinedFragment
    returns the same getGateName() as returned for self>
    inside_cf_gate_distinguishable isInsideCF() implies <test that no other inside cf gate attached to a message
    with its other end in the same InteractionOperator as self returns the same getGateName() as returned for
    self>

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

ActionInputPin notations missing

  • Key: UML25-502
  • Legacy Issue Number: 18507
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    UML 2.4.1, in the activity notation for ActionInputPin (as specialized) (Clause 12.3.3), says:

    "An action input pin with a ReadVariableAction as a fromAction is notated as an input pin with the variable name written beside it. An action input pin with a ReadSelfObject as a fromAction is notated as an input pin with the word “self” written beside it. An action input pin with a ValueSpecification as a fromAction is notated as an input pin with the value specification written beside it."

    The above seems to be missing from 2.5's notation section for ActionInputPin (Clause 16.2.4), though it is covered in Annex B (Clause B.4.3, Activity Diagram Labels), search on "ActionInputPin".

    Would also be good to include figures in the notation section for ActionInputPin (Clause 16.2.4), similar to Figure 16.38 (Presentation option for AddVariableValueAction).

  • Reported: UML 2.5b1 — Wed, 27 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Dropping the description of this notation was unintentional

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

UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole

  • Key: UML25-515
  • Legacy Issue Number: 18699
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In UML 2.5 section 11.7.3 Collaboration Semantics says:

    Collaborations may be specialized from other Collaborations. If a role is extended in the specialization, its type in the specialized Collaboration must conform to its type in the general Collaboration. The specialization of the types of the roles does not imply corresponding specialization of the Classifiers that realize those roles. It is sufficient that they conform to the constraints defined by those roles.

    A specialized Collaboration can redefine some roles of its parent Collaborations but it should be possible to reuse them without redefining them.
    Unfortunately, this is not possible:

    Collaboration::collaborationRole subsets StructuredClassifier::/role, which is a derived union subsetted only by StructuredClassifier::ownedAttribute.

    That is, the inherited roles of a parent Collaboration are not roles of its specializing Collaborations.

    Currently, Collaboration::collaborationRole : ConnectableElement[*] subsets StructuredClassifier::role.
    That is, it is up to the discretion of the modeler to decide which subset of a Collaboration's roles are to be the Collaboration's collaborationRoles as well.

    It seems that the subset constraint is too strong; that is, it seems it should be relaxed such that a modeler could pick a subset of a Collaboration's roles and Collaboration's inherited roles as its collaborationRoles.
    That is, I suggest replacing:

    Collaboration::collaborationRole : ConnectableElement[*]

    {subsets StructuredClassifier::role}

    with:

    Collaboration::collaborationRole : ConnectableElement[*]

    { subsets Classifier::inheritedMember}

  • Reported: UML 2.5b1 — Tue, 7 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue is based on a misunderstanding. In fact the modeler chooses some ConnectableElements to be collaborationRoles,
    and /role is derived from that.
    Disposition: Closed - No Change

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

UML2.5's Connector role constraint excludes inherited roles

  • Key: UML25-514
  • Legacy Issue Number: 18697
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    UML 2.5, section 11.8 provides an OCL encoding of the following role constraint on a Connector:

    [3] The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be roles of the Classifier
    that owned the Connector, or they must be ports of such roles.

    inv: structuredClassifier <> null
    and
    end->forAll( e |
    structuredClassifier.role->includes(e.role)
    or
    e.role.oclIsKindOf(Port) and structuredClassifier.role->includes(e.partWithPort))

    Inherited roles are excluded because StructuredClassifier::/role is a derived union that is subsetted only once by StructuredClassifier::ownedAttribute

    In 17.7.3, Collaboration Semantics, the UML spec uses the term 'role' in a way that clearly suggests a broader intent than a subset of owned attributes:

    Neither all Features nor all contents of the participating instances nor all links between these instances are always required in a particular Collaboration. Therefore, a Collaboration is often defined in terms of roles typed by Interfaces.

    Collaborations may be specialized from other Collaborations. If a role is extended in the specialization, its type in the specialized Collaboration must conform to its type in the general Collaboration. The specialization of the types of the roles does not imply corresponding specialization of the Classifiers that realize those roles. It is sufficient that they conform to the constraints defined by those roles.

    In 17.7.3 CollaborationUses semantics, the UML spec uses the term 'role' in a way that could not legitimately restricted to a subset of owned attributes but instead include inherited attributes:

    The roleBindings are implemented using Dependencies owned by the CollaborationUse. Each role in the Collaboration is bound by a distinct Dependency and is its supplier. The client of the Dependency is a ConnectableElement that relates in some way to the context Classifier: it may be a direct role of the context Classifier, or an element reachable by some set of references from the context Classifier. These roleBindings indicate which ConnectableElement from the context Classifier plays which role in the Collaboration.

    One of the CollaborationUses owned by a Classifier may be singled out as representing the Behavior of the Classifier as a whole. This is called the Classifier’s representation. The Collaboration that is related to the Classifier by its representation shows how the instances corresponding to the StructuralFeatures of this Classifier (e.g., its attributes and parts) interact to generate the overall Behavior of the Classifier. The representing Collaboration may be used to provide a description of the Behavior of the Classifier at a different level of abstraction than is offered by the internal structure of the Classifier. The Properties of the Classifier are mapped to roles in the Collaboration by the role bindings of the CollaborationUse.

    I suggest replacing the term 'role' in chapter 11 and 17 with 'all roles' or 'owned an inherited roles' where applicable.

    I also suggest introducing a query:

    StructuredClassifier::allRoles() : ConnectableElement[*]
    body: allFeatures()>select(oclAsKind(ConnectableElement))>collect(oclAsType(ConnectableElement))->asSet()

    Then the roles constraint on Connector in 11.8 should read:

    [3] The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be owned or inherited roles of the Classifier
    that owned the Connector, or they must be ports of such roles.

    inv: structuredClassifier <> null
    and
    end->forAll( e |
    structuredClassifier.allRoles()->includes(e.role)
    or
    e.role.oclIsKindOf(Port) and structuredClassifier.allRoles()->includes(e.partWithPort))

  • Reported: UML 2.5b1 — Tue, 7 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the suggestions in the issue. For the Collaborations clause, avoid using “role” at all and use “collaborationRole”
    instead, which is defined for that purpose.
    This also resolves 7416.

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

Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature

  • Key: UML25-505
  • Legacy Issue Number: 18545
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature. This is not sufficient, since a Signal may specialize other signals and, thus, the Message should also allow to specify arguments for inherited attributes. Of course, redefined attributes need to be sorted out.

  • Reported: UML 2.5b1 — Wed, 13 Mar 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Instead of using the Signal.ownedAttributes directly in the OCL (let signalAttributes : OrderedSet(Property)
    = signature.oclAsType(Signal).ownedAttribute->asOrderedSet()) the inherited operation
    Classifier::inheritedMember():NamedElement[0..*] ought to be used in the let-statement. The operation
    filters redefined inherited elements and delivers the complete set of all inherited members, including the
    properties. These need to be extracted from the set of inherited members eventually. The resulting OCL
    would look like this:
    let signalAttributes : OrderedSet(Property) =
    signature.oclAsType(Signal).inheritedMember()->
    select(n:NamedElement | n.oclIsTypeOf(Property)->asOrderedSet()

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

Classifier operation inherit(NamedElement[*]) : NamedElement[*]

  • Key: UML25-504
  • Legacy Issue Number: 18544
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    Classifier operation inherit(NamedElement[*]) : NamedElement[*] needs to be overridden for Signal, Interface, Enumeration, Component, Association

  • Reported: UML 2.5b1 — Wed, 13 Mar 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The definition in Classifier can handle redefinition for all of them, without need for any overriding

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

Forked association notation ill-formed

  • Key: UML25-511
  • Legacy Issue Number: 18684
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Description: Figure 11.34 (Composite aggregation sharing a source segment) shows three association lines sharing one end (window), implying the end is owned by three classes, which isn't possible. Even if the three classes redefine window using the same name, the "shared" end would actually be separate elements in the model, though they would appear notationally the same. If this is the intention, redefinition of window should be added to the figure, and the text should explain that the "shared" graphical elements refer to three underlying model elements, (Annex B should be updated also). The notation wasn't in 2.4.1 that I can find.

  • Reported: UML 2.5b1 — Wed, 24 Apr 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The notation was in 2.4.1 and all earlier versions of UML. Quoting from UML 1.1 spec: “If there are two
    or more aggregations to the same aggregate, they may be drawn as a tree by merging the aggregation ends
    into a single segment. This requires that all of the adornments on the aggregation ends be consistent. This
    is purely a presentation option; there are no additional semantics to it”. From UML 2.4.1: “If there are two
    or more aggregations to the same aggregate, they may be drawn as a tree by merging the aggregation ends
    into a single segment. Any adornments on that single segment apply to all of the aggregation ends.”
    Some clarification is in order, both with regard to this particular notation, and with regard to the general
    question of what adornments may be suppressed in the notation for an Association. In particular, there is
    a misleading note about the default values for uniqueness and ordering that implies that the absence of a
    prop-modifier on the diagram has a semantic consequence; whereas in fact it is just another adornment that
    may be suppressed.

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

UML 2.5 Beta 1 9.5.3 Qualifiers

  • Key: UML25-501
  • Legacy Issue Number: 18505
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The description of qualifiers in section 9.5.3 is unclear.
    I'm really struggling to understand it. The second paragraph
    in particular seems to unnecessarily divide qualifiers by
    the opposite end multiplicity. (In fact opposite ends, but
    the opposite end is for binary associations only.) I have
    no idea why this hints at implementation issues. Likewise
    why does the note mention tables and indices? It shouldn't
    be a note as it's a constraint on the multiplicity given
    the qualifier values.

    Here is an alternative explanation to replace all three
    paragraphs:

    A qualified Association end has qualifiers that partition
    the instances associated with an instance at that end, the
    qualified instance. Each partition is designated by a qualifier
    value, which is a tuple comprising one value for each qualifier.
    The multiplicities at the other ends of the association
    determine the number of instances in each partition. So, for
    example, 0..1 means there is at most one instance per qualifier
    value. If the lower bounds are non-zero, the qualifier values
    must be a finite set, for example, the qualifiers are typed by
    enumerations.

  • Reported: UML 2.5b1 — Tue, 26 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    accept suggestion

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

Transition redefinition

  • Key: UML25-500
  • Legacy Issue Number: 18495
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    A question: For transitions, the spec says:

    “… while the source State and trigger are preserved”

    Maybe related to not being a native speaker, but for me “preserved” means that at least the triggers defined for the extended transition must remain in the redefining transition, whereas new triggers can be added.

    Or does “preserve” mean in this context really to seal the triggers, i.e., I cannot add a new one?!

  • Reported: UML 2.5b1 — Thu, 21 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 6395

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

parts should be allowed to show their interfaces

  • Key: UML25-513
  • Legacy Issue Number: 18695
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification allows ports on parts to also show the interfaces of the type of the port:

    page 202: "Lollipop and socket symbols may optionally be shown to indicate the provided and required interfaces of the Port, using the same notation as for the Port’s definition."

    The same thing is not allowed for parts. While it might be not all that important for parts, it makes the notation incoherent.

    Proposed Resolution:
    Add following sentence:

    "Lollipop and socket symbols may optionally be shown to indicate the provided and required interfaces of the Part, using the same notation as for the Part’s definition."

  • Reported: UML 2.5b1 — Fri, 3 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue is correct, and it is indeed inconsistent not to permit this option

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

Behavior is not allowed to be source or target of an InformationFlow

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

    The InformationFlow element has an additional constraint that only allows a few classifiers to be source and target of an information flow. I don’t know why an Activity ­ or more general a Behavior ­ is not allowed to be a source or target of an information flow.

    I propose to allow Behavior source/target of an InformationFlow.

  • Reported: UML 2.4.1 — Tue, 30 Apr 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Seems like a reasonable request. Although not truly a duplicate of issue 18415, we merge this issue with 18415
    because both issues affect the same OCL constraint. It will be less confusing to construct a reply to both problems in
    one place.
    Disposition: Merged with 18415

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

UML 2.5 FTF] Editorial / §15.5.1 p429

  • Key: UML25-510
  • Legacy Issue Number: 18677
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    I don’t know whether this has already been raised or corrected

    In §15.5.1 “Summary”, p429. The second sentence starts with: “Generally, tThe ControlNodes […]” => the double “t” has to be removed.

  • Reported: UML 2.5b1 — Tue, 16 Apr 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This has already been corrected.
    Disposition: Closed - No Change

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

Inheriting Connectors

  • Key: UML25-509
  • Legacy Issue Number: 18650
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should?

    If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model.

    See diagram attached

  • Reported: UML 2.5b1 — Wed, 10 Apr 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There are two aspects to this issue. Firstly, it needs to be made clearer that redefinition causes the redefining
    feature to stand in for the redefined feature in all uses of the redefined feature, including referring to it. This
    applies in many circumstances including connectors, transitions and activity edges. Secondly, there needs
    to be a well-defined notation for inherited features (such as connectors) so that a diagram can depict an
    inherited connector connecting to a redefined part.
    In the case of provided interfaces there is already a notation using a forward slash. This seems ill-advised
    since forward slash normally means derived. Change this notation to be the caret, and make the forward
    slash a deprecated option.

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

UML 2.5 FTF 14.2.3 Page 327 Typo

  • Key: UML25-507
  • Legacy Issue Number: 18569
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Two examples of AnyReceivEvent rather than AnyReceiveEvent

  • Reported: UML 2.5b1 — Tue, 19 Mar 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Spelling error - Change “AnyReceivEvent” in section 14.2.3 to “AnyReceiveEvent”.

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

Incorrect text on state list notation interchange

  • Key: UML25-506
  • Legacy Issue Number: 18566
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Under Figure 14.12 (Submachine Sate that uses an exit point), there is a NOTE saying the graphical notation for state lists cannot be exchanged normatively, but the interchange model for this given in the paragraph under Figure B.14 (State Shapes), starting at the third sentence.

  • Reported: UML 2.5b1 — Sun, 17 Mar 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    correct the statement cited

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

UML 2.5 FTF 15.3.3 Page 406 decisionInputBehavior rather than decisionInput

  • Key: UML25-508
  • Legacy Issue Number: 18570
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The semantics of DecisionNode consistently uses
    decisionInputBehavior. However the property is
    actually decisionInput. Similarly for the notation
    and the constraint two_input_parameters.

  • Reported: UML 2.5b1 — Tue, 19 Mar 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed that this is incorrect

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

UML 2 Super/Components/missing description of Connector::contract

  • Key: UML25-582
  • Legacy Issue Number: 7622
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The association end Connector::contract, specified in figure 78 on page 135 is not documented in the description for Connector

  • Reported: UML 1.4.2 — Wed, 4 Aug 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 Super/Interactions/notation for accessing a static feature

  • Key: UML25-581
  • Legacy Issue Number: 7621
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Context:

    Invoking static or class methods on classes is incredibly common. If you look at a typical Java or .NET app (or the libraries themselves), or even Smalltalk, between 5-10% of the calls are class method calls. If you reverse engineer any Java or C# code to a sequence diagram, one should be able to see what’s a class method call on class X, versus instance calls. When you creatively draw an interaction diagram, the reader (a human or tool) should be able to know when something is a static call on a class.

    There are literally thousands of class methods in the Java and .NET core libraries. Any significant java app makes thousands of calls to these many library class methods, in addition to hundreds or thousands of calls to app-defined class methods.

    Problem:

    This is basic stuff, but the interaction diagram notation is not clear on how to show this. Tool vendors need a solution ASAP; many are in beta, and want to know the “correct” way asap, during rev eng of java code to a seq dgm, to show such calls. E.g., given the basic java code that i show in the attached example picture, how to rev eng the code to a seq dgm.
    And my book, that teaches intro OOA/D, has to show the solution – i’ve got an aug 30 publishing deadline.

    UML 1 had a way to solve this in interaction diagrams, with underlined/not underlined labels in the boxes, where not underlined indicated it was a class, and thus a class method call. But of course, that convention doesn’t work with UML 2 lifeline boxes.

    The problem can probably be solved with the appropriate label in a lifeline box, and ensuring that the context composite structure diagram relates appropriately.

    Solution:

    I’ve asked this question to Jim Rumbuagh, who gave a “convention” solution i very much like, for the lifeline box label: “ClassName : Class ”

    e.g. “Font : Class”, “Collections : Class” or perhaps “Font : Type” if reverse engineering from C#.

    e.g.., going meta and viewing the class as an instance of class Class.

    In Java and Smalltalk (for example) all classes are indeed instances of class Class. In .NET, they are instances of class Type.

    Then the lifeline box still represents an instance (of class Class or Type or whatever), and the “class messages” are still instance messages.

    I attach a diagram that gives a sequence diagram example.

    And–and i consider this important–the solution should be obviously understandable and straightforward to a novice, as is Jim’s. It corresponds to an OO programmer’s mental model. I encourage the committee members to choose a solution that is simple and obvious, that maps straightforward to the language most OO developers are working in – Java or C#, not an obscure solution.

    An outstanding problem, with bigger ramifications, is the names “Font” and “Class” in the related context diagram. Where are they defined? Of course, most of these classes will be from the core Java or .NET libraries (each have about 20,000 classes). I propose being able to declare a convention something like “assume that in this composite structure diagram there is an implicit import of the classes needed from the java libraries (or other libraries).”

    Well, some convention like that is needed in any event, because we are frequently calling instance methods on instances of java library classes – in a typical java app, 30-50% of the calls are to objects from the library. You can’t expect (because it would be too fussy/awkward/unusable) a UML modeler working in Java to re-create or have to explicit import specific parts of the Java libraries (or various common 3rd party libraries) every time they want to refer to library objects – which is frequently.

    i attach a picture to illustrate.

  • Reported: UML 1.4.2 — Wed, 4 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue here is to be able to describe calls on static methods.
    Static Operations are defined on Types, with the property “isStatic” declared as true.
    It needs to be clarified, that every connectable element can receive messages with signatures associated with
    its static operations.

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

Missing notation for Behaviors in a BehavioredClassifier

  • Key: UML25-584
  • Legacy Issue Number: 7625
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    There's no notation specified for showing the ownedBehaviors of a BehavioredClassifier. This could be done by using another compartment in the context classifier, but this is not mentioned, nor is the syntax for the behavior and its parameters specified that I could find.

  • Reported: UML 1.4.2 — Tue, 10 Aug 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

Name without a colon for Property in Composite Structures

  • Key: UML25-583
  • Legacy Issue Number: 7624
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    In Composite Structures, under 9.3.12 Property, the following
    paragraph under "Presentation Options" under "Notation" is
    inconsistent with the rest of UML in creating a special
    interpretation of a missing notation element:

    "A property symbol may be shown containing just a single name
    (without the colon) in its name string. This implies the
    definition of an anonymously named class nested within the
    namespace of the containing class. The part has this anonymous
    class as its type. Every occurrence of an anonymous class is
    different from any other occurrence. The anonymously defined
    class has the properties specified with the part symbol. It is
    allowed to show compartments defining attributes and operations
    of the anonymously named class."

    The simple omission of notation elements is part of the option
    in virtually all UML diagrams to elide elements that aren't
    relevant or are defined and shown on other diagram views.
    Implying something to be created by the absence of an
    element breaks from user expectations.

    In this case, the most natural expectation of a simple name on
    a property box, without any colon, is that the string is just
    the name of the part or property, and that the type for the
    name, ordinarily shown using a ":Type" string, has been omitted
    from the diagram.

    The simplest way to resolve this issue is just to remove this
    paragraph from the specification. The specification would then
    revert to the default interpretation of a missing notation
    element, which is just that it isn't shown on a particular
    diagram view, not that it doesn't exist.

    The application of Composite Structure diagrams to systems
    engineering, in response to the UML for Systems Engineering
    RFP, expects to use all the flexibility that UML provides to
    include or not include diagram elements on particular views
    of a complex system, to avoid cluttering the many partial
    views that might be needed. Resolution of this issue is
    essential to avoid having a different rule for a name without
    a colon in standard UML vs. its application to systems
    engineering.

  • Reported: UML 1.4.2 — Fri, 6 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The BNF for Property does make the [’:’ <prop-type>] optional, so this is indeed an inconsistency in the
    spec. Delete the offending paragraph

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

Profiles in Compliance Level 1?

  • Key: UML25-586
  • Legacy Issue Number: 7627
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It has been suggested that Profiles should be part of Compliance Level 1 (Basic Level) rather than part of Compliance Level 2 (Intermediate Level) as currently defined. The rationale is that it gives any UML user the ability to specialize UML. We already know from experience that UML is almost ALWAYS specialized when it is used – implicitly or explicitly. Given that, we might as well provide users at all levels with the ability to use profiles. I feel that this is a reasonable suggestion.

  • Reported: UML 1.4.2 — Tue, 10 Aug 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

Redundant parameter specifications for Operation and Behavior

  • Key: UML25-585
  • Legacy Issue Number: 7626
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    A Behavior can be defined in the context of a BehavioredClassifier where it must have a specification BehavioralFeature which defines its parameters and return value. A Behavior may also stand alone in order to represent procedural-based models in which case the Behavior specifies its own parameters and return result.

    There is a constraint that specifies the parameters of a Behavior in the context of a BehavioredClassifier must match the parameters of its specification BehavioralFeature. However, parameter matching is not explicitly defined. Is it match in mode, name, type, multiplicity, constraints, etc., or just type?

    A better solution would be to disallow behavior parameters if the behavior has a specification. This would eliminate the need to redundantly specify the parameters for a behavior if it has a specification, and then enforce a constraint to have them match.

    Specifically:

    1. section 13.3.3, remove constraint: [1] The parameters of the behavior must match the parameters of the implemented behavioral feature.

    2. add a new (second) constraint: [2] A Behavior with a specification BehavioralFeature obtains its parameters from the BehavioralFeature and cannot specify its own parameters.

    3. add a new constraint: [3] A Behavior with a specification BehavioralFeature cannot have any redefinedBehaviors. The redefinitions come from the BehavioralFeature.

  • Reported: UML 1.4.2 — Tue, 10 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    The UML 2.5 specification is clear now (in 13.2.3, under “Behavioral Features and Methods”) that how the
    parameters of a method are matched to its specifying behavioral feature is intentionally not formalized, in
    order to allow for different possible approaches to this in different user models.
    Disposition: Closed - No Change

  • 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

UML 2 Super/Activities/Class-Activity association missing

  • Key: UML25-579
  • Legacy Issue Number: 7607
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    An activity diagram is a graphical form of method, however there is no way to assign them to a class that would contain such a method. This may be more general than activity diagrams. For example, the same could apply to sequence diagrams. Since organizing structure and behavior by class is a fundamental OO concept, we need to have a way to associate UML-expressed methods to the “organizing” class.

  • Reported: UML 1.4.2 — Fri, 30 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

UML2 super&infra/Profiles/ownership of Image

  • Key: UML25-578
  • Legacy Issue Number: 7598
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    In the current UML2metamodel, the ownership of the new Image metaclass is
    not specified.

  • Reported: UML 1.4.2 — Fri, 23 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

Figures 103 and 121 use <> dependencies

  • Key: UML25-588
  • Legacy Issue Number: 7645
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    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 1.4.2 — Fri, 20 Aug 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

. <> on Usage

  • Key: UML25-587
  • Legacy Issue Number: 7644
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    1. <<create>> on Usage is defined in the standard stereotypes and in the
    retired stereotypes. It is used in Figure 103 and 121 of the FAS.

  • Reported: UML 1.4.2 — Fri, 20 Aug 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 Super/Templates/Template substitution symbol problematic

  • Key: UML25-580
  • Legacy Issue Number: 7618
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Templates use an arrow symbol inline with the text to show a binding of a template parameter

    Problem: typographic problem. the arrow symbol is not present in many common fonts (times, arial, Helvetica, …). Therefore, one must use another font for this character (e.g., ZapfDingbats). That will create some fuss at several levels, related to fonts, usability, and tools. It also creates more dependency on printing with commercial printers; if you’re a book author, you know that adding more fonts to a book is another source of error. Yes, solvable, but nice to simplify.

    Solution: use a simple symbol part of the basic character fonts (e.g., in Arial, …). I suggest ‘= ™

    Example: ArrayList<T = Person>

  • Reported: UML 1.4.2 — Tue, 3 Aug 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

Port should specialize featuringClassifier

  • Key: UML25-577
  • Legacy Issue Number: 7567
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Apparently a structural feature can be on more than one classifier,
    because the multiplicity of /featuringClassifier is 1..*. Not all the
    subtypes of StructuralFeature narrow this to one, or change it to strong
    ownership (eg, Port).

    Is it intentional that structural feature have more than one
    featuringClassifier, and not be owned by that classifier? If not, Bran,
    please assign this to classes. Otherwise, it is problem for Ports as
    well.

  • Reported: UML 1.4.2 — Wed, 7 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

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

Clarification of use of BNF for textual notations

  • Key: UML25-538
  • Legacy Issue Number: 18802
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In a number of places, the UML specification uses BNF to specify textual notations. However, as for all UML surface syntax, UML textual notations are generally for presentation. There is no requirement that such notations be unambiguously parsable – for example, a modeler may use arbitrary characters like “/” and “:” in a property name, even though these are used as special punctuation in the BNF for property textual notation. This can be confusing to some readers, since BNF is commonly used to specify parsable programming language text. Therefore, it may be worth providing a general clarification of this up front, perhaps in Clause 6 of the specification.

  • Reported: UML 2.5b1 — Tue, 9 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Make such a clarification in 6.4.1

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

ActivityParameterNode notation

  • Key: UML25-537
  • Legacy Issue Number: 18801
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Customers are constantly asking for the ability to show parameter direction on ActivityParameterNode symbol.

    UML spec says:
    An ActivityParameterNode is notated as an ObjectNode, except that the full textual specification of the associated Parameter (see sub clause 9.4) may be used to label the ActivityParameterNode instead of the normal name/type label.

    However, I can't find Parameter BNF.

    Could you please help me to find/define a "standard" notation and don't you think it should be clarified in the spec?

  • Reported: UML 2.5b1 — Thu, 4 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    In 9.4.4 it says “There is no general notation for Parameter. Specific subclasses of BehavioralFeature define
    notation for their Parameters.”
    There are two subclasses of BehavioralFeature, Operation and Reception. Operation defines a notation for
    Parameter within its BNF. Reception says “Receptions are shown in the receptions compartment using the
    same notation as for Operations with the keyword «signal».”
    So there is only one notation for Parameter, and it should be defined there, so that ActivityParameterNode
    can refer to it.
    The notation for ParameterSet is incorrectly specified in the same way.
    This also resolves 17906.

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

Avoid covariant parameters in metamodel operation redefinition

  • Key: UML25-539
  • Legacy Issue Number: 18810
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The vast majority of operation redefinitions in the metamodel have invariant parameters, but four operations inconsistently use covariant parameter redefinition. MOF actually says nothing about whether covariant redefinition is allowed, but for consistency and type-safety the UML spec should avoid it. This can be done using a precondition that requires the parameter to be of the right type.

    Region::isRedefinitionContextValid(), State::isRedefinitionContextValid(), StateMachine::isRedefinitionContextValid(), and Classifer::conformsTo().

  • Reported: UML 2.5b1 — Thu, 11 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The operations that do not have covariant parameters are isCompatibleWith(p), isDistinguishableFrom(n,
    ns), and isConsistentWith(redefinee).
    The implementations of isCompatibleWith explicitly check the type of the parameter as part of the test:
    p.oclisKindOf(self.oclType()).
    The implementations of isDistinguishableFrom explicitly check the type of the parameter.
    The implementations of isConsistentWith call isRedefinitionContextValid() as a precondition. The truth of
    this precondition is a consequence of well-formedness rules.
    Rather than using a precondition as suggested in the issue, it is safer to make the operations explicitly check
    the parameter type in their logic.

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

The resolution to Issue 18528 contains incorrect OCL and operation names

  • Key: UML25-536
  • Legacy Issue Number: 18793
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In the resolution to 18528, the operation getOperand() should have the type InteractionOperand, not InteractionFragment. Also the name getGateName() should be getName() throughout the revised text.

  • Reported: UML 2.5b1 — Tue, 2 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Change the type of Gate::getOperand(), and fix the names

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

The resolution to issue 18415 contains invalid OCL

  • Key: UML25-535
  • Legacy Issue Number: 18792
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    18415 was applied in Ballot 6. The revised OCL for sources_and_targets_kind contains the expressions self.informationSource.classifier and self.informationTarget.classifier, which are not well-typed. The first subexpression gives a NamedElement which in general does not have a classifier. The correct OCL should check if it is an InstanceSpecification, cast to InstanceSpecification and then check its classifier.

  • Reported: UML 2.5b1 — Tue, 2 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Revise the OCL and text related to sources_and_targets_kind, bearing in mind that an InstanceSpecification
    may in general have several classifiers

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

Wording corrections in Behavior Diagrams and Activity Diagram Labels

  • Key: UML25-546
  • Legacy Issue Number: 18823
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause B.4.2 (Behavior Diagrams), second bullet, UseCase => Actor.

    Clause B.4.3 (Activity Diagram Labels), second bullet, UMLObjectNodes with ActivityParameterNodes => UMLShapes with ActivityParameterNodes as modelElements

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Make the suggested edits

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

Labels for generalization sets in UML DI

  • Key: UML25-545
  • Legacy Issue Number: 18821
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    Annex B should explain how to model labels of generalization sets.

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add that generalization set constraint text are modeled as UMLLabels with generalization sets as modelElements,
    and that these labels and the ones for power types are owned by their generalization or generalization
    set edges. Also add that generalization set lines are modeled as UMLShapes with generalization sets as
    modelElements.

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

Classifier and state annotations in UML DI

  • Key: UML25-541
  • Legacy Issue Number: 18817
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    Annex B should explain how the

    {abstract}

    annotations in UMLClassifierShapes and the

    {extended}

    and

    {final}

    annotations in UMLStateShapes are modeled.

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clarify that these are direct instances of UMLLabel containing the text as specified by UML

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

Dashed interaction lifelines in UML DI

  • Key: UML25-540
  • Legacy Issue Number: 18816
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    Interaction lifelines can be dashed, but the model in Annex B cannot express this.

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add property to UMLInteractionDiagram to specify whether lifelines are dashed

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

Action operation redefinition is invalid

  • Key: UML25-532
  • Legacy Issue Number: 18789
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The operation Action::allOwnedNodes() redefines Action::allActions(). That must surely be wrong.

  • Reported: UML 2.5b1 — Tue, 2 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    yes, this is wrong

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

Association::endType() is inconsistent

  • Key: UML25-531
  • Legacy Issue Number: 18788
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The operation Association::endType() is inconsistent in multiplicity and ordering with the derived property endType which it is intended to calculate – the property is [1..*, ordered, unique} and the operation is

    {0..*, ordered, nonunique}

    . We think that the property is correct and the operation should be changed to match.

  • Reported: UML 2.5b1 — Tue, 2 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    In fact

    {ordered}

    is meaningless and unnecessary. Change both to be 1..*, unordered, unique. Introduce
    a constraint to ensure that all ends have a type, as stated in the semantics text in 11.5.3. Also change the
    definition of Property::subsettingContext which currently uses this property incorrectly.
    This resolves also 18859.

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

Improve documentation of how derived properties are calculated

  • Key: UML25-534
  • Legacy Issue Number: 18791
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Summary: Clause 6.4 needs to explain that derived properties are calculated by having an operation with the same name and return type.

  • Reported: UML 2.5b1 — Tue, 25 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Improve 6.4 to explain this.

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

The resolution to 18697 contains errors

  • Key: UML25-533
  • Legacy Issue Number: 18790
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The definition for the new operation allRoles() contains no textual documentation. Also the OCL is wrong; it should read:

    allFeatures()>select(oclIsKindOf(ConnectableElement))>collect(oclAsType(ConnectableElement))->asSet()

  • Reported: UML 2.5b1 — Tue, 2 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Provide a textual documentation and change the OCL

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

Template parameter rectangles

  • Key: UML25-544
  • Legacy Issue Number: 18820
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    Annex B should explain how template parameter rectangles are modeled

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clarify that the template signature rectangles have template signatures as modelElements

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

Ownership of property qualifier rectangles

  • Key: UML25-543
  • Legacy Issue Number: 18819
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    Annex B should explain the ownership of property qualifier rectangles

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add that the UMLShape for property qualifier rectangles is owned by the UMLEdge for the association
    being qualified

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

Dependencies with more than two ends in UML DI

  • Key: UML25-542
  • Legacy Issue Number: 18818
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    Annex B should explain how dependency lines with more than two ends are modeled

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clarify that a UMLShape is used as the central point of the arrows.

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

Location: 18.1.5 Examples Figure 18-9. 690 - Description does not match figure 18-9

  • Key: UML25-432
  • Legacy Issue Number: 18074
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Current text Figure 18-9 illustrates an ownedUseCase of a Class using an optional ownedMember compartment.
    In the figure 18-9, the title of the compartment is owned use cases. The description should explain the discrepancy.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Optional compartment naming is specified in 9.2.4.

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

Location: 18.1.5 Examples Figure 18-2. 689 - Explain about multiplicity

  • Key: UML25-431
  • Legacy Issue Number: 18072
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Please explain the multiplicity as used on this Figure 18-2. Without a good explanation, an example doesn’t really help
    Something like this.
    In this example, a Customer or Administrator may or may not participate in any of their associated Use Cases (hence the 0..1 multiplicity). From the Use Case perspective, it must have an Actor to initiate it (hence the 1 multiplicity). The Deposit and Register ATM use cases require participation by the Bank, while the bank can participate with many Deposit and Register ATM use cases at the same time.

    This description will address open UML 2.4 issue 8854

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the proposal. This also resolves issue 8854

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

Location: 18.1.4 Notation P. 688 - Point to diagram (03)

  • Key: UML25-424
  • Legacy Issue Number: 18065
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “An Actor is represented by “stick man” icon with the name of the Actor in the vicinity (usually above or below) the icon.”

    [AC] I would add at the end “See figure 18-6”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the proposal, using text to clarify that the figure is an example; and fix the typo.

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

Location: 18.1.4 Notation P. 688 - Point to diagram (02)

  • Key: UML25-423
  • Legacy Issue Number: 18064
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “A UseCase may also be shown using the standard rectangle notation for Classifiers with an ellipse icon in the upper-right-hand corner of the rectangle. In this case, “extension points” is an optional compartment. This rendering is more suitable when there are a large number of extension points or features.”

    [AC] I would add at the end “See figure 18-5”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the proposal, using text to clarify that the figure is an example

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

Location: 18.1.4 Notation P. 688 - Point to diagram (08)

  • Key: UML25-429
  • Legacy Issue Number: 18070
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “An Include relationship between UseCases is shown by a dashed arrow with an open arrowhead pointing from the base UseCase to the included UseCase. The arrow is labeled with the keyword «include»..”
    .”

    [AC] I would add at the end “See figure 18-4”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the proposal, using text to clarify that the figure is an example

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

Location: 18.1.4 Notation P. 688 - Point to diagram (07)

  • Key: UML25-428
  • Legacy Issue Number: 18069
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “An Extend relationship between UseCases is shown by a dashed arrow with an open arrowhead pointing from the extending UseCase towards the extended UseCase. The arrow is labeled with the keyword «extend». The condition of the Extend as well as references to the ExtensionPoints are optionally shown in a note symbol (see 7.2.4) attached to the corresponding arrow.”

    [AC] I would add at the end “See figure 18-3”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the proposal, using text to clarify that the figure is an example

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

Location: 18.1.4 Notation P. 688 - Point to diagram (06)

  • Key: UML25-427
  • Legacy Issue Number: 18068
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “The nesting (owning) of a UseCase by a Classifier may optionally be represented by nesting the UseCase ellipse inside the Classifier rectangle in a separate compartment. This is a case of the optional compartment for ownedMembers described in 9.2.4.”

    [AC] I would add at the end “See figure 18-9”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the proposal, using text to clarify that the figure is an example

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

Location: 18.1.4 Notation P. 688 - Point to diagram (05)

  • Key: UML25-426
  • Legacy Issue Number: 18067
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Other icons that convey the kind of Actor may also be used to denote an Actor, such as using a separate icon for non-human Actors.”

    [AC] I would add at the end “See figure 18-8”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the proposal, using text to clarify that the figure is an example

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

Location: 18.1.5 Examples Figure 18-2. 689 - Explain about «Subsystem»

  • Key: UML25-430
  • Legacy Issue Number: 18071
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    It might be useful to explain in the text somewhere that the «Subsytem»ATM System is (necessarily) a component.

    This clarification will address open UML 2.4 issue 16494

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Explain that the subsystem is a Component; also clarify the notation to insist that the metaclass of the subject
    should be explicitly shown in cases where it is ambiguous.
    This also resolves issue 16494.

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

Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - At least one actor

  • Key: UML25-436
  • Legacy Issue Number: 18080
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    current text (696): A UseCase specifies a set of actions performed by its subject, which yields an observable result that is of value for one or more Actors or other stakeholders of the subject

    Missing OCL to enforce this constraint.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18045

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

Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - At least one actor

  • Key: UML25-435
  • Legacy Issue Number: 18079
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    current text (696): A UseCase specifies a set of actions performed by its subject, which yields an observable result that is of value for one or more Actors or other stakeholders of the subject

    Missing OCL to enforce this constraint.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18045

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

Location: 18.1.4 Notation P. 688 - Point to diagram (04)

  • Key: UML25-425
  • Legacy Issue Number: 18066
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “An Actor may also be shown as a Classifier rectangle with the keyword «actor», with the usual notation for all compartments.”

    [AC] I would add at the end “See figure 18-7”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the proposal, using text to clarify that the figure is an example.

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

Location: 18.1.5 Examples Figure 18-10. 691 - Duplicate Diagram

  • Key: UML25-433
  • Legacy Issue Number: 18075
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Figure 18-10 duplicates Figure 18-2.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No, it doesn’t. It reuses part of 18.2 in a different context. Needs a better explanation

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

Location: 18.2 Classifier Descriptions Include Constraints. 696 - Includes must be a DAG

  • Key: UML25-434
  • Legacy Issue Number: 18078
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Missing constraint or discussion anywhere that the chain of includes relations must not contain loops

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There is already a constraint to this effect: UseCase::cannot_include-self.
    Disposition: Closed - No Change

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

UML 2.5 issue: Clause 6.3 should contain a definition of "execution scope"

  • Key: UML25-483
  • Legacy Issue Number: 18376
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The semantics of static are defined with respect to a concept called “execution scope”. I think that concept needs a definition in section 6.3. Maybe the terminology is wrong – it might be “model instance” or “model execution” or something, but there needs to be a term for a set of related executing instances that comprise an instantiation of the model.

  • Reported: UML 2.5b1 — Tue, 15 Jan 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed. The concept of “execution scope” is also relevant to the reading of classifier extents.

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

Fixed-point issues with the definition of default values for literals

  • Key: UML25-482
  • Legacy Issue Number: 18287
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The definition of LiteralBoolean in the XMI for UML1.5 includes the following:

    <packagedElement xmi:type="uml:Class" xmi:id="LiteralBoolean" name="LiteralBoolean">

    …

    <ownedAttribute xmi:type="uml:Property" xmi:id="LiteralBoolean-value" name="value" visibility="public">

    …

    <defaultValue xmi:type="uml:LiteralBoolean" xmi:id="LiteralBoolean-value-_defaultValue"/>

    </ownedAttribute>

    …

    So the default value for value, which is correctly specified as false in the model, is specified by the absence of a value attribute as “the default value for LiteralBoolean::value” in the XMI. This is circular and ill-defined.

    One issue is with the XMI specification. The rule that property values should not be serialized when they have their default value should not apply when those properties are being used to define default values for themselves. Another issue is with the UML xmi. This needs to serialize the value for the default value of literals, regardless of other considerations. In the case above, value=”false”.

  • Reported: UML 2.5b1 — Wed, 5 Dec 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Resolving Issue 18286 against XMI will make it valid to serialize the default value of the value property for
    literals. For UML 2.5, we will serialize them. XMI 2.5 will be published at the same time as UML 2.5 and
    UML 2.5 will be serialized as an instance of it.

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

Fix the notation to allow assignment of a decision to partition when the swimlanes are not practical.

  • Key: UML25-475
  • Legacy Issue Number: 18192
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Fix the notation to allow assignment of a decision to partition when the swimlanes are not practical.

  • Reported: UML 2.5b1 — Mon, 22 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The notation already allows this, as described in Subclause 15.6.4 of the UML 2.5 beta specification. Under
    “Activity Partitions”, it states “In some diagramming situations, using parallel lines to delineate ActivityPartitions
    is not practical. An alternative is to place the partition name in parenthesis above the ActivityNode
    name. . . ” Thus the desired alternative notation is already provided for any ActivityNode. However, since
    the associated figure only shows Actions, the applicability to other ActivityNodes could be clearer.

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

UML association semantics vis-a-vis Interfaces (and other types of classifiers)

  • Key: UML25-474
  • Legacy Issue Number: 18185
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The semantics of associations are specified in terms of links, which the UML 2.4 spec defines as: "a tuple with one value for each end of the association, where each value is an instance of the type of the end" and the 2.5 spec as "a tuple with one value for each memberEnd of the Association, where each value is an instance of the type of the end". However, the specs include several examples of associations between interfaces. Since interfaces are abstract classifiers they cannot have instances ("Interfaces may not be instantiated"), the semantics of associations whose ends terminate on interfaces cannot be described by the above semantics.

    Some other semantics need to be provided for such cases.

    Furthermore, the issue extends to other types of classifiers (e.g., collaborations) where the meaning of "instance" is not straightforward.

  • Reported: UML 2.5b1 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    With regard to Interfaces, the issue relates to the wording “an instance of the type at the end”, which should
    be loosened to include “an instance of a type that implements the type at the end”.

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

confusing wording and terminology for TransitionKind in the section “Transition kinds relative to source”.

  • Key: UML25-473
  • Legacy Issue Number: 18184
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    A "local" transition is a group transition that emanates from a composite state (i.e., it is a group transition representing transitions form any contained substate of the composite source state) and terminates on an internal subvertex (the target vertex). This is OK and quite useful. However, the wording is confusing as is the terminology.

  • Reported: UML 2.5b1 — Fri, 19 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 13920

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

Section 11: feature inheritance should be orthogonal to the topology of well-formed connections in a structured classifi

  • Key: UML25-470
  • Legacy Issue Number: 18171
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Title: UML2.5, section 11: feature inheritance (of attribute properties,
    ports and connectors) should be orthogonal to the topology of well-formed
    connections in a structured classifier

    Summary:

    SysML uses extensively UML's StructuredClassifiers.
    In UML 2.4.1, the well-formedness constraints for UML's
    StructuredClassifiers were written in English only.
    In UML 2.5, the well-formedness constraints have both English descriptions
    and OCL specifications.

    Unfortunately, the UML 2.5 OCL specifications for the well-formedness of
    UML's StructuredClassifiers are too restrictive for SysML in 3 areas:

    1) StructuredClassifier::/role is a derived union that is subsetted only
    once by StructuredClassifier::ownedAttribute.

    This means that inherited attributes of a StructuredClassifier are not
    considered to be roles of that StructuredClassifier.

    2) StructuredClassifier::/part is derived and the derivation is:
    ownedAttribute->select(isComposite)

    This means that inherited attributes of a StructuredClassifier are not
    considered to be parts of that StructuredClassifier.

    3) Connector has a constraint, roles, stated as follows:

    The ConnectableElements attached as roles to each ConnectorEnd owned by a
    Connector must be roles of the Classifier that owned the Connector, or
    they must be Ports of such roles.

    inv: structuredClassifier <> null
    and
    end->forAll( e |
    structuredClassifier.role->includes(e.role)
    or
    e.role.oclIsKindOf(Port) and
    structuredClassifier.role->includes(e.partWithPort))

    There is a significant conceptual asymmetry between the two disjuncts of
    the forAll() clause.

    The first disjunct is: structuredClassifier.role->includes(e.role)

    This restricts the ConnectableElement to be a role of the
    StructuredClassifier owning the Connector; that is, the ConnectableElement
    must be an ownedAttribute of that StructuredClassifier.

    The second disjunct is: e.role.oclIsKindOf(Port) and
    structuredClassifier.role->includes(e.partWithPort)

    This also restricts the ConnectableElement::partWithPort to be a role of
    the StructuredClassifier owning the Connector; however, the
    ConnectableElement Port may be inherited!
    (see ConnectorEnd::role_and_part_with_port)

    The conceptual asymmetry is that it is OK to connect inherited ports of
    owned attributes but it is not OK to connect inherited attributes.

    >From a conceptual point of view, UML 2.5 does not provide a rationale for
    restricting the connectivity of UML StructuredClassifiers to owned
    attributes only.
    >From a conceptual point of view, feature inheritance (I.e., of attribute
    properties and of connectors) should be orthogonal to the topology of
    connections in a StructuredClassifier.

  • Reported: UML 2.4.1 — Thu, 11 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18697

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

ConnectableElement-end" has @isOrdered='true'

  • Key: UML25-469
  • Legacy Issue Number: 18140
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I've just came across another issue: "ConnectableElement-end" has @isOrdered='true'. Since it is derived (and not derivedUnion) there is a corresponding operation for that attribute. However, the 'return' parameter for that operation doesn't declare @isOrdered='true'.
    Shouldn't the return parameter of operations that describe derived attributes always 'match' the corresponding attribute ?

  • Reported: UML 2.4.1 — Fri, 5 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The result of the operation should be ordered if the property is ordered. But the operation cannot produce
    an order, and there seems to be no requirement for the property to be ordered

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

The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance

  • Key: UML25-472
  • Legacy Issue Number: 18177
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML 2.5: “The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance”, with this email discussion attached

  • Reported: UML 2.5b1 — Thu, 18 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue boils down to the following key points.
    1. The property inheritedMember, which is part of the calculation of the members of a Classifier, does
    not include private members of generalizing Classifiers.
    2. Private properties of generalizing Classifiers should be instantiable as slots in InstanceSpecifications,
    even though they are not “inherited” according to 1.
    3. Something of a disagreement about whether redefined properties may have slots, even though they are
    excluded from inheritedMember. The resolution is to allow slots to be instantiable for private inherited properties, but still to hide redefined
    properties (which is done through the operation inherit()). This is done by defining and using a new operation
    for Slot constraints. Some other documentation is improved for clarity.
    This also resolves 18414.

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

UML 2.5 issue: structural features with isStatic = true may not have a slot in InstanceSpecifications

  • Key: UML25-471
  • Legacy Issue Number: 18176
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There should be a constraint that structural features with isStatic = true may not have a slot in InstanceSpecifications

  • Reported: UML 2.5b1 — Thu, 18 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No, there should not. Slots can be used to model the values of static features.
    Disposition: Closed - No Change

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

Notation for state machine specializations

  • Key: UML25-478
  • Legacy Issue Number: 18248
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In chapter 14, the notation for state machine specializations uses <<extended>> and

    {final}.


    <<extended>> is defined as a constraint-based keyword for a Region or a StateMachine.
    However, the notation in 14.3.4 clearly indicates that a state can be extended.
    There should be a new entry in the keyword table specifying the constraint-based application
    of the extended keyword to a State that has a non-empty redefinedState.


    The notation only covers the possibility of a modeler declaring states and transitions as {final}

    .
    Conceptually, a modeler should also be able to declare a region as

    {final}.
    There is no definition for what {final}

    is. Since it requires explicit declaration from the modeler,
    it should be defined as a stereotype-based keyword notation with a new stereotype <<final>> defined in the UML standard profile.

    <<extended>> and

    {final}

    should be explicitly defined in the semantics section in 14.3.3.

  • Reported: UML 2.5b1 — Mon, 5 Nov 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 12380

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

UML2.5 issue : missing constraints on aggregation / composition

  • Key: UML25-477
  • Legacy Issue Number: 18228
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    As far as I know, a Property may only be marked as an aggregation or composition if either (a) it is not an association end or (b) it is the end of a binary association and the other end is not marked as an aggregation or composition. The spec does not actually say this clearly, and there is no OCL to enforce it.

  • Reported: UML 2.5b1 — Thu, 25 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The text for Association says “A binary Association may represent a composite aggregation. . . ”. It doesn’t
    explicitly exclude the undesirable configurations.

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

Two different Dashed Arrow Styles for Reply message in Figure 17.2 Interaction Example

  • Key: UML25-476
  • Legacy Issue Number: 18226
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The example in Figure 17.2 has different dash types for the two reply messages.

    This is confusing since it is by no means significant.

  • Reported: UML 2.5b1 — Tue, 23 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed. Amend Figure 17.2 in a sense that both reply arrows are identical.

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

Error in Dependency notation example

  • Key: UML25-481
  • Legacy Issue Number: 18275
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

    Subclause: 7.7.4

    In Figure 7.18, the name within the guillemets should be a stereotype name, not the dependency name. The dependency name should be separate from the stereotype.

  • Reported: UML 2.5b1 — Tue, 20 Nov 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 15046

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

Error in diagram using StringExpressions

  • Key: UML25-480
  • Legacy Issue Number: 18273
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

    Subclause: 7.4.5

    In Figure 7.6, replace $<resource>$ with $a<Resource>$, $<resource>Allocation$ with $a<Resource>Allocation$ and $<resourceKind>$ with $the<ResourceKind>$ (for Request) or $a<ResourceKind>$ (for System).

    The notation for template binding shown in Figure 7.6 is also inconsistent with the description in 7.3.4.

  • Reported: UML 2.5b1 — Tue, 20 Nov 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed.
    This also resolves Issue 17794.

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

Inconsistent template binding notation example

  • Key: UML25-479
  • Legacy Issue Number: 18271
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: OMG Unified Modeling Language (OMG UML), Version 2.5 FTF – Beta 1 (ptc/2012-10-24)

    Subclauses: 7.3.4, 9.3.5

    In 7.3.4, it states that “A TemplateBinding is shown as a dashed arrow with the tail on the bound element and the arrowhead on the template and the keyword «bind». The binding information may be displayed as a comma-separated list of template parameter substitutions…” However, Figure 9.5 in 9.3.5 shows an example of a classifier binding using a realization arrow, not just a plain dashed arrow, and has the template parameter substitutions appearing within angle brackets. Both of these things are inconsistent with 7.3.4.

  • Reported: UML 2.5b1 — Tue, 20 Nov 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The same problem was there in 2.4

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

UML2.5: clarification about the semantics of redefinition

  • Key: UML25-468
  • Legacy Issue Number: 18132
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    There are three closely related problems in this issue:

    1) incorrect constraint in Structured Classifiers, clause 11, Connector:

    roles The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be roles of the Classifier that owned the Connector, or they must be Ports of such roles.
    inv: structuredClassifier <> null
    and
    end->forAll( e |
    structuredClassifier.role->includes(e.role)
    or
    e.role.oclIsKindOf(Port) and structuredClassifier.role->includes(e.partWithPort))

    • The OCL constraint does not take into account the structured classifier's inherited roles.
    • The English constraint description is ambiguous whether inherited roles are to be included or not.

    2) The structured classifier clause does not adequately explain the semantics of redefining parts and connectors.

    For structured classifiers with inherited parts and/or connectors and redefined parts and/or connectors, there are two views of a given structured classifier:
    The abstract syntax view which retains the abstract syntax distinction between a redefining element and a redefined element.
    The semantics view where all occurrences of a redefined element are replaced by its redefining element.

    Ed's message below explains the distinction between these two views.

    3) More generally, the distinction between the abstract syntax view & the semantics view needs to be addressed for all kinds of redefineable elements; particularly those where the semantics of redefinition can have a significant impact on UML structure and behavior diagrams, including but not limited to:
    Class diagrams
    State machine diagrams
    Activity diagrams
    Interaction diagrams
    Etc

  • Reported: UML 2.4.1 — Tue, 2 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Part 1 of the issue was handled by resolving 18697. Parts 2 and 3 were handled by resolving 18650.
    Disposition: Closed - No Change

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

Lifeline has no type.

  • Key: UML25-467
  • Legacy Issue Number: 18127
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Lifeline has no type. Type comes from ConnectableElement it represents.

    That means, we must have "fake" property created for every call to static operation (one per class).

    Should it be property of Interaction? Or should it be property of context Classifier? This is an issue.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 7621

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

Location: Table B.1 UML Keywords p 778 - Use of # in Semantics col

  • Key: UML25-466
  • Legacy Issue Number: 18124
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Expressions such as visibility <> #public are not clear (I suppose this is OCL) and should be explained. Also the of isRelative = true (w/o the #) appears inconsistent

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    We can tidy up the semantics column in the table in Annex C with the following fixes:
    1. Replace enumeration literals denoted with hash signs by properly qualified names - so #public becomes
    VisibilityKind::public (this resolves 7426).
    2. Remove the qualification from property names - the qualification is obvious from the metamodel
    element column.
    3. Replace BehavioredClassifer::self.oclIsKindOf(StateMachine) by StateMachine (this resolves 18117).
    4. Replace the semantics for apply by ProfileApplication (this resolves 18417)
    5. Make a number of other changes to improve consistency and correctness.

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

UML 2.5 issue; the word "individual" is incorrect in 9.8

  • Key: UML25-484
  • Legacy Issue Number: 18384
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Clause 9.8 uses the word “individual” in several places where it would be correct and consistent to use “instance”.

  • Reported: UML 2.5b1 — Tue, 22 Jan 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Replace individual by instance and change “individual instance” to “instance.”

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

Location: B.4.4 State Shapes P. 752 - State List Limitations

  • Key: UML25-451
  • Legacy Issue Number: 18106
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    State lists are not limited to no triggers
    See Figure 14-13 and Figure 14-14.

    They are limited to no effects, though I don't see why

    Also this does not cover Figure 14-13, which has the transition F going back to the original state. This can't be modeled as transition to a junction pseudostate. Either transition F is not legal for a state list, or this paragraph is overly restrictive.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Remove the text saying state list have no triggers. The effect limitation is defined by the state machine
    chapter and only restated in Annex B. However, there are other errors in the description of the underlying
    model, so the text should refer to the state machine chapter to reduce redundancy.

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

Location: B.2.4 P. 739 - confusing model and diagram

  • Key: UML25-450
  • Legacy Issue Number: 18105
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Is there a model in the diagram?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18104

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

Location: Table 21-1 PrimitiveType semantics Real P. 726 - IEEE 754

  • Key: UML25-441
  • Legacy Issue Number: 18091
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Should we be point to IEEE 754 the well-known standard (754-1985 or 754-2008) or
    the newer ISO/IEC/IEEE 60559:2011 (with identical content to IEEE 754).
    I would imagine that getting our spec through the ISO process would be easier if we point to the ISO standards

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The point about smoothing ISO acceptance is well taken. Text changed to reference the more recent standard
    with a note that it is identical to IEEE 754 so that experienced readers will recognize that the transition make
    no substantive change.

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

Location: 21.1 Summary P. 726 - Missing header

  • Key: UML25-440
  • Legacy Issue Number: 18090
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The diagram of the model should be in a separate section called "21.2 Model", cf 22.2.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Location: Figure 18-3 Example Extend p.689 - Circle on comment "anchor" not standard

  • Key: UML25-438
  • Legacy Issue Number: 18084
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    This notation, using the circle at the end of the line is not indicated elsewhere. As it is, it appears to be only used in extension conditions?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Fix it. The same problem occurs in 18.11. The problem is caused by the Pavel Hruby stencil.
    This also resolves issues 9017 and 9362.

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

Location: 18.1.1 Summary p 685 - emergent behavior

  • Key: UML25-437
  • Legacy Issue Number: 18083
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the spec, emergent is a special term with its own definition (not exactly the term as used outside the specification)

    The different uses of the term should be made conforming.

    1) emergent behavior as in 13.1
    vs
    2) emergent behavior as in 13.2.3 (2x), 13.4, or 18.1.1
    vs
    3) Emergent Behavior as in 17.1.4

    It should certainly be in the index.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17965

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

Location: Table 21-1 String P. 726

  • Key: UML25-445
  • Legacy Issue Number: 18095
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    'computational language expression' and 'OCL expression' are almost the same. 'name' is not mentioned.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The similarity of “computational language expression” and “OCL expression” is harmless here, and a computational
    language expression might be many thing dissimilar to and an OCL expression. For example, a COBOL language
    fragment would qualify as a computational language expression but certainly would not qualify as anything even close
    to an OCL expression. The reference to ‘name’ is unclear, and thereby, ignored.
    Disposition: Closed - No Change

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

Location: Table 21-1 P. 726 - Title of table not great

  • Key: UML25-444
  • Legacy Issue Number: 18094
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Again not semantics. Suggest "PrimitiveType Domains".
    [If it defined semantics, it would define how many Boolean instances there may be.]

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Ok, we can fix this one harmlessly

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

Location: 21.2 Semantics P. 726 - Subsection title

  • Key: UML25-443
  • Legacy Issue Number: 18093
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    This is an unfortunate title for a subsection that defines no semantics. Perhaps unavoidable for auto-generated consistency.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The existing title seems reasonable enough here, even if the contents are not precisely semantics.
    Disposition: Closed - No Change

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

Location: Table 21-1 PrimitiveType semantics Real P. 726 - Real Number representation

  • Key: UML25-442
  • Legacy Issue Number: 18092
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Current Text: Typically an implementation will represent Real numbers using a
    Suggested Text: Typically an implementation will internally represent Real numbers using a
    We already have a standard for Real Literals

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Suggested change made

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

Location: Figure 21-3

  • Key: UML25-448
  • Legacy Issue Number: 18098
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Class boxes in close proximity should generally have the same height, width, and font size

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Figure 21-3 contains a single class box.
    Disposition: Closed - No Change

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

Location: Table 21-1 P. 726 - Row ordering

  • Key: UML25-447
  • Legacy Issue Number: 18097
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    What is the row ordering rationale? Suggest alphabetical order, else increasing domain size order.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The table is only 5 items long. No one will be confused by the existing ordering and lookup is easy since the entire
    table occurs on a single page.
    Disposition: Closed - No Change

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

Location: Table 21-1 Unlimited Natural P. 726 - Infinity

  • Key: UML25-446
  • Legacy Issue Number: 18096
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The infinity value was called 'infinity' in UML 2.3 and 2.4. It is called 'unlimited' in OCL. It is called 'unlimited' in 8.2.4. Introducing the new term 'unbounded' seems undesirable, particularly in view of the familiarity and appropriateness of the mathematical concept of 'infinity'. [OCL should change to 'infinity'. UML Integer should grow to include +/- infinity to eliminate the inconsistency wrt Real/UnlimitedNatural.]
    Suggest replace 'unbounded' by 'infinity'

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue was discussed at length by the FTF. It was concluded to leave things as they are in the specification.
    Disposition: Closed - No Change

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

Location: Figure 20-4 and accompanying text P. 719 - InformationItem can represent multiple types?

  • Key: UML25-439
  • Legacy Issue Number: 18089
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The way you've documented this, it's unclear whether a informationItem can represent both other informationItems and concrete Classifiers.
    Current text: InformationItems can represent other InformationItems or concrete Classifiers.
    Suggested Text: InformationItems can represent other InformationItems and concrete Classifiers.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Reword as suggested

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

Location: B.2.3 P. 738 - confusing model and diagram

  • Key: UML25-449
  • Legacy Issue Number: 18104
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Is there a model in the diagram?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    If this refers to the phrase “model in Figure” referring to the metamodels figures, we could change it to “model shown
    in Figure”, but no one will be confused by the current wording.
    This resolves also 18105.
    Disposition: Closed - No Change

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

Active and passive

  • Key: UML25-595
  • Legacy Issue Number: 7673
  • Status: closed  
  • Source: International Business Machines ( James Rumbaugh)
  • Summary:

    I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes:

    1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?)
    1a. Which may be single or possibly multiple (not sure if this is relevant)
    1b. Which may start automatically or may be explicitly started (but why whom??)

    2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke)

    3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive")

    4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary)

    Note that various combinations of these are possible, so an object could be both "active" and "passive".

    But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all?

    The current specification has a lousy definition of the terms, one that is circular.

  • Reported: UML 1.4.2 — Fri, 3 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    It may or may not be better to not use the phrases “active” and “passive”, but this is well established now in UML. The
    2.5 specification is clear that an “active” class is precisely one with “isActive=true”, and the OCL constraintsmake it
    clear what this entails. The other points discussed in the issue are also now more clearly addressed in the specification.
    Disposition: Closed - No Change

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

P.58 Missing closing bracket in second constraint

  • Key: UML25-594
  • Legacy Issue Number: 7669
  • Status: closed  
  • Source: CA Technologies ( Danny Saro)
  • Summary:

    Missing closing bracket in second constraint on P.58

    It reads:

    classifier->forAll(c |

    (c.allFeatures()>forAll(f | slot>select(s | s.definingFeature = f)->size() <= 1)

    )

    And should read:

    classifier->forAll(c |

    (c.allFeatures()>forAll(f | slot>select(s | s.definingFeature = f)->size() <= 1))

    )

  • Reported: UML 1.4.2 — Tue, 10 Aug 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

Compliance points - Diagram Interchange

  • Key: UML25-591
  • Legacy Issue Number: 7651
  • Status: closed  
  • Source: Gentleware AG ( Marko Boger)
  • Summary:

    From letters from Bran Selic and Pete Rivett I learn that the Superstructure
    FTF plans to revoke Diagram Interchange as a compliance point to UML 2
    compliance. As the Chair of the Diagram Interchange FTF I urge you to make
    compliance Diagram Interchange a necessity for full compliance.

    In all discussions I attended it was always pointed out that the ability to
    exchange UML diagrams compliant to a standard using XMI was the single most
    important issue missing in UML 1. The Diagram Interchange specification was
    specifically designed to solve this problem. It is of essence that Diagram
    Interchange remains a part of UML 2 compliance. Otherwise the whole UML 2
    standard is drastically reduces in its value.

    The Diagram Interchange specification is of high quality. It is fully
    implemented by Gentleware to provide a reference, we have made cross checks
    with various other vendors that confirm high quality and interchangability.
    May I also point out that Prof. Mario Jeckle, our friend we miss dearly, has
    implemented an XSLT transformation from XMI to SVG. It is available on his
    web site at www.jeckle.de.

  • Reported: UML 1.4.2 — Fri, 20 Aug 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

included use case wrongly referred to as the including use case

  • Key: UML25-598
  • Legacy Issue Number: 7683
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Section 16.3.5 Include (from UseCases)

    The Semantics section for Inlcude, page 603 in the 042808.pdf convenience document, says "An include relationship between two use cases means that the behavior defined in the including use case is included in the behavior of the base use case."

    For "including" read "included (or addition) " and for "base" read "base (or including)".

    The parenthetical "addition" is needed because this is the term used in the abstract syntax, which does not have "included" as a rolename. Likewise, the abstract syntax does not recognize a role called "base use case" but calls it the "includingCase".

  • Reported: UML 1.4.2 — Tue, 7 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

check the BNF example given in the text

  • Key: UML25-597
  • Legacy Issue Number: 7676
  • Status: closed  
  • Source: Merrill Lynch ( Michael Anderson)
  • Summary:

    I'd check the BNF example given in the text. While an order designator can be used with the grammer shown, the uniqueness designator seems to just be hanging out in limbo.

  • Reported: UML 1.4.2 — Sun, 5 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

Bidirectional messages to a port object

  • Key: UML25-590
  • Legacy Issue Number: 7650
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    How do required and provided interfaces on a port support messages from
    both inside and outside the composite? Messages to a port object sent
    from the inside of the containing composite must be declared in the
    required interface of the port object, but usually messages sent to an
    object must also be declared in the provided interfaces. Is there a
    special case for ports? Didn't see anything in the spec explaining
    this.

  • Reported: UML 1.4.2 — Tue, 31 Aug 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

Figures 120 and 121

  • Key: UML25-589
  • Legacy Issue Number: 7646
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figures 120 and 121 underline the association names, which doesn't
    seem consistent with the notation for instances in Figure 21.

  • Reported: UML 1.4.2 — Fri, 20 Aug 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

"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

P.35 Typo in OCL definition of isDistinguishableFrom query

  • Key: UML25-593
  • Legacy Issue Number: 7668
  • Status: closed  
  • Source: CA Technologies ( Danny Saro)
  • Summary:

    There is a typo in the OCL definition of the isDistinguishableFrom query. The 2nd line of the definition states:

    isDistinguishable =

    This should read as:

    isDistinguishableFrom =

  • Reported: UML 1.4.2 — Tue, 10 Aug 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

misleading omission

  • Key: UML25-553
  • Legacy Issue Number: 18947
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The text in 6.1 and Annex E describing the serialization compatibility between 2.4.1 and 2.5 omits to mention that the clientDependency attribute needs to be present in 2.4.1 and absent in 2.5 for all NamedElements that are the clients of a Dependency. This omission is misleading

  • Reported: UML 2.5b1 — Fri, 20 Sep 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Include wording in 6.1 and Annex E to explain this change. Also point out that ordering may have been
    either added or removed from some properties for semantic consistency

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

Validation errors in UML metamodel

  • Key: UML25-552
  • Legacy Issue Number: 18873
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    A body condition is specified for operation '<<oMGIssueTag>> <Operation> clientDependency () : Dependency [0..*]', but it is not a query.

    A body condition is specified for operation '<Operation> isConsistentWith (redefinee : RedefinableElement) : Boolean', but it is not a query.

    Derived union '<<oMGIssueTag>> <Property> / action : Action [0..1]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / action : Action [0..1]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / classifier : Classifier [0..1]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / directedRelationship : DirectedRelationship [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / directedRelationship : DirectedRelationship [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / memberNamespace : Namespace [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / relationship : Relationship [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / structuredClassifier : StructuredClassifier [0..*]' is not read only.

    IRJA0273E "<Package> Activities" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> Actions."

    IRJA0273E "<Package> CommonBehavior" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

    IRJA0273E "<Package> Deployments" has one or more package import cycles involving "<Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> StructuredClassifiers."

    IRJA0273E "<Package> InformationFlows" has one or more package import cycles involving "<Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> StructuredClassifiers, <Package> UseCases."

    IRJA0273E "<Package> Interactions" has one or more package import cycles involving "<Package> Classification, <Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure."

    IRJA0273E "<Package> SimpleClassifiers" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

    IRJA0273E "<Package> StateMachines" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

    IRJA0273E "<Package> UML" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> Actions."

    IRJA0273E "<Package> UseCases" has one or more package import cycles involving "<Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> StructuredClassifiers."

    IRJA0273E "<Package> Values" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

    Redefining element '<<oMGIssueTag>> <Operation> isDistinguishableFrom (n : NamedElement, ns : Namespace) : Boolean' is not consistent with redefined element '<Operation> isDistinguishableFrom (n : NamedElement, ns : Namespace) : Boolean'. UML::Interactions::Gate::isDistinguishableFrom Model Validation Problem

    Redefining element '<Operation> isConsistentWith (redefinee : RedefinableElement) : Boolean' is not consistent with redefined element '<Operation> isConsistentWith (redefinee : RedefinableElement) : Boolean'. UML::Activities::ActivityNode::isConsistentWith Model Validation Problem

    Redefining element '<Property> region : Region [0..*]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]'. UML::StateMachines::A_redefinitionContext_region::region Model Validation Problem

    Redefining element '<Property> state : State [0..*]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]'. UML::StateMachines::A_redefinitionContext_state::state Model Validation Problem

    Redefining element '<Property> structuredClassifier : StructuredClassifier [0..1]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / structuredClassifier : StructuredClassifier [0..*]'. UML::StructuredClassifiers::A_ownedAttribute_structuredClassifier::structuredClassifier Model Validation Problem

    Redefining element '<Property> transition : Transition [0..*]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]'. UML::StateMachines::A_redefinitionContext_transition::transition Model Validation Problem

  • Reported: UML 2.5b1 — Wed, 14 Aug 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The operations with bodies definitely need to be marked as queries.
    The derived unions definitely need to be marked as readonly. Cyclic package imports are not invalid.
    Three of the redefinitions are in fact invalid:
    region : Region [0..*]’ is not consistent with redefinableElement : RedefinableElement [0..*]
    state : State [0..*]’ is not consistent with redefined element redefinableElement : RedefinableElement [0..*]
    transition : Transition [0..*]’ is not consistent with redefined element redefinableElement : RedefinableElement
    [0..*]’.
    They appear in figure 14.35. The navigable ends of these associations are derived to mean “the nearest
    containing”. The non-navigable ends should be subsets (e.g. “the subset of elements redefined in this
    context that happen to be states”), not redefinitions.
    The remainder are not errors.

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

PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value

  • Key: UML25-547
  • Legacy Issue Number: 18831
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'.
    The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools.

  • Reported: UML 2.5b1 — Thu, 25 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The W3 XML Schema 1.1 DataTypes specification includes an example of a definition of a datatype that is
    conceptually equivalent to that of PrimitiveTypes::UnlimitedLiteral in clause 2.4.1.3 of the XML Schema
    1.1 DataTypes specification: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#atomic-vs-list
    2.4.1.3 Union datatypes
    Union types may be defined in either of two ways. When a union type is ’constructed’ by ’union’, its
    ’value space’, ’lexical space’, and ’lexical mapping’ are the “ordered unions” of the ’value spaces’, ’lexical
    spaces’, and ’lexical mappings’ of its ’member types’. It will be observed that the ’lexical mapping’ of a
    union, so defined, is not necessarily a function: a given ’literal’ may map to one value or to several values
    of different ’primitive’ datatypes, and it may be indeterminate which value is to be preferred in a particular
    context. When the datatypes defined here are used in the context of [XSD 1.1 Part 1: Structures], the xsi:type
    attribute defined by that specification in section xsi:type can be used to indicate which value a ’literal’ which
    is the content of an element should map to. In other contexts, other rules (such as type coercion rules) may
    be employed to determine which value is to be used. When a union type is defined by ’restricting’ another
    ’union’, its ’value space’, ’lexical space’, and ’lexical mapping’ are subsets of the ’value spaces’, ’lexical
    spaces’, and ’lexical mappings’ of its ’base type’. ’Union’ datatypes are always ’constructed’ from other
    datatypes; they are never ’primitive’. Currently, there are no ’built-in’ ’union’ datatypes.
    Example
    A prototypical example of a ’union’ type is the maxOccurs attribute on the element element in XML Schema
    itself: it is a union of nonNegativeInteger and an enumeration with the single member, the string “unbounded”,
    as shown below.
    <attributeGroup name="occurs">
    <attribute name="minOccurs" type="nonNegativeInteger"
    use="optional" default="1"/>
    <attribute name="maxOccurs"use="optional" default="1">
    <simpleType>
    <union>
    <simpleType>
    <restriction base=’nonNegativeInteger’/>
    </simpleType>
    <simpleType>
    <restriction base=’string’>
    <enumeration value=’unbounded’/>
    </restriction>
    </simpleType>
    </union>
    </simpleType>
    </attribute>
    </attributeGroup>
    It is not possible to follow the above example because theMOF/XMI restricts a schemaType to be a datatype
    defined in the XML Schema DataType specification

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

Assocation display options too narrow

  • Key: UML25-549
  • Legacy Issue Number: 18848
  • Status: closed  
  • Source: NIST ( Mr. Raphael Barbau)
  • Summary:

    The options on class and composite diagrams for how associations are displayed (with/without dots, etc) apply to other diagrams, such as package and object diagrams.

  • Reported: UML 2.5b1 — Thu, 1 Aug 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Introduce a class for the association options that generalizes the classes for structure diagrams and use case
    diagrams.

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

Annex E lacks sub-clauses for the XMI details for StandardProfile and UMLDI

  • Key: UML25-548
  • Legacy Issue Number: 18837
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Provide sub-clauses like the resolution for issue 18831

  • Reported: UML 2.5b1 — Wed, 31 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This resolution depends on 18831.
    The nsPrefixes are taken from the UML 2.5 Beta1 XMI artifacts

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

UML 2.5 issue: subsettingContext() has incorrect logic

  • Key: UML25-551
  • Legacy Issue Number: 18859
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The current logic says

    if association <> null then association.endType->excluding(type)

    But if the association has many ends of the same type, this is the wrong logic. Note this is independent of the fact that endType is a set – if it were a bag or sequence all occurrences of the type would be removed.

    It needs to work directly with the memberEnds – remove the current property from the memberEnds and collect the remaining types.

  • Reported: UML 2.5b1 — Wed, 7 Aug 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18788

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

Headed composite and not ownedElement

  • Key: UML25-550
  • Legacy Issue Number: 18858
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In Figure B.3 (UML Diagrams and Diagram Elements) the heading property is composite, but not an ownedElement.

  • Reported: UML 2.5b1 — Wed, 7 Aug 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The heading property is just to identify the label that should conform to the heading syntax given in Annex
    A. It is not necessary for it to be composite. Heading labels will be owned by the diagram element they are
    nested in, like other labels

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

Activity::structuredNode is incorrectly marked as readOnly = true

  • Key: UML25-554
  • Legacy Issue Number: 18948
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Activity::structuredNode is incorrectly marked as readOnly = true

  • Reported: UML 2.5b1 — Fri, 20 Sep 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This appears to be a throwback to 2.4, in which it was also marked as derived - it got marked as not derived
    by the resolution to urgent issue 16232. In 2.4 it was readonly and derived; in 2.4.1 it was neither (which
    means that readonly was removed when the issue was applied, even though the issue did not call for that);
    in 2.5 it has for some reason become readonly again. The only explanation I might offer for this is that
    somebody noticed while applying 16232 that readonly needed to be removed and did it, but this change did
    not get checked in.
    The resolution is to set readOnly to false. The only impact on the specification document is figure 16.45,
    which needs to be changed. The generated classifier descriptions do not contain the

    {readOnly}

    annotation

    • this is a separate issue which will need to be addressed in the future but is too disruptive to address at
      the time of writing. The consequence is that no change is needed to the generated classifier description for
      Activity::structuredNode.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Annex C Keywords p 777 - Capitalization of «trace»

  • Key: UML25-456
  • Legacy Issue Number: 18113
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Throughout the spec, «trace», is indicated to be standard profile stereotype. However in the list of standard profile stereotypes, it is given as «Trace». It is also given as «Trace» in the table of Keywords here in Annex C.
    What is the correct capitalization?
    The document needs to be consistent

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18454

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

Location: Annex C Keywords P. 777 - Previously unmentioned constraints given in Keywords Annex

  • Key: UML25-455
  • Legacy Issue Number: 18112
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The first paragraph gives a number of constraints on model element names, in particular stereotypes. I don't believe this is mentioned in either the NamedElement description or the Stereotype description. I don't think this is a constraint that should be left to an annex, if indeed it should exist: the EJB profile example in figure 12-19 has an Entity stereotype that extends Component as does StandardProfile.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The main problem here is that the “standard stereotypes” are identified as keywords. This gives them
    an undeserved primacy. They should have exactly the same privileges as any user-defined stereotypes:
    which means they should be removed from Annex C altogether. The constraint on stereotype names is
    already defined by name_not_clash in Clause 12, the notation for stereotypes is defined in Clause 12, and
    the standard stereotypes themselves are defined in Clause 22. They don’t belong in Annex C at all.

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

Location: B.6 UMLILabel Constraints. P 766 - Use Case Oval.

  • Key: UML25-453
  • Legacy Issue Number: 18109
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    How are use case ovals (and their titles) handled? As too model elements?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There are two diagram elements because labels are separate from the diagram elements they label, see Annex B.2.4
    (Labels) in the Beta 1.
    Disposition: Closed - No Change

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

Location: B.6 Classifier Description UMLInheritedStateBorderKind [Enumeration] Literals p 763

  • Key: UML25-452
  • Legacy Issue Number: 18108
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    Title: Specification of color
    Description: This is inconsistent with the idea that UML does not prescribe color for notations.
    Proposed Resolution: give a literal of Shaded or Hatched

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The Beta 1 has an enumeration that does not include colors. This portion of the model was changed in 18650, but still
    does not include colors.
    Disposition: Closed - No Change

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

Location: Table B.1 UML Keywords p 778 - Keywords should be in index

  • Key: UML25-458
  • Legacy Issue Number: 18116
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Every keyword should be in the index. Actually none of them are indexed to this location. Some keywords don’t appears in the index at all.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18118

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

Location: Annex C Keywords p 777 - Capitalization of «create»

  • Key: UML25-457
  • Legacy Issue Number: 18114
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Throughout the spec, «create», is someimes spelled with an initial cap and sometimes not, indicated to be standard profile stereotype. However in the list of standard profile stereotypes, it is given as «Create». It is also given as both «Create» and «create» in the table of Keywords here in Annex C.
    What is the correct capitalization?
    The document needs to be consistent

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18454

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

Location: Index p. 796 among others - Index items with only one page

  • Key: UML25-464
  • Legacy Issue Number: 18122
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    I think there are few items that should appear only once in the index.

    For example, look at isTabbed. it appears in the index with a page # of 769 which is where the formal classifier description appears. However, isTabbed also appears on page 751 where the field is described.

    as another example, look at isSynchronous which is indexed from page 527 the formal areas, but isSynchronous is defined on page 479.

    It is also used on page 672

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18118

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

Location: Index p 795 - Index of "is"

  • Key: UML25-463
  • Legacy Issue Number: 18121
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Why would "is" be in the index. "Is" is not a UML specific term.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18118

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

Location: Index

  • Key: UML25-460
  • Legacy Issue Number: 18118
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Neil Capey)
  • Summary:

    Entries don't hyperlink back to the main document (this is a show stopper for me).

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The SMSC has determined that OMG specifications should not contain an index

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

Location: Annex C Keywords P. 780 - Bizarre definition of statemachine

  • Key: UML25-459
  • Legacy Issue Number: 18117
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The keyword statemachine has semantics "BehavioredClassifer::self.oclIsKindOf(StateMachine)". Surely the semantics should just be "StateMachine" with a separate keyword for ProtocolStateMachine.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18124

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

Location B.6 UMLStateShape statelist p 770 - StateList Limitations

  • Key: UML25-454
  • Legacy Issue Number: 18111
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    State lists are not limited to no triggers
    See Figure 14-13 and Figure 14-14.

    They are limited to no effects, though I don't see why

    Also this does not cover Figure 14-13, which has the transition F going back to the original state. This can't be modeled as transition to a junction pseudostate. Either transition F is not legal for a state list, or this paragraph is overly restrictive.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18106

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

Location: Index p 793 - emergent behavior

  • Key: UML25-462
  • Legacy Issue Number: 18120
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the spec, emergent is a special term with its own definition (not exactly the term as used outside the specification)

    The different uses of the term should be made conforming.

    1) emergent behavior as in 13.1
    vs
    2) emergent behavior as in 13.2.3 (2x), 13.4, or 18.1.1
    vs
    3) Emergent Behavior as in 17.1.4

    It should certainly be in the index.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17965

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

Location: Index Mis. - Missing terms in the Index

  • Key: UML25-465
  • Legacy Issue Number: 18123
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    'alphabet' missing
    'Boolean' missing
    'Character Set' missing
    'false' missing
    'floating point' missing
    'Integer' missing
    'infinity' missing
    'OCL' missing
    'OCL expression' missing
    'primitive' missing
    'PrimitiveType' reference to Section 21 missing
    'PrimitiveTypes' missing
    'Real' missing
    'String' missing
    'true' missing
    'unbounded' missing
    'Unicode' missing
    'UnlimitedNatural' missing

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18118

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

Type: Structural - Location Index p 790, 794,

  • Key: UML25-461
  • Legacy Issue Number: 18119
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Neil Capey)
  • Summary:

    Short index entries: alt, in, and is are not formatted corrected.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18118

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

Location: 15.5.1 - typo

  • Key: UML25-394
  • Legacy Issue Number: 18014
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Detail; the word used is not a word, "produceas", perhaps what is wanted is "as"

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Location: Figure 15.57 page 426

  • Key: UML25-393
  • Legacy Issue Number: 18013
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Detail:
    Explain how the exception works with the other out parameter.
    Should Accepted Computers also be streaming?
    If not, under what circumstances are the AcceptedComputers released?
    Without an exception, how would this stop?
    Does the AcceptedComputers only release when rejectedcomputers is raised and handled; otherwise when would it be released?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This example is problematic a couple of ways. First, the fact that the input parameter is streaming would,
    indeed, seem to indicate that the outputs should be streaming. However, it is not allowed for a parameter to
    be both isStream and isException (constraint Parameter::stream_and_exception). Second, the description of
    example implies that computers are sorted into rejected and accepted. However, in Subclause 15.2.3 it states
    “An output posted to an exception Parameter precludes outputs from being posted to other output Parameters
    of a Behavior.” So having any rejected computers would preclude having any accepted computers.
    The intent of the examples in Subclause 15.4.5 are simply to illustrate the use of ActivityParameterNodes,
    including for streaming and exception Parameters. However, the examples should do this in a way that
    makes sense.

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

Location: 17.2.3 Semantics Interaction Fragments p 607

  • Key: UML25-399
  • Legacy Issue Number: 18023
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    Title: Reference to “InteractionOperator” should instead say “InteractionOperand”
    Description:
    current text
    An InteractionFragment may either be contained directly in an enclosing Interaction, or may be contained within an InteractionOperator of a CombinedFragment,

    Discussion:
    In that sentence, “InteractionOperator” should be changed to “InteractionOperand.” The InteractionOperand metaclass has an association end “fragment : InteractionFragment.” An interaction operator, on the other hand, is simply an attribute of a combined fragment; it has no association with an interaction fragment.

    Proposed Resolution:
    Change “InteractionOperator” to “InteractionOperand” in that sentence.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    In that sentence, “InteractionOperator” should be changed to “InteractionOperand.” The InteractionOperand
    metaclass has an association end “fragment : InteractionFragment.” An interaction operator, on the other
    hand, is simply an attribute of a combined fragment; it has no association with an interaction fragment.
    Change “InteractionOperator” to “InteractionOperand” in that sentence.

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

17.1.5 Interaction Diagram Variants p 607

  • Key: UML25-398
  • Legacy Issue Number: 18021
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    What is the rationale for making Timing Diagrams optional for tool compliance?

    Description:
    This clause states, “Conformant UML 2.5 tools are not required to implement Timing Diagrams.” UML 2.5 takes the bold step—which I favor—of eliminating the formal compliance levels, and then carves out caveats in the fine print. What is the rationale for making Timing Diagrams part of the UML spec., but then stating that they’re optional for tool compliance?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Most existing implementations do not implement timing diagrams, so this recognizes established practice.
    Disposition: Closed - No Change

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

Location: p 484 - Exception store

  • Key: UML25-397
  • Legacy Issue Number: 18019
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    1) Makes sense to have the notation for an exception store to be a triangle
    2) The left most action on this diagram is an exceptionhandler.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue is on Figure 16.19 in Subclause 16.3.4, under “Pin Annotations”. The triangle notation here is on a Pin
    corresponding to a Parameter with isException = true, not to a “store” for a raised exception. Therefore, the leftmost
    action is not an exception handler and the arrow is just a normal ObjectFlow.
    Disposition: Closed - No Change

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

Location: Figure 15-23 p.411

  • Key: UML25-396
  • Legacy Issue Number: 18017
  • Status: closed  
  • Source: Alion Science and Technology ( Jim Logan)
  • Summary:

    Figure 15-23 shows streaming activity edges--are those control flows or object flows? I don't think control flows can stream, and these activity edges don't look like object flows to me.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Location: Figure 15-23

  • Key: UML25-391
  • Legacy Issue Number: 18007
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Use

    {stream}

    not [stream]

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Location: p. 357 StateMachine Redefinition

  • Key: UML25-390
  • Legacy Issue Number: 18005
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    StateMachine Redefinition Notation
    As far as I remember, this is a new specification in UML 2.5. The semantics of redefining state machine is clear. I find it rather confusing is the notation. When you redefine a generalized state machine, you typically do not want to redraw the whole state machine. The proposed notation means that the whole state machine must be re-drawn with the added modeling elements.

    Also, this notation supports only the addition to the generalized state machine, but not the deletion or modification of the generalized state machine

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Location: p. 338 Transition execution sequence

  • Key: UML25-389
  • Legacy Issue Number: 18004
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    Transition execution sequence
    In this sequence, missing is the transition action. When does the action associated with a transition execute?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18003

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

Location: p. 338 Transition execution sequence

  • Key: UML25-388
  • Legacy Issue Number: 18003
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    Transition execution sequence
    In this sequence, missing is the transition action. When does the action associated with a transition execute?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add the missing item in the list that describes the transition execution sequence.

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

Location: Figure 15-63

  • Key: UML25-395
  • Legacy Issue Number: 18015
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Detail:
    Unclear why this Alternative ExceptionHandler notation requires pins on both ends, when the standard notation only has a pin on one side. Perhaps pins should always be there, or never be there.

    The description just has the zig-zag adornment on a straight line and does not mention the pins

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The diagram is incorrect.

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

Location: p. 337 Conflicting Transitions

  • Key: UML25-387
  • Legacy Issue Number: 18002
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    Clarification of conflicting transitions
    This requires clarification. So, does this mean that conflicting transitions are not allowed? Sometimes conflicting transitions can only be identified at run time, for example, in the case of guarded transitions.

    The following paragraph clarifies some of the ambiguity, but not all of it. Still, the case when two transitions are at the same nesting level is still ambiguous.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 9840

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

Location: Page 413, 15.3.2 Abstract Syntax Control Nodes Figure 15-26

  • Key: UML25-392
  • Legacy Issue Number: 18008
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Multiplicity Limitations on DecisionInputFlows

    It does not seem logically necessary that a particular ObjectFlow can only connect to [0..1] DecisionNodes. Why can't more be connected?
    For example, the same ObjectFlow could be used in multiple swimlanes.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Location: p. 337 Conflicting Transitions

  • Key: UML25-386
  • Legacy Issue Number: 18001
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    Explain how conflicts arise
    I suggest to add text to explain that this happens in the case of higher transition exiting a composite state machine or a state that has regions

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

What is “Intentionally Not specified”?

  • Key: UML25-317
  • Legacy Issue Number: 17898
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “The precise lifecycle semantics of composite aggregation is intentionally not specified.” (and two following sentences)

    [AC] Is it explained somewhere in the spec what is the meaning of the “intentionally not specified” expression? Not by bad intentions, I suppose, but the reader may wonder why.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This topic is introduced in clause 2, Conformance. Clarify the text to include the phrase “intentionally not
    specified”.

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

What is aggregation

  • Key: UML25-316
  • Legacy Issue Number: 17897
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Composite aggregation is a strong form of aggregation that requires a part (see 11.2.3) instance be included in at most one composite instance at a time.”

    [AC] It could be also useful to explain in general terms what an aggregation (whether shared or composite) is.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Explain aggregation better

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

inout parameters and effects

  • Key: UML25-311
  • Legacy Issue Number: 17891
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Problem: 9.023
    Severity: minor
    Type: clarification
    Location: 9.4.3 p 118
    Title: inout parameters and effects
    Description:
    Current Text:
    Only in and inout Parameters may have a delete effect. Only out, inout, and return Parameters may have a create effect.

    1) What is passed out for a deleted inout Parameter
    2) What happens to the input if a create effect is applied to an inout Parameter

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue arises from a mistaken impression that an inout parameter requires the same value to go in and
    out. Correct the text to avoid giving this impression.
    This also resolves 18759.

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

Effect Intent

  • Key: UML25-310
  • Legacy Issue Number: 17890
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “The effect property may be used to declare additional indications of the effect on values passed in or out of a Parameter. It is a declaration of the modeler's intent, and does not have execution semantics: the modeler must ensure that the Parameter has the stated effect.”
    [AC] The implementation, not the modeler, must ensure the effect.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17584

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

Return Parameter order

  • Key: UML25-308
  • Legacy Issue Number: 17888
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “A single Parameter may be distinguished as a return Parameter.“

    [AC] This sentence should be placed after the following one, and made clearer. I guess its meaning is “Only one Parameter may be marked as return

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Yes, it needs rewording and moving. This also resolves 17889.

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

Default value of readonly should be referenced

  • Key: UML25-307
  • Legacy Issue Number: 17887
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “If a StructuralFeature is marked with isReadOnly true, then it may not be updated once it has been assigned an initial value. Conversely, when isReadOnly is false, the value may be modified at any time.”

    [AC] I would say that when isReadOnly is not marked (i.e. is false, that is the default, see page 163) then the values can be modified.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Parameter Sets

  • Key: UML25-313
  • Legacy Issue Number: 17893
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    AC] The last two paragraphs in the 9.4.3 section are about ParameterSets. They are really unclear to me. I guess ParameterSets are intended to be only defined and used when an alternative exist, but an example would be in my opinion very useful.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There is further explanation and examples in 16.3. Add a forward reference to it.

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

isException and direction and effect

  • Key: UML25-312
  • Legacy Issue Number: 17892
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Current text: The isException property applies to output Parameters

    1) Does this mean that isException can apply to inout parameters?
    2) Should isException always have effect=create?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    1) No - this is excluded by Parameter::not_exception
    2) No. Firstly, effects are optional. Secondly, there seems no more reason to put constraints on the effect of an
    exception parameter than on any other out parameter.
    Disposition: Closed - No Change

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

Location: 9.5.3 p 122 In the common case

  • Key: UML25-320
  • Legacy Issue Number: 17901
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    Suggest: In the specific case

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Simplify the explanation to remove statements about what is commonly done.

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

Location: 9.5.3 p 121 Why not all empty

  • Key: UML25-319
  • Legacy Issue Number: 17900
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    If only one instance has all values with the isID true to be empty, what’s the problem.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    I’m not sure there is a problem, and because the spec intentionally leaves this implementation-independent,
    it seems an unnecessary restriction - maybe there is some technology for which one instance might validly
    have an empty ID.

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

Use isReadOnly default

  • Key: UML25-314
  • Legacy Issue Number: 17895
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “A read only StructuralFeature is shown using

    {readOnly} as part of the notation for the StructuralFeature. This annotation may be suppressed, in which case it is not possible to determine its value from the diagram. Alternatively a confirming tool may only allow suppression of the {readOnly}

    annotation when isReadOnly=false. In this case it is possible to assume this value in all cases where

    {readOnly}

    is not shown.”

    [AC] In the metamodel, isReadOnly=false is the default. If nothing is shown, the default should be assumed, I suppose

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The original text is quite clear about what it means if nothing is shown. Still, in an effort to address whatever
    the issue is, make it clear that false is the default, and fix the typo for “conforming”.

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

Redefinition does not allow for overloading

  • Key: UML25-315
  • Legacy Issue Number: 17896
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Feature redefinitions may either be explicitly notated with the use of a

    {redefines <x>}

    property string on the Feature or implicitly by having a Feature with the same name as another Feature in one of the owning Classifier’s more general Classifiers. In both cases, the redefined Feature shall conform to the compatibility constraint on the redefinitions.

    By allowing reuse of the name to cause redefinition, you prevent overloading. A class should be allowed to more than one operation with the same name with different argument lists.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    We should be more precise and require a compatible signature as well as the same name

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

What is “Intentionally Not specified”?

  • Key: UML25-318
  • Legacy Issue Number: 17899
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “A Property may be marked, via the property isID, as being (part of) the identifier (if any) for Classifiers of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML. If multiple Properties are marked (possibly...”

    [AC] I would specify “are marked as isID (possibly…”

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Note that the title of this issue is wrong, and really belongs to 17898. This issue is editorial.

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

Return Parameter pronoun

  • Key: UML25-309
  • Legacy Issue Number: 17889
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Its type is ParameterDirectionKind”.

    [AC] The subject of this sentence should be the Direction property, but the pronoun comes after another sentence, whose subject is differ

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17888

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

Two categories is not enough

  • Key: UML25-223
  • Legacy Issue Number: 17767
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Using only 2 semantic categories forces Use Cases into the Behavioral semantics category, which is not appropriate by the definition. An additional category of Intentional, Goal, or Requirement Semantics is needed to cover the Use cases. This is supported by the Use Cases clause not being in the behavior section of the document.

    Making this change will probably required changes to the diagram of diagrams in Appendix A and Figure 6.1 below. However as these are only explanatory (not normative) they should not impact users, except to make it more understandable.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17768

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

UML Semantics

  • Key: UML25-222
  • Legacy Issue Number: 17766
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The UML semantics are defined in the UML spec. This is confusing.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    A distinction is being made in 6.3.2 between the MOF semantics that apply to the interpretation of the UML
    abstract syntax model by a tool that conforms to that and the semantics of UML models themselves. But
    perhaps this could be better expressed in the first paragraph

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

Semantics Areas section not clear

  • Key: UML25-224
  • Legacy Issue Number: 17768
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Figure 6.1 gives some semantic areas and the following paragraphs are intended to describe them. I don't think this is done terribly clearly. In particular the specific terms given in the diagram don't all appear in the text as is (Structural Foundations, Inter/Intra-Object Behavior Base); it's not clear what the middle area actually is as the diagram doesn't name it; and the structure of the paragraphs doesn't match the areas.

    The middle paragraph, "The base behavioral...", is particularly unclear - I don't think the second clause of the first sentence actually makes sense. It also includes a 'Note' that isn't really a note at all since it gives a fundamental property of the behavioral semantics.

    Proposed Resolution:

    Add titles to the diagram to identify the areas, perhaps on the right hand side:
    Higher-level formalisms
    Base behavioral semantics
    Structural semantics

    Make each paragraph correspond exactly to an area in the diagram. This largely means that the middle paragraph should be rewritten to include the actions text and object communication information. (Why not just call the *-Object Behavior Base, "Object Communication"?)

    Split the 'Note' into a separate final paragraph that isn't described as a note, just more detailed information about the nature of UML behaviors.".

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Figure 6.1 was carried over from the UML 2.4.1 specification. It should have been replaced with a figure
    more appropriate to the new text.
    This also resolves issue 17767.

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

Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Variants are not defined

  • Key: UML25-413
  • Legacy Issue Number: 18047
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Each UseCase specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more Actors”.

    [AC] I think the clause “possibly including variants” could and should be avoided, because: a) “variant” is not a term defined in the specification, and could be interpreted differently by different readers
    b) it does not lead to a better explanation of what a behavior specification is.

    However, the clause “possibly including variants” was also included in the 11-08-06 version

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed. “Possibly including variants” is not the language of a normative specification. The variation capabilities
    (include, extend) are specified elsewhere

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

Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Actors need not initiate

  • Key: UML25-412
  • Legacy Issue Number: 18046
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Each UseCase specifies a unit of useful functionality that the subject provides to its users (i.e., a specific way of interacting with the subject). This functionality, which is initiated by an Actor, must always be completed for the UseCase to complete.”

    [AC] I think the clause “which is initiated by an Actor” is wrong, according to the use case theory formulated by Jacobson, where each use case must provide value to an actor, but not necessarily be initiated by an actor, because there are also time-triggered use cases.

    What's more, this clause does not correspond to any constraint in the metamodel. So, even if it was also in the 11-08-06 version, I suggest to remove it

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Are actors mandatory?

  • Key: UML25-411
  • Legacy Issue Number: 18045
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    current text: “A UseCase is the specification of a set of behaviors performed by a subject, which yields an observable result that is of value for one or more Actors”
    Other than this and the next paragraph, there is no indication that an actor is mandatory, e.g., no OCL, no relationship on the diagram. Consider updating the Figure 18.1 UseCases to show a relationship between the actors and usecases to make a use case require an actor.

    In addition, this is contradicted by p 686, which says: “UseCases may have associated Actors,”, which seems to indicate that actors are not mandatory.

    So
    • Make the text consistent between 685 and 686
    • Consider updated Figure 18-1 to show at least one actor
    • Consider adding OCL to force at least one actor.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Changing the multiplicity or adding a constraint would be inappropriate because it could break existing
    models, so change the wording.
    This also resolves issues 18079 and 18080

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

Location: Pg. 615, Figure 17.4.3: Semantics, Sub-clause: Messages

  • Key: UML25-405
  • Legacy Issue Number: 18034
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    his clause states, “A lost Message is a Message where the sending event occurrence is known, but there is no receiving event occurrence. We interpret this to be because the Message never reached its destination.”
    The semantics described in the second sentence seem unnecessarily strict. Additionally, this interpretation for a lost Message is inconsistent with the interpretation of a found Message described in the next paragraph: “We interpret this to be because the origin of the [found] Message is outside the scope of the description.” The semantics of a lost Message should be similar.

    Proposed Resolution:

    Change the second sentence in the excerpt to read: “We interpret this to be because the destination of the [lost] Message is outside the scope of the description.”

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Change the second sentence in the excerpt to read: “We interpret this to be because the destination of the
    [lost] Message is outside the scope of the description.”.

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

Pg. 613, Clause 17.3.4: Notation

  • Key: UML25-404
  • Legacy Issue Number: 18032
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    Title: Incomplete grammar for “<lifelineident>” in Clause 17.3.4
    Summary: This clause specifies the following grammar for “<lifelineident>”:

    <lifelineident> ::= ([<connectable-element-name>[‘[‘<selector>‘]’]] [: <class_name>][decomposition]) | ‘self’

    “<class_name>”, however, is too restrictive for the type. A lifeline may represent an instance of an Actor, not just an instance of a Class. In fact, the metamodel, as written, allows a lifeline to represent an instance of any type of BehavioredClassifier. Here are the relationships:

    A lifeline represents 0..1 instances of ConnectableElement.
    ConnectableElement is a type of TypedElement.
    TypedElement has an association with 0..1 instances of Type.
    BehavioredClassifier is a type of Classifier, which is a type of Type.
    BehavioredClassifier has 4 specializations: Class, Actor, UseCase, and Collaboration.

    Therefore, any of these 4 subtypes may serve as the type of the connectable element that a lifeline represents. But only 2 of these make sense in the context of a lifeline: Class and Actor. So there are really 2 problems that need to be resolved. Recommendations provided below

    Proposed Resolution:
    1) The grammar for “<lifelineident>” needs to be expanded to allow for an actor to serve as the type of the connectable element that a lifeline represents, and
    2) A constraint needs to be introduced to allow only two of the four subtypes of BehavioredClassifier to serve as the type of the connectable element that a lifeline represents.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18748

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

Location: Pg. 612, Clause 17.2.5 - Minor rewording to Clause 17.2.5

  • Key: UML25-403
  • Legacy Issue Number: 18029
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    This clause states, “The :User sends a message Code and its duration is measured.” I don’t believe it’s meaningful to refer to a message’s duration; neither the Duration metaclass nor the DurationObservation metaclass have an association with the Message metaclass. Rather, the DurationObservation metaclass is associated with 1..2 NamedElements that are the event occurrences on either end of the observation. In the case of a Message, those event occurrences are the “send” and the “receive.” I recommend rewording the excerpted sentence as shown below.

    Proposed Resolution:
    Recommend rewording the sentence as follows: “The :User sends a message Code and the duration between its send and receive occurrences is measured.”

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Reword the sentence as follows: “The :User sends a message Code and the duration between its send and
    receive occurrences is measured.”.

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

Location: Pg. 612, Figure 17.5 - Modify Figure 17.5 to enhance readability

  • Key: UML25-402
  • Legacy Issue Number: 18027
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    The placement of the labels “CardOut

    {0..13}” and “OK” is ambiguous. A reader may confuse which message they are associated with. Also, the non-UML arrow associated with the “TimeObservation” label (outside of the diagram frame) is unnecessarily cluttering the diagram.

    Proposed Resolution: Move the “CardOut {0..13}

    ” and “OK” labels to eliminate the ambiguity. Move the “TimeObservation” label to the right side of the figure to de-clutter the diagram.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Do not agree that the caption placements in Figure 17.5 are ambiguous, especially since a similar caption placement
    is used in Figure 17.3.
    Also, the TimeObservation red arrow pointer is acceptable as it is in Figure 17.5.
    Disposition: Closed - No Change

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

Location: 18.1.1 Summary P. 685 - A Subject may only refer to a single system

  • Key: UML25-410
  • Legacy Issue Number: 18044
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “A UseCase’s subject represents the system or systems under consideration to which the UseCase applies.”

    [AC] This addition wasn't in the previous UML version, 11-08-06, where the description was “The subject is the system under consideration to which the use cases apply.”

    I consider the plural “or systems” ambiguous, because it lets the reader think that the subject may refer to more than a single system.
    If we want to say that the subject may be a very complex one, such as a system of systems (and this may be indeed useful in my opinion) we should state this point explicitly.

    So I suggest to go back to the previous formulation, or to state more explicitly that the subject may refer to an arbitrarily complex system

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Reword as suggested.

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

General value lifeline Row p 647

  • Key: UML25-409
  • Legacy Issue Number: 18042
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    picture is missing

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Include figure from UML 2.4.1 table

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

Location: Table 17.6 entire table p 646

  • Key: UML25-408
  • Legacy Issue Number: 18041
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Detail: Cell boundaries often stepped on by diagrams in 2nd column, partial elements in some cells.

    Example: Frame row page 646

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agree to resize the figures to fit within the cell boundaries of the table

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

Pg. 611, Clause 17.2.5: Examples - : Insert “formal” in reference to gates in the “Examples” clause (17.2.5)

  • Key: UML25-401
  • Legacy Issue Number: 18026
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    This clause states, “Finally a fourth message is sent from the ACSystem to the environment through a gate with implicit name out_Unlock.” I recommend inserting the word “formal” in front of “gate” to help readers reinforce the connection to what they’re seeing on the diagram in Figure 17.3.

    Proposed Resolution: Insert “formal” in front of “gate” in that sentence.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Insert “formal” in front of “gate” in that sentence

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

Location: 17.2.4 Notation ExecutionSpecification p608 - : Specification of color

  • Key: UML25-400
  • Legacy Issue Number: 18025
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    Description: This clause states, “ExecutionSpecifications are represented as thin rectangles (grey or white) on the lifeline.” However, this is inconsistent with the idea that UML does not prescribe color for notations

    Proposed Resolution: In place of references to color, we should stick with the convention of using the terms “hollow” to mean the same color as the diagram background and “solid” to mean the same color as the boundary of the node or the path notation. In the case of overlapping notations (e.g. ExecutionSpecifications), perhaps the spec. can prescribe patterns (e.g. cross-hatch) instead of color.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Close no change, clause 6 defines black grey or white.
    Disposition: Closed - No Change

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

Location: LostMessage Row p 639

  • Key: UML25-407
  • Legacy Issue Number: 18039
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    “the Receiver is either not known, out of scope, or does not happen”

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Should clarify along with resolution to 18034

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

Pg. 617, Figure 17.4.3: Semantics, Sub-clause: Gates - Replace “formal” with “actual” in Clause 17.4.3

  • Key: UML25-406
  • Legacy Issue Number: 18035
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    This clause states, “Gates are matched by name, with a formal Gate matched with a formal Gate having the same name, and with an inner CombinedFragment Gate matched with an outer CombinedFragment Gate having the same name.” The second occurrence of the word “formal” should be replaced with “actual” to be consistent with the idea expressed about CombinedFragment gates in the second part of the sentence, “…inner…matched with an outer…”.

    Proposed Resolution: Replace the second occurrence of the word “formal” with “actual”.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Replace the second occurrence of the word “formal” with “actual”.

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

Default value for LiteralString

  • Key: UML25-264
  • Legacy Issue Number: 17817
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Why does LiteralString have no default value? suggest the Empty string. Discussion:
    If the answer to this relates to problem 8.001, then a detailed explanation is required in the spec.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The real question is why some LiteralSpecifications have a default value, more than why LiteralString does not. The
    only reason that certain LiteralSpecifications still have default values in UML 2.5 is for backward compatibility with
    the UML 2.4.1. In particular, removing default values for LiteralInteger and LiteralUnlimitedNatural would have a
    significant effect on how multiplicity bound are serialized in user models.
    Disposition: Closed - No Change

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

Optional String Multiplicity

  • Key: UML25-263
  • Legacy Issue Number: 17816
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Why is the multiplicity for String include 0, but the multiplicities for the other literals do not? LiteralString should be as optional as LiteralBoolean

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    LiteralString::value has a multiplicity of 0..1 in UML 2.5 for no other reason than to maintain backward compatibility
    with the UML 2.4.1 metamodel, which was a goal for UML 2.5. A LiteralString with no value essentially represents
    a string of “no characters” and so is equivalent to a LiteralString whose value is the empty string.
    Disposition: Closed - No Change

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

Excessive null checks

  • Key: UML25-256
  • Legacy Issue Number: 17808
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    There are lots of checks for whether lowerBound() and upperBound() are null in various operations. However when would either of those operations return null? And if either of them did, wouldn't it just be invalid?

    Source: dave.hawkins@oracle.com

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 13992

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

Single and set of aren't really parallel

  • Key: UML25-255
  • Legacy Issue Number: 17806
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Original:
    that a single or a set of model Elements requires

    Proposed Resolution:
    that a single model Element or a set of model Elements requires

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the suggestion. (This text appears in the description of the Dependency class.)

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

Missing a

  • Key: UML25-252
  • Legacy Issue Number: 17802
  • Status: closed  
  • Source: Oracle ( Dominique Poudret)
  • Summary:

    "attached to set" should read "attached to a set"

    Proposed Resolution:

    Add the missing "a".

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The phrase “attached to set” does not seem to appear anywhere in the UML 2.5 beta document. Perhaps the issue was
    based on review of an earlier version.
    Disposition: Closed - No Change

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

inconsistent spacing on diagram

  • Key: UML25-251
  • Legacy Issue Number: 17801
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    First attribute
    purchase : Purchase [*]….
    Second attribute
    account: Account [0..5]

    Inconsistent space between name and “:” distracts from message of diagram
    Source: Michael Jesse Chonoles

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

TypedElement description could be expanded

  • Key: UML25-260
  • Legacy Issue Number: 17812
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The description of TypedElement should say something about it representing values, which the Type description implies.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The description of the TypedElement metaclass is sufficient to describe it syntactically. The semantics of TypedElement
    as a representation and its relationship to Type is covered in 7.5.3 (as revised by the resolution to Issue 17797).
    Disposition: Closed - No Change

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

It seems to me that a relationship requires a minimum of two relatedElements

  • Key: UML25-259
  • Legacy Issue Number: 17811
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    It seems to me that a relationship requires a minimum of two relatedElements

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Use of the diamond symbol (?)needs to be explained

  • Key: UML25-254
  • Legacy Issue Number: 17805
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Place in the material explaining the format of the spec.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    It already is explained in 6.4.1:
    “If the association end is a composition, this is indicated by a small black diamond adjacent to the name of the end.”
    Disposition: Closed - No Change

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

Instantiate Dependency

  • Key: UML25-253
  • Legacy Issue Number: 17804
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Shouldn't the Car class depend on the CarFactory class? (as the text states) It doesn't seem like the instance of CarFactory depends on instance of Car which the figure suggest

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 11489

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

Generalization Relationship to itself?

  • Key: UML25-261
  • Legacy Issue Number: 17813
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Generalization Relationship:
    A subclass of the owning package,
    or a superclass of the owning package or
    Does the owning package have a generalization relationship to itself?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The location referenced in the issue is to the list of literals for VisibilityKind. However, it is not clear what the issue
    is really asking. The only use of the term “generalization relationship” is in the definition of “protected” visibility,
    which says “A NamedElement with protected visibility is visible to Elements that have a generalization relationship
    to the Namespace that owns it.” This means that the Namespace owning the element must be the general Element in
    the generalization relationship (generalization is “to” the general element). However, Generalization is only defined
    for Classifiers, not Packages, so there is no “owning package” here.
    Disposition: Closed - No Change

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

Negatively phrased sentence

  • Key: UML25-262
  • Legacy Issue Number: 17814
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Is there some way of saying this clearly?

    Outside the nearest enclosing Package, a NamedElement marked as having package visibility is not visible. Only NamedElements that are not owned by Packages can be marked as having package visibility

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This quoted text leaves out the first sentence of the description of VisibilityKind::package, which is “A NamedElement
    with package visibility is visible to all Elements within the nearest enclosing Package (given that other owning
    Elements have proper visibility).” This is a positive sentence and the primary definition. Given what the semantics of
    this really is, it is not apparent how to say it more clearly.
    Disposition: Closed - No Change

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

Sentence difficult to read

  • Key: UML25-258
  • Legacy Issue Number: 17810
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Current Text
    The query allOwningPackages() returns all the Packages that in which this NamedElement is directly or indirectly contained, without any intervening Namespace that is not a Package.

    Rewrite using simple sentences

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed that the description could be improved

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

allNamespace description doesn't match OCL

  • Key: UML25-257
  • Legacy Issue Number: 17809
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The allNamespaces operation is described as "working outwards." However the OCL uses the prepend operation, which produces a sequence that works inwards.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Location p 152 Generalization Attributes: IsSubstitutable

  • Key: UML25-338
  • Legacy Issue Number: 17920
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “isSubstitutable : Boolean [0..1] = true Indicates whether the specific Classifier can be used wherever the general Classifier can be used. If true, the execution traces of the specific Classifier shall be a superset of the execution traces of the general Classifier. If false, there is no such constraint on execution traces. If unset, the modeler has not stated whether there is such a constraint or not.”

    [AC] I have always assumed that substitutability is a fundamental characteristic of generalizations, not an option. I may be wrong, of course, but I would like to see in the spec a discussion of this topic. If it is in the spec, I have not found it.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    In the beta spec, isSubstitutable is not mentioned in the main semantics clause and should be.
    Generalization, in object-oriented design, implies substitutability in some context. It is not always the case
    that generalization implies substitutability in every possible context. The isSubstitutable property is intended
    to indicate those cases

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

Location p 153 complete_and_disjoint: Abstract Implication

  • Key: UML25-340
  • Legacy Issue Number: 17922
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    I'm not sure this is correct. i see the logic of saying this, but I can imagine circumstances where the generalization would be complete and disjoint, but the generalization class would be useful to instantiate as a temporary until I determine which one of the subclasses it is.

    Forcing it to be abstract is a coding style limitation, which should not be required

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Actually this constraint was not there in UML 2.4.1 so should not have been introduced, independently of
    coding style discussions.
    In the related examples in clause 9, the superclass is in fact abstract; remove the implication that this is a
    consequence of the generalization set.

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

Location p 153 complete_and_disjoint: Complete vs covering?

  • Key: UML25-339
  • Legacy Issue Number: 17921
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Location p 153 complete_and_disjoint: Complete vs covering?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This is a complaint about the fact the complete and covering are synonyms. But they are clearly defined as synonyms
    in 9.7.3 and the notation uses the word complete while the metamodel uses the word covering. We don’t want to
    change either metamodel or notation.
    Disposition: Closed - No Change

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

Location: p 145 CallConcurrencyKind [Enumeration - blocks -- > locks

  • Key: UML25-334
  • Legacy Issue Number: 17916
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “guardedMultiple invocations of a BehavioralFeature may occur simultaneously to one instance, but only one is allowed to commence. The others are blocked until the performance of the currently executing BehavioralFeature is complete. It is the responsibility of the system designer to ensure that deadlocks do not occur due to simultaneous blocks.”
    Typo: should be locks.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17915

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

Location: p 145 (3X) Detail: simultaneously -- > concurrently

  • Key: UML25-333
  • Legacy Issue Number: 17915
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    These words mean something different. Concurrently would include overlapping calls, simultaneously means at the same instant.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Rephrase to use the word “overlapping” rather than “simultaneous”. Also make the metamodel documentation
    consistent.
    This also resolves 17916.

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

Location p 146 Classifier Description: isAbstract

  • Key: UML25-337
  • Legacy Issue Number: 17919
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “isAbstract : Boolean [1..1] = false
    If true, the Classifier does not provide a complete declaration and cannot be instantiated.”

    [AC] I would remove “does not provide a complete declaration and”, because the completeness of declaration is not the point of abstraction.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed. The semantics of isAbstract are spelled out fully in the main semantics and this should be a summary
    of that

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

Location p 145 Classifier Description: objects -> instances

  • Key: UML25-336
  • Legacy Issue Number: 17918
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “A Classifier represents a classification of objects according to their Features. Classifiers are related by Generalizations.”

    [AC] Classifiers are also related by other relationships

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This sentence adds no value and simply serves to confuse

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

Location p 162 two_parameter_sets: Why

  • Key: UML25-343
  • Legacy Issue Number: 17925
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    It should be possible to have two parametersset that are the same, but taking different paths in the activity diagram

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Parameter sets can’t have edges linked to them, so it wouldn’t be possible to distinguish paths based on parameter sets.
    A fork is needed after each parameter.
    Disposition: Closed - No Change

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

Location p 157 isConsistentWith: missing rules

  • Key: UML25-342
  • Legacy Issue Number: 17924
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Even though an operation it has the same # of parameters and the type is the same, does not really make the types match.
    For example, changing effect or unique--> nonUnique would change the “effective” type though not in a way that UML recognizes

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 15499

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

Location p 154 Association Ends: Instances of multiple classifiers

  • Key: UML25-341
  • Legacy Issue Number: 17923
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    If there can be more than one classifier, there could be more than one structuralfeature with the same name. How are these handled, or notated. They may have different types.
    Could also have two operations with the same name.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This refers to the notation for InstanceSpecification. Qualified names can be used to disambiguate

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

Location p 162 ParameterSet constraints input: Exceptions and parameterset

  • Key: UML25-344
  • Legacy Issue Number: 17926
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    It appears that as Exceptions are not streaming, they must be part of a output ParameterSet. Practically, they may be part of all of the output ParameterSets.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    That’s right. The same exception parameter can be in multiple parameter sets, or in its own parameter set.
    This could be construed as asking for the “input” constraint on ParameterSet to allow exception parameters to be
    non-streaming when outside parameter sets. It’s clearer to require the exception parameter to have its own parameter
    set, to emphasize the exclusion from others, even though it is technically redundant.
    Disposition: Closed - No Change

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

Location p 145 Classifier Description - objects -> instances

  • Key: UML25-335
  • Legacy Issue Number: 17917
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Objects are not defined in the spec, while instances are

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Subclause 6.3 will define objects, instances and values in alignment with the terminology used by fUML.
    Clause 9 needs to follow this terminology correctly.
    This also resolves 17875

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

While-->And

  • Key: UML25-249
  • Legacy Issue Number: 17799
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Too much emphasis on contrast

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This is a general stylistic issue that should be up to the author. Where “while” is used, the contrast is intended.
    Disposition: Closed - No Change

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

Unclear description of multiplicities

  • Key: UML25-248
  • Legacy Issue Number: 17798
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The first paragraph talks about "cardinalities", but it isn't really clear to which set this cardinality refers. I think the first two paragraphs need to be reworded to talk about a collection of values before talking about cardinalities.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Imports

  • Key: UML25-243
  • Legacy Issue Number: 17793
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The meaning of access should be described above under the import section

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    As specified in 7.4.4, the notation “«access»” is simply used to denote a private import. The distinction between public
    and private imports is already discussed in 7.4.3.
    Disposition: Closed - No Change

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

ElementImport cannot be further imported

  • Key: UML25-242
  • Legacy Issue Number: 17790
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    An imported Element that is publicly visible can be further imported...using either ElementImports..."

    While this is true for PackageImports, it isn't for ElementImports. The ElementImport directly references the PackageableElement so other ElementImports are irrelevant

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Confusing description of types

  • Key: UML25-247
  • Legacy Issue Number: 17797
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The description of types isn't terribly clear. There are several uses of "this" and "represents" that aren't clear. The third sentence, "Values..." uses "element" and seems to be repeating the second sentence.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed.
    This also resolves Issues 17796 and 17812

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

Note refers to an undiscussed concept

  • Key: UML25-238
  • Legacy Issue Number: 17786
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The sentence "Note that the set..." talks about unqualified names, but there isn't any discussion of what those actually are so the note seems rather out of place.

    Proposed Resolution:

    Change sentence to simply describe the use of unqualified names rather than being a confusing note.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Packageable Elements and Imports

  • Key: UML25-240
  • Legacy Issue Number: 17788
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Why not separate this into two sections. One on packageable elements and the other on imports. They are distinct concepts and belong in distinct subclauses. Under the packageable element subclause, note that elements that are not packageable are generally owned by a type/classifier, such as behavioral and structural features.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The only reason that PackageableElement is introduced in Subclause 7.4.3 is because it is used in ElementImport and
    PackageImport. Any further discussion on the semantics of PackageableElement should appropriately be in Clause 12
    on Package, not in Clause 7.
    Disposition: Closed - No Change

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

Missing word

  • Key: UML25-239
  • Legacy Issue Number: 17787
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "In a template ..., a NamedElement may have an associated ? whose..."

    Is this supposed to be StringExpression?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17601

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

Missing TypedElement - use of the term constrained seems to be circular

  • Key: UML25-246
  • Legacy Issue Number: 17796
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    use of the term constrained seems to be circular. Perhaps delete 'constrained to be'.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17797

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

Missing TypedElement

  • Key: UML25-245
  • Legacy Issue Number: 17795
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Should this figure include a reference from MultiplicityElement to TypedElement, since MultiplicityElement constrains the numbers of values of the TypedElement

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Presumably the reference is to Figure 7.10, the abstract syntax of types and multiplicity elements. The answer to the
    question is “no”. ConnectorEnd is a MultiplicityElement that is not a TypedElement. In other cases, element metaclass
    specializes bothMultiplicityElement and TypedElement, so no association fromMultiplicityElement to TypedElement
    is needed. The element simply is both a MultiplicityElement and a TypedElement.
    Disposition: Closed - No Change

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

Missing OCL

  • Key: UML25-250
  • Legacy Issue Number: 17800
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    No OCL for the rules for calculating the lower value of a multiplicity as given in text in 7.5.4 Notation / Multiplicity Element

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The rules for determining the multiplicity lower bound given in 7.5.4 are not constraints on the metamodel, so they
    have no OCL. Rather, they are rules for mapping the textual concrete syntax for multiplicity to the abstract syntax.
    Thus, the notation “*” does not mean that the multiplicity lowerValue is not given in the abstract syntax, but that the
    lowerValue is explicitly “0” and the upperValue is explicitly “*”. Similarly, a notation such as “2” means that the
    lowerValue and upperValue are both explicitly “2”. (Note that the case of “1” is special since, in the abstract syntax,
    the default for both upper and lower bound is “1”, so neither have to be given explicitly in this case.)
    Disposition: Closed - No Change

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

Packageable Elements and Imports (02)

  • Key: UML25-241
  • Legacy Issue Number: 17789
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    an a package, being a packageable element, be a TemplateParameter? This needs to be explained.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Yes, a Package being a PackageableElement can be the parameteredElement of a TemplateParameter. The semantics
    are as described in general for Templates and TemplateParameters. There are no further semantics to explain.
    Disposition: Closed - No Change

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

Incorrect text describing diagram elements

  • Key: UML25-244
  • Legacy Issue Number: 17794
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    "the<RresourceKind>
    "theFacilitySpecification
    theQualificaion
    are all not in the diagram

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18273

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

Location 13.1 Summary p 305 - Use of the word “emergent”

  • Key: UML25-358
  • Legacy Issue Number: 17965
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    in the spec, emergent is a special term with its own definition (not exactly the term as used outside the specification)

    The different format of the term should be made conforming.

    1) emergent behavior as in 13.1
    vs
    2) emergent behavior as in 13.2.3 (2x), 13.4, or 18.1.1
    vs
    3) Emergent Behavior as in 17.1.4

    It should certainly be in the index.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The uses of “emergent behavior” in 13.2.3, 13.4 and 18.1.1 are consistent with its definition in 13.1. And
    there is no index as such in which the term could be concluded.
    The only remaining issue is 17.1.4, which uses “Emergent Behavior”, as well as a number of other terms, in
    a capitalized form. These seem to be left over references to the “Execution model” that is supposedly to be
    found in Clause 13, but which is no longer there in the UML 2.5 specification. Subclause 17.1.4 is really no
    longer applicable

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

Operations p 245 (2X) typo

  • Key: UML25-357
  • Legacy Issue Number: 17946
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Comppnent – > Component

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

Location Figure 11-23 s p.217 - Instance/roll names

  • Key: UML25-355
  • Legacy Issue Number: 17944
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    There is no name for the wheel placing the role of rightFront. However there is a name for the rightRear wheel. The text describing the diagram implies that all the the right wheel instances are unnamed.

    In addition, the tire playing the role of the leftRear and the rightRear have the same name L2, which is wrong.

    Also the constructor is not connected to the instance. See 11.010

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Replace the figure. This also resolves 17945

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

Location Figure 11-22 s p.216 - Title doesn’t match contents

  • Key: UML25-354
  • Legacy Issue Number: 17943
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Current text:
    Figure 11-22 InstanceSpecification describes the return value of an Operation

    The diagram doesn’t show this, it show a dependence on an instance, but not that this the return value of a particular operation.

    The relevant text, 11.4.4 Notation on page 213 says
    A usage dependency may relate an InstanceSpecification to a constructor for a Class,

    The diagram doesn’t connect the instance to the constructor, just to the class.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Replace the figure and change the caption

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

Location: Constraints p 193 - Missing constraint?

  • Key: UML25-351
  • Legacy Issue Number: 17938
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    ownedReception + ownedOperation >0

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue is suggesting that an interface with no operations or receptions should be disallowed. But such an empty
    interface might be a suitable root for an inheritance hierarchy. There is insufficient justification to introduce such a
    constraint.
    Disposition: Closed - No Change

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

Location 10.4.4 Notations p.188 - Reception compartment

  • Key: UML25-350
  • Legacy Issue Number: 17936
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Where does the unmentioned reception compartment go?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    In fact the notation for Interfaces is the default notation for Classifiers, as described fully in 9.2.4. Rather
    than partially replicating the description, use a reference to the complete specification

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

Location 10.3.3 Signals p.186

  • Key: UML25-349
  • Legacy Issue Number: 17934
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    I’m not sure “object” is the best word.

    1) Object is methodology based. Prefer using instances
    2) Can the reception of a signal be a static scoped behavior?, therefore being a class not an object

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The word “object” is used pervasively throughout the spec. The point about static is covered by:
    “Where semantics are not explicitly specified for static Features, those semantics are undefined.”
    Disposition: Closed - No Change

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

10.2.4 Notation p 184. - Enumeration attributes and operations

  • Key: UML25-348
  • Legacy Issue Number: 17933
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Current text:
    The attributes and operations compartments may be suppressed, and typically are suppressed and empty.

    What could be in the attributes compartment?

    Could you have operations on an enumeration, such as predecessor, successor ?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 8274

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

Location: 10.2.3 Enumeration p. 184: New EnumerationLiterals

  • Key: UML25-346
  • Legacy Issue Number: 17931
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    An Enumeration that specializes another may define new EnumerationLiterals; in such a case the set of applicable literals comprises inherited literals plus locally-defined ones.

    “New” could mean completely new, or it could be redefined, that is, changing the value for an existing literal. Please be clear, specifying which types of changes are allowed

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    EnumerationLiteral is not a subclass of RedefinableElement, so we don’t believe there was ever an intention
    to redefine literals

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

Location: 10.2.4 Notation p 184

  • Key: UML25-347
  • Legacy Issue Number: 17932
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    What is the Name of literal compartment?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    We don’t believe that earlier versions of UML explicitly gave this compartment a name, but because we
    have said that a conforming tool may support compartment naming, we ought to give it one. “literals” is the
    obvious choice.

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

Location Figure 11-21 s p.216 - Instance/roll names

  • Key: UML25-353
  • Legacy Issue Number: 17942
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    There is no name for the wheel placing the role of rightFront. However there is a name for the rightRear wheel. The text describing the diagram implies that all the the right wheel instances are unnamed.

    In addition, the tire playing the role of the leftRear and the rightRear have the same name L2, which is wrong.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Replace the figure.

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

Location Figure 11-23 s p.217 - Instance/roll names (02)

  • Key: UML25-356
  • Legacy Issue Number: 17945
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    There is no name for the wheel placing the role of rightFront. However there is a name for the rightRear wheel. The text describing the diagram implies that all the the right wheel instances are unnamed.

    In addition, the tire playing the role of the leftRear and the rightRear have the same name L2, which is wrong.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17944

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

Location: Figure 11-3

  • Key: UML25-352
  • Legacy Issue Number: 17940
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Figure and title must be on same page

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

Wrong Reference

  • Key: UML25-281
  • Legacy Issue Number: 17841
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The notation in Figure 17.5 for timing annotation on sequence diagram does not match the almost identical diagram of Figure 8.5

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Figure 8.5 should match Figure 17.5. Figure 17.5 is the more correct of the two. However, Figure 17.5
    highlights the terms ’duration’ and ’now’ in bold style. This may people mislead to the assumption that
    these terms are kind of predefined keywords, which is not the case. So that could be improved, two.
    This also resolves Issue 10974.

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

missing headings

  • Key: UML25-280
  • Legacy Issue Number: 17840
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Missing headings for DurationInterval, TimeInterval, DurationConstraint, TimeConstraint.
    These must be distinct to fully populate the PDF Bookmarks.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Titles under the Semantics parts in the UML 2.5 specification are not intended to necessarily be class names but,
    rather, to label semantic areas being discussed. Actual class names are bookmarked under the Classifier Descriptions
    subclauses.
    Disposition: Closed - No Change

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

Min/Max

  • Key: UML25-290
  • Legacy Issue Number: 17867
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    More consistent to use 'temporal distance' rather than range.

    max ... refers to the later time.

    min ... refers to the earlier time.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The basic semantics of Interval are specified in terms of a “range”, and the semantics of the subclasses of Interval are
    also described using the same terms. This seems most consistent, and also avoids confusion with the use of “temporal
    distance” in the discussion of the semantics of Duration.
    Disposition: Closed - No Change

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

Two anonymous invariants

  • Key: UML25-289
  • Legacy Issue Number: 17861
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Two anonymous invariants violates distinguishability.
    Simpler
    inv BehaviorHasResult: behavior <> null impliesbehavior.ownedParameter->size() = 1 and behavior.ownedParameter->forAll(direction=ParameterDirectionKind::return)

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The referenced constraints are not anonymous in the current version of the specification (they are named “one_return_result_parameter”
    and “only_return_result_parameters”. These constraints could, perhaps, be combined more simply into one
    Disposition: Closed - No Change
    Report

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

8.6 p 100 isCompatibleWith() ..save space

  • Key: UML25-292
  • Legacy Issue Number: 17870
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Change
    The query isCompatibleWith() determines if this Parameterable element is compatible with the specified parameterable element. By default parameterable element P is compatible with parameterable element Q if the kind of P is the same or a subtype as the kind of Q. In addition, for a ValueSpecification, the type must be conformant with the type of the specified ParameterableElement (which must have a type, since it must be a kind of ValueSpecification).

    to

    The query isCompatibleWith() determines if the self ParameterableElement is compatible with the specified ParameterableElement. A ValueSpecification extends the default that the ParameterableElement P is compatible with ParameterableElement Q if the kind of P is the same or a subtype as the kind of Q. Additionally, the type of self must be conformant with the type of the specified ParameterableElement (which must have a type, as it must be a kind of ValueSpecification).

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 12250

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

Save Space

  • Key: UML25-291
  • Legacy Issue Number: 17869
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Consider saving space by listing Diagrams, Generalizations, Specializations on the same line as their title.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The FTF did not agree that this change would be an improvement.
    Disposition: Closed - No Change

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

result() error

  • Key: UML25-288
  • Legacy Issue Number: 17860
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Surely invoking result on a non-behavior is invalid?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The OpaqueExpression::result operation specifies the derivation of the OpaqueExpression::result attribute. There is no
    concept in UML of an attribute having a derived value that is an “error”. The result attribute is optional (multiplicitly
    0..1) and it simply has no value if the OpaqueExpression does not have a behavior, as given by the result operation.
    Disposition: Closed - No Change

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

French

  • Key: UML25-287
  • Legacy Issue Number: 17857
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    I guess you mean something "OCL", but you could mean "French"

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    “French” is perfectly legal to use as a value of OpaqueExpression::language. It is allowable to use natural language in
    the body of an OpaqueExpression and it is encouraged to explicitly record the language used. (This is most commonly
    “English” but could certainly be “French”.)
    Disposition: Closed - No Change

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

Invariant name

  • Key: UML25-284
  • Legacy Issue Number: 17844
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The invariant is unnamed in the OCL snippet, but named in the editorial text.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The constraint has the name “no_expr_requires_observation”, presented in the same way as the name of all other
    constraints in the document.
    Disposition: Closed - No Change

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

Improve readability of constraint names

  • Key: UML25-283
  • Legacy Issue Number: 17843
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    IMHO NoExprRequiresObservation is more readable than no_expr_requires_observation which is important since the text may well appear in tool error messages.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    As admitted in the issue itself, this is a matter of opinion. The use of lowercase underscores in the UML metamodel
    is established and consistent, and it does not seem worth it to change it across the entire metamodel on a matter of
    opinion.
    Disposition: Closed - No Change

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

Association Descriptions not that useful

  • Key: UML25-295
  • Legacy Issue Number: 17874
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Association Descriptions not that useful

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This is an opinion which the document editor does not share.
    Disposition: Closed - No Change

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

IsNull not Boolean

  • Key: UML25-294
  • Legacy Issue Number: 17873
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    IsNull not Boolean

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Presumably this issue is about the isNull operation of ValueSpecification. The definition of the operation is “The query
    isNull() returns true when it can be computed that the value is null.” The implication is that isNull returns true only if
    “it can be computed that the value is null”. In other cases, it always returns false. So the return multiplicity is correct.
    In any case, in practice this operation is overridden by subclasses of ValueSpecification in specific cases in which it
    can be computed (e.g., LiteralNull::isNull returns true).
    Disposition: Closed - No Change

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

Duration Definition

  • Key: UML25-282
  • Legacy Issue Number: 17842
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    "the temporal distance between two time instants "

    is not necessarily true. The value may be derived by an arbitrary computation over the set of observations. Could be three standard deviations.

    Suggest "a temporal distance as a DurationObservation or as a computation over a set of observations

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The suggested change leaves Duration defined in terms of “temporal distance”, but essentially leaves “temporal distance”
    undefined. To have a meaning, a “distance” must be between two things. However it is computed, a Duration
    is always, in the end, by definition, a “distance between two time instants”, the beginning and the end of the Duration.
    Note that this statement in no way requires that the observations used to compute the Duration be limited to just giving
    the beginning and end time instants – the observations are just used in some way to determine those instants and define
    the Duration.
    Disposition: Closed - No Change

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

Set--> List

  • Key: UML25-286
  • Legacy Issue Number: 17856
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Location: 8.6 p 94 OpaqueExpression Description

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    It would probably be best to say “collection” instead of “set”.

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

Why is value optional

  • Key: UML25-285
  • Legacy Issue Number: 17853
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Why is value optional

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17816

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

Turing Machine lurking paradox?

  • Key: UML25-293
  • Legacy Issue Number: 17871
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Turing Machine lurking paradox?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 12250

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

Location: 9.6.3 Operations p 127 Undefined ?

  • Key: UML25-323
  • Legacy Issue Number: 17904
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    this sounds peculiar.
    Intentionally undefined by the modeler, or by the authors of the specification.
    In think this should say
    The behavior of an invocation of an Operation when a precondition is not satisfied is not defined in UML

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Location: 9.5.3 p 121 Can’t qualifiers be queries?

  • Key: UML25-322
  • Legacy Issue Number: 17903
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Qualifiers should be able to be queries that return an enumerated type that otherwise meets the criteria for qualifiers. This would allow for different mapping to the set at the other end, that might be situationally determined.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Qualifiers are represented by properties, which might be derived. Derived properties are essentially queries.
    Disposition: Closed - No Change

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

Location: 9.8.4 Notation p 141

  • Key: UML25-330
  • Legacy Issue Number: 17912
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “If the InstanceSpecification is shown using an enclosing shape (such as a rectangle) that contains the name, the ValueSpecification is shown within the enclosing shape.”

    [AC] How would otherwise be possible to show an InstanceSpecification?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    It might be a line, representing a link.
    Disposition: Closed - No Change

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

Location: 9.8.3 Semantics p 139

  • Key: UML25-329
  • Legacy Issue Number: 17911
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    and if one classifier is abstract and one is not (and they are not realized by generalization)

    It would seem that if any of the classifiers are abstract, the instancespec only partially describes the instance? This need explanation

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The current text is just confusing. It already explains later on that they may be partial

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

Location: 9.6.4 Notation p 128 Is return a reserved parameter name?

  • Key: UML25-326
  • Legacy Issue Number: 17908
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The return result of the Operation may be expressed as a return parameter, or as the type of the Operation. For example:

    toString(return : String)

    means the same thing as

    toString() : String

    Why is this true. The 1st example, could be interpreted as an operation with a parameter named “return”.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This paragraph is inconsistent with the BNF, ambiguous, misleading, and unnecessary. Delete it.

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

Location: 9.6.4 Notation p 127 Simplify description of syntax

  • Key: UML25-325
  • Legacy Issue Number: 17906
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    AC] This section on the syntax of operations is complex in itself, but also too hard to read. Maybe a little more structure could improve its readability. E.g. separate the template operation syntax from the previous part.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18801

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

Location: 9.5.3 p 122 Qualifiers must be enumerated type

  • Key: UML25-321
  • Legacy Issue Number: 17902
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    I believe qualifiers must be constrained to be an enumerated type. For example, can an qualifier be a real number?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Qualifiers can be any type that a property can have. If the type has an infinite range, then the lower bound of
    the qualifier must be 0. This is explained by the note in 9.5.3. However, this note contains the phrase “such
    as enumerated values or integer ranges” - since there is no way in UML to define a type that represents an
    integer range, that phrase needs to be modified to exclude this possibility, which will make Enumerations
    stand out as important.
    Note that we might consider a constraint that a lower bound of one implies an enumerated type, but this
    would unnecessarily exclude the possibilities of typing a qualifier with a PrimitiveType with a fixed set of
    values, or a DataType all of whose parts are finite

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

Location: 9.6.3 Operations p 127

  • Key: UML25-324
  • Legacy Issue Number: 17905
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “The bodyCondition for an Operation constrains the return result. The bodyCondition differs from postconditions in that the bodyCondition may be overridden when an Operation is redefined, whereas postconditions may only be added during redefinition.”

    [AC] The concept of bodyCondition is not explained, and I fear it is less known that the concepts of precondition and postconditions, that are explained. On page 158, it is said that only query operations may have a bodyCondition. An explanation would be useful.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    It is explained in the sense that it says “The bodyCondition for an Operation constrains the return result.”
    Improve the wording to explain that the bodyCondition specifies the calculation of the result value which
    should satisfy the postconditions

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

Location: 9.7.5 Examples p 135 Political Correctness

  • Key: UML25-328
  • Legacy Issue Number: 17910
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    When you say that the generalization by Gender into woman and man is complete and disjoint you are making a politically sensitive statement. You need a caveat, perhaps as a footnote, acknowledging that you are only using this for sample syntax purposes and not claiming facts about the world.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed about the political sensitivity. This should actually be a blanket disclaimer for the entire specification.

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

Location: 9.7.5 Examples p 134 Generalization Sets

  • Key: UML25-327
  • Legacy Issue Number: 17909
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    [AC] Figures 9.23 and 9.24 are, in my opinion, misleading. It seems, based on these examples, that either the generalization set name is shown, or the relative constraints (e.g.

    {incomplete, disjoint}

    ), while both could be shown. Same problem in previous figures, from 9.17 to 9.20

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There is a law of diminishing returns on this particular section of the specification. Rather than investing
    effort on more diagrams, fix this by explicitly stating that any combination of these labels may be shown.

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

Location: 9.8.4 Notation p 141 representing the roles vs representing the instances

  • Key: UML25-331
  • Legacy Issue Number: 17913
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    a bit confusing. It says:
    may contain nested rectangles representing the instances playing its roles

    Do you mean
    may contain nested rectangles representing the roles the instance is playing? Please clarify nearby

    Give an example with the roles

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    In an instance specification for a structured classifier, the nested rectangles do represent instances playing its roles.
    There are several examples in clause 11, and clause 9 refers the reader to them with a hyperlink. Moving the structured
    examples to clause 9 would make the forward reference problem worse, not better. The current specification text is
    accurate as it stands.
    Disposition: Closed - No Change

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

Location: 9.9 Classifier Descriptions Association Ends p 144 Behavioral --> Behavior

  • Key: UML25-332
  • Legacy Issue Number: 17914
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    Correct Typo (done). Also I have doubts about the upper multiplicity.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The typo was corrected before the beta document. The upper multiplicity of BehavioralFeature::method is explained
    in 13.2.
    Disposition: Closed - No Change

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

Clarification of imports

  • Key: UML25-237
  • Legacy Issue Number: 17785
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Type: Clarification of imports
    The following are not obvious:
    1) Can a non-package namespace, such as a class, have a package
    import relationship to a package? From the metamodel yes

    2) Can a namespace, of any type, do a element import of a package?
    From the metamodel yes

    3) Can a package do an element import of a attribute?
    From the metamodel yes

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    It is not clear why these things are claimed to be “not obvious”. As shown in Figure 7.5 and described in the text of
    subclause 7.4.3, any Namespace (including a Class) can have a PackageImport of any Package and any Namespace
    can have an ElementImport of a Package. In the former case, the the members of the Package are imported, while, in
    the latter case, only the Package is imported.
    A Package cannot import an attribute, however, since attributes are Properties, which are not PackageableElements.
    Per Figure 7.5 and subclause 7.4.3, only PackageableElements may be imported.
    Disposition: Closed - No Change

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

Namespace Abstract Syntax incorrect

  • Key: UML25-236
  • Legacy Issue Number: 17784
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    memberNamespace should be readOnly and union. This appears to be wrong in the metamodel.

    Proposed Resolution:

    Update metamodel.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The union annotation is added by the resolution 17172. Having memberNamespace annotated as readOnly is unnecessary
    for a non-navigable, association-owned end.
    Disposition: Closed - No Change

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

Add reference to association notation section

  • Key: UML25-230
  • Legacy Issue Number: 17775
  • Status: closed  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    Suggest adding a reference to the section where association end notations are discussed. When I got to figure 7.1, I realized that no one had yet told me what a ball or a colored diamond on an association end meant. I don't think we can assume that readers will necessarily have enough past history with UML to know all of this stuff without the spec being explicit.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17774

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

How does dot notation work

  • Key: UML25-229
  • Legacy Issue Number: 17774
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Does the Dot indicate the owning side or the non-owning side? Some clarification is needed here.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Extraneous Note

  • Key: UML25-227
  • Legacy Issue Number: 17771
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Note starting
    Note that this framework only deals with event-driven,…

    This note interrupts the explanation of the diagram and side-tracks it, and is essentially irrelevant to the main topic.

    Proposed Resolution:
    Split the 'Note' into a separate final paragraph that isn't described as a note, just more detailed information about the nature of UML behaviors.".

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17768

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

Sentence does not make sense

  • Key: UML25-226
  • Legacy Issue Number: 17770
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Sentence beginning paragraph
    The base behavioral semantics of UML builds on this structural foundation, addressing both the basic framework of the execution of behaviors and such execution may result….

    The use of both in this sentence prepare the reader for two semi-parallel items. The sentence does not have such.

    Proposed Resolution:
    Redo sentence to discuss the behavioral section of the diagram Figure 6.1

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17768

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

Owning Comments

  • Key: UML25-233
  • Legacy Issue Number: 17779
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    If every Element in a model must be owned by some other Element of that model, with the exception of the top-level Packages of the model, then all Comments, as Elements, must be owned. The Root diagram has ownership for comments being optional, owningElement [0..1]

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17776

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

Root Abstract Syntax missing adornments/metamodel incorrect

  • Key: UML25-232
  • Legacy Issue Number: 17777
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The ends "relationship", "directedRelationship" (x2) should all be

    {readOnly, union}

    . This appears to be wrong in the metamodel.

    Proposed Resolution:

    Update metamodel.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The union annotation is added by the resolution 17172. Having the ends annotated as readOnly is unnecessary, since
    they are non-navigable, association-owned ends.
    Disposition: Closed - No Change

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

Owning Rules

  • Key: UML25-234
  • Legacy Issue Number: 17780
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    There should be a constraint that all Elements are owned, except the top element.
    Also, the text refers to models and packages, yet these are not defined yet. Perhaps there should be forward reference to model, and the reference to package should be deleted.
    Source: Sandy Friedenthal
    Discussion:
    Are root packages required to be "models"?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There is already a constraint that all elements must be owned, Element::has_owner (except of Packages, for
    which the underlying mustBeOwned() operation is overridden.
    The word “model” is used in 7.2.3 in a colloquial sense, not as a reference to the specific Model construct.
    It is not the case that root Packages are required to be Models.
    It is agreed, however, that it would be useful to include a forward reference to the Packages clause.

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

Owning Comments

  • Key: UML25-231
  • Legacy Issue Number: 17776
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    All comments should be owned.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The owningElement property opposite Element::ownedComment is optional. But the Element::has_owner constraint
    enforces the fact that all Comments (as kinds of Elements) must be owned. Having ownedElement for a Comment be
    optional simply allows for the possibility of a case in which a Comment (or some subclass of Comment) may have
    some specialized ownership other than the generic owningElement/ownedComment association (even though there is
    currently no such case in the UML metamodel).
    This also closes duplicate Issue 17779.
    Disposition: Closed - No Change

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

Figure 6.1 does not relate to rest of Specification

  • Key: UML25-225
  • Legacy Issue Number: 17769
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Many of the items given in the diagram don't all appear in the text as is (Structural Foundations, Inter/Intra-Object Behavior Base);

    Proposed Resolution:
    Redo diagram using items from the specification or explicitly correlate the items to areas within the spec.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17768

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

Can Comments own comments?

  • Key: UML25-235
  • Legacy Issue Number: 17781
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Does this mean that Comments can own Comments? It looks like Comments can annotate Comments, which is not a problem. Can Comments own anything else?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Yes, Comments can own Comments. They cannot own anything else.
    Disposition: Closed - No Change

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

What type of slash?

  • Key: UML25-228
  • Legacy Issue Number: 17773
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    This is a good place to show if it’s a forwards or backwards slash

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Location: Page 330, 331, 333, 14.2.3, Page 347, 14.2.4, Page 375, 14.5 PseudostateKind

  • Key: UML25-367
  • Legacy Issue Number: 17978
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    Title: History State described multiple times
    Summary The History State is described here:
    State history (p. 330)
    Entering a state (p. 331)
    PseudostateKind (p. 333)
    History State Notation (p. 347)
    PseudoStateKind classifier description (p 357).

    Though it is OK to have descriptions in the various predefined sections, it seems that in this case I need to read all places to fully understand the history state.
    On other occasions the wording is slightly different (e.g., containing state-owning state), so that the reader wonders, whether there is a different meaning.
    On page 333 the description of deepHistory is incomplete: It doesn’t describe the default history state. This is described at other places, but not describing it here misleads the reader to think, that only shallowHistory has this feature.

    Proposed Res Reduce the number of places. Focus the description on the purpose of the section, hyperlink to other parts of the description where necessary.

    Source: axel.scheithauer@oose.de

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed: the redundancy is both a maintenance problem and can be confusing due to minor discrepancies
    between the texts. Since the duplicate text in question describes the semantics of the pseudostates, it should
    be retained in the Semantics section (14.2.3) of the StateMachines chapter and removed from the Classifier
    Descriptions section (14.5). It would be convenient to add some kind of hyperlink from the Classifier
    Descriptions entry to the corresponding Semantics entry, but, since the descriptions text is auto-generated
    from the metamodel, this would be rather difficult to achieve technically. However, it is expected that
    readers interested in the semantics of the individual literals will naturally assume that they should refer to
    the Semantics section

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

Location: Page 329 States - Stable

  • Key: UML25-366
  • Legacy Issue Number: 17977
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    s the configuration stable if there is a pending deferred event that should be processed?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add clarifying sentence in the section defining what constitutes a stable state.

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

Location: Page 315 Association ends - Explain about having no nestedClassifier

  • Key: UML25-362
  • Legacy Issue Number: 17971
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    How can it be? What are the consequences. Is this something to be avoided.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue is not entirely clear, but it seems to be asking why there is no nestedClassifier property for Behavior.
    However, Behavior is a subclass of Class and it inherits nestedClassifier from Class.
    Disposition: Closed - No Change

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

Location: Page 313, 13.2.4 Notation relative

  • Key: UML25-361
  • Legacy Issue Number: 17969
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Title: Relative to what?
    The concept of relative TimeEvent does not make sense unless a base Event is identified. This should be reflected in the metamodel diagrams and definitions. This is often a problem with timers in activity diagrams.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Note: The correct Notation subclause reference is 13.3.4, not 13.2.4.
    In Subclause 13.3.3, under Time Events, it states “Relative TimeEvents shall always be used in the context of a Trigger,
    and the starting point is the time at which the Trigger becomes active.”
    Disposition: Closed - No Change

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

Location: Page 341, 14.2.4 - Example for graphical expression of behavior in states

  • Key: UML25-369
  • Legacy Issue Number: 17981
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The spec says
    “Alternatively, in place of a textual behavior expression the various Behaviors associated with a State or internal Transition can be expressed using the appropriate graphical representation (e.g., an activity diagram)”.
    How would that be shown? As an embedded Activity Diagram in a compartment with the name of the triggers in the left upper corner?

    Proposed Res Add an example or give more details.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Rather than come up with some difficult-to-implement nested diagram solution to this, it seems simplest to
    clarify that the behavior in such cases would be specified in a separate diagram. Add a clarifying statement to the text.

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

Location: Page 328 Regions 14.2.3 - Text about regions without initial state

  • Key: UML25-365
  • Legacy Issue Number: 17976
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    “No one approach is defined for the case when there is no initial Pseudostate exists within the Region.”
    Proposed Res “What it means if none is defined, is left to the modeler.”

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Axel: The main reason for raising issue was, that I think, this is not correct English:
    “No one approach is defined for the case when there is no initial Pseudostate exists within the Region.”
    Bran: Actually, the English is at least formally correct. In fact, the same formulation is used elsewhere in
    the spec (section 13.2.3). However, since it has proven confusing to at least one reader, that wording should
    be changed throughout the spec.

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

Location: Page 346, State List Notations

  • Key: UML25-371
  • Legacy Issue Number: 17983
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Do State Lists exchange via diagram exchange?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18566

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

Location: Page 341, State - More examples needed

  • Key: UML25-370
  • Legacy Issue Number: 17982
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    There are some common combination notation examples that should be demonstrated and explained. That is, internal activities Behaviors compartments and decomposition compartments.
    1) A composite state that also has a compartment for the do/activity, and possibly entry/ and exit/actions
    2) A composition state with a hidden decomposition, with compartments as above.
    3) A composite state, with regions, that also has a compartment for the do/activity, and possibly entry/ and exit/actions, crossing the regions, and compartments that are region-specific.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add one more figure with an example that provides a combination of regions and compartments with an
    explanatory caption

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

Location: Page 338, Transition selection algorithm - Maximal Set

  • Key: UML25-368
  • Legacy Issue Number: 17980
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The phrase “maximal set” increases the confusion here. It appears to possibly mean that the possible sets of transitions are evaluated and the maximal set is chosen. The algorithm that is describing indicates a local decision making approach that just chooses the next transition.
    The whole concept of the “set” seems misleading in the light of immediate decisions.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clarify that multiple Transitions can fire simultaneously for a given event occurrence; remove the confusing
    term “maximal”

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

Location: 14.2.1 Summary - Behavior StateMachines for UseCases

  • Key: UML25-364
  • Legacy Issue Number: 17974
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Can we make this possible, explicitly?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The text already mentions that a behavioral state machine can be used for any owned behavior of a BehavioredClassifier.
    It seems inappropriate to single out use cases and not mention all the others. Besides, figure 18.12 explicitly
    shows an example of a state machine associated with a use case.
    Disposition: Closed - No Change
    Report

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

Location: 14.1 Summary p 326

  • Key: UML25-363
  • Legacy Issue Number: 17973
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Can we point to a useful Harel book?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Location Behavior Parameters p 307 - Streaming and Multiplicity

  • Key: UML25-360
  • Legacy Issue Number: 17967
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    If there is a minimum multiplicity on a streaming parameter, is it
    1) The min # must be there to start
    2) The minimum # must arrive before it finishes.
    3) If a streaming parameter has a default how does that work?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The semantics of multiplicity on a streaming parameter is described as part of the semantics of CallAction.
    There are no special semantics defined for the defaultValue of a streaming parameter.

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

Location Behavior Parameters p 307 - Optional with default value

  • Key: UML25-359
  • Legacy Issue Number: 17966
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    what happens when an in parameter is optional and has a defaultvalue?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The defaultValue is still evaluated. This could be clarified

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

Alterative Scopes?

  • Key: UML25-304
  • Legacy Issue Number: 17883
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    Title: Alterative Scopes?
    current text: “Inherited static StructuralFeatures shall have one of two alternative semantics, within a given execution scope:
    1. The value of the StructuralFeature is always the same for any inheriting Classifier as its value for the owning Classifier.
    2. The StructuralFeature has a separate and independent value for its owning Classifier and for each Classifier that inherits it.”

    [AC] This is not clear to me. Which one of the semantics apply in a certain execution scope?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The question doesn’t really make sense: indicating that the wording does need clarification.
    This also resolves issue 17884.

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

Multiplicity of 0..0

  • Key: UML25-303
  • Legacy Issue Number: 17882
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Location: p 117 Not handled / discussed

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17881

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

Location p.112 (9.3 Classifier Templates)

  • Key: UML25-301
  • Legacy Issue Number: 17880
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    [AC] Since this section is (in my opinion) an advanced topic, and a feature of the UML not always used by most practitioners, I would rather move it after the sections about features, properties, and operations

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    We decided as a basic principle to mimimize forward references, and the current organization achieves that quite well.
    Moving this section later would introduce more forward references from Property and Operation.
    Disposition: Closed - No Change

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

Incompatible with SysML

  • Key: UML25-300
  • Legacy Issue Number: 17879
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    This is not compatible with SysML, which I believe calls them "constraints" --> Location: 9.2.4 p 110.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    UML 2.4.1 did not specify what the compartment heading was for constraints — it simply said that such a
    compartment is possible

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

the parent of a Classifier is not its owner.”

  • Key: UML25-297
  • Legacy Issue Number: 17876
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Note: the parent of a Classifier is not its owner.”

    [AC] This note is not completely clear, in my opinion, maybe because it relates two unrelated concepts (generalization and ownership) without sufficient explanation in the context of this description.

    Furthermore, I could interpret the note in different ways:

    • the parent of a Classifier is not necessarily its owner
    • the parent of a Classifier may not be its owne
      Proposed Resolution:

    Update metamodel.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    It is indeed somewhat unclear. Rephrase

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

Location: p.116 (9.4.3 Semantics)

  • Key: UML25-302
  • Legacy Issue Number: 17881
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “For each instance of a Classifier there is a value or collection of values for each direct or inherited non-static attribute of the
    Classifier”

    [AC] Again, an attribute may have a value or collection of values in any instance. It has not necessarily one, unless constrained by its multiplicity. In the following sentences is discussed the upper multiplicity, but never the lower one.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Expand the explanation to handle lower bounds

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

What is inherited or not

  • Key: UML25-298
  • Legacy Issue Number: 17877
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “When a Classifier is generalized, certain members of its generalizations are inherited, that is they behave as though they were defined in the inheriting Classifier itself.”.

    [AC] This sentence suggests that some members are inherited, some are not. In the following sentence it is explained, as examples, that attributes and operations are inherited. But which are members that are NOT inherited? Are there examples, or, better, rules?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There is a later paragraph in the cited section that says:
    The set of members that are inherited is called the inheritedMembers. Unless specified differently for a particular kind
    of Classifier, the inheritedMembers are members that do not have private visibility.
    This is clear.
    Disposition: Closed - No Change

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

Inherited members

  • Key: UML25-299
  • Legacy Issue Number: 17878
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “For example, an inherited member that is an attribute has a value or collection of values in any instance of the inheriting Classifier, and an inherited member that is an Operation may be invoked on an instance of the inheriting Classifier.”.

    [AC] An attribute may have a value or collection of values in any instance. It has not necessarily one, unless constrained by its multiplicity.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    A minor point, and pedantically “a collection of values” includes the possibility of no values. Reword

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

Redefinable Static attributes

  • Key: UML25-306
  • Legacy Issue Number: 17886
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Are static structuralfeatures redefinavble? Are they redefinable only ounder scope 2?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There are no constraints that say they are not redefinable, so they are. What that means is covered by the sentence:
    Where semantics are not explicitly specified for static Features, those semantics are undefined.
    Disposition: Closed - No Change

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

Examples of alternative scopes?

  • Key: UML25-305
  • Legacy Issue Number: 17884
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Can you say more about these options. I don't know but, for example, is #1 Ada and #2 Objective C.
    Some explanatory comment might help.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17883

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

Objects?

  • Key: UML25-296
  • Legacy Issue Number: 17875
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    It should probably be instances not objects, based on 9.2.3

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17917

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

Location: p. 329 State Configurations

  • Key: UML25-378
  • Legacy Issue Number: 17992
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    Title: What state are you in when the entry action is being executed?
    As I remember, this is new in this version (UML 2.5). This line implies that a state is not active until the entry action has been executed and completed (or the entry method has returned). This is also how Umple (try.umple.org) implements state machines. The issue with this choice is that if you query the state machine while the entry action is being executed, the return value will be outdated. This is a concern even if the entry action takes insignificant amount of time.
    For example, what if the entry action code queries the state machine? In that case, the query will return the source state (and not the current state). Here is the example using Umple

    stateMachine {
    State1

    { event1 -> State2; }

    State2 {
    entry /

    {defaultEntryActionMethod();}


    }
    }

    private void defaultEntryActionMathod() {
    if (currentState == State1)

    {.. .. ..}
    if (currentState == State2)
    {.. .. ..}

    }

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This requires a clarification. The revised text below is based on the view that a state machine is always “in”
    some state configuration, even while undergoing a transition. That is, the state machine is “in” a particular
    state as soon as it reaches that state through an incoming transition. This in turn means that any behaviors
    that are associated with that transition have been completed.
    This resolution also resolves issues 17994 and 17995.

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

Location: p. 328 Regions - Resolve intentional ambiguity

  • Key: UML25-377
  • Legacy Issue Number: 17991
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    This is an area of intentional ambiguity. Why not just make a choice regarding a region with no start state? I would suggest that UML should allow a region without a start state and go with the second choice "the region remains inactive while the containing state is active."

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The reason this was defined as a variation point is to support the different semantics that were realized in various
    existing state machine realizations (at least those that were of concern when UML 2.0 was being defined). Selecting
    only one variant as the only valid one would be, in effect, a change in the semantics of UML, which would have an
    impact on existing models.
    Disposition: Closed - No Change

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

Location: Transition , bottom of page 352

  • Key: UML25-373
  • Legacy Issue Number: 17986
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    What's a Data node? Not defined in the spec?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clarify the distinction between the two notations and remove the sentence referring to Data node.

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

Location: Page 347, 14.2.4

  • Key: UML25-372
  • Legacy Issue Number: 17985
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    Title: state list examples with alternative notation without state lists
    Summary The text on state lists is difficult to understand without a graphical representation of the examples.

    Proposed Res Add corresponding diagram without state list to Figure 14-13

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Change diagram 14.13 to include an example for case (b)
    Remove current diagram 14.14, because it adds no new information (it only gives an example for the situation
    shown in 14.13 but with meaningful statenames.
    Add a new diagram 14.14 to show the equivalent statemachine without state lists. Remove Text about history
    states and the corresponding transition in diagram 14.13.

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

Location: p 378 State Description - What is hidden?

  • Key: UML25-376
  • Legacy Issue Number: 17990
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The concept of hidden in this paragraph is unclear. Certainly any state, including those of behavior StateMachines can be visible to the users. Please add "usually" before the word "hidden" in the 2nd sentence of this paragraph and offer or refer to explanation

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    add clarification

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

Location: p 373 outgoing_from_initial - Limitations on guards

  • Key: UML25-375
  • Legacy Issue Number: 17989
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The limitation on not having a guard seems not justified, if we can constrain that the set of guards are covering.
    Please explain or fix.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The reason for not allowing a trigger on an initial transition is because that transition is triggered by the creation
    and/or start behavior action of the state machine’s context object. That is, it is not triggered in the same way as other
    transitions, by the arrival of amessage-based event occurrence. Putting a guard on this transition would allow for the
    possibility that the transition would not be taken if the guard is false, leaving the state machine in an indeterminate
    half-created state. (At that point, nothing further could be done with such a state machine, except to destroy it.) The
    intent of this constraint, therefore, is to ensure that the initial transition is always taken.
    Of course, the ability to branch following creation of the state machine is easily achieved by terminating the initial
    transition on a choice point Pseudostate that has outgoing guarded transitions.
    Disposition: Closed - No Change

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

Page 353, 14.2.4 - StateMachine symbols on graphical representations of Transitions

  • Key: UML25-374
  • Legacy Issue Number: 17988
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The spec says that a choice point symbol on a graphical representation of a transition is not part of any Activity. That’s exactly what I expected, since a choice point is not allowed in an Activity. Then it says, that the symbol maps to a choice Pseudostate and uses the same notation. In other words, the choice point symbol maps to a choice point and uses the choice point symbol. Hm.
    What is the difference between a choice point symbol on a transition with textual representation and on a transition with a graphical representation? The same is unclear with state, initial state, merge, and final state symbols. The symbols are the same and mean the same as in normal transitions. The example in figure 14-30 supports this view.

    Proposed Res Explain in more detail. If possible add the corresponding Activity Diagram.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The cited statement is taken out of context, which provides a setting for this seeming tautology. The context here is
    the special graphical notation for transitions, which is distinct from the rest of the state machine notation. Hence, the
    choice point symbol could, for example, be mapped to a conditional statement instead of a pseudostate. By saying
    explicitly that it maps to a choice point pseudostate clarifies this point. The same goes for all the other symbols.
    Hence, it is not as trivial as it sounds.
    In the text that introduces this notation there is a clear statement that this is a unique notation applicable only to
    Transitions (“As an alternative, in cases where the effect Behavior can be described as a control-flow based sequence
    of Actions, there is a graphical representation for Transitions and compound transitions which is similar to the notation
    used for Activities.”). There is also a Note, introduced as part of the resolution to issue 17986, that clearly warns that
    the notation is not an the same as the notation for Activities. It is not clear that any further statementswill help. Adding
    an activity diagram example here would likely only lead to confusion.
    Disposition: Closed - No Change

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

Location: p. 333 FinalState

  • Key: UML25-382
  • Legacy Issue Number: 17996
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    Difference between FinalState and state w/o outgoing transition.
    I see no difference between FinalState and any other state without any outgoing transition. I suggest (similar to what we did with Umple) is to delete the object when the FinalState is reached. In the case of regions, all regions must reach a final state before the object is deleted.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    These are actually two separate issues: whether a final state is the same as a state without outgoing transitions and the
    semantics of final states.
    There is a difference between final states and the terminate pseudostate. This is intentional, since final state has a
    local effect within a region whereas terminate has a global effect (in the sense that it terminates the context object).
    Terminate was introduced to allow modelers to explicitly specify when they want to context object to be terminated.
    Adding an implicit version of that capability (i.e., when all regions reached a final state) seems only to add complexity.
    Furthermore, note that the state machine may be invoked through a submachine state, which would most probably
    mean that, in those cases, the implicit termination would likely be inappropriate.
    Those who wish to add such semantics are always free to do so through a profile.
    Disposition: Closed - No Change

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

Location: p. 331 Exiting a State - Clarification of Exiting a State

  • Key: UML25-381
  • Legacy Issue Number: 17995
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    This can be clarified. When does the state machine configuration get updated?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Location: p. 337 2nd ¶

  • Key: UML25-385
  • Legacy Issue Number: 18000
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    Title: More Non-Determinism
    Similar to my comment earlier on this type of non-determinism

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Location: p. 336 Compound transitions

  • Key: UML25-384
  • Legacy Issue Number: 17998
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    More than one transitions guarded to be true?
    A known under-specification. For tool developers, it is better to make a choice here. In Umple (since it is a textual notation) we give precedence to the transition that was defined earlier in the sequential text.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The possibility of multiple true guards can never be practically excluded in practice (e.g., guards may involve variables).
    As for how to deal with that situation, UML leaves that up to the tool implementers. There does not seemto be
    a compelling case to define a formal rule, especially since that might cause backward compatibility problems in some
    models (i.e., some tools may have chosen a different way of defining precedence).
    Disposition: Closed - No Change

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

Location: p. 333 Transitions - How do multiple triggers work?

  • Key: UML25-383
  • Legacy Issue Number: 17997
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    This seems new to me. Does this mean that a Transition can be triggered by more than one event? if so, then what is the priority between them. For example, what if two triggering events for the same transition are fired at the same time? Which event becomes consumed by that transition? What if one of the events is a deferredEvent?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add a clarification statement to avoid confusion

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

Location: p. 330 Deferred Events - Value of Deferred Events

  • Key: UML25-379
  • Legacy Issue Number: 17993
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    I think this is also new specification in UML 2.5. If so, it should be added to the summary of new specifications at the beginning of the document.

    This is a feature with some value. The question is the following. Does this feature brings more value than the complexity it adds to the specification and the tools that supports UML? My view is that such a feature adds more avoidable complexity to the tools. At the same time, the same behavior can be achieved using the already existing UML features. I would vote against this feature in favor of keeping the specifications less complex

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The submitter is mistaken. Deferred events have always been a part of UML state machines.
    Disposition: Closed - No Change

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

Location: p. 331 Explicit Entry - Clarification of Explicit Entry

  • Key: UML25-380
  • Legacy Issue Number: 17994
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    I would like to note that when entering a composite state, the current configuration of the state machine will not be updated until all entry actions are called, executed, and completed.

    It makes more semantics sense to update the parent state machine right after its entry action is called, and recursively thereafter for all nesting levels.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Unlimited Natural

  • Key: UML25-268
  • Legacy Issue Number: 17822
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    'unlimited' is called 'infinity' in UML 2.4, 'unlimited' in OCL, 'unbounded' in Section 21.The comment that 'unlimited' is not 'infinity' does not make any sense to me. If it is unlimited then any value from 0 all the way to infinity is permissible, so the upper bound is indeed infinity.

    Suggest the mathematically consistent 'infinity' and remove the note.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed that this should be made consistent. Notwithstanding the use of “unbounded” in Section 21, the
    current specification text generally uses the term “unlimited” for “*”, which is also consistent with the name
    of the type UnlimitedNatural. The reason to distinguish this from “infinity” is that “*” is only used to
    represent an “unlimited range”, never as a value resulting from an infinite computation (in the sense that,
    say, +/- infinity are values in certain floating point computation systems).
    This resolution also resolves issue 18442. The proposed resolution to 17798 already removes references to
    “infinite” and uses the term “unlimited” in relation to the discussion of the upper bound of a multiplicity in
    Subclause 7.5.3.

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

String concrete syntax is missing

  • Key: UML25-267
  • Legacy Issue Number: 17821
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Specifying a Concrete Syntax requires just that. It must provide a solution to expressing all characters in a predictable fashion. So given the constraint of "..." encapsulation, how are internal " represented? How are Unicode and newlines expressed? Suggest reusing the OCL 2.3 clarification of backslashes. The concrete syntax comprises a sequence of zero or more characters or escape sequences surrounded by single quote characters. The [B] form with adjacent strings allows a long string literal to be split into fragments or to be written across multiple lines.[A] StringLiteralExpCS ::= #x27 StringChar* #x27
    [B] StringLiteralExpCS[1] ::= StringLiteralExpCS[2] WhiteSpaceChar* #x27 StringChar* #x27

    where

    StringChar ::= Char | EscapeSequence

    WhiteSpaceChar ::= #x09 | #x0a | #x0c | #x0d | #x20

    Char ::= x20-#x26 | x28-#x5B | x5D-#xD7FF | xE000-#xFFFD | x10000-#x10FFFF

    EscapeSequence ::= '\' 'b' – #x08: backspace BS

    '\' 't' – #x09: horizontal tab HT
    '\' 'n' – #x0a: linefeed LF
    '\' 'f' – #x0c: form feed FF
    '\' 'r' – #x0d: carriage return CR
    '\' '"' – #x22: double quote "
    '\' ''' – #x27: single quote '
    '\' '\' – #x5c: backslash \
    '\' 'x' Hex Hex – #x00 to #xFF
    '\' 'u' Hex Hex Hex Hex – #x0000 to #xFFFF

    Hex ::= [0-9] | [A-F] | [a-f]

    A minor change could share the syntax definition and define the body as above prohibiting un-escaped usage of the character used as the surrounding quotes.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue statement presumes that characters in a string are encoded as Unicode. However, as a modeling language,
    UML does not presume any specific character set (it is specifically stated in 8.2.4 that “The character set used is
    unspecified.”) Therefore it is not possible to provide specific, standard notation for specific characters, particularly
    unprintable control characters.
    Disposition: Closed - No Change

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

BNF rules allow for a real 0

  • Key: UML25-270
  • Legacy Issue Number: 17824
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    BNF rules allow for a real “0”

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    That is true. After all, “0” is a real number. In fact, the BNF allows any natural-literal to be used as a real-literal.
    The textual syntax for real-literals is provided for the purpose of displaying LiteralReals in a model, and there is no
    requirement that it be unambiguously parsable as a means of entry of literals by a tool.
    Disposition: Closed - No Change

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

Notation: Real

  • Key: UML25-269
  • Legacy Issue Number: 17823
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The wording for Real allows '000.9' and '.9' as valid numbers. Permitting redundant leading zeroes is undesirable given the usage of leading zero as octal in some languages. Permitting the omission of a leading zero is also undesirable. The equivalent wording in OCL 2.3 is better but not perfect. "A real literal consists of an integer part, a fractional part and an exponent part. The exponent part consists of either the letter 'e' or 'E', followed optionally by a '' or '-' letter followed by an exponent integer part. Each integer part consists of a sequence of at least one of the decimal digit characters. The fractional part consists of the letter '.' followed by a sequence of at least one of the decimal digit characters. Either the fraction part or the exponent part may be missing but not both."UML and OCL should have compatible definitions.

    What is the concrete syntax for +/- infinity?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Both “000.9” and “+.9” are numerically correct representations of Reals. As a modeling language, it seems that UML
    should allow the same flexibility in literal notation as typical mathematical convention would allow. If a modeler wants
    to write “.9”, it doesn’t seem necessary for UML tools to be required to prevent this. There is no syntax for +/- infinity,
    since these are not values included in the mathematical range of real numbers. Certain floating point implementations
    may include such values, but the concept of Real in UML has intentionally been kept independent of implementation
    standards and, instead, kept as close to the mathematical conception of real numbers as possible (similarly to how
    Integer has previously been handled in UML).
    Disposition: Closed - No Change

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

LiteralNull semantics

  • Key: UML25-266
  • Legacy Issue Number: 17820
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    This makes no sense to me. The absence of a value is modeled by the absence of a value, particularly given that UML provides no CollectionTypes to model the multiplicity of values.If the upper bound is one, then LiteralNull could possibly be an alternative to a Literal'NotNull', but it isn't an empty set. If the upper bound is greater than one, how are any of the values really represented in UML?If LiteralNull is to be an optional value, it should derive from LiteralBoolean, LiteralReal. etc.

    Suggest delete LiteralNull or redefine it solely for use as the '0' of a [0..1] multiplicity.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 9700

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

Default value for LiteralReal

  • Key: UML25-265
  • Legacy Issue Number: 17818
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Why does LiteralReal have no default value?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The only reason that certain LiteralSpecifications still have default values in UML 2.5 is for backward compatibility
    with the UML 2.4.1. When LiteralReal was added in UML 2.5, it was decided not to compound the problem by giving
    LiteralReal a default value. (In addition, no UML tooling yet supported LiteralReal, since it was new, which made
    including a default real value in the UML metamodel difficult.)
    (See also the resolution to Issue 17817.)
    Disposition: Closed - No Change

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

Always non-negative

  • Key: UML25-279
  • Legacy Issue Number: 17839
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Duration is always non-negative value, so re-write text
    “A Duration is a non-negative value, often an integer expression ….

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Subclause 8.4.4 is on notation, so a statement on what whether a Duration is, in general, non-negative is not really
    appropriate there. Indeed, under 8.4.3 Semantics, it says that “UML does not define any specific type or units” that
    a Duration value may have, so whether a Duration is “non-negative” is not actually generally meaningful. The text
    in 8.4.4 is simply saying that a Duration is, notationally, “often a non-negative integer expression”, and, in this case,
    “non-negative” is meaningful, since it specifically modifies the phrase “integer expression”.
    Disposition: Closed - No Change

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

Duration

  • Key: UML25-278
  • Legacy Issue Number: 17838
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    What does it mean to have both an expr and an observation?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    According to 8.4.3, under Duration, “The expr may reference the observations associated with the Duration but no
    standard notation is defined for such references.” There are no further standard semantics defined for how observations
    are used in the evaluation of the expr of a Duration.
    Disposition: Closed - No Change

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

set - > list

  • Key: UML25-274
  • Legacy Issue Number: 17830
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    concatenating a set of substrings. concatenating a list of substrings

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed that “list” should be used instead of “set”.

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

Plural headers when class name is singular

  • Key: UML25-273
  • Legacy Issue Number: 17827
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Title is plural, class name is singular. Should be singular to give clear PDF bookmarks

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Titles under the Semantics parts in the UML 2.5 specification are not intended to necessarily be class names but,
    rather, to label semantic areas being discussed. Actual class names are bookmarked under the Classifier Descriptions
    subclauses.
    Disposition: Closed - No Change

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

body text strings

  • Key: UML25-276
  • Legacy Issue Number: 17832
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    may have a body that consists of a sequence of text Strings should be may have a sequence of body text Strings

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The current wording is technically correct, and it is consistent with similar wording used in the discussion of Opaque-
    Behaviors and OpaqueActions.
    Disposition: Closed - No Change

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

sentence unclear

  • Key: UML25-275
  • Legacy Issue Number: 17831
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    one or subExpressions of it may should be or one of its subExpressions may

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Actually, what was intended was “one or more subExpressions”.

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

Past vs Present

  • Key: UML25-271
  • Legacy Issue Number: 17825
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    specify computed values is a past tense potentially implying an already computed value. Suggest either specify computable values or specify computation of values

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The use of “computed” as an adjective in the phrase “computed values” does not necessarily imply “past
    tense”, but simply means “values that are computed” or “values resulting from a computation”. Perhaps the
    latter more explicit phraseology would be clearer, however.

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

String expression notation missing

  • Key: UML25-277
  • Legacy Issue Number: 17834
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    This is unclear. Several examples are needed

    missing string expression notation

    What is it? "aaa" + "bbb" ???

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    StringExpressions are used only as nameExpressions of NamedElements in UML. The notation for nameExpressions,
    such as it is, is discussed in Subclause 7.4.4. There is already a cross-reference for this at the end of the description of
    the notation of Expressions in 8.3.4.
    Disposition: Closed - No Change

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

{ordered} at wrong end

  • Key: UML25-272
  • Legacy Issue Number: 17826
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary: {ordered}

    on wrong end of StringExpression.subExpression

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 7882

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

UML diagram interchange: limitation of complex properties

  • Key: UMLDI-20
  • Legacy Issue Number: 7262
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The representation of properties as a collection of string key-value pairs means that non-string properties need to be encoded as strings. Can this present a limitation for more complex properties (references, maps, lists…etc)?

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

A schema definition has to be added for the completeness of the specificati

  • Key: UMLDI-19
  • Legacy Issue Number: 7788
  • Status: closed  
  • Source: Gentleware AG ( Marko Boger)
  • Summary:

    A schema definition has to be added for the completeness of the specification

  • Reported: UMLDI 1.0b1 — Wed, 29 Sep 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

Introduce a 'Nesting Guide'

  • Key: UMLDI-5
  • Legacy Issue Number: 7257
  • Status: closed  
  • Source: Gentleware AG ( Marko Boger)
  • Summary:

    Introduce a 'Nesting Guide' to specify the contained-container hierarchies
    of the diagram elements to represents all model elements of the semantic
    model

    Explanation:

    The semantic model elements are typically represented by a hierarchy of
    nested diagram elements which have a container-contained relationship. To
    specify which hierarchy of diagram elements is needed to model a special
    represenation of a model element we need a nesting guide which describes the
    hierachies for all model elements. This nesting guide should be an appendix
    to the diagram interchange specification and is added as an appendix to this
    document.

    Gentleware will provide a nesting guide that refers to the UML 1.4
    metamodel. As soon as the super- and infrastructure of the UML 2.0 is
    finally adopted a nesting guide for UML 2.0 should be created.

  • Reported: UMLDI 1.0b1 — Fri, 16 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

Change role name in DI metamodel

  • Key: UMLDI-4
  • Legacy Issue Number: 7252
  • Status: closed  
  • Source: Gentleware AG ( Marko Boger)
  • Summary:

    Change role name in DI metamodel of the SemanticModelBridge associated with the Diagram from 'namespace' to 'owner'

    Explanation:

    The association between the class 'Diagram' and 'SemanticModelBridge' in the DI metamodel has the intension to model which namespace is assigned to a diagram. So the name of the role of the SemanticModelBridge has been 'namespace'. But state diagrams and activity diagrams belong to a state machine. So the name 'owner' fits better in this context.

  • Reported: UMLDI 1.0b1 — Fri, 16 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

UML diagram interchange: unit of measurement

  • Key: UMLDI-14
  • Legacy Issue Number: 7268
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The coordinate system assumes ‘pixel’ to be the unit of measurement. Often publishing applications use a physical measurement instead (like himetric). Do we need to consider that? Which is more common for the types of applications in consideration?

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

UML diagram interchange: translucent property unnecessary?

  • Key: UMLDI-13
  • Legacy Issue Number: 7267
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Is the ‘Translucent’ property needed? Cannot be inferred by not having a background color property?

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

UML diagram interchange: do diagrams have to be nodes?

  • Key: UMLDI-12
  • Legacy Issue Number: 7266
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    If you considered zoom and viewport position to be in the workspace, then a diagram just has a name. This means a diagram does not have to be a node. It could just be a GraphElement. Also the diagram link having the same properties will have the same issue (By persisting these properties in the mode, team members would have to share these (not necessarily the expectation). )

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

UML diagram interchange: containment vs reference

  • Key: UMLDI-16
  • Legacy Issue Number: 7273
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    With regard to the OMG issue of changing the semantic bridge’s association with the diagram role from ‘namespace’ to ‘owner’, the request is appropriate but the justification that state diagrams are owned by state-machines and therefore the role name has to change is not correct. In fact, the important relationship between a state diagram and its state-machine should not be the containment but rather the reference relationship. A state diagram references a state-machine element through the semantic bridge’s ‘semantic model’ role. The containment relationship is optional; a state diagram could legitimately be referencing a state-machine but contained within another namespace (although not typical).

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

UML diagram interchange: association as a graph node

  • Key: UMLDI-15
  • Legacy Issue Number: 7272
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    You gave an example about the adornment of an association and its representation as a graph node. I thought this information can be deduced from the semantic relationship! Why do you need to explicitly represent it as a node?

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

UML diagram interchange: inappropriate diagram properties

  • Key: UMLDI-7
  • Legacy Issue Number: 7260
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Some properties like the diagram zoom level or viewport positions might not be suitable for a team environment, where each person could change them without having to share this preference with the rest of the team. By persisting these properties in the mode, team members would have to share these (not necessary the expectation). Alternatively, these properties could be part of the workspace preferences.

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

UML diagram interchange: views may need more context

  • Key: UMLDI-6
  • Legacy Issue Number: 7258
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The semantic bridge contains either a single reference property or a simple string. Some views, however, need more semantic context than that. (eg: pattern instance views need two semantic references to represent the semantic context).

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

UML diagram interchange: cut-out diagram feature

  • Key: UMLDI-11
  • Legacy Issue Number: 7265
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Regarding the cut-out diagram feature, I cannot see how the large diagram can layout out its referenced diagrams without explicitly store layout information. Is there any? This should be documented.

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

UML diagram interchange: dubious value of leaf elements

  • Key: UMLDI-10
  • Legacy Issue Number: 7264
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Rendering UML shapes is the responsibility of the tool. Therefore, there is no value in using Leaf Elements in the aggregation of UML views. If the intention of using them is notational (like whether attribute visibility should be textual or iconic) then a property is the better way to represent it.

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

Rename the specification to OMG Diagram Interchange Specification

  • Key: UMLDI-18
  • Legacy Issue Number: 7568
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The current title of the document reflects the original RFP but is far
    too specific for the standard produced and unnecessarily limits how
    people may think it can be applied.

    Proposed resolution:
    Rename the specification to OMG Diagram Interchange Specification

  • Reported: UMLDI 1.0b1 — Wed, 7 Jul 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

UML 2 Diagram Interchange / Assigning icons to stereotypes

  • Key: UMLDI-17
  • Legacy Issue Number: 7305
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There is a need to uniquely assign one or more stereotype icons to a stereotype, when that stereotype is defined. It should be explained how this stereotype is displayed and how multiple stereotypes are handled.

  • Reported: UMLDI 1.0b1 — Wed, 5 May 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

UML diagram interchange: more features in schema?

  • Key: UMLDI-9
  • Legacy Issue Number: 7263
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Vendors usually add more features to UML diagrams which could require more features in the schema. Is it expected for these features to be omitted when exporting to DI? If no, then there has to be an agreement on those formats as well

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

UML diagram interchange: limitation of complex properties

  • Key: UMLDI-8
  • Legacy Issue Number: 7261
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The representation of properties as a collection of string key-value pairs means that non-string properties need to be encoded as strings. Can this present a limitation for more complex properties (references, maps, lists…etc)?

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

property CoreSemanticModelBridge.element

  • Key: UMLDI-1
  • Legacy Issue Number: 6971
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The property CoreSemanticModelBridge.element should reference the class
    MOF::Object rather than Elements::Element. MOF::Object is the implicit
    superclass of everything in UML2/MOF2.
    Making this change allows diagram elements to refer to instances of any
    metamodel: not just UML2.

  • Reported: UMLDI 1.0b1 — Tue, 3 Feb 2004 05:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

Allow a Diagram Element to represent multiple Model Elements

  • Key: UMLDI-3
  • Legacy Issue Number: 7165
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    SemanticModelBridge.element (actually realized on its subclasses
    currently) has a multiplicity of 1.
    There are several cases where one visual diagram element will represent
    multiple elements in the metamodel (abstract syntax).
    For example 'AssemblyConnector' which I think should be a single symbol
    consisting of joined 'cup and ball' (see p148 of Superstructure
    ptc/03-08-02).

    Proposed resolution: change the multiplicity of
    SemanticModelBridge.element from 1 to 1..*.

  • Reported: UMLDI 1.0b1 — Thu, 18 Mar 2004 05:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

UML Diagram interchange -- change Rational ref to IBM

  • Key: UMLDI-2
  • Legacy Issue Number: 6973
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The current draft spec still refers to Rational Software in the front matter. Any references to this should be changed to IBM Rational Software

  • Reported: UMLDI 1.0b1 — Mon, 9 Feb 2004 05:00 GMT
  • Disposition: Resolved — UMLDI 1.0
  • Disposition Summary:

    No Data Available

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

Incarnation ?

  • Key: UML25-219
  • Legacy Issue Number: 17763
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Delete "within an incarnation" This is confusing

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed that the use of “incarnation” is confusing and unnecessary here. However, the intent is still that the
    individuals being discussed are “within” the system, so this should not be deleted.

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

Show how UML is a MOF metamodel

  • Key: UML25-218
  • Legacy Issue Number: 17761
  • Status: closed  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    We often say something like "UML is a MOF metamodel" or similar. It would be useful, I think, to show somewhere, perhaps in this subsection, exactly how that happens. For example, UML Classifier is an instance of MOF Classifier (right?), but nowhere do we actually SHOW how this happens. I think it would be instructive to show the general audience explicitly how this happens.
    Proposed Resolution: Add described text.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This material belongs in clause 6.2. Insert some text explaining that the abstract syntax of UML is defined
    by a UML model, replacing the paragraph that belonged to 2.4.1.

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

Conformance definitions ?

  • Key: UML25-214
  • Legacy Issue Number: 17756
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    current text: “
    A detailed definition of ways in which UML tools can be made conformant with this specification.

    As there is no separate conformance level, it appears that there is only one “way” to be conformant. Perhaps the whole sentence should be scratched.

    Clause 2 covers types of conformance not ways of conformance. so perhaps there is just a mismatch of terminology

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The bullet point is redundant because the very next section is all about conformance. Delete it.

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

Impact of merging profiles isn't small

  • Key: UML25-213
  • Legacy Issue Number: 17755
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    While the L3 profile only contained 3 stereotypes, that doesn't make this change small and by implication trivial. My expectation was that it should be trivial for tools to migrate 2.4.1 models to 2.5. However if both L2 and L3 profiles are applied to a package, this isn't the case and it isn't clear how any associated data should be merged. I understand the motivation for combining the profiles, but I don't think this should happen in 2.5.

    There is no mention of this migration issue in Annex E, which suggests that merely changing the version numbers is sufficient.

    Proposed Resolution:

    Continue to have separate profiles in 2.5 and consider merging them with full migration information in future UML version.
    Source: dave.hawkins@oracle.com

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue correctly notes that Annex E omits a mention of this change. Fix this omission.

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

Keyword Usage

  • Key: UML25-217
  • Legacy Issue Number: 17759
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the referenced document title, the terms OPTIONAL, REQUIRED, RECOMMENDED, and NOT RECOMMENDED are also defined. Our documents also use some of these terms. Is the usage of these terms conformal to RFC 2119?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Refer instead to the ISO rules

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

ISO version of UML 2?

  • Key: UML25-216
  • Legacy Issue Number: 17758
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Though it might be ok to mention that we are not based on the 19502:2005 technology, recently ISO/IEC have accepted UML 2.4.1, and that is more important to be mentioned. I don’t remember the correct document #.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    It seems rather pointless and unnecessary to mention any of this, particularly because the ISO docs are
    semantically the same as the OMG docs

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

Within the System

  • Key: UML25-220
  • Legacy Issue Number: 17764
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Change 'within a system' to 'to one or more objects'. This will be consistent with the references to objects in the other two bullets in this section. Also, the event may have a consequence outside the system.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The proposed change does not really address the final point of the issue, since “objects” in this context are
    already “within the system”. Also, the occurrence may have a consequence for an execution, not just an
    object (objects are being distinguished from executions at this point).

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

Capture Submitters, Supporters, etc

  • Key: UML25-212
  • Legacy Issue Number: 17754
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    If section 0 is going away at some time, don't we still need to capture the submitters, supporters, and friends.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    We already have all the authors, supporters and reviewers. All that we are missing is the submitting companies.

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

Modeling Individuals

  • Key: UML25-221
  • Legacy Issue Number: 17765
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Why is instance specification not included?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Value specifications are mentioned as a means to model objects, but it would make more sense to use
    instance specifications here instead, since that is the most common why to explicitly model objects in UML.
    (An instance specification is not itself a value specification, though an instance value, which is a kind of
    value specification, can reference an instance specification and an instance specification can have its value
    specified by a value specification.)

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

DI Conformance implies Model Interchange Conformance

  • Key: UML25-215
  • Legacy Issue Number: 17757
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Doesn’t DI conformance imply MI conformance?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Clarification on the semantics of Multiplicities

  • Key: UML25-191
  • Legacy Issue Number: 17583
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of Multiplicities
    Where: section 7.5.3
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    Multiplicitie: both ValueSpecification should be of the same type and of a type which has a total ordering defined on it and upper should be superior to lower.

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Actually, given the definitions of the operations lowerBound and upperBound, lowerValue should have type
    Integer and upperValue should have type UnlimitedNatural. More precisely, if lowerValue is not null, then
    lowerValue.integerValue() should not be null, and if upperValue is not null, then upperValue.unlimitedNaturalValue()
    should not be null. (There is already a constraint that upperBound() >= lowerBound()).

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

Clarification on the semantics of UML

  • Key: UML25-190
  • Legacy Issue Number: 17582
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of UML
    Where: section 6.3.1
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    It is not clear form the text:

    • What is the 'state' of an object/individual?
    • Are events and behavior 'objects'? Ie are they described by classifiers?
      Are classifiers also objects? Ie can a classifier describe another classifier?
  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The state of an object is the set of values associated with the properties of the classifier of the object.
    Event occurrences are not objects, but behavior executions actually are objects in UML behavioral semantics,
    because Behavior is a subclass of Class. However, it is clearer for the conceptual discussion of 6.3.1 to
    consider executions separately from objects.
    Classifiers may sometimes be considered individuals in their own right (e.g., see the discussion of static
    structural features in 9.4.3).

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

Conformance point

  • Key: UML25-189
  • Legacy Issue Number: 17581
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Conformance point
    Where: section 2
    Nature of Issue: Revision
    Severity of Issue: Significant
    Full Description of the Issue:

    • Dependencies among conformance points are not stated in all the case. Particularly, when they are no dependency, this need to be pointed out.
    • I don't understand the last paragraph which seems nevertheless to open a door to the most permissive conformance point ever read: does that say that if a vendor don't want to do everything s/he just have to state so and this is good? As a UML tool users, I cannot imagine this.
    • "Where the UML specification provides options for a conforming tool, these are explicitly stated in the specification": such options should also be gathered in this section for clearness.
    • What is the status of the section 6 wrt conformance and particularly 6.3 about UML semantics? At least, add a reference to 6.3 in the "Semantic conformance" bullet and in section 6 specify which chapter is informative and which is normative
  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    On point 1, introduce a statement that conformance points are independent unless otherwise stated.
    On point 2, this paragraph is something of a hangover from an idea about “feature support statements” in
    UML 2.4. It doesn’t add significant value, so delete it.
    On point 3, the FTF discussed this and decided that a complete solution to this proposal is intractable, and a
    partial solution (e.g. by searching through the text looking for “conforming”) is not worth doing.
    On point 4, introduce text in the semantic conformance point to state that 6.3 is normative

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

Clarification on the semantics of Properties

  • Key: UML25-193
  • Legacy Issue Number: 17585
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of Properties
    Where: section 9.5.3
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:

    • AgregationKind: "if a composite instance is deleted, all of its parts are normally deleted" what does mean 'normally'? Which other case could arise?
    • Does the definition of "composite" imply that an element can't be part of two composite instances in the same time? If yes, it should be stated so.
  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The word “normally” simply introduces confusion and should go.
    Some rephrasing is required to clarify that all composed instances are called parts, and also to use appropriate
    wording to clarify that the composition semantics only apply where the instances are objects.

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

Clarification on the semantics of Parameters

  • Key: UML25-192
  • Legacy Issue Number: 17584
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of Parameters
    Where: section 9.4.3
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    the 'effect' on a Parameter is not multiple but couldn't a parameter be read and updated or created?

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Yes, it could, and making effect multiple might be a desirable enhancement, but could affect interoperability.
    Instead,clarify that a single effect does not exclude other effects from occurring. Also clarify that effect does
    not apply to primitive types, because they cannot be created or deleted. Update the definitions in the table
    to be non-circular.

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

Clarification on the semantics of Manifestation

  • Key: UML25-197
  • Legacy Issue Number: 17590
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of Manifestation
    Where: section 19.3.3
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    The semantics of Manifestation is not defined in 19.3.3.

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The last paragraph of 19.3.3 defines the semantics of Manifestation as follows: “An Artifact may embody, or manifest,
    a number of model elements. The Artifact owns the Manifestations, each representing the utilization of some
    PackageableElement. Profiles may extend the Manifestation relationship to indicate particular forms of embodiment.
    For example, «tool generated» and «custom code» might be two Manifestations for different Classes embodied in an
    Artifact.” This seems sufficiently clear.
    Disposition: Closed - No Change

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

Clarification on the aim of Collaborations

  • Key: UML25-196
  • Legacy Issue Number: 17588
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the aim of Collaborations
    Where: section 11.7
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    "It (purpose of Collaborations) is intended as a means for capturing standard design patterns": could you please elaborate on this because this is not trivial. An example would also be welcomed.

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The Observer design pattern (http://en.wikipedia.org/wiki/Observer_pattern) is the first in the Examples
    section, so there is already an example. But the quoted sentence may still be somewhat confusing, because
    Collaborations can be used to describe other things than standard design patterns, and standard design patterns
    can be described using other things than Collaborations (e.g. templates). Since it doesn’t add clarity,
    let’s remove it.

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

Clarification on the semantics of ports in Encapsulated Classifiers

  • Key: UML25-195
  • Legacy Issue Number: 17587
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of ports in Encapsulated Classifiers
    Where: section 11.3.2
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    Please specify clearly that the ConnectableElements connected by a same Connector must belong to the same StructuredClassifier: this made some issues in the past (UML4DDS).

    • The concept of 'side' of a port is not explained enough, depending if it is a port or a port on a part.
    • "if there is a Connector attached to only one side of a Port, any requests arriving this Port will be lost" does it also stand for port which are not 'on a part'? Because in that case, the Port is an external boundary and a Connector may only be inside the Encapsulated Classifiers, may it not?
  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The first part of the issue is the same as 17586, and requires no changes because the constraint Connector::
    roles covers it.
    The second and third parts of this issue refer to the sentence “If there is a Connector attached to only one
    side of a Port, any requests arriving at this Port will be lost.” It is quite right to say that at this point in the text
    the concept of “side” of a Port is not well defined. But further, if there is a Connector attached to only one
    side of a Port, then it may well be the case that the model is simply silent about what happens to requests:
    there is no reason to say that they shall be lost. Indeed, most of the examples in this clause have Connectors
    only attached to one side of a Port. Hence the sentence should be deleted, as it adds only confusion.

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

Clarification on the semantics of Connectors within Structured Classifiers

  • Key: UML25-194
  • Legacy Issue Number: 17586
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of Connectors within Structured Classifiers
    Where: section 11.2.3
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    Please specify clearly that the ConnectableElements connected by a same Connector must belong to the same StructuredClassifier: this made some issues in the past (UML4DDS).

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This is already clearly specified by the Connector::roles constraint. There is a live discussion about whether this
    constraint is too tight (it should probably permit connecting to inherited roles), but that is a different issue.
    Disposition: Closed - No Change

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

Declassifying of Annex D

  • Key: UML25-198
  • Legacy Issue Number: 17592
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Declassifying of Annex D
    Where: Annex D
    Nature of Issue: Revision
    Severity of Issue: Minor
    Full Description of the Issue:
    This annex is too poor (only sequence diagrams are dealt with) to be called 'normative'.

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    We decided to address the issue by retitling the Annex and deleting the first paragraph that implies the
    approach can be more widely applied to behavioral diagrams.

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

Missing word in section 7.4.3, "Semantics"

  • Key: UML25-200
  • Legacy Issue Number: 17601
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "associated whose subexpressions"

    There's clearly a word missing between "associated" and "whose".

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed. The missing word is “StringExpression

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

Four typos

  • Key: UML25-199
  • Legacy Issue Number: 17600
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    1. 13.4 Classifier Descriptions, Association Ends, p315
    "Behaviosr" -> "Behavio(u)r"

    2. 7.4.3 Semantics, Namespaces, p32
    "A namespace may also import NamedElements ...". "namespace" should be capitalised ("Namespace").

    3. 7.8 Classifier Descriptions, ElementImport [Class], Attributes, p49
    "whetherthe" -> "whether the".

    4. 9.9 Classifier Descriptions, Operations, p165
    "is the same or a subtype as" -> "is the same or a subtype of".

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    1. “Behaviosr” no longer appears in the text. No change.
    2. The problem remains: fix it.
    3. “whetherthe” no longer appears in the text. No change.
    4. “is the same or a subtype as” appears in ValueSpecification::isCompatibleWith and Property::isCompatibleWith;
    fix it.

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

ElementImport semantics

  • Key: UML25-206
  • Legacy Issue Number: 17610
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "An ElementImport identifies an Element in a different Namespace, and allows the Element to be referenced using its name without a qualifier in the Namespace owning the ElementImport."

    Firstly, different to what?

    Secondly, "its name" is confusing, since the name may be changed via aliasing.

    I think this should be rewritten as: "An ElementImport identifies a NamedElement in a Namespace other than the one that owns it, and allows that NamedElement to be referenced using an unqualified name in the Namespace owning the ElementImport."

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Same name" vs. "indistinguishable name"

  • Key: UML25-205
  • Legacy Issue Number: 17608
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    " ...it also excludes PackageableElements that would have the same name as each other when imported."

    Surely this should say " ... it also excludes PackageableElements that would have indistinguishable names when imported."

    (See discussion of Namespace semantics on p33).

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Missing Table of Figures, Table of Tables - Location: TOC p 10

  • Key: UML25-211
  • Legacy Issue Number: 17753
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:
  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Generate a table of figures and table of tables

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

Minor vs Major revision

  • Key: UML25-210
  • Legacy Issue Number: 17752
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Current text:
    “Version 2.5 is a minor revision to the UML 2.4.1 specification. It supersedes formal/2011-08-06”

    However, in 6.1 Specification Simplification, we have the following text.
    This specification has been extensively re-written from its previous version to make it easier to read by removing redundancy and increasing clarity. In particular, the following major changes have been made since UML 2.4.1:

    Notice that it identifies major changes

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Formally-speaking according to the Policies and Procedures it is a minor revision. However some clarification
    is in order.

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

Further clarify Element ownership constrains

  • Key: UML25-204
  • Legacy Issue Number: 17606
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    13. p26: "Every Element in a model must be owned by some other Element of that model ..."

    "Some" could perhaps be more precisely stated - "Every Element in a model is owned by exactly one other Element of that model ..."

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Semantic conformance implies Abstract Syntax conformance

  • Key: UML25-203
  • Legacy Issue Number: 17605
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    The conformance statement notes that "Model interchange conformance implies abstract syntax conformance" and "Diagram interchange conformance implies both concrete syntax conformance and abstract syntax conformance".

    As far as I can tell, Semantic conformance implies Abstract Syntax conformance. For consistency, this could also be noted.

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

isConsistentWith() definition broken

  • Key: UML25-207
  • Legacy Issue Number: 17612
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    The definition of "isConsistentWith(redefinee : RedefinableElement) : Boolean" is broken in at least two ways.

    Firstly, the OCL includes the term "op.ownedParameter->at(1)" which should presumably be "op.ownedParameter->at" (substitute letter "i" for digit "1").

    Secondly, the OCL and textual definition say that each parameter is checked for conformance in the same direction, regardless of whether they're "in" or "out" parameters.

    To deliver a safe substitutability (aka conformsTo) relationship, the "in" parameters of the substituting operation must conform to the "in" parameters of the substituted operation, but the "out" parameters must conform in the opposite direction (i.e. "out" parameters of the substituted operation conform to the "out" parameters of the substituting operation).

    Since "inout" parameters pass parameters in both directions, they must conform in both directions simultaneously (which is a good definition of being "the same type").

    Correcting the first bug is trivial. However, unless the second bug is also corrected, the given definition of isConsistentWith() will flag many type-safe substitutions as "not consistent", and many unsafe substitutions as "consistent". It must be corrected.

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 15499

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

Suggested improvements to conformance section

  • Key: UML25-202
  • Legacy Issue Number: 17604
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    p15: "A conforming UML 2.5 tool shall be able to load and save XMI in UML 2.4.1 format as well as UML 2.5 format." It would be worth inserting a reference to Annexe E (p 784) which gives a rationale for this conformance requirement.

    p15: "A tool demonstrating diagram interchange conformance can import and export conformant DI ..." Similarly, it would be worth inserting a reference here to Annexe B (p736) on UML Diagram Interchange.

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the suggestions

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

Section 11.5. - Clause 11: Structured Classifiers

  • Key: UML25-209
  • Legacy Issue Number: 17749
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Section 11.5.4 says “Generalizations between Associations can be shown using a generalization arrow between the Association symbols”. What about shared target style and generalization sets? Is a conforming tool required to do these for association generalizations?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Make these explicitly optional

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

PDF links to Primitive Types don't work

  • Key: UML25-201
  • Legacy Issue Number: 17602
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    The comprehensive hyperlinks in the PDF version of the specification are useful when reading it online. However, the links for the Primitive types (Boolean, Integer, String, Real, UnlimitedNatural) don't work.

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The individual primitive types don’t have their own heading in the document. Make the hyperlinks go to the
    clause heading for clause 21.

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

Superfluous word on p309

  • Key: UML25-208
  • Legacy Issue Number: 17614
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    "(i.e. the type of the corresponding Parameters, order, must be the same)"

    The word "order" and the two commas are superfluous.

  • Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Problem with ExtensionEnd::lower

  • Key: UML24-111
  • Legacy Issue Number: 15762
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In the UML 2.4 metamodel, there is a definition of ExtensionEnd::/lower in the superstructure that marks the property as derived, and at the same time gives it a default of 0. The spec text and diagrams do not show it as derived, so the metamodel and diagrams are inconsistent. The same is true in 2.3.

    This seems to be a significant issue with regard to profile interchange, so I’d like to fix it in 2.4. Juergen, could we have an issue number please?

    Profiles::ExtensionEnd::/lower redefines MultiplicityElement::/lower.

    MultiplicityElement::/lower is marked as derived. It does not have a default value. Instead, there is a derivation constraint:

    lower = lowerBound(); and operation

    lowerBound() = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif

    In the metamodel, ExtensionEnd::/lower is marked as derived, redefining MultiplicityElement::/lower, and with default value = 0. What is this supposed to mean? If it redefines MultiplicityElement::/lower, presumably it should redefine the way that it is derived. But it does not. So there is no well-defined derivation.

    If we regarded the derivation in MultiplicityElement to be somehow “inherited” across the redefinition, we would then have a clash between the 1 defined in Multiplicity::lowerBound(), and the 0 defined as the default value for ExtensionEnd::lower.

    I think to fix this what we ought to do is the following. Instead of giving ExtensionEnd::/lower a default value, we should provide the following constraints and operations in ExtensionEnd:

    lower = lowerBound(); and

    lowerBound() = if lowerValue->isEmpty() then 0 else lowerValue.integerValue() endif

    This seems to be consistent with current profile interchange practice. I see the following in MIWG testcase3, which is consistent with my proposal.

    <packagedElement xmi:type="uml:Extension" xmi:id="_9YgZUFzvEd6YpLSSRX9zkg" name="Property_Stereotype3" memberEnd="_9YgZUVzvEd6YpLSSRX9zkg _9YgZU1zvEd6YpLSSRX9zkg">

    <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="_9YgZUVzvEd6YpLSSRX9zkg" name="extension_Stereotype3" type="_FbscYFzfEd6YpLSSRX9zkg" aggregation="composite" owningAssociation="_9YgZUFzvEd6YpLSSRX9zkg" association="_9YgZUFzvEd6YpLSSRX9zkg">

    <lowerValue xmi:type="uml:LiteralInteger" xmi:id="_9YgZUlzvEd6YpLSSRX9zkg" value="1"/>

    </ownedEnd>

    </packagedElement>

  • Reported: UML 2.3 — Tue, 19 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    After analysis, it becomes clear that the diagnosis above is flawed. When Profiles are merged in at L2 and above, Kernel is merged in too. When they are all merged in, the complete definition of ExtensionEnd::/lower [0..1] is acquired from the following sources:

    • the fact that it is derived is from AuxiliaryConstructs::Profiles
    • the constraint that determines how it is derived from lowerBound() is inherited from Kernel::MultiplicityElement
    • the redefined operation lowerBound() is merged from InfrastructureLibrary::Profiles::ExtensionEnd: the operation is specified there even though lower is not derived in that place. This operation redefines Core::Constructs::MultiplicityElement::lowerBound(), so after merging will redefine Kernel::MultiplicityElement::lowerBound().
      However, the [0..1] multiplicity of lower() – the operation which gives the derivation for ExtensionEnd::/lower in the metamodel – conflicts with the [1] multiplicity of the corresponding redefined lower() operation in MultiplicityElement – it represents a “widening” of the multiplicity in a redefinition. This turns out to be a bug in the metamodel. In the spec, MultiplicityElement::lower(), MultiplicityElement::lowerBound() MultiplicityElement::upper(), MultiplicityElement::upperBound(), ValueSpecification::integerValue() are all defined with result types of Set(Integer), but have been implemented in the metamodel as Integer[1]. So the material defects are that lower is not correctly defined in the text or diagrams of clause 18, and the operations around MultiplicityElement and ValueSpecification should have their multiplicities corrected.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML state machines: inconsistent subset of StateMachine::extendedStatemachine

  • Key: UML24-108
  • Legacy Issue Number: 15669
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Issue 15265 proclaimed that StateMachine::extendedStatemachine should subset Classifier::redefinedClassifier. However, while the text entry for this field does this, the diagram in Figure 15.3 subsets Behavior::redefinedBehavior instead. It seems that the fix was not applied properly. Note that Behavior::redefinedBehavior is not a derived union property, so Figure 15.3 is just plain wrong – although it could be argued that the proper fix is to make it a derived union and have StateMachine::extendedStatemachine redefine Behavior::redefinedBehavior

  • Reported: UML 2.3 — Thu, 30 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Figure 15.3 (referring to the version of 2.4 published in September 2010) is not wrong – it is valid for a property to subset a non-derived one. However the semantic question here is what exactly extendedStateMachine is supposed to mean that cannot be accomplished by using redefinedBehavior.
    It is wrong, however, in the sense that resolution 15265 was not correctly or consistently applied.
    At this point we need at least to make the resolution consistent.
    I propose to do this by making extendedStateMachine redefine behavior::redefinedBehavior, having the effect that only a state machine may redefine a state machine.

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

isDerived with DefaultValue

  • Key: UML24-107
  • Legacy Issue Number: 15668
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    I think derived properties should not have default values, since they are calculated from other info in the model and not from those default values.

    Here is a list of such derived properties in the metamodel:

    PropertyIsDerivedWithDefaultValue : 13
    property = <Property> UML::State::/ isSubmachineState : Boolean
    defaultValue = <Literal Boolean> false
    property = <Property> UML::State::/ isSimple : Boolean
    defaultValue = <Literal Boolean> true
    property = <Property> UML::State::/ isOrthogonal : Boolean
    defaultValue = <Literal Boolean> false
    property = <Property> UML::State::/ isComposite : Boolean
    defaultValue = <Literal Boolean> false
    property = <Property> UML::Operation::/ upper : UnlimitedNatural [0..1]
    defaultValue = <Literal UnlimitedNatural> 1
    property = <Property> UML::Operation::/ lower : Integer [0..1]
    defaultValue = <Literal Integer> 1
    property = <Property> UML::Operation::/ isUnique : Boolean
    defaultValue = <Literal Boolean> true
    property = <Property> UML::Operation::/ isOrdered : Boolean
    defaultValue = <Literal Boolean> false
    property = <Property> UML::MultiplicityElement::/ upper : UnlimitedNatural [0..1]
    defaultValue = <Literal UnlimitedNatural > 1
    property = <Property> UML::MultiplicityElement::/ lower : Integer [0..1]
    defaultValue = <Literal Integer> 1
    property = <Property> UML::Message::/ messageKind : MessageKind
    defaultValue = <Instance Value> unknown
    property = <Property> UML::ExtensionEnd::/ lower : Integer [0..1]
    defaultValue = <Literal Integer > 0
    property = <Property> UML::Extension::/ isRequired : Boolean
    defaultValue = <Literal Boolean> false

    do we need to fix them?

  • Reported: UML 2.3 — Thu, 30 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The FTF agrees that these default values are meaningless, and in many cases confusing. Remove them

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

Change all properties typed by data types to aggregation=none

  • Key: UML24-104
  • Legacy Issue Number: 15575
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There is no semantic for making a property with a data type composite, so remove these markings

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    UML::OpaqueAction::language
    UML::OpaqueAction::body
    UML::OpaqueBehavior::language
    UML::OpaqueBehavior::body
    UML::OpaqueExpression::language
    UML::OpaqueExpression::body

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

Give all constraints unique names within their context.

  • Key: UML24-103
  • Legacy Issue Number: 15574
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Several constraints have no names. A couple of constraints have different names in different merge increments, but are the same constraint:

    UML::Constraint::not_apply_to_self, UML::Constraint::not_applied_to_self,

    UML::Classifier::generalization_hierarchies, UML::Classifier::no_cycles_in_generalization

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Here are the constraints with no names.
    UML::Transition::isConsistentWith::
    UML::RedefinableTemplateSignature::isConsistentWith::
    UML::RedefinableElement::isConsistentWith::
    UML::Property::isConsistentWith::
    UML::Package::makesVisible::
    UML::Operation::isConsistentWith::
    UML::OpaqueExpression::value::
    UML::OpaqueExpression::isPositive::
    UML::OpaqueExpression::isNonNegative::
    UML::MultiplicityElement::isMultivalued::
    UML::MultiplicityElement::includesMultiplicity::
    UML::MultiplicityElement::includesCardinality::
    UML::Classifier::inheritableMembers::
    UML::Classifier::hasVisibilityOf::
    These are all preconditions of operations. All of the bodies are named “spec” so I propose that all of the preconditions are named “pre”. I notice that Classifier::inheritableMembers has an incorrect un-named postcondition.

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

UML 2.4 - ConditionalNode - Semantics

  • Key: UML24-110
  • Legacy Issue Number: 15711
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The last paragraph of the semantics section of 12.3.18 ConditionalNode, states

    Within the body section, variables defined in the loop node or in some higher-level enclosing node may be accessed and updated with new values. Values that are used in a data flow manner must be created or updated in all clauses of the conditional; otherwise, undefined values would be accessed.

    I assume that the reference to ‘loop node’ is incorrect.

  • Reported: UML 2.3 — Sat, 9 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue is obsolete. The quoted text is no longer used in the UML 2.5 beta specification.
    Disposition: Closed - No Change

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

DecisionNode at all guards evaluated to false

  • Key: UML24-109
  • Legacy Issue Number: 15708
  • Status: closed  
  • Source: gmx.net ( Stephan Grund)
  • Summary:

    DecisionNode's behaviour when a token cannot pass any edge at the moment it arrives and the guards are evaluated is not specified.
    When will the guards be evaluated next time?

  • Reported: UML 2.3 — Thu, 7 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This is covered in the UML 2.5 beta specification in Subclause 15.3.3 under “Decision Nodes”. The specification
    states: “If any of the outgoing edges of a DecisionNode have guards, then these are evaluated for each incoming
    token.” and “A token offered on the primary incoming edge of a DecisionNode shall not traverse any outgoing edge
    for which the guard evaluates to false.” So, if no guards evaluate to true, the token will not traverse any of the outgoing
    edges. The next time the guards are evaluated is when the next token is offered to the DecisionNode.
    Disposition: Closed - No Change

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

EnumerationHasOperations : UML::VisibilityKind::bestVisibility

  • Key: UML24-101
  • Legacy Issue Number: 15572
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    This is disallowed by MOF. [8] Enumerations may not have attributes or operations. This operation is not used – remove it.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Agreed: the operation is defined in both Infrastructure 9.21.2 (and index) and Superstructure 7.3.56 but is not used anywhere.

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

Parameter have Effects

  • Key: UML24-100
  • Legacy Issue Number: 15571
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    These are attributes in the metamodel, but are not included in MOF 2.4, so should be removed.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Here are the parameters that have effect set in the metamodel. Parameter::effect is defined with multiplicity [0..1], and in metamodels should be set to null.
    UML::Classifier::maySpecializeType::c
    UML::Classifier::inheritableMembers::c
    UML::Property::isAttribute:
    UML::Region::isRedefinitionContextValid::redefined
    UML::State::isRedefinitionContextValid::redefined
    UML::Component::usedInterfaces::classifier
    UML::Component::realizedInterfaces::classifier
    UML::StateMachine::isRedefinitionContextValid::redefined
    UML::RedefinableElement::isRedefinitionContextValid::redefined

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

Property::isID should not be optional

  • Key: UML24-106
  • Legacy Issue Number: 15664
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Property::isID should not be optional”. The summary is “Property::isID should have multiplicity 1..1 and default value = false. There is no additional useful semantic provided by making it optional

  • Reported: UML 2.3 — Tue, 28 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

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

stereotype <> for defining parameterized classes is nowhere defined

  • Key: UML24-112
  • Legacy Issue Number: 15765
  • Status: closed  
  • Source: Vienna University of Economics and Business ( Bernhard Hoisl)
  • Summary:

    Usage of <<bind>> to define parameterized classes in object diagrams is nowhere defined in the UML specification. Not as a keyword in Annex B (p. 707) and also not as a standard stereotype (Annex C, p. 713).

    I just wondered what the actual definition of <<bind>> may be. Maybe it would be good to define it somewhere.

  • Reported: UML 2.3 — Tue, 19 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 18454

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

UML 2.4 - Interaction

  • Key: UML24-105
  • Legacy Issue Number: 15622
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In the semantics section of MessageEnd it says “Subclasses of MessageEnd define the specific semantics appropriate to the concept they represent.”

    However, in the semantics section of MessageOccurrenceSpecification, a subclass of MessageEnd, it says “No additional semantics”

    So it’s not clear what the semantics of MessageOccurrenceSpecification are.

  • Reported: UML 2.3 — Tue, 21 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

The metamodel contains instances of Model

  • Key: UML24-102
  • Legacy Issue Number: 15573
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    InfrastructureLibrary and UML are instances of Model, and MOF does not include Model.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Change Models to Packages

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

xmi files in the 2.4 RTF deliverables have cmof tags contained in a non-XMI root element

  • Key: UML24-80
  • Legacy Issue Number: 15438
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    xmi files in the 2.4 RTF deliverables have cmof tags contained in a non-XMI root element. Was it intentional that the current UML format XMI files use MOF/2.4 and
    XMI/2.4 in their namespaces, even though these namespaces won't actually be correct? There is also an error in the structure of the .xmi files. A non xmi:XMI root element has been used that includes a cmof:Tag element, which is incorrect. The following files are affected:
    10-08-17.xmi
    10-08-18.xmi
    10-08-22.xmi
    10-08-23.xmi
    10-08-27.xmi
    10-08-28.xmi
    10-08-29.xmi
    L0.merged.xmi
    L1.merged.xmi
    L2.merged.xmi
    LM.merged.xmi

    Example:
    ==> LM.merged.xmi <==
    </ownedComment>
    </ownedLiteral>
    </packagedElement>
    <cmof:Tag xmi:id="_2" name="org.omg.xmi.nsPrefix" value="uml" element="_0"/> </uml:Package> Should be:
    ==> LM.merged.xmi <==
    </ownedComment>
    </ownedLiteral>
    </packagedElement>
    </uml:Package>
    <cmof:Tag xmi:id="_2" name="org.omg.xmi.nsPrefix" value="uml" element="_0"/> </xmi:XMI>

    I've also just noticed that the most recent package resolution added a property named "URI" rather than "uri", which is inconsistent with the old MOF property and is slightly unusual capitalisation for a property.
    However that's a minor point.

  • Reported: UML 2.3 — Thu, 26 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    It was intentional to use the 2.4 namespaces, see 15530.
    Publish all of the xmi files that include cmof:Tag elements with a top-level XMI tag.
    Leave the property named URI as it is.
    Fix the profile XMI examples to conform to the normative specs.

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

Operation::isConsistentWith

  • Key: UML24-82
  • Legacy Issue Number: 15499
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    The description for Operation::isConsistentWith(redefinee : RedefinableElement) suggests that parameter direction should be consistent

    "A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result."

    However, the OCL provided does not check that the "direction" of parameters is consistent.

    Operation::isConsistentWith(redefinee: RedefinableElement): Boolean;

    pre: redefinee.isRedefinitionContextValid(self)

    result = redefinee.oclIsKindOf(Operation) and
    let op: Operation = redefinee.oclAsType(Operation) in
    self.ownedParameter->size() = op.ownedParameter->size() and
    Sequence

    {1..self.ownedParameter->size()}

    ->
    forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(1).type))

  • Reported: UML 2.3 — Mon, 13 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Clause 9.6.3 currently says “This redefinition may specialize the types of the owned Parameters. . . ” and,
    contradicting this, says “In UML, such rules for type conformance are intentionally not specified.”
    We do not mandate either covariance or contravariance for parameters in operation definition, explicitly
    allowing either. We will require parameter direction, uniqueness and ordering to be the same. We will
    require a multiplicity for which one of the following is true:
    • The same as the redefined parameter
    • For an in parameter, multiplicity including (wider than) that of the redefined parameter
    • For an out or return parameter, the redefined parameter’s multiplicity includes (is wider than) that of
    the redefining parameter.
    This also resolves Issues 17924 and 17612.

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

UML2.4: StandardProfileL2 & L3 are incomplete as delivered

  • Key: UML24-81
  • Legacy Issue Number: 15439
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    1) the deliverables below are not well formed; each of StandardProfileL2 and StandardProfileL3 below is missing a reference to the UML2.4 metamodel as a PackageImport element.

    Filename: StandardProfileL2.xmi
    Description: This file contains the XMI of the UML v2.4 Standard Profile L2 as an instance of UML 2.4 using XMI 2.1.
    Doc Number (if any): ptc/2010-08-22
    Normative: Yes
    Dependencies: UML.xmi
    URL: http://www.omg.org/spec/UML/20100901/StandardProfileL2.xmi

    Filename: StandardProfileL3.xmi
    Description: This file contains the XMI of the UML v2.4 Standard Profile L3 as an instance of UML 2.4 using XMI 2.1.
    Doc Number (if any): ptc/2010-08-23
    Normative: Yes
    Dependencies: UML.xmi
    URL: http://www.omg.org/spec/UML/20100901/StandardProfileL3.xmi

    2) the inventory is missing the StandardProfileL2 & StandardProfileL3 as an instance of UML2.4 using XMI2.4.

    The artifacts on the UML2.xRTF SVN for StandardProfileL2/L3 as UML2.4/XMI2.4 have the same problem as the artifacts in (1).

  • Reported: UML 2.3 — Mon, 30 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

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

bodyCondition and isQuery

  • Key: UML24-84
  • Legacy Issue Number: 15501
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Constraint [7] in Kernel::Operation says:

    "A bodyCondition can only be specified for a query operation"

    Let us look at the definition of isQuery and bodyCondition:

    bodyCondition: Constraint[0..1]
    An optional Constraint on the result values of an invocation of this Operation.

    isQuery : Boolean
    Specifies whether an execution of the BehavioralFeature leaves the state of the system unchanged (isQuery=true) or whether side effects may occur (isQuery=false).

    Question:

    I am not sure why specifying a condition on the result of an operation is only limited to operations with no side effects. What is wrong with specifying a condition on the result of a non-query operation?

  • Reported: UML 2.3 — Mon, 13 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Body conditions are already a major source of logical uncertainty and inconsistency between OCL and UML. Relaxing
    their usage would only make this worse: the OCL spec states “An OCL expression may be used to indicate the result
    of a query operation”.
    This also resolves 15768.
    Disposition: Closed - No Change

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

isConsistentWith

  • Key: UML24-83
  • Legacy Issue Number: 15500
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    The operation RedefinableElement::isConsistentWith(redefinee : RedefinableElement) has the documentation:

    "The query isConsistentWith() specifies, for any two RedefinableElements in a context in which redefinition is possible, whether redefinition would be logically consistent. By default, this is false"

    It is not clear from this description above whether the parameter "redefinee" is the redefining or the redefined element.

    A look at some of the overrides of this operation like Property::isConsistentwith(redefinee : RedefinableElement):

    " A redefining property is consistent with a redefined property if the type of the redefining property conforms to the type of the redefined property, and the multiplicity of the redefining property (if specified) is contained in the multiplicity of the redefined property. "

    The description suggests that the "redefinee" is probably the "redefined" property.

    On the other hand, the precondition provided in OCL suggests that "refinee" is definitely the "redefining" property:

    pre: redefinee.isRedefinitionContextValid(self)

    since RedefinableElement::isRedefinitionContext(redefined : RedefinableElement) has the description:

    "...at least one of the redefinition contexts of this element must be a specialization of at least one of the redefinition contexts of the specified element."

    In summary, this means RedefinableElement has the two operations:

    RedefinableElement::isConsistentWith(redefining : RedefinableElement)
    RedefinableElement::isRedefinitionContext(redefined : RedefinableElement)

    At least "redefinee" should be renamed to "redfining" since this is the term used in the descriptions. However, having the two closely related operations taking opposite parameters make it very confusing and inconsistent.

  • Reported: UML 2.3 — Mon, 13 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The issue has identified a serious problem of understanding with the operations that define what consistency
    between RedefinableElements means. Does A.isConsistentWith(B) get calculated when A is redefining, or
    when A is being redefined? The parameter name “redefinee” seems to imply that it gets calculated when A
    is redefining. But this turns out not to be the case. According to constraint redefinition_consistent, it is when A is being redefined. This also applies to the
    logic of Property::inConsistentWith and Operation::isConsistentWith (although see also 15499). For all
    other definitions of isConsistentWith the direction does not matter. So the logic consistently states that the
    parameter is the redefining element. Make this clear by renaming the parameter as redefiningElement.
    Now isRedefinitionContextValid is the other way around, as evidenced by the precondition for inConsistentWith:
    redefinee.isRedefinitionContextValid(self).
    Make this clearer by naming the parameter redefinedElement.
    It would perhaps be better to systematically reverse the sense of one of these operations, but that seems
    overly disruptive at this point. The constraint redefinition_context_valid is wrong. It omits the term “self”,
    rendering the constraint tautological. All of the constraints in RedefinableElement are too cryptic to be clear.

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

"unique" annotation

  • Key: UML24-74
  • Legacy Issue Number: 15399
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Since the "isUnique" and "isOrdered" properties have default values, do we need to have both 'unique'/'nonunique' and 'ordered'/'unordered' textual annotations? or do we only need ones for non-default values?

    I noticed that in some presentation option sections in the spec both annotation values are mentioned, while in other sections only one value is mentioned (diagrams in the spec also use them inconsistently):

    Superstructure:

    7.3.3 Association has 'nonunique' and 'ordered <= This seems to be the most correct
    7.3.32 MultiplicityElement has 'unique'/'nonunique' and 'ordered'/'unordered'
    7.3.36 Operation has 'unique' and 'ordered'
    7.3.44 Property have 'unique'/ 'nonunique' and 'ordered'

    Infrastructure:

    9.12.1 MultiplicityElement has 'unique'/'nonunique' and 'ordered'/'unordered'
    11.8.2 Operation has 'unique' and 'ordered'
    11.3.5 Property have 'unique' and 'ordered'

    What made me notice that is the addition of 'id' by resolution 15369, do we need to log an issue to fix this later?

  • Reported: UML 2.3 — Thu, 5 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The inconsistency is still there as specified in the issue. The general notation is defined in MultiplicityElement.
    It does have to be repeated for Property because the syntax allows the insertion of ‘=’ <default>
    between the multiplicity and prop-modifiers, and for Operation because the <oper-property> can be intermingled
    with others. The ‘sequence’ option is present for Property but inconsistently absent for Operation.
    The <parm-property> term is currently undefined and needs to have the same options.

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

The stereotype «Create» and keyword «create» are both defined in the UML 4 document

  • Key: UML24-77
  • Legacy Issue Number: 15419
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The stereotype «Create» and keyword «create» are both defined in the UML 4 document

    a. Figure 9.10 uses «create»

    b. Figure 9.27 uses «create»

    c. In appendix B, 2nd page, the «create» keyword is defined to apply to an operation that is a constructor, and to apply to a usage dependency, both uses of «create» appear in the Table B.1. This is consistent with items a and b above.

    d. In table C.1, both these uses are also defined as stereotypes, but with «Create». However, as stereotype matching is case insensitive, this is also consistent with items a and b above. So are the usages in a and b, keywords or stereotypes?

    e. In the last (and unlabeled) table in section C of obsolete elements, «create» is obsolete when applying to a CallEvent or Usage. How does this fit in?

    similar problems apply to several elements in table B.1 which are both stereotypes and keywords

  • Reported: UML 2.3 — Tue, 17 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 18454

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

Figure 9.2 (Abstractions subpackage dependencies) has wrong dependency

  • Key: UML24-76
  • Legacy Issue Number: 15413
  • Status: closed  
  • Source: gmail.com ( Dmitry Semikin)
  • Summary:

    On the figure 9.2 "The Abstractions package contains several subpackages, all of which are specified in this clause" (shows all dependencies of Abstractions package subpackages)the Namespaces package do not depend on any others. But actually it depends on Ownerships package. Note: it is shown in right way in section "9.14 Namespaces Package".

    Side effect:
    Classifiers package depends (directly) on Namespaces package (which is shown in right way in chapter "9.4 Classifiers Package". And it depends on Ownerships package only indirectly (through Namespaces package). But on "Figure 9.2 - The Abstractions package contains several subpackages, all of which are specified in this clause" both dependencies are shown (which is not correct).

    To be fixed:
    on the "Figure 9.2 - The Abstractions package contains several subpackages, all of which are specified in this clause"
    1. Add dependency "Namespaces ---> Ownerships"
    2. Remove dependency "Classifiers ---> Ownerships"

  • Reported: UML 2.3 — Thu, 12 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

"isStatic" property of Feature no longer appears in any diagram

  • Key: UML24-79
  • Legacy Issue Number: 15429
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    I noticed that the "isStatic" property of Feature no longer appears in any diagram. There may be others missing meta-attributes, but this is the one I detected. I realize that the XMI is the definitive spec of the metamodel, but, nonetheless, I think that the diagrams should be complete and not partial. Diagrams are for human readers and XMI for machines (unless, of course, you are Pete Rivett – just kidding, Pete!).

    Also, I am disappointed that you retained the practically useless notion of navigability in the metamodel, even though we now have the dot notation supported in diagrams. Given the fact that navigability is a run-time concept, I see no value in keeping it in the metamodel, which is, after all, a static definition. (But, I am pretty sure I will now be deluged with people who will try to convince me that navigability arrows are still useful (my response: no, they are not).)

    Perhaps the "isStatic" problem can be fixed as an editorial fix prior to the meeting?

  • Reported: UML 2.3 — Wed, 25 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Show the isStatic property. In addition, this is a systematic error, and there are other cases where the metamodel has content that does not show on any diagram.

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

coveredBy : InteractionFragment [0..1] should be [*]

  • Key: UML24-78
  • Legacy Issue Number: 15427
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    coveredBy holds a number of MessageOccurenceSpecifications and so on. It mustn't be [0..1] but be [*].

  • Reported: UML 2.3 — Tue, 24 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

redefinitionContext of Property

  • Key: UML24-85
  • Legacy Issue Number: 15525
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Constraint [4] in Property implies an owned end can redefine any end of any ancestor of its owning association, whether that end is association owned or not.

    However in the case of an association-owned end redefining a (non-association) classifier-owned end, whose association is an ancesor (of the owning association), the redefinitionContexts are stil:

    the owningAssociation for the redefining proeprty
    the classifier for the redefined property

    Doesn't this violate constraint [1] of RedefinableElement

    [1] At least one of the redefinition contexts of the redefining element must be a specialization of at least one of the redefinition contexts for each redefined element.
    self.redefinedElement->forAll(e | self.isRedefinitionContextValid(e))

    where

    RedefinableElement::isRedefinitionContextValid(redefined: RedefinableElement): Boolean;
    result = self.redefinitionContext->exists(c | c.allParents()->includes(redefined.redefinitionContext))

    since the classifier can never be an ancestor of the association?

  • Reported: UML 2.3 — Wed, 15 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    There was an earlier discussion in the RTF that agreed that this constraint is inconsistent with the operation
    isRedefinitionContextValid, and proposed that the operation isRedefinitionContextValid should be redefined
    for Property, to give the correct logic, which is that a property may redefine another in the inheritance
    hierarchy regardless of whether the property is association-owned or class-owned. This is the same logic as
    for subsetting.

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

Ambiguous constraints for transitions

  • Key: UML24-73
  • Legacy Issue Number: 15394
  • Status: closed  
  • Source: Safran Engineering Services ( Samuel Rochet)
  • Summary:

    Current UML specification use the two following constraints:

    15.3.8 Pseudostate (from BehaviorStateMachines)
    Constraint [9] The outgoing transition from an initial vertex may have a behavior, but not a trigger or guard
    (self.kind = PseudostateKind::initial) implies (self.outgoing.guard->isEmpty() and self.outgoing.trigger->isEmpty())

    15.3.14 Transition (from BehaviorStateMachines)
    Constraint [5] Transitions outgoing pseudostates may not have a trigger (except for those coming out of the initial pseudostate)
    (source.oclIsKindOf(Pseudostate) and (source.kind <> #initial)) implies trigger->isEmpty()

    These constraints are not really contradictory but it is not clear to know if an initial pseudostate can or cannot have a trigger.

  • Reported: UML 2.3 — Tue, 3 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    In UML 2.5 these constraints have been removed. In fact, there is now a constraint “initial_transition” that makes it
    explicit that an initial pseudostate cannot have a trigger.
    Disposition: Closed - No Change

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

Typo: isStric => isStrict

  • Key: UML24-72
  • Legacy Issue Number: 15384
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Typo in third paragraph below fig. 18.8: isStric should be isStrict

  • Reported: UML 2.3 — Wed, 28 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Qualified name is incorrectly claimed to be unambiguous

  • Key: UML24-75
  • Legacy Issue Number: 15401
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The description of NamedElement claims that:

    A named element also has a qualified name that allows it to be
    unambiguously identified within a hierarchy of nested namespaces.

    However the validation rules for names within a namespace take, by default, the type into account and, for a behavioral feature, parameters. The qualified name uses only the name and thus isn't unambiguous as claimed.

  • Reported: UML 2.3 — Fri, 6 Aug 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 15400

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

UML 2.4: Add package:URI

  • Key: UML24-68
  • Legacy Issue Number: 15370
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This is one of two structural extensions added to UML by MOF, which if incorporated into UML would allow (constrained) Superstructure models to be used as MOF metamodels.

    Regardless of MOF, it has been requested that UML have ability to uniquely reference external elements in order to support:

    Federated models

    References to libraries of datatypes

    Profiles

    At the moment, although XMI does support such references, there is no way in the model itself, to specify the URI that should be used.

    This has been a specific problem for Profile definition where there is no standard way in UML to specify the URI to be used for XMI interchange.

    Proposed Resolution:

    Superstructure

    Add the following to the Attributes section of 7.3.77, Package:

    URI: String [0..1]

    {id} Provides an identifier for the package that can be used for many purposes. A URI is the universally unique

    identification of the package following the IETF URI specification, RFC 2396 http://www.ietf.org/rfc/rfc2396.txt and it must comply with those syntax rules.

    .

    Add the following to the end of the Semantics section of 7.3.77, Package:

    The URI can be specified to provide a unique identifier for a Package. Within UML there is no predetermined usage for this, with the exception of profiles (see Using XMI to exchange Profiles in section 18.3.6). It may, for example, be used by model management facilities for model identification. The URI should hence be unique and unchanged once assigned. There is no requirement that the URI be dereferenceable (though this is of course permitted) .



    Add the following to the end of the Notation section of 7.3.77, Package:

    The URI for a Package may be indicated with the text {uri=<uri>} following the package name.



    Update Figure 7.63 to add the following under the word Types in the middle package example:

    {uri=http://www.abc.com/models/Types}



    Update Figure 7.14 to include URI: String {id}

    in class Package

    Update subsection Using XMI to exchange profiles in section 18.3.6, Profile as follows:

    Replace:

    The Profile to CMOF mapping should also include values for CMOF Tags on the CMOF package corresponding to

    Profile in order to control the XMI generation. The exact specification of these tags is a semantic variation point. A

    recommended convention is:

    nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi

    where:

    • <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with

    (dot) substituted for ::, and all other illegal XML QName characters removed, and

    • <profileName> is the name of the Profile,

    • nsPrefix = <profileName>,

    • all others use the XMI defaults.

    With:

    For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI. The name attribute of the Profile is used for the nsPrefix in XMI.

    Infrastructure

    Add the following to the Attributes section of 11.9.2, Package:

    URI: String [0..1]

    {id} Provides an identifier for the package that can be used for many purposes. A URI is the universally unique

    identification of the package following the IETF URI specification, RFC 2396 http://www.ietf.org/rfc/rfc2396.txt and it must comply with those syntax rules.

    .

    Add the following to the end of the Semantics section of 11.9.2, Package:

    The URI can be specified to provide a unique identifier for a Package. Within UML there is no predetermined usage for this, with the exception of profiles (see Using XMI to exchange Profiles in section 18.3.6). It may, for example, be used by model management facilities for model identification. The URI should hence be unique and unchanged once assigned. There is no requirement that the URI be dereferenceable (though this is of course permitted) .



    Add the following to the end of the Notation section of 11.9.2, Package:

    The URI for a Package may be indicated with the text {uri=<uri>} following the package name.



    Update Figure 11.27 to add the following under the word Types in the middle package example:

    {uri=http://www.abc.com/models/Types}



    Update Figure 11.26 to include URI: String {id}

    in class Package

    Update subsection Using XMI to exchange profiles in section 13.1.6, Profile as follows:

    Replace:

    The Profile to CMOF mapping should also include values for CMOF Tags on the CMOF package corresponding to

    Profile in order to control the XMI generation. The exact specification of these tags is a semantic variation point. A

    recommended convention is:

    nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi

    where:

    • <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with

    (dot) substituted for ::, and all other illegal XML QName characters removed, and

    • <profileName> is the name of the Profile,

    • nsPrefix = <profileName>,

    • all others use the XMI defaults.

    With:

    For a Profile the URI attribute (inherited from package) is used to determine the nsURI to be used to identify instances of the profile in XMI. The name attribute of the Profile is used for the nsPrefix in XMI.

  • Reported: UML 2.3 — Tue, 13 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Add the proposed property.

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

UML 2.4: Add Property::isId

  • Key: UML24-67
  • Legacy Issue Number: 15369
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This is one of two structural extensions added to UML by MOF, which if incorporated into UML would allow (constrained) Superstructure models to be used as MOF metamodels.

    Regardless of MOF, it is a fundamental capability missing from UML in being able to model various data structures for languages such as SQL and XML Schema which all have the notion of identifier.

    Although MOF restricts classes to have only one Property with isId = true, for generality the proposal does not restrict this in UML.

    Should this issue be applied to UML, a mirror issue will be applied to MOF.

    Proposed Resolution:

    Superstructure

    Add the following to the Attributes section of 7.3.44, Property:

    isID: Boolean [0..1] - True indicates this property can be used to uniquely identify an instance of the containing Class.

    Add the following to the end of the Semantics section of 7.3.44, Property, immediately before the sub-heading ‘Package AssociationClasses’:

    A property may be marked as being (part of) the identifier (if any) for classes of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML. If multiple properties are marked (possibly in superclasses) then it is the combination of the (property, value) tuples that will logically provide the uniqueness for any instance. Hence there is no need for any specification of order and it is possible for some (but not all) of the property values to be empty. If the property is multivalued then all values are included.

    Replace the following in the definition of <prop-modifier> in the Notation section of 7.3.44, Property:

    ‘redefines’ <property-name> | ‘ordered’ | ‘unique’ | ‘nonunique’ | <prop-constraint>

    With:

    ‘redefines’ <property-name> | ‘ordered’ | ‘unique’ | ‘nonunique’ | ‘id’ | <prop-constraint>

    Add the following line before that defining <prop-constraint>:

    · id means that the property is part of the identifier for the class

    Update Figure 7.12 to include isID : Boolean[0..1] in class Property

    Update the definition of the attribute ‘qualifiedName’ in section 7.3.33, NamedElement, from:

    / qualifiedName: String [0..1]

    To:

    / qualifiedName: String [0..1]

    {id}

    Infrastructure

    Add the following to the Attributes section of 10.2.5, Property:

    isID: Boolean [0..1] - True indicates this property can be used to uniquely identify an instance of the containing Class.

    Add the following to the end of the Semantics section of 10.2.5, Property:

    A property may be marked as being (part of) the identifier for classes of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML. If multiple properties are marked (possibly in superclasses) then it is the combination of the (property, value) tuples that will logically provide the uniqueness for any instance. Hence there is no need for any specification of order and it is possible for some (but not all) of the property values to be empty. If the property is multivalued then all values are included.

    Replace the following in the definition of <prop-modifier> in the Notation section of 11.3.5, Property:

    ‘redefines’ <property-name> | ‘ordered’ | ‘unique’ | <prop-constraint>

    With:

    ‘redefines’ <property-name> | ‘ordered’ | ‘unique’ | ‘id’ | <prop-constraint>

    Add the following line before that defining <prop-constraint>:

    · id means that the property is part of the identifier for the class

    Update Figures 10.3 and 11.5 to include isId : Boolean[0..1] in class Property

  • Reported: UML 2.3 — Tue, 13 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Add the proposed property.

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

UML 2.4: Inconsistent rendering of OCL in UML metamodel

  • Key: UML24-71
  • Legacy Issue Number: 15378
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    This is a UML 2.4 issue please:

    Inconsistent rendering of OCL in UML metamodel.

    According to the conventions mostly applied in the UML metamodel, the specifications of the body conditions of operations have the form “result = <OCL expression>” and the operation is specified to have a return parameter named “result”. Invariants, pre- and post-conditions, on the other hand, are simply Boolean expressions with no “result = “. Note that many invariants are specified in OCL as “true”, being placeholders for invariants that are currently only specified in text. There are some placeholder operations, for which the specification should be “result = <default value for the type of result>”, i.e. result = false, result = 0, or result = null.

    Applying these conventions consistently will greatly enable future generation of specification documents. This means making the following changes:

    All operations in the metamodel should be changed to have a return parameter named “result”.

    The following operation and constraint specifications should be changed as indicated by changeto:

    InfrastructureLibrary::Core::Constructs::Classifier::hasVisibilityOf()

    “hasVisibilityOf = (n.visibility <> VisibilityKind::private)” changeto “result = (n.visibility <> VisibilityKind::private)”

    InfrastructureLibrary::Core::Constructs::Classifier::inheritedMember()

    “self.inheritedMember->includesAll(self.inherit(self.parents()>collect(p|p.inheritableMembers(self))>asSet()))” changeto “result = self.inherit(self.parents()>collect(p|p.inheritableMembers(self))>asSet())”

    UML::Classes::Kernel::Classifier::hasVisibilityOf()

    “hasVisibilityOf = (n.visibility <> VisibilityKind::private)” changeto “result = (n.visibility <> VisibilityKind::private)”

    UML::Classes::Kernel::Classifier::inheritedMember()

    “self.inheritedMember->includesAll(self.inherit(self.parents()>collect(p|p.inheritableMembers(self))>asSet()))” changeto “result = self.inherit(self.parents()>collect(p|p.inheritableMembers(self))>asSet())”

    UML::Classes::Kernel::OpaqueExpression::value()

    “true” changeto “result = 0”

    UML::Classes::Kernel::VisibilityKind::bestVisibility()

    “pre: not vis->includes(#protected) and not vis->includes(#package)” changeto “not vis->includes(#protected) and not vis->includes(#package)”

    UML::Deployments::ComponentDeployments::DeploymentSpecification

    “result = self.deployment->forAll (d | d.location..oclIsKindOf(ExecutionEnvironment))” changeto “self.deployment->forAll (d | d.location.oclIsKindOf(ExecutionEnvironment))”

    UML::Deployments::Nodes::CommunicationPath

    “result = self.endType->forAll (t | t.oclIsKindOf(DeploymentTarget))” changeto “self.endType->forAll (t | t.oclIsKindOf(DeploymentTarget))”

    UML::Interactions::Fragments::InteractionUse

    Two placeholder invariants specified as “N/A” –changeto- “true”

    UML::StateMachines::BehaviorStateMachines::StateMachine::LCA()

    “true” – changeto- “result = null”

  • Reported: UML 2.3 — Wed, 21 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Agree to the changes proposed in the summary, except for OpaqueExpression::value() and StateMachine::LCA(). For these operations the result is undefined so it is incorrect to return a defined result. Instead a body of true is actually correct: it is logically equivalent to result=result.

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

Over-general sentence about MOF and Profiles

  • Key: UML24-70
  • Legacy Issue Number: 15372
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    18.3.6 Semantics contains the following untrue sentence which should be deleted

    “The profile mechanism may be used with any metamodel that is created from MOF, including UML and CWM.”

  • Reported: UML 2.3 — Tue, 13 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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.3 Superstructure: Non-sensible text for modelLibrary stereotype

  • Key: UML24-69
  • Legacy Issue Number: 15371
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The description for the stereotype in Annex C contains significant semantics which are not reflected anywhere else in the specification, nor as Constraints associated with the stereotype. Because this is a stereotype, not a keyword, these are not warranted.

    The full text is as follows:

    A package that contains model elements that are intended to be reused by other packages. Model libraries are frequently used in conjunction with applied profiles. This is expressed by defining a dependency between a profile and a model library package, or by defining a model library as contained in a profile package.

    The classes in a model library are not stereotypes and tagged definitions extending the metamodel. A model library is analogous to a class library in some programming languages. When a model library is defined as a part of a profile, it is imported or deleted with the application or removal of the profile. The profile is implicitly applied to its model library. In the other case, when the model library is defined as an external package imported by a profile, the profile requires that the model library be there in the model at the stage of the profile application. The application or the removal of the profile does not affect the presence of the model library elements

    Specifically the problems are:

    a) More specifics should be given for “This is expressed by for a dependency between a profile and a model library package” – such as the direction and name.

    b) Replace ‘tagged definitions’ by ‘properties’ or at least ‘tag definition’

    c) The text ‘is imported or deleted’ is vague and goes beyond anything in Profile semantics (for example does it mean a PackageImport is implicitly created?)

    d) “The profile is implicitly applied to its model library” does not make sense except in the specific case that the model library is a set of stereotyped elements, regardless of whether the model library owned by the profile: if the model library is for use within or with the profile why would it be necessary to apply stereotypes to its elements? And it goes beyond Profile semantics as well as resulting in a circular dependency between library and profile.

    e) “In the other case, when the model library is defined as an external package imported by a profile,” is inconsistent with the earlier description of ‘the other case’ which is as defined via a Dependency (not an import).

    f) “the profile requires that the model library be there in the model at the stage of the profile application” is both vague (‘be there’) and beyond profile semantics.

    Proposed resolution

    Replace the paragraph with the following:

    A package that contains model elements that are intended to be reused by other packages. Though model libraries are frequently used in conjunction with applied profiles, the classes in a model library are not stereotypes extending the metamodel. A model library is analogous to a class library in some programming languages.

  • Reported: UML 2.3 — Tue, 13 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Accept the proposal

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

UML 2.3, Figure 18.1

  • Key: UML24-58
  • Legacy Issue Number: 15269
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In UML 2.3, Figure 18.1 shows that InfrastructureLibrary::Profiles imports InfrastructureLibrary::Core::Constructs; however, this relationship should be a merge, not an import because:
    1) the InfrastructureLibrary::Profiles package adds merge increments to several metaclasses from Core::Constructs, e.g., Class, Package.
    2) the InfrastructureLibrary::Profiles package copies metaclasses from Core::Constructs without adding any content, e.g., NamedElement.

    Although UML merges Profiles at L2, the use of (1) and (2) requires a package merge relationship betwen Profiles & Constructs to reflect the intended semantics of merge increment for (1) and copy-down for (2).

    Resolution:

    Change the PackageImport relationship from InfrastructureLibrary::Profiles to InfrastructureLibrary::Core::Constructs to a PackageMerge relationship in:

    • figure 13.1 of the infrastructure specification
    • the infrastructure metamodel
    • figure 18.1 of the superstructure specification.
  • Reported: UML 2.3 — Thu, 27 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Term "method activation" deprecated?

  • Key: UML24-57
  • Legacy Issue Number: 15268
  • Status: closed  
  • Source: Technische UniversitäMü Institut füormatik I1 ( Florian Schneider)
  • Summary:

    In the section describing Lifelines, the term "method activations" is used twice, both times on page 508.

    (1) "To depict method activations we apply a thin grey or white rectangle that covers the Lifeline line."
    (2) "See Figure 14.12 to see method activations."

    Having had a look at Figure 14.12 and having read section 14.3.10 ExecutionSpecification, I believe that the term "method activation" is deprecated and should be substituted by the term "execution specification".

  • Reported: UML 2.3 — Fri, 28 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Agree that "method activation" should be changed to "execution specification" in 17.3.4 and 17.3.5

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.3 Issue: Constraint InformationFlow.sources_and_target_kinds

  • Key: UML24-66
  • Legacy Issue Number: 15356
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    Section 17.2.1 of the superstructure document, InformationFlow

    The text of the constraint reads "The sources and targets of the information flow can only be one of the following kind: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition and InstanceSpecification except when its classifier is a relationship (i.e. it represents a link)."

    The OCL reads:
    (self.informationSource->forAll(p | p->oclIsKindOf(Actor) or oclIsKindOf(Node) or ...

    the "p->" is missing from the second term above (should be "p->oclIsKindOf(Node)") and from all subsequent terms.

  • Reported: UML 2.3 — Wed, 7 Jul 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

NamedElement::clientDependency constrained to subset DirectedRelationship::source

  • Key: UML24-65
  • Legacy Issue Number: 15288
  • Status: closed  
  • Source: yahoo.com ( Scott Forbes)
  • Summary:

    In Figure 7.15, NamedElement::clientDependency is constrained to subset DirectedRelationship::source. Should be Dependency::client constrained, similarly Dependency::supplier should subset target.

  • Reported: UML 2.3 — Thu, 10 Jun 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Figure 7.10 shows Feature::isStatic as abstract

  • Key: UML24-64
  • Legacy Issue Number: 15285
  • Status: closed  
  • Source: yahoo.com ( Scott Forbes)
  • Summary:

    In Figure 7.10, Feature::isStatic is shown as an abstract attribute. Also StructuralFeature::isReadOnly and all attributes of MultiplicityElement in Figure 7.5, p27

  • Reported: UML 2.3 — Wed, 9 Jun 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

split the addition of generalization relationships among association in 14977 in two parts

  • Key: UML24-59
  • Legacy Issue Number: 15274
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Please create a new issue number to split the addition of generalization relationships among association in 14977 in two parts.

    Cases 2 and 3 below will remain in 14977 and the generalization relationships added for case 1 below will be moved to a resolution for this new issue number.

    This will give everyone in the RTF an opportunity to vote on the relationship between association end subsetting & association generalization separately from the fixes to the association end subsets.

  • Reported: UML 2.3 — Sat, 5 Jun 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

It seems odd to say that Service “computes a value”.

  • Key: UML24-62
  • Legacy Issue Number: 15280
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    It seems odd to say that Service “computes a value”.

  • Reported: UML 2.3 — Tue, 6 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Delete the offending phrase

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Create

  • Key: UML24-61
  • Legacy Issue Number: 15279
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    I do not understand the following in Create (when applied to BehavioralFeature) “May be promoted to the Classifier containing the feature.” The same appears on Destroy

  • Reported: UML 2.3 — Tue, 6 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 15144

  • Updated: Fri, 6 Mar 2015 20:58 GMT

issues relating to Figure 7.14 - The Packages diagram of the Kernel package

  • Key: UML24-63
  • Legacy Issue Number: 15283
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1 A_owningPackage_packagedElement shown as directional
    2 owningPackage shown as public member of association, not declared as an association of PackageableElement (7.3.38)
    3 A_package_ownedType shown as bidirectional, but package not declared as an association of Type (7.3.51)
    4 PackageableElement::visibility:VisibilityKind default value is 'false' (7.3.38) - already submitted

  • Reported: UML 2.3 — Tue, 8 Jun 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Auxiliary

  • Key: UML24-60
  • Legacy Issue Number: 15278
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    "The class that the auxiliary supports may be defined explicitly using a Focus class or implicitly by a dependency relationship." - how a class be defined implicitly let alone via a Dependency? Likewise in the description of Focus

  • Reported: UML 2.3 — Tue, 6 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 15144

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MultiplicityElement constraint 1 inconsistent with possible [0..0] multiplicity

  • Key: UML24-130
  • Legacy Issue Number: 16595
  • Status: closed  
  • Source: gmail.com ( Joost Doesburg)
  • Summary:

    In the description of a MultiplicityElement in the superstructure, constraint 1 claims that
    'upperBound()->notEmpty() implies upperBound() > 0', while in the last paragraph of the semantics, it is declared that a multiplicity of [0..0] is possible.
    These statements are in conflict with each other.

  • Reported: UML 2.3 — Thu, 13 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Figure 7.31 propose an “association-like” notation for attributes

  • Key: UML24-128
  • Legacy Issue Number: 15899
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Figure 7.31 propose an “association-like” notation for attributes:

    • clarifying whether aggregation kind can be shown
    • the notation for association end property attribute should be clearly distinct from that for a property attribute that is not an association end, even for the visually impaired.
  • Reported: UML 2.3 — Tue, 14 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 15237

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Statement mistake

  • Key: UML24-127
  • Legacy Issue Number: 15898
  • Status: closed  
  • Source: CGI ( Wayne Li)
  • Summary:

    On page 613, the section of "Semantic", the first sentence of "An include relationship between two use cases means that the behavior defined in the including use case is included in the
    behavior of the base use case." , the "including" should be "included"

  • Reported: UML 2.3 — Mon, 13 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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 numbering

  • Key: UML24-129
  • Legacy Issue Number: 16043
  • Status: closed  
  • Source: web.de ( Kay Weihmann)
  • Summary:

    In my opinion section 9.2 should be numbered as section 9.1.2. That would match to the rest of the numbering scheme.

  • Reported: UML 2.3 — Thu, 24 Feb 2011 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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.4: “Figure 7.31 shows the dot at the wrong end.”

  • Key: UML24-124
  • Legacy Issue Number: 15873
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML 2.4: “Figure 7.31 shows the dot at the wrong end.” From: Pete Rivett pete.rivett@adaptive.com
    Sent: 14 December 2010 17:50
    To: Steve Cook
    Cc: Maged Elaasar; andrew@omg.org
    Subject: RE: New notation for attribute

    No it did not come from me: I think it was Jim or Bran or Ed (see attached).

    However attached is an updated figure I drew from scratch.

    Pete

    From: Steve Cook Steve.Cook@microsoft.com
    Sent: Tuesday, December 14, 2010 4:44 AM
    To: Pete Rivett
    Cc: Maged Elaasar; Andrew Watson (andrew@omg.org)
    Subject: RE: New notation for attribute

    Pete – I believe you made that figure. Is it possible to supply a correct one?

    From: Pete Rivett pete.rivett@adaptive.com
    Sent: 13 December 2010 20:10
    To: Ed Seidewitz; Steve Cook; Bran Selic
    Cc: BERNARD, Yves; uml2-rtf@omg.org
    Subject: RE: New notation for attribute

    I agree the diagram should be fixed as an editorial change: things are confusing enough as it is. We need to check with Andrew on the correct procedure.

    In terms of the concepts, it seems that navigability is the thing we should lose – specifically for metamodeling.

    What does it mean to say that it’s not possible (‘efficiently’) to navigate from a class to its specializations (for example)? What modeling tool would disallow a user (or OCL conditions or QVT transformations) from discovering this information?

    That’s not to say navigability has no value for other types of model. I don’t feel qualified to comment. Clearly some people like it.

    However, given the current definition of navigability and the fact that we have the dot notation (love it or hate it) for end ownership, I propose we eliminate the use of navigability from the definition of UML itself (and indeed any other metamodel) – since it’s redundant, confusing and makes no sense for metamodels. And it sets a poor example for use of navigability as a general modeling capability.

    This will make no difference at all to the XMI for model interchange – since it’s the end ownership that determines serialization. So I believe it is something we should do for UML 2.5.

    Pete

    From: Ed Seidewitz ed-s@modeldriven.com
    Sent: Monday, December 13, 2010 10:21 AM
    To: Steve Cook; Bran Selic
    Cc: BERNARD, Yves; uml2-rtf@omg.org
    Subject: RE: New notation for attribute

    Steve –

    I checked the actual resolution in Ballot 5, and the revised text actually does proposed updating the diagram with the dot in the wrong place. So the document was indeed updated properly per the resolution. However, the issue itself called for the use of the dot notation, which was simply applied incorrectly in the figure update. I am concerned that, now that the figure has been noticed, some people will start actually thinking that the “dot on the wrong end” is the right way to show an attribute using “association-like notation”, which will just cause even more confusion!

    As to getting rid of the dot notation, the was a looong discussion in the UML 2.0 FTF about the need to have both the concepts of navigability and end ownership and that these need to be separated (which they were not in UML 2.0 as originally submitted). You can talk to Conrad Bock more about the reasons for this, but unless the constituency behind this has gone away (which I don’t think it has), I don’t think we will be able to get rid of the dot notation. In the past 5 years, no one has really like this notation, but no one has come up with anything better that satisfies everyone involved!

    – Ed

    --------------------------------------------------------------------------------

    From: Steve Cook Steve.Cook@microsoft.com
    Sent: Monday, December 13, 2010 1:09 PM
    To: Ed Seidewitz; Bran Selic
    Cc: BERNARD, Yves; uml2-rtf@omg.org
    Subject: RE: New notation for attribute

    I’ve said it before and I will say it again: the dot notation for association end ownership is a mistake. To put it mildly. No normal user of UML cares a fig about this stupid dot. It means nothing semantically, being purely about model management, and is a step in diametrically the wrong direction, simply adding more unnecessary complexity UML.

    The fact that the RTF screwed it up in 2.4 only goes to show how non-intuitive this notation is: it gets through an RTF review and vote, despite the fact that the proposal is introduced by a UML expert and represents the simplest possible example.

    I don’t believe that this is an editorial change. I think we deserve to be embarrassed by it for a good few months. Maybe this embarrassment would convince us to get rid of the thing altogether in 2.5.

    – Steve

    From: Ed Seidewitz ed-s@modeldriven.com
    Sent: 13 December 2010 17:55
    To: Bran Selic
    Cc: BERNARD, Yves; uml2-rtf@omg.org
    Subject: RE: New notation for attribute

    Bran –

    You are right, I was looking at the UML 2.3 spec. The resolution to Issue 10087 changed Figure 7.31 “to show dot-notation”. But it looks like the dot was placed at the wrong end! I am hoping this can be considered an editorial error that can be fixed in the final clean up of the spec document (Steve, Maged??).

    In any case, I think the intention was that this notation alternative look exactly like association notation – that is, it is indeed overloaded notation, which I agree is a bad idea. But changing this would be more than an editorial change, hence the suggestion of recording this as an issue.

    – Ed

    --------------------------------------------------------------------------------

    From: bran.selic@gmail.com bran.selic@gmail.com On Behalf Of Bran Selic
    Sent: Monday, December 13, 2010 12:42 PM
    To: Ed Seidewitz
    Cc: BERNARD, Yves; uml2-rtf@omg.org
    Subject: Re: New notation for attribute

    ???I believe that you are saying that this is a case of an overloaded notation. If I understood you correctly, you are telling me that the line that looks like an association is not an association and that the black dot – which definitely appears on one line end in Figure 7.31 in my copy of ptc/10-08-02 (smudge on my screen?) – which looks like the notation for denoting end ownership also means something else (and, furthermore, reverses the usual convention).

    Ugh! Overloading notations is a bad idea.

    Cheers...Bran

    On Mon, Dec 13, 2010 at 12:31 PM, Ed Seidewitz <ed-s@modeldriven.com> wrote:

    Bran –

    I don’t see any black dot at all in Figure 7.31. Note that there are no association ends in Figure 7.31, since it is showing an attribute Window with no association. It just looks like an association, which is an ambiguity in the notation which should probably be fixed. Just putting a black dot on the far end would still leave the graphical notation ambiguous as to whether there was actually an association or not. Not having any association end name at the near end is not enough, since this can be suppressed even when there is an association.

    – Ed

    --------------------------------------------------------------------------------

    From: bran.selic@gmail.com bran.selic@gmail.com On Behalf Of Bran Selic
    Sent: Monday, December 13, 2010 12:14 PM
    To: Steve Cook
    Cc: Rouquette, Nicolas F (316A); BERNARD, Yves; uml2-rtf@omg.org

    Subject: Re: New notation for attribute

    Hmmmm. That example looks wrong to me; that is, the black dot is at the wrong end. I believe the intent of this example was to show an attribute Window::size[1] of type Area. But, according to Figure 7.19, the black dot indicating end ownership should appear on the association end that is AWAY from its owning classifier. But, the diagram in figure 7.31 has the black dot on the near association end. Do I have this wrong?

    In retrospect, we should have simply completely dispensed with the concept of navigability and retained the arrow to mean end ownership, which is what most people expect and which is actually intuitive. The black dot is not intuitive and bound to create confusion – such as the case above (regardless of whether I am right or wrong above).

    Cheers...Bran

    On Sun, Dec 12, 2010 at 6:59 AM, Steve Cook <Steve.Cook@microsoft.com> wrote:

    I believe this option is already there: see figure 7.31.

    From: Rouquette, Nicolas F (316A) nicolas.f.rouquette@jpl.nasa.gov
    Sent: 11 December 2010 11:59
    To: BERNARD, Yves
    Cc: uml2-rtf@omg.org
    Subject: Re: New notation for attribute

    Yves,

    This idea makes sense as part of the Diagram Definition for UML.

    • Nicolas.

    On Dec 10, 2010, at 4:01 AM, BERNARD, Yves wrote:

    According to several discussions I had with UML users, it appears that many of them, who have the intent to simply to add an attribute to a class, finally create an association to the type of the required attribute. In all case I faced, the reason was that they prefer the notation UML proposes for association which is much more powerful. Mainly:

    Capability to get a modular diagram thanks to the “link notation”
    Capability to show the aggregation kind

    However attributes and association are not the same and it is a pity to introduce such a drift in the semantics just because of the notation.

    What do you think about adding a notation for the attributes that would offer the capability to represent all their properties and to designate their type using a link?

  • Reported: UML 2.3 — Tue, 14 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Replace the offending diagrams.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2: Multiplicity of Lifeline's coveredBy is incorrectly specified

  • Key: UML24-123
  • Legacy Issue Number: 15870
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the UML 2.3, UML 2.4 Superstructure spec, "14.3.17 Lifeline" section, coveredBy is
    marked with [0..1] multiplicity. In the corresponding figure in the
    beginning of the Interactions chapter it is marked *.

    coveredBy : InteractionFragment [0..1]

  • Reported: UML 2.3 — Fri, 3 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Fix minor inconsistencies between infrastructure specification document & metamodel

  • Key: UML24-116
  • Legacy Issue Number: 15778
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Description: To ensure that the UML2.4 metamodel is consistent with the specification document, the following inconsistencies must be resolved:

    1) NamedElement::qualifiedName()

    InfrastructureLibrary::Core::Abstractions::Namespaces::NamedElement::qualifiedName()

    ? this corresponds to 9.14.1 constraint [2] – OK

    InfrastructureLibrary::Core::Constructs::NamedElement::qualifiedName()

    ? no description of this in clause 11 for Core::Constructs – OK per current conventions that clause 11 does not duplicate the constraints/operations from the merged increments shown in 11.2

    For the superstructure:

    ? the description in super 7.3.34 constraint [2] is copied from 9.14.1 constraint [2] ? OK

    ? UML::Classes::Kernel::NamedElement::qualifiedName() is missing ? not OK per current conventionss that Kernel in the superstructure has all of the elements corresponding to the resulting merge of Core::Constructs and what it merges per infra figure 11.2

    Resolution:

    In the metamodel add qualifiedName() to UML::Classes::Kernel::NamedElement with the same definition as in InfrastructureLibrary::Core::Constructs::NamedElement::qualifiedName()

    2) DataType::inherit()

    ? No description anywhere of InfrastructureLibrary::Core::Constructs::DataType::inherit() in infra 11.6.1 or super 7.3.11

    ? UML::Classes::Kernel::DataType::inherit() is missing ? not OKK per current conventions that Kernel in the superstructure has all of the elements corresponding to the resulting merge of Core::Constructs and what it merges per infra figure 11.2

    Resolution:

    1.a) figure 11.2 is only in the document, the package merge relationships are not in the infrastructure at all.

    ? add the relationships as described in infra 11.2

    ? add a package merge relationship from Core::Constructs to Core::Abstractions::Element, which other merge increments in Core::Abstractions import.

    2) DataType::inherit()

    In the metamodel, copy InfrastructureLibrary::Core::Constructs::DataType::inherit() into UML::Classes::Kernel::DataType::inherit()

    In Infrastructure 11.6.2 and Superstructure 7.3.11, add the following section:

    Additional Operations

    [1] The inherit operation is overridden to exclude redefined properties.

    DataType::inherit(inhs: Set(NamedElement)) : Set(NamedElement);

    inherit = inhs->excluding(inh | ownedMember->select(oclIsKindOf(RedefinableElement))>select(redefinedElement>includes(inh)))

  • Reported: UML 2.3 — Mon, 25 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The issue summary is a bit garbled, but here is a summary of what it proposes, in order to make the metamodel and specification document consistent.
    In the metamodel add qualifiedName() to UML::Classes::Kernel::NamedElement with the same definition as in InfrastructureLibrary::Core::Constructs::NamedElement::qualifiedName()
    In the metamodel change infrastructure figure 11.2 so that Constructs does not merge Basic, and instead Constructs does merge Core::Abstractions::Elements. The merge to Basic is conceptually flawed because Basic has a different and conflicting definition and semantics for Operation.
    Note that these merges remain purely conceptual – they are not explicit in the metamodel.
    In the metamodel, delete the association Core::Abstractions::BehavioralFeatures::A_parameter::behavioralFeature, because if this association was actually merged according to figure 11.2 it would be an orphaned derived union, with no subsets in the metamodel.
    In the metamodel, copy InfrastructureLibrary::Core::Constructs::DataType::inherit() into UML::Classes::Kernel::DataType::inherit()
    In Infrastructure 11.6.1 and Superstructure 7.3.11, add the following section:
    Additional Operations
    [1] The inherit operation is overridden to exclude redefined properties.
    DataType::inherit(inhs: Set(NamedElement)) : Set(NamedElement);
    inherit = inhs->excluding(inh | ownedMember->select(oclIsKindOf(RedefinableElement))>select(redefinedElement>includes(inh)))

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing relation between "Namespaces" package and "Ownerships" package in fig. 9.2 (p. 30)?

  • Key: UML24-115
  • Legacy Issue Number: 15774
  • Status: closed  
  • Source: TU Darmstadt ( Martin Wieber)
  • Summary:

    Compare "Figure 9.37 - The Namespaces package" on page 71 of same document.

  • Reported: UML 2.3 — Fri, 22 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Deep history for orthogonal states

  • Key: UML24-120
  • Legacy Issue Number: 15791
  • Status: closed  
  • Source: asu.edu ( Joe Mooney)
  • Summary:

    "A region may have at most one deep history vertex." (pg 564)
    "A composite state may have at most one deep history vertex." (pg 557)

    This implies that only one region of a composite state may have a deep history vertex. There is no formal constraint to the effect. Please clarify.

    "deepHistory represents the most recent active configuration of the composite state that directly contains this pseudostate" (pg 557)
    This implies that all regions of a orthogonal composite state are returned to the the most recent active configuration of the composite state but...at the bottom of page 570 it asserts the other regions are entered "by default" which has a different semantic. Please clarify.

  • Reported: UML 2.3 — Mon, 1 Nov 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The second quoted sentence is no longer there, but there is still some text that implies that history vertices
    are State based rather than Region based. These should be fixed.
    Fix all places where it is implied that history vertices belong to States rather than Regions.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter semantics related to Behavior and BehavioralFeature

  • Key: UML24-119
  • Legacy Issue Number: 15787
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    On my first UML 2.5 efforts at consolidating the semantics of Classifiers in the merged model it becomes very obvious that Parameter has two sets of semantics: one related to the parameters of BehavioralFeatures and one related to the parameters of Behaviors.

    ParameterSet semantics talks almost exclusively about Behaviors. There is a forward reference in 12.3.13 that says “See semantics of ParameterSet”. But all 12.3.43 says is “A behavior with output parameter sets can only post outputs to the parameters in one of the sets per execution. The same is true for operations with parameter sets.” 12.3.13 also says “See notation for ParameterSet” – that is simply false, because 12.3.43 only has notation for Behaviors (well, actually Activities, because Behavior has no notation (13.3.2) but that’s the topic of a separate discussion).

    ParameterEffectKind, as well, talks exclusively about Behaviors.

    So on the face of it, the Parameter behavior related to BehavioralFeatures is distinct from the Parameter behavior related to Behaviors.

    Now, in the UML specification, there actually appear to be two separate metaclasses called Parameter. There is the one defined in Kernel, together with the one defined in Collaborations as a merge increment: the merge happens via Collaborations->InternalStructures->Interfaces->Dependencies->Kernel.

    There is a second one defined in CompleteActivities. According to the specification text, this is a specialization (it does not say merge) of the one in Kernel. However these are the merges: CompleteActivities->IntermediateActivities->BasicActivities->FundemantalActivities->BasicBehaviors->Kernel. So CompleteActivities::Parameter is also merged with the others.

    The end result is Parameter which defines both direction: ParameterDirectionKind and effect: ParameterEffectKind, that can be organized into subsets, regardless of where it is used. But there are almost no semantics and no notation specified for the Behavior-oriented features as they relate to BehavioralFeature.

    One explanation of this might that the merge is accidental, and there are supposed to be two definitions of Parameter. This is belied, however, by 12.3.13 and figure 12.18.

    Can anybody explain what this is supposed to be about? Are these meanings of Parameter really supposed to be integrated like this? What are the meanings of effect and parameterSet for Operations and Receptions? What is the relationship between direction and effect for a Parameter?

  • Reported: UML 2.3 — Wed, 27 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    In UML 2.5 it has been made clear that there is only one metaclass Parameter and its semantics are now defined in one
    place.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property.isReadOnly is redundant with StructuralFeature.isReadOnly

  • Key: UML24-118
  • Legacy Issue Number: 15781
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    According to figure 7.12, Property.isReadOnly redefines StructuralFeature.isReadOnly. But the redefinition is not mentioned in 7.3.45.

    Both of these properties have the same name, type, multiplicity and default, so Property.isReadOnly is unnecessary.

    The resolution will be to delete Property.isReadOnly from metamodel, text and diagram.

  • Reported: UML 2.3 — Mon, 25 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    We decided to delete Property::isReadOnly and move the words used to specify it to StructuralFeature::isReadOnly.
    This will not affect interoperability.
    This also resolves 7857.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Part document structures in Infrastructure need to conform to ISO Standard Document Template Conventions

  • Key: UML24-122
  • Legacy Issue Number: 15822
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    UML 2.3 RTF resolved ISSUE 14277 as follows:

    Japan Superstructure PAS Ballot Comments - comment 20
    Summary:
    Part I, II, III,, IV This is a multipart standard, use of "Part I,
    II, III, IV" make confusion. Delete unnecessary Part IV and Make others
    rewrite as clauses. 7. Structure, 12 Behavior, 19 Supplement and
    renumber other clauses.
    Resolution:
    Agree to change word “Part” to “Sub Part” throughout document.

    PTC/9-9-10 , the UML 2.3 Infrastructure convenience document has the changes of the
    tem “Part” to “Subpart”, as per the resolution to ISSUE 14277 by the UML 2.3 RTF.

    However the published UML 2.3 Infrastructure reverted to the use of the term “Part”.

    Also, ISO document templates do not allow hanging text.

    The introductory text for each is not in any numbered clause.

    Proposed Resolution:

    Change term “Part” to “Subpart”, as in PTC/9-9-10.

    Change title of section 6.2 to be “How to Read this Specificaton” as in PTC/9-9-10, and
    to be consistent with Superstructure.

    Add a new section

    6.2.2 Contents of Subparts

    6.2.2.1 Contents of Subpart I ­ Introduction

    <move the hanging intro from Part I into this subclause, with minor edits to fix pointers
    to sections>

    6.2.2.2 Contents of Subpart II ­ Infrastructure Library

    <move the hanging intro from Part II into this subclause, with minor edits to fix pointers
    to sections>

    6.2.2.3 Contents of Subpart III - Annexes

    <move the hanging intro from Part II into this subclause,>

  • Reported: UML 2.3 — Mon, 22 Nov 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Big UML 2.4 problem: missing defaults in XMI

  • Key: UML24-121
  • Legacy Issue Number: 15804
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This came up in the MIWG testing (though that was for UML 2.2)

    There seem to be several cases where the specification has defaults that are not represented in the XMI.

    Examples of this are as follows:

    ActivityEdge::guard : ValueSpecification [1..1] = true

    ActivityEdge::weight : ValueSpecification [1..1] = 1

    ObjectNode::upperBound : ValueSpecification [1..1] = *

    They all seem to be ValueSpecifications so I’m sure there are others.

    BTW these are all listed under Attributes of the metaclass whereas they are in fact modeled as Associations with ValueSpecification. So should they not be placed into the Associations section? Something to look at for 2.5 I guess.

  • Reported: UML 2.3 — Mon, 1 Nov 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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 with multiple return parameter

  • Key: UML24-114
  • Legacy Issue Number: 15769
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    We are talking about an operation declared in the UML metamodel, so

    Operation::returnResult() : Parameter [0..1]

    is definitely valid UML notation.

    while

    Operation::returnResult() : Set(Parameter)

    which is the way it is now in spec is definitely not valid UML notation, it is supposed to be:

    Operation::returnResult() : Parameter [*]

    In both cases, the way OCL interprets the result of such opertion is similar to how it interprets any value, as a collection, and as such collection operations can be called on it.

    Therefore, to be consistent, this operation should be changed have a simple "Parameter" as a return type.

    However, if we are going to leave this operation with * multiplicity to be more robust or OCL friendly, then at least we should be consistent in those other cases, where we have singular return result.

    OperationHasSingularReturnResult : 16
    operation = <Operation> UML::Vertex::containingStateMachine () : StateMachine
    operation = <Operation> UML::Transition::redefinitionContext () : Classifier
    operation = <Operation> UML::Transition::containingStateMachine () : StateMachine
    operation = <Operation> UML::Stereotype::profile () : Profile
    operation = <Operation> UML::Stereotype::containingProfile () : Profile
    operation = <Operation> UML::StateMachine::LCA (s1 : State, s2 : State) : Namespace
    operation = <Operation> UML::State::redefinitionContext () : Classifier
    operation = <Operation> UML::State::containingStateMachine () : StateMachine
    operation = <Operation> UML::Region::redefinitionContext () : Classifier
    operation = <Operation> UML::Region::containingStateMachine () : StateMachine
    operation = <Operation> UML::Property::opposite () : Property
    operation = <Operation> UML::Package::containingProfile () : Profile [0..1]
    operation = <Operation> UML::Operation::type () : Type
    operation = <Operation> UML::LinkAction::association () : Association
    operation = <Operation> UML::Extension::metaclassEnd () : Property
    operation = <Operation> UML::Extension::metaclass () : Class

  • Reported: UML 2.3 — Fri, 15 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The issue is obsolete. The generated Operation descriptions are now correct.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong constraint on Operation::bodyCondition

  • Key: UML24-113
  • Legacy Issue Number: 15768
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    The spec says:

    bodyCondition: Constraint[0..1]
    An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule

    couple this with:

    The bodyCondition for an operation constrains the return result. The bodyCondition differs from postconditions in that
    the bodyCondition may be overridden when an operation is redefined, whereas postconditions can only be added during
    redefinition.

    Also, in the current MM, the defined operations logic is implemented as a body Condition.

    Therefore, the bodyCondition is not an invariant, but rather a condition that describes the return result. of an operation

    Since a non-query operation can also have a return result, I see no reason to prevent a body condition on it.

  • Reported: UML 2.3 — Fri, 15 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 15501

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Be explicit that type does not need to be set for LiteralBoolean etc.

  • Key: UML24-117
  • Legacy Issue Number: 15779
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Today we are inconsistent in the metamodel about whether the type of a LiteralBoolean value is set or not. Some are; most are not, and there is no guidance in the spec about which is correct. Since the type is completely obvious, we can be explicit about this:

    LiteralBoolean

    Constraints:

    [1] Since the type of a LiteralBoolean is by definition a Boolean, it would be redundant to specify the type explicitly.

    type->isEmpty()

    LiteralInteger

    Constraints:

    [1] Since the type of a LiteralInteger is by definition an Integer, it would be redundant to specify the type explicitly.

    type->isEmpty()

    LiteralReal

    Constraints:

    [1] Since the type of a LiteralReal is by definition a Real, it would be redundant to specify the type explicitly.

    type->isEmpty()

    LiteralString

    Constraints:

    [1] Since the type of a LiteralString is by definition a String, it would be redundant to specify the type explicitly.

    type->isEmpty()

    LiteralUnlimitedNatural

    Constraints:

    [1] Since the type of a LiteralUnlimitedNatural is by definition an UnlimitedNatural, it would be redundant to specify the type explicitly.

    type->isEmpty()

  • Reported: UML 2.3 — Mon, 25 Oct 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    After discussion the RTF resolved that making changes of this kind to the spec is too controversial. Instead, we simply go through the metamodel making sure that all instances of subtypes of LiteralSpecification have their type set to null, in order to make the metamodel consistent.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Constraint is Wrong

  • Key: UML24-126
  • Legacy Issue Number: 15881
  • Status: closed  
  • Source: motorola ( bruce lu)
  • Summary:

    In the first item of the 'Constraints' clause,
    (self.name->isEmpty() or self.allNamespaces()>select(ns | ns.name>isEmpty())->notEmpty())
    implies self.qualifiedName->isEmpty()

    should be
    self.name->isEmpty() or (self.allNamespaces()>select(ns | ns.name>isEmpty())->notEmpty())
    implies self.qualifiedName->isEmpty()

  • Reported: UML 2.3 — Wed, 8 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Wrong Classifier Name

  • Key: UML24-125
  • Legacy Issue Number: 15880
  • Status: closed  
  • Source: NSN ( bruce lu)
  • Summary:

    In the 'Associations' clause of section 9.10.3, the last association 'value : InstanceSpecification [*]' is wrong. It should be 'value : ValueSpecification [*]

  • Reported: UML 2.3 — Tue, 7 Dec 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

UML2 - Invalid constraint for Actor

  • Key: UML24-49
  • Legacy Issue Number: 15162
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    16.3.1 Actor says: [1] An actor can only have associations to use cases, components, and classes. Furthermore these associations must be binary. self.ownedAttribute->forAll ( a | (a.association->notEmpty()) implies ((a.association.memberEnd.size() = 2) and (a.opposite.class.oclIsKindOf(UseCase) or (a.opposite.class.oclIsKindOf(Class) and not a.opposite.class.oclIsKindOf(Behavior))))

    But an Actor does not have any ownedAttribute property, so this constraint is invalid.

  • Reported: UML 2.3 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 10780

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Detailed modeling of the Standard Profiles

  • Key: UML24-48
  • Legacy Issue Number: 15144
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    I was reading through the descriptions of the Standard Stereotypes and noticed some oddities, and some aspects that should be explicitly modeled now we are creating normative definitions thereof.

    Overall this exercise has illustrated to me that the tabular approach for defining them is utterly inadequate and we should use one or more profile diagrams. Rather than having the explicit modeling only in the XMI

    BTW it seems to me that the 2nd 'Language Unit' column of the table in Annex C is misleading and pointless so should be deleted: the Stereotypes do not have a language unit. Not even the extended metaclasses have one, once merged into their L2 or L3 metamodel.

    Also if it's not too much hassle it would be handy to include the descriptions from Annex C in the XMI Stereotype definitions.

    If for no other reason these need to be updated to reference other stereotypes using their upper case name.

    The following are points where explicit modeling is called for; I also raise some questions about the descriptions which may need to be raised as issues:

    1. I'm a bit baffled by the following from Auxiliary: "The class that the auxiliary supports may be defined explicitly using a Focus class or implicitly by a dependency relationship." - how a class be defined implicitly let alone via a Dependency? Likewise in the description of Focus

    2. We should model a Constraint that the client and supplier of Dependencies stereotyped by Call must both be Operations. The description should use client and supplier not source and target

    3. Likewise for Create (when applied to Dependencies) they must both be Classifiers.

    4. There are 2 rows for Create – I presume this is one Stereotype that extends 2 metaclasses.

    5. I do not understand the following in Create (when applied to BehavioralFeature) “May be promoted to the Classifier containing the feature.” The same appears on Destroy

    6. The Derive stereotype should have a computation Property to ‘specify the computation’. I suggest this should be of type OpaqueExpression?

    7. The description of Implement is a bit unclear - does it imply that the stereotype itself has a Dependency property? Or should we model a Constraint that the base_Component must be the client of a Dependency?

    8. We should model that Document is a subclass of File. And, I guess, the Constraint that an element with Document applied cannot also have Source and Executable applied (what about Script and Library though?). Is File abstract as implied by the description?

    9. Executable is a subclass of File. And I guess it should have the same constraint?

    10. Library is a subclass of File

    11. ModelLibrary needs to be cleaned up - I will raise a separate issue

    12. Description of Process seems a bit lacking

    13. It seems Realization and ImplementationClass cannot both be applied to the same element?

    14. Script is a subclass of File.

    15. Send should have constraint that the client and supplier of Dependencies to which it is applied are instances of Operation and Signal respectively. The description should use client and supplier not source and target

    16. It seems odd to say that Service “computes a value”.

    17. Source is a subclass of File.

    18. It seems Specification and Type cannot both be applied to the same element?

    19. The description of Utility “A class that has no instances, but rather denotes a named collection of non-member attributes and operations, all of which are class-scoped” – not sure what it means by ‘non-member’, but this seems to imply a constraint on the features of the Class to which it is applied. And I guess a Constraint that the Class must also be abstract (it has no instances).

  • Reported: UML 2.3 — Wed, 24 Mar 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This is quite a lot of things in one issue, most of which have already been resolved by explicitly modeling
    the profile. Some of the points suggest adding constraints to stereotypes, which I propose not to resolve
    here but instead to submit a new issue to capture the proposal. Some of the points require rewording for
    clarification, and the current resolution does this.
    The point about Derive is incorrect: Abstraction already has a mapping in the model.
    I am averse to copying the definitions into the metamodel because it will introduce redundancy and run the
    risk of future inconsistency.
    This also resolves 15278 and 15279.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 issue - misleadingly named associations

  • Key: UML24-52
  • Legacy Issue Number: 15263
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The association between Package and Stereotype called “A_ownedStereotype_profile” is misleadingly named. It should be called “A_ownedStereotype_package”.

    The association between BehavioredClassifier and Behavior called “A_ownedParameter_behavioredClassifier” is misleadingly named. It should be called “A_ownedBehavior_behavioredClassifier”.

  • Reported: UML 2.3 — Tue, 25 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Make the changes as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Meaning of BodyCondition and its alignment with OCL

  • Key: UML24-51
  • Legacy Issue Number: 15259
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    The UML superstructure allows an Operation to have:

    bodyCondition: Constraint[0..1] : An optional Constraint on the result values of an invocation of this Operation. Subsets Namespace::ownedRule

    Since bodyCondition is of type Constraint, its expression must be boolean according to clause 7.3.10 (Constraint):

    [1] The value specification for a constraint must evaluate to a Boolean value.

    Now, the OCL spec states in 7.3.6 that an operation body expression has the form:

    context Typename::operationName(param1 : Type1, ... ): ReturnType
    body: – some expression

    and gives an example:

    context Person::getCurrentSpouse() : Person
    pre: self.isMarried = true
    body: self.mariages->select( m | m.ended = false ).spouse

    Notice that in this example, the expression is NOT boolean, therefore if "self.mariages->select( m | m.ended = false ).spouse" was used as an expression in the bodyCondition, it would not be valid.

    Am I missing something?

    in RSA, we got around this by requiring the expression to be of the format:

    context Typename::operationName(param1 : Type1, ... ): ReturnType
    body: result = some expression

    Is the keyword "result" legal in the expression of bodyCondition?

  • Reported: UML 2.3 — Wed, 19 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    OCL body expressions and UML bodyConditions are inconsistently specified. For the UML spec, the
    bodyConditions need to be Boolean. The way we do this is by naming the result parameter of all of the
    operations as “result”. Then the body expressions should be of the form “result = <expression>”.
    Unfortunately, doing this in RSA causes type errors because RSA gives a well-typed expression its internal
    Boolean type which is not the same type as the UML 2.5 PrimitiveType Boolean.
    So in order to keep RSA as happy as possible, and reduce error-prone work, we’ll keep the body expressions
    in the metamodel in the OCL-like form (without the “result =”) and cause the XMI generation process to
    wrap result = (. . . ) around all of the body expressions.
    This also resolves 13258.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Resolution to issue 14063

  • Key: UML24-53
  • Legacy Issue Number: 15264
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Accepted resolution in UML 2.4 Ballot 8 for issue 14063 has a problem because ActivityGroup::inActivity needs to refer to StructuredActivities::Activity

  • Reported: UML 2.3 — Tue, 25 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The accepted resolution for 14063 in Ballot 8 states the following:
    “In the UML 2.3 Superstructure Specification, Subclause 12.2 Abstract Syntax, in Figures 12.21 and 12.22, replace the unqualified ActivityGroup classes on the diagrams with the qualified UML::Activities::FundamentalActivities::ActivityGroup class. Remove the StructuredActivities::ActivityGroup and CompleteStructuredActivities::ActivityGroup classes from the metamodel.”
    The problem is that ActivityGroup in StructuredActivities refers, via its property inActivity, to Activity in StructuredActivities. Removing StructuredActivities::ActivityGroup deprives this property of a home. Hence we need to reinstate the copies of ActivityGroup.
    Then we also need to copy down Action into CompleteStructuredActivities, and its associations input and output, so that the structuredNodeInput

    {subsets input}

    and structuredNodeOutput

    { subsets output}

    work correctly, i.e. subset the correct types of InputPin and OutputPin.
    Note than none of this will have any effect on the merged definition of UML.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue 14287 and 13330 resolutions are inconsistent and incorrectly applied.

  • Key: UML24-55
  • Legacy Issue Number: 15266
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    13330, resolved in UML 2.3, was not correctly applied to the specification diagrams. The following instructions were not carried out:

    Show the association name label in Figure 17.18

    Show the association name label in Figure 17.29

    Show the association name label in Figure 17.30

    Perhaps as a consequence of this, 14287 in 2.4 should have been resolved as a dup of 13330, not as an inconsistent set of changes.

  • Reported: UML 2.3 — Wed, 26 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Do not make the changes to association names as proposed in 13287. Instead, leave the names as resolved in 13330 and in the UML 2.3 metamodel.
    Show the names in the diagrams as specified by 13330.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Subclasses of Classifier should subset redefinedClassifier when they redefine

  • Key: UML24-54
  • Legacy Issue Number: 15265
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML 2 Subclasses of Classifier should subset redefinedClassifier when they redefine. In particular, Behavior::redefinedBehavior should subset Classifier::redefinedClassifier, not Element::redefinedElement; and StateMachine::extendedStateMachine should subset Classifier::redefinedClassifier, not Element::redefinedElement. These are exactly analogous to the problem raised in issue 14554.

  • Reported: UML 2.3 — Tue, 25 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Make the suggested changes.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MessageEvents

  • Key: UML24-47
  • Legacy Issue Number: 15136
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Could you guys shed some light in this area?
    Every tool vendor has different ideas (and implementation) what event types should be used at message ends for call message, reply message, create message or destroy message.

  • Reported: UML 2.3 — Tue, 9 Mar 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issue 14629 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association owned derived union

  • Key: UML24-46
  • Legacy Issue Number: 15128
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Is it really illegal to define a non-navigable association-owned property as derived union?

    When I try that I invalidate the following constraint in section 7.3.44 the metamodel:

    [6]Only a navigable property can be marked as readOnly.
    isReadOnly implies isNavigable()

    Why "efficiency of access" (as implied by navigability) restrics read-only access?

    One way to get around that is to make the property owned in the "navigableOwnerEnd" vs. "ownedEnd" of the association? do we have any precedence of doing that in an abstract syntax?

  • Reported: UML 2.3 — Mon, 22 Mar 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This constraint seems to be an old constraint from UML 1.x when navigability meant the same as ownership of property. It is not consistent with the meaning of navigability now, which is about “efficiency of access”.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

composite tags

  • Key: UML24-50
  • Legacy Issue Number: 15167
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Are composite tag definitions allowed?

  • Reported: UML 2.3 — Tue, 6 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    A Stereotype is a kind of Class and the semantics of a Property defined on a Stereotype is the same as
    that of a Property defined on a Class. Therefore, a Stereotype Property can have composite aggregation.
    The value of a composite Stereotype Property will be owned by an instance of such Stereotype. The type
    of such Property cannot be a Stereotype (since Stereotypes are owned by their Extensions) or a metaclass
    (since instances of metaclasses are owned by other instantances of metaclasses); however, the type of such
    Property can be a Class defined in the Profile or a DataType defined in the Profile or accessible via import
    or via the Profile’s metamodel reference.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Issue: OCL in resolution 11114 is incorrect

  • Key: UML24-56
  • Legacy Issue Number: 15267
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The OCL is the resolution is:

    self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self)))

    It has two problems:

    1- It is missing a closing ")" needed to balance the brackets, correcting this yields

    self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self))))

    2- the "collect" operation above returns a Bag, and since "inherit" operation expects a Set as input, the cast "toSet()" is needed, correcting this yields:

    self.inheritedMember->includesAll(self.inherit( self.parents()>collect(p | p.inheritableMembers(self))>asSet() ))

  • Reported: UML 2.3 — Wed, 26 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    As the summary says

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2.3 definition of Classifier::hasVisibilityOf is circular

  • Key: UML24-45
  • Legacy Issue Number: 15126
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    If we consider class A inherits from class B, and we have an instance of A called a, and a property in B called p. Let’s calculate the visibility of p in a, assuming p is private. I’m doing substitutions, a bit loosely, but you’ll get the point.

    a::hasVisibilityOf(p) : Boolean if (a.inheritedMember->includes(p)) then hasVisibilityOf = false else hasVisibilityOf = true

    -> we need to calculate a.inheritedMember

    a.inheritedMember->includesAll(a.inherit(

    {B.inheritableMembers(a) }

    ))

    -> we need to calculate B.inheritableMembers(a)

    B.inheritableMembers(a) =

    {p}

    ->select(m | a.hasVisibilityOf(m)) …. a.hasVisibilityOf(p)

    -> we are in a loop!

  • Reported: UML 2.3 — Wed, 10 Mar 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issue 10006 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2.3: Missing subsetting from A_redefinedClassifier_classifier in XMI

  • Key: UML24-44
  • Legacy Issue Number: 15125
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The XMI for A_redefinitionContext_redefinableElement is this:

    <ownedMember xmi:type="cmof:Association" xmi:id="Classes-Kernel-A_redefinedClassifier_classifier" name="A_redefinedClassifier_classifier" memberEnd="Classes-Kernel-Classifier-redefinedClassifier Classes-Kernel-A_redefinedClassifier_classifier-classifier">
    <ownedEnd xmi:type="cmof:Property" xmi:id="Classes-Kernel-A_redefinedClassifier_classifier-classifier" name="classifier" type="Classes-Kernel-Classifier" upper="*" lower="0" owningAssociation="Classes-Kernel-A_redefinedClassifier_classifier" association="Classes-Kernel-A_redefinedClassifier_classifier"/>
    </ownedMember>

    In the spec, classifier is shown as

    {subsets redefinitionContext}

    . This is missing from the XMI.

  • Reported: UML 2.3 — Wed, 10 Mar 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issue 14977 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

loopVariable ownership

  • Key: UML24-29
  • Legacy Issue Number: 14962
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: OMG UML Superstructure, Version 2.3 (ptc/2009-09-09)

    Subclause: 12.3.35 LoopNode

    The loopVariables of a LoopNode are OutputNodes, but they are not part of the outputs of the LoopNode. Therefore, they need to be independently owned by the LoopNode.

    The propery LoopNode::loopVariable should subset Element::ownedElement, and the association should be shown as composite on Figure 12.22. Otherwise the mustBeOwned constraint will be violated for loopVariables.

  • Reported: UML 2.3 — Tue, 12 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue is obsolete. loopVariables are owned by LoopNodes in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association conflicts with MemberEnds IsDerived flags

  • Key: UML24-95
  • Legacy Issue Number: 15566
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML::CompositeStructures::InternalStructures::A_feature_featuringClassifier

    UML::Activities::FundamentalActivities::A_subgroup_superGroup

    UML::Activities::FundamentalActivities::A_containedNode_inGroup

    UML::Activities::CompleteStructuredActivities::A_containedEdge_inGroup

    UML::Activities::StructuredActivities::A_containedNode_inGroup

    UML::Activities::CompleteActivities::A_containedNode_inGroup

    UML::Activities::IntermediateActivities::A_subgroup_superGroup

    UML::Activities::IntermediateActivities::A_containedEdge_inGroup

    UML::Activities::IntermediateActivities::A_containedNode_inGroup

    InfrastructureLibrary::Core::Abstractions::Constraints::A_ownedMember_namespace

    InfrastructureLibrary::Core::Abstractions::Classifiers::A_feature_featuringClassifier

    InfrastructureLibrary::Core::Abstractions::Namespaces::A_ownedMember_namespace

    InfrastructureLibrary::Core::Abstractions::Ownerships::A_ownedElement_owner

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    These are associations with both ends derived. There is a MOF constraint: An Association is derived if all its Properties are derived. Hence all of these associations should be marked as derived. In addition, there is currently inconsistency elsewhere in the metamodel about which associations should be marked as derived. For example, A_redefinitionContext_region, with derived=false, and A_redefinitionContext_state, with derived=true. These are obviously inconsistent.
    In order to correct this we?ll apply the following additional constraint:
    ? An association in which all navigable (class-owned) ends are derived is derived
    The reasoning behind this is as follows.
    If you take the meaning of an association to be a set of links, and the meaning of an association end to be a set of instances of the type at the end of the association, then “derived” means that these sets can be calculated from other information. The other ingredient is whether the set can be altered “by hand”, as it were: and I am assuming that non-navigable ends cannot be altered by hand, i.e. they do not correspond to a settable API on a class. I don?t believe there is anything formal to substantiate this assumption, but it seems to be current practice for the metamodel to be constructed according to it. In this sense, all non-navigable ends are “derived”, whether you say so or not.
    The following are violations of this additional constraint:
    InfrastructureLibrary::Core::Abstractions::BehavioralFeatures::A_parameter_behavioralFeature
    InfrastructureLibrary::Core::Abstractions::Constraints::A_member_memberNamespace
    InfrastructureLibrary::Core::Abstractions::Generalizations::A_general_classifier
    InfrastructureLibrary::Core::Abstractions::Namespaces::A_member_memberNamespace
    InfrastructureLibrary::Core::Abstractions::Redefinitions::A_redefinedElement_redefinableElement
    InfrastructureLibrary::Core::Abstractions::Redefinitions::A_redefinitionContext_redefinableElement
    InfrastructureLibrary::Core::Abstractions::Relationships::A_relatedElement_relationship
    InfrastructureLibrary::Core::Abstractions::Relationships::A_source_directedRelationship
    InfrastructureLibrary::Core::Abstractions::Relationships::A_target_directedRelationship
    InfrastructureLibrary::Core::Abstractions::Super::A_inheritedMember_classifier
    InfrastructureLibrary::Core::Constructs::A_attribute_classifier
    InfrastructureLibrary::Core::Constructs::A_endType_association
    InfrastructureLibrary::Core::Constructs::A_importedMember_namespace
    InfrastructureLibrary::Core::Constructs::A_inheritedMember_classifier
    InfrastructureLibrary::Core::Constructs::A_member_memberNamespace
    InfrastructureLibrary::Core::Constructs::A_opposite_property
    InfrastructureLibrary::Core::Constructs::A_parameter_behavioralFeature
    InfrastructureLibrary::Core::Constructs::A_redefinedElement_redefinableElement
    InfrastructureLibrary::Core::Constructs::A_redefinitionContext_redefinableElement
    InfrastructureLibrary::Core::Constructs::A_relatedElement_relationship
    InfrastructureLibrary::Core::Constructs::A_source_directedRelationship InfrastructureLibrary::Core::Constructs::A_target_directedRelationship
    InfrastructureLibrary::Core::Constructs::A_type_operation
    InfrastructureLibrary::Profiles::A_ownedStereotype_owningPackage
    InfrastructureLibrary::Profiles::A_profile_stereotype
    UML::Actions::BasicActions::A_input_action
    UML::Actions::BasicActions::A_output_action
    UML::Activities::CompleteStructuredActivities::A_input_action
    UML::Activities::CompleteStructuredActivities::A_output_action
    UML::AuxiliaryConstructs::Templates::A_inheritedParameter_redefinableTemplateSignature
    UML::AuxiliaryConstructs::Templates::A_redefinitionContext_redefinableElement
    UML::Classes::Interfaces::A_attribute_classifier
    UML::Classes::Kernel::A_attribute_classifier
    UML::Classes::Kernel::A_classifier_enumerationLiteral
    UML::Classes::Kernel::A_endType_association
    UML::Classes::Kernel::A_general_classifier
    UML::Classes::Kernel::A_importedMember_namespace
    UML::Classes::Kernel::A_inheritedMember_classifier
    UML::Classes::Kernel::A_member_memberNamespace
    UML::Classes::Kernel::A_opposite_property
    UML::Classes::Kernel::A_parameter_behavioralFeature
    UML::Classes::Kernel::A_redefinedElement_redefinableElement
    UML::Classes::Kernel::A_redefinitionContext_redefinableElement
    UML::Classes::Kernel::A_relatedElement_relationship
    UML::Classes::Kernel::A_source_directedRelationship
    UML::Classes::Kernel::A_superClass_class
    UML::Classes::Kernel::A_target_directedRelationship
    UML::Classes::Kernel::A_type_operation
    UML::CommonBehaviors::BasicBehaviors::A_context_behavior
    UML::CommonBehaviors::BasicBehaviors::A_result_opaqueExpression
    UML::Components::BasicComponents::A_provided_component
    UML::Components::BasicComponents::A_required_component
    UML::CompositeStructures::InternalStructures::A_attribute_classifier
    UML::CompositeStructures::InternalStructures::A_definingEnd_connectorEnd
    UML::CompositeStructures::InternalStructures::A_part_structuredClassifier
    UML::CompositeStructures::InternalStructures::A_role_structuredClassifier
    UML::CompositeStructures::Ports::A_ownedPort_encapsulatedClassifier
    UML::CompositeStructures::Ports::A_provided_port
    UML::CompositeStructures::Ports::A_required_port
    UML::StateMachines::BehaviorStateMachines::A_redefinitionContext_region
    UML::StateMachines::BehaviorStateMachines::A_redefinitionContext_transition
    UML::StateMachines::ProtocolStateMachines::A_referred_protocolTransition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fix association end multiplicities

  • Key: UML24-94
  • Legacy Issue Number: 15565
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    InfrastructureLibrary::Profiles::A_metamodelReference_profile::profile from [1] to [0..1]

    InfrastructureLibrary::Profiles::A_metaclassReference_profile::profile from [1] to [0..1]

    CompleteStructuredActivities::A_structuredNodeInput_structuredActivityNode::structuredActivityNode from [1] to [0..1]

    CompleteStructuredActivities::A_structuredNodeOutput_structuredActivityNode::structuredActivityNode from [1] to [0..1]

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The first change is needed because otherwise a PackageImport and an ElementImport must be owned by a profile, which is bad.
    The second change is needed because otherwise InputPins and OutputPins must be the inputs and outputs of StructuredActivityNode (fig 12.22), which is also bad.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicity Element Is MultiValued With Default Value

  • Key: UML24-98
  • Legacy Issue Number: 15569
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    This applies to DurationObservation::firstEvent[0..2] default = true, and DurationConstraint::firstEvent[0..2], defaultValue = true. This conflicts with CMOF constraint [9] Multivalued properties cannot have defaults, and is also meaningless because firstEvent size is constrained to be 0 or 2.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Remove the default as it violates a CMOF constraint

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Derived properties that are not marked read-only

  • Key: UML24-97
  • Legacy Issue Number: 15568
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Although there is a case in general modeling that derived properties need not be read-only, we should apply a convention in the UML metamodel that derived properties are read-only. There are 24 exceptions to this convention.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Here is the list of properties that are derived but not readonly. In the absence of compelling arguments why each should not be made readonly, we should make it readonly. This will make the metamodel more systematic and consistent.
    Vertex::outgoing
    Vertex::incoming
    Stereotype::profile (Infra fig 12.2, Super fig 18.2)
    Property::opposite (Super fig 7.12)
    Property::isComposite (Super fig 7.12)
    Property::default (Super fig 7.12)
    Parameter::default (Super fig 7.11)
    Package::ownedType (Infra fig 11.26, Super fig 7.14)
    Package::ownedStereotype (Infra fig 12.2, Super fig 18.2)
    Package::nestedPackage (Infra fig 11.26, Super fig 7.14)
    Operation::upper (Super fig 7.11)
    Operation::type (Super fig 7.11)
    Operation::lower (Super fig 7.11)
    Operation::isUnique (Super fig 7.11)
    Operation::isOrdered (Super fig 7.11)
    MultiplicityElement::upper
    MultiplicityElement::lower
    EnumerationLiteral::classifier (Super fig 7.13)
    EncapsulatedClassifier::ownedPort
    Connector::kind (Super fig 8.3)
    ConnectableElement::end (Super fig 8.3)
    Classifier::general
    Class::superClass (Super fig 7.12)
    ExtensionEnd::lower However we cannot make all of these properties read-only, because some of them are defined as non-derived in infrastructure. Because the merge rules are such that writeable overrides read-only, in order to make them read-only in the merged model, we.d have to make them read-only even when they are non-derived in Infrastructure, which would make no sense.
    Another reason not to make them all readonly is the following paragraph in Superstructure 2.3:
    ¡°Thus, it is not meaningful to claim compliance to, say, Level 2 without also being compliant with the Level 0 and Level 1. A tool that is compliant at a given level must be able to import models from tools that are compliant to lower levels without loss of information.¡±
    This implies that properties writable at L0 should be writeable at L3.
    The properties affected by this are:
    Property::opposite
    Property::isComposite
    Property::default
    Parameter::default
    Package::ownedType
    Package::nestedPackage
    MultiplicityElement::upper
    MultiplicityElement::lower
    Classifier::general
    Class::superClass
    We are allowed by the notation not to show

    {readOnly} on the diagrams. We will show {readOnly}

    on some diagrams because (a) we are changing these diagrams for other reasons and (b) the tool enforces an ¡°all or nothing¡± rule on which decorations we show for attributes. Our current convention is not to show readOnly in the specification text (with one exception), so we.ll carry on with the convention.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Message's signature is still derived property (in text only):

  • Key: UML24-89
  • Legacy Issue Number: 15560
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    /signature:NamedElement[0..1] The signature of the Message is the specification of its content. It refers either an Operation or a Signal.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This is as a result of an incomplete application of resolution 14629, which was formulated slightly ambiguously.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 issue: UML 2.4 normative deliverables should be published in MOF2.4 / XMI 2.4 format

  • Key: UML24-88
  • Legacy Issue Number: 15530
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML 2.4 normative deliverables should be published in MOF2.4 / XMI 2.4 format.

  • Reported: UML 2.3 — Thu, 16 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Remove all of the cmof files from the published set of artifacts for UML 2.4. Instead, publish the following normative artifacts in MOF2.4/XMI2.4 format:
    Infrastructure.xmi
    Superstructure.xmi
    L0.xmi
    L1.xmi
    L2.xmi
    L3.xmi
    LM.xmi
    PrimitiveTypes.xmi
    UML.xmi (the merged L3 model)
    StandardProfileL2.xmi
    StandardProfileL3.xmi
    Also publish the following non-normative artifacts in MOF2.4/XMI2.4 format:
    L0.merged.xmi
    LM.merged.xmi
    L1.merged.xmi
    L2.merged.xmi
    Change all references to MOF 2 and XMI 2 in the specification text accordingly.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Redefinition of association-owned ends requires association generalization

  • Key: UML24-96
  • Legacy Issue Number: 15567
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There are 21 examples of association generalizations that need to be introduced in order to make association-owned end redefinition valid

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The redefinition context for an association-owned end is the association itself. Hence in order for redefinition of such ends to be well-formed, the associations must participate in appropriate generalizations.
    Here are the problematic redefinitions:
    redefiningElement = A_specification_timeConstraint::timeConstraint
    redefinitionContext = A_specification_timeConstraint
    redefinedElement = A_specification_intervalConstraint::intervalConstraint
    redefinedContext = A_specification_intervalConstraint
    redefiningElement = A_specification_intervalConstraint::intervalConstraint
    redefinitionContext = A_specification_intervalConstraint
    redefinedElement = A_specification_owningConstraint::owningConstraint
    redefinedContext = A_specification_owningConstraint
    redefiningElement = A_specification_durationConstraint::durationConstraint
    redefinitionContext = A_specification_durationConstraint
    redefinedElement = A_specification_intervalConstraint::intervalConstraint
    redefinedContext = A_specification_intervalConstraint
    redefiningElement = A_request_sendObjectAction::sendObjectAction
    redefinitionContext = A_request_sendObjectAction
    redefinedElement = A_argument_invocationAction::invocationAction
    redefinedContext = A_argument_invocationAction
    redefiningElement = A_representation_classifier::classifier redefinitionContext = A_representation_classifier
    redefinedElement = A_collaborationUse_classifier::classifier
    redefinedContext = A_collaborationUse_classifier
    redefiningElement = A_redefinitionContext_transition::transition
    redefinitionContext = A_redefinitionContext_transition
    redefinedElement = A_redefinitionContext_redefinableElement::redefinableElement
    redefinedContext = A_redefinitionContext_redefinableElement
    redefiningElement = A_redefinitionContext_state::state
    redefinitionContext = A_redefinitionContext_state
    redefinedElement = A_redefinitionContext_redefinableElement::redefinableElement
    redefinedContext = A_redefinitionContext_redefinableElement
    redefiningElement = A_redefinitionContext_region::region
    redefinitionContext = A_redefinitionContext_region
    redefinedElement = A_redefinitionContext_redefinableElement::redefinableElement
    redefinedContext = A_redefinitionContext_redefinableElement
    redefiningElement = A_preCondition_protocolTransition::protocolTransition
    redefinitionContext = A_preCondition_protocolTransition
    redefinedElement = A_guard_transition::transition
    redefinedContext = A_guard_transition
    redefiningElement = A_ownedStereotype_owningPackage::owningPackage
    redefinitionContext = A_ownedStereotype_owningPackage
    redefinedElement = A_packagedElement_owningPackage::owningPackage
    redefinedContext = A_packagedElement_owningPackage
    redefiningElement = A_ownedDefault_templateParameter::templateParameter
    redefinitionContext = A_ownedDefault_templateParameter
    redefinedElement = A_default_templateParameter::templateParameter
    redefinedContext = A_default_templateParameter
    redefiningElement = A_ownedAttribute_structuredClassifier::structuredClassifier
    redefinitionContext = A_ownedAttribute_structuredClassifier
    redefinedElement = A_role_structuredClassifier::structuredClassifier
    redefinedContext = A_role_structuredClassifier
    redefiningElement = A_ownedActual_templateParameterSubstitution::templateParameterSubstitution
    redefinitionContext = A_ownedActual_templateParameterSubstitution
    redefinedElement = A_actual_templateParameterSubstitution::templateParameterSubstitution
    redefinedContext = A_actual_templateParameterSubstitution redefiningElement = A_min_timeInterval::timeInterval
    redefinitionContext = A_min_timeInterval
    redefinedElement = A_min_interval::interval
    redefinedContext = A_min_interval
    redefiningElement = A_min_durationInterval::durationInterval
    redefinitionContext = A_min_durationInterval
    redefinedElement = A_min_interval::interval
    redefinedContext = A_min_interval
    redefiningElement = A_max_timeInterval::timeInterval
    redefinitionContext = A_max_timeInterval
    redefinedElement = A_max_interval::interval
    redefinedContext = A_max_interval
    redefiningElement = A_max_durationInterval::durationInterval
    redefinitionContext = A_max_durationInterval
    redefinedElement = A_max_interval::interval
    redefinedContext = A_max_interval
    redefiningElement = A_endData_destroyLinkAction::destroyLinkAction
    redefinitionContext = A_endData_destroyLinkAction
    redefinedElement = A_endData_linkAction::linkAction
    redefinedContext = A_endData_linkAction
    redefiningElement = A_endData_createLinkAction::createLinkAction
    redefinitionContext = A_endData_createLinkAction
    redefinedElement = A_endData_linkAction::linkAction
    redefinedContext = A_endData_linkAction
    redefiningElement = A_classifier_enumerationLiteral::enumerationLiteral
    redefinitionContext = A_classifier_enumerationLiteral
    redefinedElement = A_classifier_instanceSpecification::instanceSpecification
    redefinedContext = A_classifier_instanceSpecification
    redefiningElement = A_classifierBehavior_behavioredClassifier::behavioredClassifier
    redefinitionContext = A_classifierBehavior_behavioredClassifier
    redefinedElement = A_ownedBehavior_behavioredClassifier::behavioredClassifier
    redefinedContext = A_ownedBehavior_behavioredClassifier

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fix 14977 vs. 14638

  • Key: UML24-93
  • Legacy Issue Number: 15564
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There is an inconsistency between 14977 and 14638 that results in inconsistent association end subsets due to incomplete copy-down from Kernel to InternalStructures.

    The resolution is to introduce 2 new generalizations

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The generalizations that need to be added are between InternalStructures::StructuredClassifier and Kernel::Classifier, and between InternalStructures::Connector and Kernel::Feature. This enables the ends of A_ownedConnector_structuredClassifier to subset all the things they need to, especially redefinitionContext/redefinableElement. This becomes obvious when you look at the draft figure 9.2. The root cause of this was an attempt to apply both 14638 and 14977 which led to the error.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association-owned association end name changes

  • Key: UML24-92
  • Legacy Issue Number: 15563
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Kernel & Infrastructure:

    A_member_namespace => A_member_memberNamespace

    Change the association-owned association end from 'namespace' to 'memberNamespace'

    Interactions::BasicInteractions

    Change:

    A_sendEvent_message => A_sendEvent_endMessage

    A_receiveEvent_message => A_receiveEvent_endMessage

    + association-owned association end: 'message' => 'endMessage'

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The reason for the first change can be understood by looking at figure 7.4. This shows importedMember subsets member. The other end of this association, non-navigable and un-named on the diagram, is called namespace in the metamodel. This needs, by symmetry, to subset the other end of the association A_member_namespace. That cannot be called namespace, because of the constraint “A Property cannot be subset by a Property with the same name”. Hence we change its name to member_Namespace, and change the association name to follow the convention.
    The second change is for similar reasons. It is actually reflected in the current figure 14.4 but the association name has not been changed to match, and the change has not been introduced in any existing resolution.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The resolution to issue 13993 that moved PrimitiveTypes to an independent package contained a mistake

  • Key: UML24-87
  • Legacy Issue Number: 15529
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The resolution to issue 13993 that moved PrimitiveTypes to an independent package contained a mistake. It specified deleting the import from InfrastructureLibrary::Core::Abstractions to PrimitiveTypes. This is incorrect. Instead it should have specified retargeting the import from InfrastructureLibrary::Core::Abstractions to the new PrimitiveTypes package, to be consistent with the new figure 7.3.

  • Reported: UML 2.3 — Thu, 16 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing subsetting of redefinitionContext by Property::owningAssociation

  • Key: UML24-86
  • Legacy Issue Number: 15526
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: UML Superstructure version 2.4 (ptc/2010-08-02)

    Subclause: 7.3.45 Property

    In Subclause 7.3.45, the description of Property::owningAssociation indicates that it subsets RedefinableElement::redefinitionContext. However, this is not shown in Figure 7.12. This subsetting relationship is necessary if an owned end of an association is to be able to redefine the ends of parent associations.

    Since this is a metamodel error, it should be fixed in UML 2.4.

  • Reported: UML 2.3 — Tue, 14 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InstanceValue has no type

  • Key: UML24-99
  • Legacy Issue Number: 15570
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There are many cases where the default value of a property is represented by an InstanceValue, which is a TypedElement, but has no type. These types should be inserted.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    In fact there are four cases where this is true for an InstanceValue that refers to an EnumerationLiteral. Other cases are instances of LiteralInteger, LiteralBoolean, etc and it seems completely redundant to mark the type of these as Integer, Boolean etc.
    UML::Classes::Kernel::Property::aggregation
    UML::Classes::Kernel::Parameter::direction
    UML::Activities::CompleteActivities::ObjectNode::ordering
    InfrastructureLibrary::Core::Constructs::Parameter::direction

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DestructionOccurenceSpecification is inherited from OccurenceSpecification instead of MessageOccurenceSpecification

  • Key: UML24-90
  • Legacy Issue Number: 15561
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    That means, it can't be set as message end of delete message (message with "cross" sign at end). Critical bug I think

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The following existing text describes the notation:
    The form of the line or arrowhead reflects properties of the message: …
    • Object deletion Message should end in a DestructionOccurrenceSpecification.
    This clearly implies that a DestructionOccurrenceSpecification must be a possible message end, so the issue is correct.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DestructionOccurenceSpecification text in Semantics still refers to events

  • Key: UML24-91
  • Legacy Issue Number: 15562
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    DestructionOccurenceSpecification text in Semantics still refers to events:
    "A destruction event represents the destruction of the instance described by the lifeline containing the OccurrenceSpecification that references the destruction event. "

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    It should not refer to events.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

serialization of a profile should always include the nsURI and nsPrefix tags

  • Key: UML24-38
  • Legacy Issue Number: 15006
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The UML Superstructure Specification (in Subclause 18.3.6) says that the

    serialization for a profile "should" (not "shall") specify the values for the

    nsURI and nsPrefix XMI tags and makes recommendations for what these values

    should be. However, this is not normative and "the exact specification of these

    tags is a semantic variation point".

    For the purposes of maximizing successful interchange, however, the

    serialization of a profile should always include the nsURI and nsPrefix tags,

    set as recommended in the specification. The serialization of any application

    of such a profile must then use the recommended forms for the URI and namespace

    prefix for any stereotype applications.

  • Reported: UML 2.3 — Mon, 25 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The offending paragraph is altered to make the nsURI and nsPrefix tags mandatory. Also phrases such as “CMOF package corresponding to the” is deleted because we are not serializing a CMOF package; we are serializing a profile as a UML model.
    We do not make the format of the tags mandatory, because organizations are at liberty to create their own formats for proprietary profiles, as long as they follow XMI rules.
    The XMI examples are modified to be up to date and to follow the rules, in resolution 14448.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incomplete resolution to 10826

  • Key: UML24-37
  • Legacy Issue Number: 15001
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Issue 10826 was asking for two things:

    what is an applied stereotype, as opposed to the definition of the stereotype that was applied
    what are tag/value pairs, as opposed to the definition of the stereotype properties that led to the tag/value pairs

    The resolution for 10826 added the following paragraph:

    An instance “S” of Stereotype is a kind of metaclass that extends other metaclasses through association (Extension) rather
    than generalization/specialization. Relating it to a metaclass “C” from the reference metamodel (typically UML) using an
    “Extension” (which is a specific kind of association), signifies that model elements of type C can be extended by an
    instance of “S” (see example in Figure 18.13). At the model level (such as in Figure 18.18) instances of “S” are related to
    “C” model elements (instances of “C”) by links (occurrences of the association/extension from “S’ to “C”).

    Up to the last sentence, the paragraph refers to ‘an instance “S” of Stereotype’ – i.e., the definition of “S”, a stereotype, in a profile — as illustrated in figure 18.13.

    The last sentence is relevant to question (1) of 10826; however, the resolution doesn’t actually answer the question — i.e., it doesn’t explain what ‘an instance of “S”’ actually is. >From Figure 18.18, the notation suggests that ‘an instance of “S”’ is some kind of instance specification but the resolution doesn’t actually say so and doesn’t address question (2) of 10826 either.

    I propose then to file a new issue about this and include Ed’s suggestion below as well as clarifying that in Figure 18.18, ‘an instance of “S”’ is actually an instance specification whose classifier happens to be ‘an instance “S” of Stereotype’, i.e., the definition of “S”, a kind of Class since Stereotype extends Class.

  • Reported: UML 2.3 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The UML 2.5 specification and in particular the resolution to issue 17160 make this issue obsolete.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of Behavior::context is not correct

  • Key: UML24-31
  • Legacy Issue Number: 14964
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: OMG UML Superstructure, Version 2.3 (ptc/2009-09-09)

    Subclause: 13.3.2 Behavior

    Behavior::context is a derived association, with its derivation given by:

    “If the behavior is owned by a BehavioredClassifier, that classifier is the context; otherwise, the context is the first BehavioredClassifier reached by following the chain of owner relationships. For example, following this algorithm, the context of an entry action in a state machine is the classifier that owns the state machine.”

    However, an entry behavior is owned by a state which is owned by a region which must be owned (directly or indirectly) by a state machine. But a state machine is a behavior, which is a class, which is a behaviored classifier. Therefore, by the given algorithm, it is the state machine that is the context of the entry behavior, not the owner of the state machine, even if the state machine is a classifier behavior.

    This is a serious problem, since the definition for Behavior::context further says “The features of the context classifier as well as the elements visible to the

    context classifier are visible to the behavior.” And it is generally assumed in state machine modeling that an entry behavior in a state machine that is a classifier behavior has visibility to the elements of the owner of the state machine. Similarly, the semantics of a read self action is determined by the context of the activity that contains that action, and if that activity is the entry behavior of a state machine that is a classifier behavior, then the result of this action should be the owner of the state machine, not the state machine.

    In summary, the second sentence given in the first quote above seems to be the true intent of Behavior::context. The first sentence should be changed to:

    “To determine the context of a Behavior, find the first BehavioredClassifier reached by following the chain of owner relationships from the Behavior, if any. If there is such a BehavioredClassifier, then it is the context, unless it is itself a Behavior with a non-empty context, in which case that is also the context for the original Behavior.”

  • Reported: UML 2.3 — Tue, 12 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Agreed, except that a slight change to the proposed text will also resolve Issue 14963

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Context of a behavior owned as a nested classifier

  • Key: UML24-30
  • Legacy Issue Number: 14963
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: OMG UML Superstructure, Version 2.3 (ptc/2009-09-09)

    Subclause: 13.3.2 Behavior

    Since a behavior is a classifier, and a class is a behaviored classifier, it is possible for a class to own a behavior either as an ownedBehavior (inherited from BehavioredClassifier), or as a nestedClassifier (defined specifically for Class). The intended semantics of nestedClassifier is simply that a classifier is a member of the owning class as a namespace. On would not expect this to imply the additional semantics given later for owned behaviors.

    However, the derivation for Behavior::context is based on the ownership of the behavior, directly or indirectly, by a behaviored classifier, regardless of how this ownership happens. Thus it would seem that a behavior owned as a nestedClassifier would have the owning class as its context, even though it is not an ownedBehavior. It would seem better to have behaviors owned as nestedClassifiers not have the owner as a context, allowing normal visibility rules to apply for access from within the behavior to elements of its owning namespace

  • Reported: UML 2.3 — Tue, 12 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issue 14964 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Matching subsettting across association ends

  • Key: UML24-32
  • Legacy Issue Number: 14977
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    What’s our position about matching subsetting across association ends? I’m looking, for example, at the property Extend::Extension. This subsets source; but its other end subsets ownedMember. This clearly implies that Extend::Extension also subsets namespace (and owner); and the ownerMember end should also subset ownedElement.

    There are plenty of examples of this all over the spec.

    It would be nice to get this right for 2.4. Is this something we’ve already identified?

  • Reported: UML 2.3 — Thu, 14 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The following OCL query is designed to find all associations that have asymmetric subsetting of their association ends:
    https://dev.enterprisecomponent.com/repository/repos/UML-RTF/trunk/Models/Constraints/RSA7.5-OCL/associationsWithAsymmetricSubsetting.ocl
    For the UML 2.4 metamodel created from the UML 2.3 metamodel, this query found 182 cases of asymmetric subsetting.
    Here is a proof that subsetting is symmetric (refer to fig 16.2 for the example, but the proof applies to any example):
    Consider UseCase u and Extend e, such that u ? e.extension.
    Then e ? u.extend [because of association invariant: c2 ? c1.p implies c1 ? c2.(p.opposite)]
    It is given that e ? u.ownedMember [ because extend subsets ownedMember ]
    Therefore u ? e.namespace [ because of association invariant ]
    Hence u ? e.extension implies u ? e.namespace, i.e. extension subsets namespace.
    For a redefined association end, the redefinition means that the same set of links are traversed by the redefining property as the redefined property. The same set of links is a special case of subsetting, and the argument then follows as for subsetting. (See 14993 which is resolved as a duplicate of this).
    Where classes and associations have needed to be copied down into a package in order to enable these changes, it has been done. We minimize changes to the current specification diagrams and text by applying the following rules:

    • Where a subsetted property is owned by an association, it is not shown in either diagram or text.
    • Where a subset constraint can be deduced, it does not need to be shown in the diagrams or text.
    • Redundant subsetted properties whose presence can be inferred from others, that are currently in the diagrams and/or text, are left there.
      We anticipate that a future version of UML may apply different conventions to its diagrams to make it simpler to reason about property subsetting.
      The vast majority of the changes involved in this resolution only occur in the metamodel and XMI, where missing subset constraints have been introduced.
      In a few cases documented in this resolution, changes are needed to the diagrams and text to show where metaclasses and/or associations are introduced into a package to make the model merge correctly. Changes are also needed to the diagrams and text wherever a material “subsets” statement is absent.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity vs Action completion

  • Key: UML24-43
  • Legacy Issue Number: 15120
  • Status: closed  
  • Source: Anonymous
  • Summary:

    "In both UML activities and UML statecharts it is sometimes necessary to recognize when some behavior (activity or state-based, respectively) has completed. However, in models without an explicit final node or final state respectively, it is not always clear when this condition is achieved

  • Reported: UML 2.3 — Thu, 4 Mar 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This is covered for Activities in the UML 2.5 beta specification this is now covered in Subclause 15.2.3 under “Activity
    Execution”:
    “The execution of an Activity with no streaming Parameters completes when it has no nodes executing and no nodes
    enabled for execution, or when it is explicitly terminated using an ActivityFinalNode (see sub clause 15.3). The
    execution of an Activity with streaming input Parameters shall not terminate until the cumulative number of values
    posted to each of those input Parameters (by the invoker of the Activity) is at least equal to the Parametermultiplicity
    lower bound. The execution of an Activity with streaming output Parameters shall not terminate until the cumulative
    number of values posted to each of those output Parameters (by the Activity itself) is at least equal to the Parameter
    multiplicity lower bound.”
    A StateMachine that does not reach a final state simply does not terminate (unless it is terminated by an explicit
    external action, such as the destruction of its context object).
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Enumeration Literal

  • Key: UML24-42
  • Legacy Issue Number: 15107
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    EnumerationLiteral specializes InstanceSpecification, which specializes PackageableElement, which inturn specializes NamedElement

    This allows enum lterals to be owned by packages and have visibility, both of which do not make a lot of sense.

    is it another case of unintended inheritance?

    Another note: does it make sense to couple the capabilities of having a 'name' and 'visibilty', as given by NamedElement?

  • Reported: UML 2.3 — Fri, 15 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    There is another related problem. The derivation of EnumerationLiteral::/classifier is simply “enumeration”,
    but EnumerationLiteral::/classifier is [1..1] and EnumerationLiteral::enumeration is [0..1]. Creating a literal
    in a package and then asking for its classifier would cause some kind of unpleasant run-type exception.
    Since an EnumerationLiteral surely must be owned by an Enumeration, fix this by changing the multiplicity
    of EnumerationLiteral::enumeration to [1..1].
    As for the visibility, unless we change the metamodel we are stuck with it. Indeed, the constraint namespace_
    needs_visibility forces the visibility to be present.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Lack of graphical example of multi-element Dependency Notation

  • Key: UML24-40
  • Legacy Issue Number: 15047
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The Notation part of section 7.3.12 includes the following text but no graphical example. Furthermore the text seems less than clear (for example whether there must be a ‘junction’ (and whether shown as a point or a line) and whether each arrow entering the junction is required to have its own (open?) arrow head.

    I think that as a result of this few, if any, tools support this notation.

    “ It is possible to have a set of elements for the client or supplier. In this case, one or more arrows with their tails on the clients are connected to the tails of one or more arrows with their heads on the suppliers. A small dot can be placed on the junction if desired. A note on the dependency should be attached at the junction point.”

  • Reported: UML 2.3 — Wed, 10 Feb 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 12511

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Poor example of Dependency notation

  • Key: UML24-39
  • Legacy Issue Number: 15046
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure 7.37 shows an example of Dependency with <<dependencyName>> in guillemets.

    The Notation text above it states:” The arrow may be labeled with an optional stereotype and an optional name.” However surely the name of the Dependency itself should not be in guillemets – only that of the stereotype.

    Note that (subclasses of) Dependency are notated using a keyword instead of a stereotype so this should also be allowed for in the text.

    Proposed resolution: the Figure should be revised to show the dependencyName not in guillemets and possibly with a stereotype name in guillemets.

  • Reported: UML 2.3 — Wed, 10 Feb 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The corresponding figure in UML 2.5 is Figure 7.18. The proposed resolution is accepted.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 7.15

  • Key: UML24-41
  • Legacy Issue Number: 15056
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    There are non-derived properties at both ends - clientDependency and supplierDependency.

    One association is non-navigable, that means supplierDependency is owned by Association, but what does it mean in UML metamodel implementation? How it should be implemented?

    Eclipse has no associations at all, we (MD) simply added this property into NamedElement, but not serializing it into XMI.

    I would suggest to make this property derived or remove at all (if it is not serialized, it does not affect backward compatibility).

  • Reported: UML 2.3 — Thu, 18 Feb 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Regarding the implementation of supplierDependency as an owned end of an Association, the specification
    does not give implementations, but in the metamodels, it means the supplierDependency property is owned
    by the corresponding association between NamedElement and Dependency (the one with supplier on the
    other end). One-way associations in UML are modeled this way.
    Make NamedElement::clientDependency derived to avoid modifying the client.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The containment between Activity and StructuredActivityNode has one end redefining and the other subsetting

  • Key: UML24-35
  • Legacy Issue Number: 14994
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The containment between Activity and StructuredActivityNode has one end redefining (wrong) and the other subsetting (right). Because redefining and subsetting should be symmetric, this means that both ends are both redefining and subsetting. This is clearly wrong, because it would mean that all nodes and groups are StructuredActivityNodes. The

    {redefines activity, redefines inactivity}

    should be turned into subsetting.

  • Reported: UML 2.3 — Wed, 20 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue is incorrect. The redefinition is necessary, per the revisions made for UML/MOF/XMI 2.4.1.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2: property redefinitions should be symmetric across associations

  • Key: UML24-34
  • Legacy Issue Number: 14993
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    When one end of an association is redefined in the metamodel, the other end should be redefined as well. Otherwise the semantics are ill-defined.

  • Reported: UML 2.3 — Wed, 20 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issue 14977 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Expansion nodes using all the tokens in them as a single collection

  • Key: UML24-33
  • Legacy Issue Number: 14991
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    UML expansion regions currently treat each input as a collection, rather
    than all the inputs as members of a single collection, as the execution
    engine currently assumes. The description of Expansion Region says
    "Each input is a collection of values. If there are multiple inputs,
    each of them must hold the same kind of collection, although the types
    of the elements in the different collections may vary. The expansion
    region is executed once for each element (or position) in the input
    collection."

    If it is decided that the execution engine should not reflect the above
    semantics, then UML needs an additional attribute on ExpansionRegion to
    indicate whether the individual tokens of the input and out expansion
    nodes are taken as collections, or whether all the tokens in the nodes
    are taken as one collection. In ExecUML this attribute value would
    always be for the second option.

  • Reported: FUML 1.0b2 — Tue, 19 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue is obsolete. The specification of the semantics of ExpansionRegions in the UML 2.5 beta specification, in
    Subclause 16.12.3, covers this.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Subsetting clauses should show the subsetted property fully qualified.

  • Key: UML24-36
  • Legacy Issue Number: 14995
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In addition to the current notation:

    {subsets activity, subsets inActivity}

    Add a notation where subsetted/redefined properties can be qualified by their owning classifier, i.e.:

    {subsets ActivityNode::activity, subsets ActivityGroup::inActivity}

    And use this notation throughout the metamodel.

    This would make it clear where to look for the subsetted/redefined properties when trying to understand the spec.

  • Reported: UML 2.3 — Wed, 20 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The qualified names from the metamodel are now used correctly throughout the generated definitions. Make
    clear that this is allowed in the notation for Property. Do the same for Operation

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of the AddVariableValueAction

  • Key: UML23-145
  • Legacy Issue Number: 14027
  • Status: closed  
  • Source: European Software Institute (ESI -Tecnalia) ( Aitor Aldazabal)
  • Summary:

    In the Semantics of the AddVariableValueAction there is a line stating: "If isReplaceAll is false and the variable is unordered and non-unique, then adding an existing value has no effect." I find this statement in correct and in conflict with the semantics defined in multiplicity element. multiplicityElement.ordered -> Specifies whether the values are inserted in a certain position which can be identified by an Integer. This has no influence whatsoever on WHAT values can be added to a variable. multiplicityElement.unique -> An instance (of any type) cannot appear more than once in the collection of values. addVariableValueAction.isReplaceAll -> Specifies if all the previous values are removed before inserting the new ones. This does have influence on WHAT values can be added to a variable. Therefore if the addVariableValueAction is true then the input collection only needs to be evaluated. Else the input collection and the existing values need to be cheked. If the variable IS unique then it must be ensured that the add operation does not put the same instance more than once in the variable. This means that input collection will be merged with the existing values collection (empty collection if isReplaceAll==true) and then the repeated isntances will be removed. If the variable IS NOT unique then there is no need to check anything. Having repeated values in an unordered collection might have sense, for example to execute an algorithm to retrieve the number of times a user has logged in.

  • Reported: UML 2.2 — Wed, 24 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3b1
  • Disposition Summary:

    duplicate of issue # 8972

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errros with some "subsets" and redefines" where the contexts of subsetting/redefintion do not conform

  • Key: UML24-15
  • Legacy Issue Number: 14634
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    a) StructuredActivities::StructuredActivityNode (specializes FundamentalActivities::ActivityGroup) with the following errors:
    StructuredActivities::StructuredActivityNode::activity redefines StructuredActivities::ActivityGroup::inActivity
    StructuredActivities::StructuredActivityNode::node subsets StructuredActivities::ActivityGroup::containedNode

    b) IntermediateActivities::Activity (does not specialize any other class), with the following errors
    IntermediateActivities::Activity::group subsets Kernel::Element::ownedElement (notice that IntermediateActivities::Activity::partition subsets IntermediateActivities::Activity::group)

    c) IntermediateActivities::ActivityGroup (does not specialize any other class), with the following errors
    IntermediateActivities::ActivityGroup::inActivity subsets Kernel::Element::owner

    d) IntermediateActivities::ActivityPartition (specializes IntermediateActivities::ActivityGroup), with the following errors
    IntermediateActivities::ActivityPartition::subpartition subsets FundamentalActivities::ActivityGroup::subgroup
    IntermediateActivities::ActivityPartition::superPartition subsets FundamentalActivities::ActivityGroup::superGroup (also notice the capitaliation diff between subpartitiion and superPartiion)

    e) CompleteActivities::InterruptibleActivityRegion (specializes BasicActivities::ActivityGroup), with the following errors
    CompleteActivities::InterruptibleActivityRegion::node subsets CompleteActivities::ActivityGroup::containedNode

    f) Interfaces::Property (specializes Kernel::StructuralFeature), with the following errors
    Interfaces::Property::interface subsets Kernel::A_attribute_classifier::classifier

      • Fixes for those require fixing the spec and metamodel
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    These problems are a consequence of improper understanding and documentation of package merge.
    a). The problem is caused because StructuredActivities::StructuredActivityNode inherits from FundamentalActivities::ActivityGroup, not StructuredActivities::ActivityGroup. Although according to the text the latter does not exist, it is actually present in the UML 2.3 metamodel. (See also 15264). The resolution is to inherit from the local ActivityGroup. Researching this also shows that the spec document is already quite seriously adrift from the metamodel. Although this will be fixed in UML 2.5, this resolution takes some steps to fix it.
    b) The problem is caused because IntermediateActivities::Activity has no base class. The resolution is to remove the subset assertion from IntermediateActivities::Activity::group. Since the subset is correctly declared in FundamentalActivities, it is reintroduced by the merge.
    c) The problem and resolution are analogous to (b).
    d) The problem is that the subsetted properties are those in FundamentalActivities, not those in IntermediateActivities. This is like (a).
    e) The problem is that InterruptableActivityRegion inherits from BasicActivities::ActivityGroup, not CompleteActivities::ActivityGroup. We make it inherit from the latter.
    f) The problem is that the Property defined in Interfaces is not related to Classifier, so there is no /attribute association to subset. We create a local Classifier and copy down the association.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Attributes without a type

  • Key: UML24-14
  • Legacy Issue Number: 14633
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Profiles::ExtensionEnd::lower is not typed (should have been of type Integer)

      • This fix is only in the metamodel
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    As suggested, set the type of „lower? to Integer

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Events referred to by OccurrenceSpecifications should be optional

  • Key: UML24-10
  • Legacy Issue Number: 14629
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In UML 2, every OccurrenceSpecification must be associated with an Event. The Event in turn should have a name and an owning package. But in general, drawing an interaction diagram does not specify a name or owner for the Events associated with the OccurrenceSpecifications.

    This means that conforming tools have to invent Events including their names and owners for all OccurrenceSpecifications in an Interaction, even though these objects have no relevance to the model. This simply consumes memory footprint without providing any user value.

    If people want to model Events, that is fine; if they wish to associate OccurrenceSpecifications with them that is fine too; what is not fine is forcing the existence of these spurious objects. Hence the multiplicity of OccurrenceSpecification.event and its redefinitions should be changed to 0..1.

  • Reported: UML 2.3 — Fri, 6 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The Events that are only defined for Interactions are superfluous and is removed. The necessary information is in the Signal or Operation designated by the signature property of Message together with the MessageKind and MessageSort properties.
    In UML 2.3 the signature attribute is derived, in this revision it is changed to non-derived.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Associations with same name that live in different packages violate unique name constraint

  • Key: UML24-13
  • Legacy Issue Number: 14632
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Some associations that have the same name, but exist in different packages in the unmerged model, show up together in the merged model violating the unique name constraint

    BasicActivities::A_outgoing_source (Figure 12.5) and BehaviorStateMachines::A_outgoing_source (Figure 15.2).
    BasicActivities::A_incoming_target (Figure 12.5) and BehaviorStateMachines::A_incoming_target(Figure 15.2).
    BasicComponents::A_realization_abstraction (Figure 8.2) and AuxilliaryConstructs::InformationFlow::A_realization_abstraction (Figure 17.2)

    One way to fix that is to rename the associations to avoid the name collission, for example:

    BasicActivities::A_outgoing_source_node and BehaviorStateMachines::A_outgoing_source_vertex
    BasicActivities::A_incoming_target_node and BehaviorStateMachines::A_incoming_target_vertex
    BasicComponents::A_realization_abstraction_component (Figure 8.2) and AuxilliaryConstructs::InformationFlow::A_realization_abstraction_flow (Figure 17.2)

      • This fix affects the respective figures to show the non-default association names explicitly
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Agree to the suggestion given in the issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

All enumertion literals in the model have their "classifier" collections empty

  • Key: UML24-12
  • Legacy Issue Number: 14631
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    All enumertion literals in the model have their "classifier" collections empty (i.e do not contain the corresponding enumertion)

    This issue also existed in UML 2.1.1. To fix, I can add the enumeration to the "classifier" collection of the literals. But, shouldn't EnumertionLiteral have redefined "classifier" and made it derived from "enumeration" association end?

    **This is a metamodel only fix

  • Reported: UML 2.3 — Wed, 18 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The „classifier? association is inherited by EnumerationLiteral from InstanceSpecification in the UML spec, not in the MOF spec, which the UML metamodel is an instance of. Therefore, the enumeration literals in UML should not have this property.
    However, in the UML spec, an enumeration literal?s classifier should always be set to the enumeration owning it. Therefore, „classifier? should be redefined to be a derived association end that gets it value from the „enumeration? property of enumeration literal, which should also be made non-optional, since an enumeration should not be owned by anything other than an enumeration.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Constraint [3] on TestIdentityAction is incorrect

  • Key: UML24-4
  • Legacy Issue Number: 14570
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: UML Superstructure (formal/09-02-02)

    Subclause: 11.3.49 TestIdentityAction

    Constraint [3] for TestIdentityAction is:

    [3] The type of the result is Boolean.

    self.result.type.oclIsTypeOf(Boolean)

    While the English statement expresses the correct intent, the OCL is wrong. As written, the OCL requires that the type of the object referenced by the type property of the OutputPin be Boolean. But this is, of course, impossible, since the type of OutputPin::type is the metaclass Type, and any value for this property must be for an instance of a concrete subclass of type, such as Classifier or PrimitiveType. Boolean, on the other hand, is represented as an instance of the metaclass PrimitiveType. That is, the OCL for this constraint is confusing metalevels.

    The OCL should really be something like:

    self.result.type = PrimitiveType instance representing Boolean

    However, unless some sort of standard way to reference the M1 instance representing Boolean within the UML metamodel, it is unclear how to formally write “PrimitiveType instance representing Boolean”.

  • Reported: UML 2.3 — Fri, 16 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Constraint [1] for WriteStructuralFeatureAction is incorrect

  • Key: UML24-3
  • Legacy Issue Number: 14569
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: UML Superstructure (formal/09-02-02)

    Subclause: 11.3.55

    The OCL for constraint [1] of WriteStructuralFeatureAction incorrectly constraints the type of the value pin of the action to be the featuring classifier of the structural feature being written to. The type of the value should actually be the same as the type of the structural feature. It is the object pin which should be constrained to have a featuring classifier as its type – but this constraint is own the parent StructuralFeatureAction class, not on WriteStructuralFeatureAction itself. The correct OCL is:

    self.value->notEmpty() implies self.value.type = self.structuralFeature.type

    (The possibility of self.value being empty is due to the resolution of Issue 9870 in UML 2.3.)

  • Reported: UML 2.3 — Fri, 16 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 - derivation for DeploymentTarget.deployedElement is invalid

  • Key: UML24-7
  • Legacy Issue Number: 14621
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    According to 10.3.6:

    context DeploymentTarget::deployedElement derive: ((self.deployment->collect(deployedArtifact))>collect(manifestation))>collect(utilizedElement)

    But self.deployment->collect(deployedArtifact) gives a collection of DeployedArtifact, not of Artifact; therefore the call to manifestation is invalid. To make it correct from a type point of view, there needs to be an additional select to pick the DeployedArtifacts that are actually Artifacts.

    While we are at it, it is highly inappropriate to have a subclass of DeployedArtifact called Artifact: the names imply the reverse of the inheritance hierarchy.

  • Reported: UML 2.3 — Wed, 11 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

UML2 - non-unique association names in L3.merged.cmof

  • Key: UML24-6
  • Legacy Issue Number: 14613
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    I think the rules say that associations should be uniquely named in a package. L3.merged has three non-unique association names:

    A_outgoing_source

    A_realization_abstraction

    A_templateParameter_parameteredElement

  • Reported: UML 2.3 — Wed, 4 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    See issues 14287 and 14632 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Some owned operations with OCL expression bodies but without their "isQuery" set to "true"

  • Key: UML24-11
  • Legacy Issue Number: 14630
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    A body condition is specified for operation '<Operation> ConnectableElement::end () : ConnectorEnd [0..*]', but it is not a query.
    A body condition is specified for operation '<Operation> Vertex::incoming () : Transition [0..*]', but it is not a query.
    A body condition is specified for operation '<Operation> Vertex::outgoing () : Transition [0..*]', but it is not a query.

    **This is a metamodel only fix

  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    All additional operations in the UML metamodel are queries and as such must be marked with isQuery = true in the metamodel

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 - definition of Property.opposite is wrong

  • Key: UML24-8
  • Legacy Issue Number: 14626
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Currently the spec says:

    If this property is owned by a class associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end.

    opposite = if owningAssociation->isEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)>any() in if otherEnd.owningAssociation>isEmpty() then otherEnd else Set{} endif else Set {} endif

    This is wrong. The opposite should be calculated properly whatever the property is owned by. It should say “if the property is an association end of a binary association, opposite gives the other end”.

  • Reported: UML 2.3 — Fri, 13 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Parameter type of MultiplicityElement::includesMultiplicity()

  • Key: UML24-5
  • Legacy Issue Number: 14580
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Christopher McClure)
  • Summary:

    In the UML Infrastructure XMI, the type of Core::Abstractions::Multiplicities::MultiplicityElement::includesMultiplicity() parameter M is Core::Basic::MultiplicityElement. The type of M should be Core::Abstractions::Multiplicities::MultiplicityElement to keep Abstractions independent of Basic.

  • Reported: UML 2.3 — Tue, 27 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

UML2: Incomplete definition for Activity.structuredNode

  • Key: UML24-9
  • Legacy Issue Number: 14627
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Currently the sentence is incomplete:

    /structuredNode : StructuredActivityNode [0..*] Top-level structured nodes in the activity. Subsets

    It should subset node and group (according to the diagram).

  • Reported: UML 2.3 — Fri, 13 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What is "top-tier packages of the UML metamodel"?

  • Key: UML23-143
  • Legacy Issue Number: 17370
  • Status: closed  
  • Source: aol.com ( Brian Book)
  • Summary:

    Under Compliance Levels, the first paragraph following the level descriptions is confusing, since it references the terms "top-tier" and "second-tier" packages without ever defining what those means.
    For me, this entire paragraph is meaningless as a result.

  • Reported: UML 2.2 — Wed, 16 May 2012 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Names of ownedEnds that were there in UML 2.1.1 are missing in UML 2.2

  • Key: UML23-125
  • Legacy Issue Number: 14355
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    The MOF 2.0 Specification section 12.4 states that "Names are required for all Types and Properties". We should ensure that all Properties in the UML xmi files have names, preferably the same as the ones that were already there in UML 2.1.1 (this is a regression). An example is:

    " Classes-Interfaces-A_interface_ownedAttribute-_ownedEnd.0" in Superstructure.xmi (2.3) and " Classes-Interfaces-A_interface_ownedAttribute-_ownedEnd.0" in Superstructure.cmof (2.2) have no names. But " Classes-Interfaces-A_interface_ownedAttribute-interface" in Superstructure.cmof (2.1.1) has names.

  • Reported: UML 2.2 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The UML 2.1.1 XMI files are fully compliant with the quoted constraint that "Names are required for all Types and Properties". The UML 2.3 XMI files; however, no longer have names for several association end properties (298 in the in Superstructure.xmi; 55 in the Infrastructure.xmi). Most of these association end properties are in fact owned ends of their respective associations. These ownedEnds are MOF Properties that had names in UML 2.1.1. We consider this to be a regression, and we are to repair all such ownedEnds by restauring their name according to the naming convention specified in clause 6.4.2 that was used to name the corresponding association.
    In addition, we will ensure that there are no other Types or Properties that have no name. In Superstructure.xmi (2.3), there are 5 Associations which also must be given names. This is an XMI-only change.
    The OCL query used to find associations with unnamed association ends using RSA 7.5.3 & the RSA-proprietary *.emx representation of the infrastructure & superstructure metamodels is the following:
    let As : Collection(Association) = self.allOwnedElements()
    ->select(oclIsKindOf(Association)).oclAsType(Association) in
    As->select(a|a.member->exists(name->isEmpty()))
    ->sortedBy(qualifiedName).qualifiedName
    The OCL query used to report unnamed associations using RSA 7.5.3 & the RSA-proprietary *.emx representation of the infrastructure & superstructure metamodels is the following:
    let As : Collection(Association) = self.allOwnedElements()
    ->select(oclIsKindOf(Association)).oclAsType(Association) in
    As->select(a|a.name->isEmpty())->collect(a|Tuple

    { pkg=a.namespace.qualifiedName, end1_type=a.member->asSequence()->at(1).oclAsType(Property).type.name, end1_name=a.member->asSequence()->at(1).oclAsType(Property).name, end2_type=a.member->asSequence()->at(2).oclAsType(Property).type.name, end2_name=a.member->asSequence()->at(2).oclAsType(Property).name}

    )

    The OCL query used to verify that all occurrences of unnamed association ends are in fact owned ends of their associations using RSA 7.5.3 & the RSA-proprietary *.emx representation of the infrastructure & superstructure metamodels is the following:
    let As : Collection(Association) = self.allOwnedElements()->select(oclIsKindOf(Association)).oclAsType(Association) in
    As->select(a|a.member->exists(name->isEmpty()))
    >forAll(a|a.member>one(m|m.name->isEmpty() and
    m.oclAsType(Property).association->notEmpty()))

  • Updated: Fri, 6 Mar 2015 20:58 GMT

notation of objet flow <> and <>

  • Key: UML23-127
  • Legacy Issue Number: 14431
  • Status: closed  
  • Source: Teuchos ( Samuel Rochet)
  • Summary:

    Description:

    Notation of ObjectFlow "selection" and "transformation" as a note symbole does not specifiy the content of the note relatively to these behaviors.

    In exemples figures 12.75 and 12.112 this note contains OCL constraints or free text.

    It could be usefull to specify what needs to be displayed. For exemple :

    • if the selection/transformation is an OpaqueBehavior then the body of the OpaqueBehavior is dislayed in the note
    • if the selection/transformation is another Behavior then the name of the Behavior is displayed in the note

    Note that same problem occurs for ObjectNode selection

  • Reported: UML 2.2 — Thu, 24 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This issue is obsolete. The UML 2.5 specification, in subclause 15.2.4, at the end of the paragraph describing the
    selection and transformation Behavior notation, has the sentence: “The body of the note symbol may either contain
    a textual representation of the Behavior (e.g., the body of an OpaqueBehavior) or the name of a Behavior that is not
    represented textually.”
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.3 draft, 11.3.1 - AcceptCallAction

  • Key: UML23-126
  • Legacy Issue Number: 14429
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The text of the description is contradictory. The first sentence says:

    “AcceptCallAction is an accept event action representing the receipt of a synchronous call request. ....”

    In the second paragraph it says:

    This action is for synchronous calls. If it is used to handle an asynchronous call, execution of the subsequent reply action will complete immediately with no effects.

    Although the description states twice that it is for the receipt of synchronous calls it then goes on to describe its use for asynchronous calls.

  • Reported: UML 2.2 — Tue, 22 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Accept call actions are intended to receive synchronous calls, however they will, indeed, also accept asynchronous calls, but, as already noted in the spec, no reply will be sent in such cases. The description could be better worded to make this clear without sounding contradictory.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Duplicate association in normative UML 2.3 superstructure file

  • Key: UML23-124
  • Legacy Issue Number: 14287
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    What state is UML 2.3 in with respect to filing issues?

    In particular, there is a duplicate association name in the Superstructure Library normative XMI file for UML 2.3 that was detected by my CMOF Import:

    Duplicate association in package: Logical View::UML::AuxiliaryConstructs::Templates: A_templateParameter_parameteredElement.
    Duplicate association in package: Logical View::UML::AuxiliaryConstructs::Templates: A_templateParameter_parameteredElement.

    I checked the XMI file and, yes, the association is duplicated

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This issue is covered by the resolution to 13330

    Revised Text:

    Disposition: Duplicate of 13330

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Infrastructure PAS Ballot Comments - comment 9

  • Key: UML23-123
  • Legacy Issue Number: 14286
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Part I, II, III GE This is a multipart standard, use of "Part I, II, III" make confusion. Delete Part III and Make others rewrite as clauses. 7. General Introduction, 10 Infrastructure Library, and renumber other clauses. Also, delete Part III page.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Agree to change word "Part" to "Sub Part" throughout document.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Infrastructure PAS Ballot Comments - comment 8

  • Key: UML23-122
  • Legacy Issue Number: 14285
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex E GE Acknowledgements are not normative specification.

    Leave them as OMG only document. Remove Annex E from ISO standard.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Acknowledgements are now in Section 6.3. However agree should be removed from ISO spec.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Infrastructure PAS Ballot Comments - comment 4

  • Key: UML23-118
  • Legacy Issue Number: 14281
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GE The following standard must be refer.

    • XMI ISO/IEC19503
    • MOF ISO/IEC19502 ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
      ISO/IEC 19503:2005 Information technology – XML Metadata Interchange (XMI)
  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Issue 14280 proposal adds the proper references for UML 2. The older versions of MOF/XMI and OCL are not compatible with UML 2.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Infrastructure PAS Ballot Comments - comment 3

  • Key: UML23-117
  • Legacy Issue Number: 14280
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GE The format of normative references doesn't meet ISO format.

    Write reference like as follow if you refer OMG's documents
    IEC Std Template, IEC, available at <http://www.iec.ch/tiss/templates.htm>

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    add references with full text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 20

  • Key: UML23-114
  • Legacy Issue Number: 14277
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Part I, II, III,, IV GE This is a multipart standard, use of "Part I, II, III, IV" make confusion. Delete unnecessary Part IV and Make others rewrite as clauses. 7. Structure, 12 Behavior, 19 Supplement and renumber other clauses.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Agree to change word "Part" to "Sub Part" throughout document.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 19

  • Key: UML23-113
  • Legacy Issue Number: 14276
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex K GE Acknowledgements are not normative specification. . Leave them as only OMG document but not ISO standard. Remove Annex K.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Acknowledgements are now in Section 6.5. Needs to be removed from ISO spec. remove section 6.5 from ISO spec and OMG spec for consistency.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Infrastructure PAS Ballot Comments - comment 7

  • Key: UML23-121
  • Legacy Issue Number: 14284
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex D GE This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as OMG only document.

    Remove Annex D from ISO standard.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolution:
    Agree, this annex is no longer in UML 2.3.
    Revised Text:

    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Infrastructure PAS Ballot Comments - comment 6

  • Key: UML23-120
  • Legacy Issue Number: 14283
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex C TH This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition.

    Remove Annex C or make it informative Annex.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Agreed, but Annex C is no longer in UML 2.3
    Revised Text:

    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Infrastructure PAS Ballot Comments - comment 2

  • Key: UML23-116
  • Legacy Issue Number: 14279
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GE ISO standard documents are described with "shall", "should" and "may".

    Define this standard with "shall", "should" and "may".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    specification uses RFC 2119 Terminology

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Infrastructure PAS Ballot Comments - comment 5

  • Key: UML23-119
  • Legacy Issue Number: 14282
  • Status: closed  
  • Source: Anonymous
  • Summary:

    4,5 GE There is no terms ,definitions and symbols.

    Remove the clause "4 Terms and definitions" and "5 Symbols".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolution:
    Leave section 4 for future revisions to add terms and definitions.
    Issue 14279 replaces section 5 with a new Notational Conventions section. see Issue 14279 (JP 2) resolution.
    Revised Text:

    Disposition: Duplicate of 14279

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Infrastructure PAS Ballot Comments - comment 1

  • Key: UML23-115
  • Legacy Issue Number: 14278
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Japan will approve this DIS if the TH comment will accept.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Revised Text:
    See resolution to OMG Issues 14283

    Disposition: Duplicate of 14283

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML type Real specification

  • Key: UML241-12
  • Legacy Issue Number: 16301
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

    Version 2.4 intruduces a new UML primitive type - Real.

    This information has not been mentioned on page 127 - 7.3.44.

    The package name (I suppose Kernel) has not been defined for LiteralReal - chapter 7.3.29 (page 95); table of contents (page II).

  • Reported: UML 2.4 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    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

Interface element - associations multiplicity not defined

  • Key: UML241-11
  • Legacy Issue Number: 16268
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

    On page 36, Figure 7.16 shows the content of Interface package. Interface element has associations to four other elements with multiplicity of *. Multiplicity information is not defined on page 89, where the association names for Interface element has been defined.

  • Reported: UML 2.4 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    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

Property::isID

  • Key: UML241-9
  • Legacy Issue Number: 16210
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Is there a semantic difference between markign an associationEnd with isID=true and putting an upper bound of "1" on its opposite end (i.e., a value of this end is related to a maximum of 1 value on the other end)?

    If there is no semantic difference, is Property::isID only useful for attributes that are not association ends (like primitive attributes that are typically not ends)?

  • Reported: UML 2.4 — Mon, 2 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Assume a classifier A has a property that is an association end typed by B, and assume its opposite end has the
    multiplicity 1..1.
    Even if this implies that, at any time, only one instance of A can be associated with a given instance of B, nothing
    stops this association from changing over time. Thus, a given instance of B cannot be used “a priori” for identifying
    an instance of A. So there is no redundancy with the semantics of Property::isID as suggested by the issue.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong package name on several Figures

  • Key: UML241-6
  • Legacy Issue Number: 16120
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Several Figures has wrong package name shown. In all cases package name should be "Core" instead of "Constructs":

    • Figure 7.3 - The Core packages
    • Part II, Figure 2 - The Core package contains the packages PrimitiveTypes, Abstractions, Basic, and Constructs...
    • Figure 9.1 - The Core package is owned by the InfrastructureLibrary pack...
    • Figure 10.1 - The Core package is owned by the InfrastructureLibrary package...
    • Figure 11.1 -The Core package is owned by the InfrastructureLibrary package...

    Also, the package name should be shown on the tab.

  • Reported: UML 2.4 — Tue, 19 Apr 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    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

Missing Namespace in Dependencies package definition?

  • Key: UML241-10
  • Legacy Issue Number: 16267
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

    On page 35, Figure 7.15 the Namespace element is described as Namespace from Dependencies package, but (on page 103) Namespace element is defined from Kernel package only.

  • Reported: UML 2.4 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    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

typo on page 46

  • Key: UML241-3
  • Legacy Issue Number: 16110
  • Status: closed  
  • Source: Anonymous
  • Summary:

    look at Page 46, there is a typo in the word "metaatribute" in the sentence:
    ...
    "AssociationEnd was a metaclass in prior UML, now demoted to a member of
    Association. The metaatribute targetScope"

  • Reported: UML 2.4 — Wed, 6 Apr 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    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

typo in new attribute name

  • Key: UML24-1
  • Legacy Issue Number: 14565
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    The new 2.3 spec contains typo (double i) in new attribute name:

    iisLocallyReentrant : Boolean = false

    In Subclause 12.3.2 Action, under Attributes.

  • Reported: UML 2.3 — Thu, 15 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML23-144
  • Legacy Issue Number: 8768
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Notation for navigable ends owned by an association. Figure 21 should include a notation for navigable ends owned by the association

  • Reported: RAS 2.2 — Thu, 5 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This was effectively resolved by the introduction of the "dot" notation in UML 2.1 for ends owned by end types.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CMOF missing several redefined property relationships

  • Key: UML24-2
  • Legacy Issue Number: 14566
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    Since CMOF does a PackageMerge of Infrastructure-Core-Basic with Infrastructure-Core-Constructs, the resulting metaclass Operation ends up having 'isOrdered', 'isUnique', 'type', 'lower' and 'upper' properties, which conflict with the names of properties it inherits, particularly from MultiplicityElement and TypedElement. This is illegal unless these properties explicitly have redefinedProperty relationships.

  • Reported: UML 2.3 — Thu, 15 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Setting Classes-Interfaces-Interface-ownedAttribute would fail to populate Classes-Kernel-Property-owner

  • Key: UML23-95
  • Legacy Issue Number: 14235
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    In Superstructure.xmi (2.3):

    Classes-Interfaces-Interface-ownedAttribute has a one-directional association to Classes-Kernel-Property and subsets Classes-Kernel-Namespace-ownedMember. Adding an instance of a merged Property to Interface-ownedAttribute would fail to populate the ‘owner’ or ‘namespace’ attributes of the Property (because the only slots are ‘class’ and ‘datatype’).

    This is inconsistent in 2 ways:

    1) The merged Property has the slots ‘class’ and ‘datatype’, but there is no slot for ‘interface’.

    2) Compare this to a merged Operation, which has ‘class’, ‘datatype’ as well as ‘interface’ (from Classes-Interfaces-Operation-interface). Also, Classes-Interfaces-Interface-ownedOperation has a bidirectional association with Classes-Interfaces-Operation-interface, which also feels at odds with Classes-Interfaces-Interface-ownedAttribute.

    3) Since Classes-Interfaces-Interface-ownedAttribute explicitly subsets ‘Classes-Kernel-Namespace-ownedMember’, we would expect that the association to ‘Classes-Kernel-NamedElement-namespace’ should produce a result. However since ‘namespace’ is a derived-union with no slots that accept an ‘Interface’, this remains empty (and consequently so does ‘owner’ even though the Property IS being owned by an Interface).

    I would like to suggest the following:

    1) Add a cmof:Class ‘Classes-Interfaces-Property’ to the package ‘Classes-Interfaces’ as an ‘ownedMember’ and change the ‘type’ of ‘Classes-Interfaces-Interface-ownedAttribute’ to ‘Classes-Interfaces-Property’.

    2) Add a cmof:Property ‘Classes-Interfaces-Property-interface’ as an ‘ownedAttribute’ of ‘Classes-Interfaces-Property’. This attribute should be 0..1 with the type ‘Classes-Interfaces-Interface’ and should subset ‘Classes-Kernel-RedefinableElement’, ‘Classes-Kernel-Feature-featuringClassifier’ and ‘Classes-Kernel-NamedElement-namespace’. Its’ association should be ‘Classes-Interfaces-A_interface_ownedAttribute’.

    3) Modify ‘Classes-Interfaces-A_interface_ownedAttribute’ to have the member ends be ‘Classes-Interfaces-Property-interface’ and ‘Classes-Interfaces-Interface-ownedAttribute’.

  • Reported: UML 2.2 — Fri, 28 Aug 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This inconsistency issue is substantiated as explained; the suggestion amounts to repairing Classes::Interfaces as a package merge extension of Classes::Kernel. In fact, the "copy-down" suggested in item (2) is implicitly shown in the fact that 'Property' like all of the other metaclasses defined in the Classes::Interfaces package are unqualified whereas the other metaclasses defined but not copied in this package are fully qualified.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect OCL in Infrastructure.xmi for 'Core-Constructs-Operation-isConsistentWith'

  • Key: UML23-94
  • Legacy Issue Number: 14228
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    The body of the ‘Core-Constructs-Operation-isConsistentWith’ Operation in Infrastructure.xmi uses an attribute called ‘formalParameter’, which does not exist in the metamodel:

    result = (redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.formalParameter.size() = op.formalParameter.size() and self.returnResult.size() = op.returnResult.size() and forAll(i | op.formalParameter[i].type.conformsTo(self.formalParameter[i].type)) and forAll(i | op.returnResult[i].type.conformsTo(self.returnResult[i].type))

    We should instead borrow the body from Superstructure.xmi which does not have that problem:

    result = (redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter.size() = op.ownedParameter.size() and forAll(i | op.ownedParameter[i].type.conformsTo(self.ownedParameter[i].type))

  • Reported: UML 2.2 — Thu, 27 Aug 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolve discrepancies for RedefinableElement amongst the following artifacts:

    • Infrastructure document (clause 11.4.4)
    • Superstructure document (clause 7.3.46)
    • Infrastructure XMI: Core::Constructs::RedefinableElement
    • Superstructure XMI: Classes::Kernel::RedefinableElement
      Resolve discrepancies for Operation::isConsistentWith amongst the following artifacts:
    • Infrastructure document (clauses 11.3.4 & 11.8.2)
    • Superstructure document (clause 7.3.36)
    • Infrastructure XMI: Core::Constructs::Operation
    • Superstructure XMI: Classes::Kernel::Operation
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 4

  • Key: UML23-99
  • Legacy Issue Number: 14261
  • Status: closed  
  • Source: Anonymous
  • Summary:

    JP4 3 GE The following standard must be refer.

    • XMI ISO/IEC19503
    • MOF ISO/IEC19502
    • OCL 2.0 ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
      ISO/IEC 19503:2005 Information technology – XML Metadata Interchange (XMI)
      OCL 2, OMG, available at
      <http://www.omg.org/spec/OCL/2.0/PDF>
  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Issue 14260 proposal adds the proper references for UML 2. The older versions of MOF/XMI and OCL are not compatible with UML 2.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 3

  • Key: UML23-98
  • Legacy Issue Number: 14260
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The format of normative references doesn't meet ISO format.

    Write reference like as follow if you refer OMG's documents
    IEC Std Template, IEC, available at <http://www.iec.ch/tiss/templates.htm>

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    add references with full text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Language unit of Usage

  • Key: UML23-93
  • Legacy Issue Number: 14220
  • Status: closed  
  • Source: No company ( Eduardo Palermo)
  • Summary:

    On C.1 StandardProfileL2 the stereotype «create» is on language unit Dependencies, and «responsability» is on language unit Classes::Kernel. I think both belong to language unit Classes::Dependencies

  • Reported: UML 2.2 — Tue, 25 Aug 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Documentation of merge increments in the superstructure

  • Key: UML23-92
  • Legacy Issue Number: 14216
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: UML Superstructure v2.2 (formal/09-02-02)

    In the superstructure specification, when a class is intended primarily as an increment to be merged with some other “base” class, this is usually documented by listing the “base” class under the Generalization section, with the annotation “(merge increment)”. While such documentation of merge intent is extremely useful for the understanding of the reader, putting this documentation under the “Generalization” section is confusing, since the way package merge is now used in the superstructure abstract syntax model has nothing to do with generalization. Further, this documentation convention is not always consistently applied, especially when the class also has “real” generalizations.

    So, the specification should retain documentation for merge increments, but the overall approach for doing this should be revised and clarified, and then this approach should be applied consistently across the specification.

  • Reported: UML 2.2 — Mon, 24 Aug 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Japan Superstructure PAS Ballot Comments - comment 2

  • Key: UML23-97
  • Legacy Issue Number: 14259
  • Status: closed  
  • Source: Anonymous
  • Summary:

    ISO standard documents are described with "shall", "should" and "may".

    Define this standard with "shall", "should" and "may".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    specification uses RFC 2119 Terminology

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 1

  • Key: UML23-96
  • Legacy Issue Number: 14258
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Japan will approve this DIS if the TH comments will accept.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The TH comments (OMG Issues 14271 - JP14, 14274 - JP17) were accepted in the approved resolutions for UML 2.3. See resolutions to OMG Issues 14271 and 14274
    Revised Text:

    Disposition: Duplicate of 14271 and 14274

  • Updated: Fri, 6 Mar 2015 20:58 GMT

is composite, but does not subset ownedElement

  • Key: UML24-23
  • Legacy Issue Number: 14926
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    I tried to collect critical metamodel implementation issues we have in our tool.

    Critical means that every time we must do changes in metamodel to be able to implement it.

    I believe, Eclipse UML2 implementation has exactly same issues.

    Issues may be devided into such groups:

    1. Properties which are composite, but do not subset ownedElement. Our solution - subset ownedElement

    2. Properties which are composite and subset other composite non-derived property. Our solution - make it non-composite as element can't be owned in two places

    I'm not sure all issues are reported, could someone help me manage that and check if all these are really must-be-fixed bugs?

    Most of these issues may be verified by running automatic script on metamodel file.

    See details below:

    1) is composite, but does not subset ownedElement

    Duration::expr:ValueSpecification [0..] is composite, but not ownedElement
    LinkEndData::qualifier:QualifierValue [0..*] is composite, but not ownedElement
    LinkAction::endData:LinkEndData [2..*] is composite, but not ownedElement
    TimeExpression::expr:ValueSpecification [0..] is composite, but not ownedElement
    ValuePin::value:ValueSpecification [1] is composite, but not ownedElement
    State::deferrableTrigger:Trigger [0..*] is composite, but not ownedElement
    CreateLinkAction::endData:LinkEndCreationData [2..*] is composite, but not ownedElement
    StructuredActivityNode::edge:ActivityEdge [0..*] is composite, but not ownedElement
    ValueSpecificationAction::value:ValueSpecification [1] is composite, but not ownedElement
    AcceptEventAction::trigger:Trigger [1] is composite, but not ownedElement
    DestroyLinkAction::endData:LinkEndDestructionData [2..*] is composite, but not ownedElement
    Stereotype::icon:Image [0..*] is composite, but not ownedElement
    TimeEvent::when:TimeExpression [1] is composite, but not ownedElement
    InteractionUse::argument:Action [0..*] is composite, but not ownedElement
    SequenceNode::executableNode:ExecutableNode [0..*] is composite, but not ownedElement
    Transition::trigger:Trigger [0..*] is composite, but not ownedElement
    StructuredActivityNode::node:ActivityNode [0..*] is composite, but not ownedElement

  • Reported: UML 2.3 — Thu, 7 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue affects the Model Interchange Working Group (MIWG).
    Issue 1 is accepted: All properties which are composite, are made to subset ownedElement.
    Issue 2 is not accepted. It is acceptable for a composition to subset another composition. This does not lead to an element being owned in two places; it leads to an element being owned in one place by two links.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

wrong Actor's constraint [1]"

  • Key: UML24-22
  • Legacy Issue Number: 14875
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Good point, it is clearly incorrect, as "ownedAttribute" is property of Class, not Classifier (Actor).
    Even more interesting, this is the only way to access attached associations (by checking owned properties), so I have no ideas how OCL can check attached associations when all properties are owned by association

  • Reported: UML 2.3 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 10780

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AcceptEventAction notation

  • Key: UML24-20
  • Legacy Issue Number: 14643
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    The Notation chapter of AcceptEventAction is very weak, there is no description where Event name or Signal name could be displayed.
    It says:
    "An accept event action is notated with a concave pentagon. A wait time action is notated with an hour glass. "

    There are some usage examples in “AcceptEventAction (as specialized)” on page 309 where signal names are inside AcceptEventAction symbol, but such notation is not described under Notation !

  • Reported: UML 2.3 — Tue, 17 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    This issue is obsolete. The description of the AcceptEventAction notation in the UML 2.5 beta specification, Subclause
    16.10.4, calls out the placement of names.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Some associations in the normative XMI has one memberEnd

  • Key: UML24-19
  • Legacy Issue Number: 14638
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    The problems regarding some associations with one memberEnd actually started in the "unmerged" model but show themselves in the "merged" model.

    In 2.3, we added copy-down merge increments for some associations, in particular we added:

    a- InternalStructures::A_feature_classifier (Figure 9.2) as a merge increment for Kernel::A_feature_featuringClassifier (Figure 7.10)
    b- BasicComponents::A_role_connectorEnd (Figure 8.3) as a merge increment for InternlStructures::A_end_role (Figure 9.3)
    c- BasicComponents::A_end_connector (Figure 8.3) as a merge increment for InternalStructures::A_end_connector (Figure 9.3)

    The problem in (a) and (b) is that the merge-increment association has a different name than the original association, thus the package merge algorithm could not match them by name and they ended up both in the merged model. Since the navigable ends of those associations still have similar names, they were matched and merged in their respective Classes but their "association" references were set to the merge-increment associations, leaving the original association with only one reference in their "memberEnd" collections.

    Trying to rename the merge increment associations in (a) and (b) similar to the original associations (by renaming the non-navigable ends and also switching the order of memberEnds references in (b)) and re-performing the package merge, the associations got matched up and only one association in each case ended up in the merged model, as expected. However, the merge algorithm could not merge the non-navigable ends of the merge increment associations with their corresponding navigable ends in the original associations (due to a bug in the algorithm implementation I think), which should have resulted in keeping only the navigable ends, so both ends showed up in the merged model and the "memberEnd" collections had 3 references. To fix that temporarily (until the bug is fixed), I manually deleted the extraneous non-navigable ends from the resulting associations in the merged model.

    **These fixes affect Figures 9.2 and 8.3 to show the names of the non-naviagle ends

    The problem in (c) is different. The two associations have similar names and matching navigable/non-navigable ends so no problem there. The problem is that the non-navigable end of the merge increment has wrong "aggregation" and "multiplicity". Currently, its "aggregation" is "None" and its multiplicity is *, where it should have had "Composite" and 1, similar to the original association end (the resulting merged end now has "Composte" and * which violates a constraint about composite ends having multiplicity more than 1). To fix that, I just had to put the "aggregation" and "multipclity" of the merge increment similar to the original.

  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    As suggested by the issue, for cases (a) and (b), both the original and the copy down association need to have the same association names, same role names and same role navigability/ownership, in order for package merge to merge them into “one” association in the target package.
    The problem in (c) is different. The two associations have similar names and matching navigable/non-navigable ends so no problem there. The problem is that the non-navigable end of the merge increment has wrong "aggregation" and "multiplicity". Currently, its "aggregation" is "None" and its multiplicity is *, where it should have had "Composite" and 1, similar to the original association end (the resulting merged end now has "Composte" and * which violates a constraint about composite ends having multiplicity more than 1). To fix that, the "aggregation" and "multiplicity" of the role in the merge increment association should be similar to the original.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Namespace collission due to package import

  • Key: UML24-18
  • Legacy Issue Number: 14637
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Package InfrastructureLibrary::Core::Abstractions::BehavioralFeatures contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Changeabilities contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Classifiers contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Comments contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Constraints contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Expressions contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Generalizations contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Instances contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Literals contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::MultiplicityExpressions contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Namespaces contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Ownerships contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Redefinitions contains two or more indistinguishable members named "<Class> Classifier."
    Package InfrastructureLibrary::Core::Abstractions::Relationships contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::StructuralFeatures contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Super contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::TypedElements contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Core::Abstractions::Visibilities contains two or more indistinguishable members named "<Class> Element."
    Package InfrastructureLibrary::Profiles contains two or more indistinguishable members named "<Class> Package."
    Package UML::Actions contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Actions::BasicActions contains two or more indistinguishable members named "<Class> BehavioralFeature."
    Package UML::Actions::CompleteActions contains two or more indistinguishable members named "<Class> OpaqueExpression."
    Package UML::Actions::IntermediateActions contains two or more indistinguishable members named "<Class> MultiplicityElement."
    Package UML::Actions::StructuredActions contains two or more indistinguishable members named "<Class> OutputPin."
    Package UML::Activities contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Activities::CompleteActivities contains two or more indistinguishable members named "<Class> OpaqueExpression."
    Package UML::Activities::IntermediateActivities contains two or more indistinguishable members named "<Class> OpaqueExpression."
    Package UML::AuxiliaryConstructs contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::AuxiliaryConstructs::InformationFlows contains two or more indistinguishable members named "<Class> Pin."
    Package UML::Classes contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Classes::Dependencies contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::CommonBehaviors contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Components contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Components::BasicComponents contains two or more indistinguishable members named "<Class> Property."
    Package UML::CompositeStructures contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::CompositeStructures::Ports contains two or more indistinguishable members named "<Class> Property."
    Package UML::Deployments contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Deployments::Artifacts contains two or more indistinguishable members named "<Class> NamedElement."
    Package UML::Interactions contains two or more indistinguishable members named "<Class> Classifier."
    Package UML::Interactions::BasicInteractions contains two or more indistinguishable members named "<Class> MultiplicityElement."
    Package UML::StateMachines contains two or more indistinguishable members named "<Class> Classifier."

      • Fixes for those require fixing the spec and metamodel
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Cycles in package imports

  • Key: UML24-17
  • Legacy Issue Number: 14636
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    "<Package> Actions" has one or more package import cycles involving "<Package> AuxiliaryConstructs, <Package> Classes, <Package> CommonBehaviors, <Package> Activities."
    "<Package> Components" has one or more package import cycles involving "<Package> AuxiliaryConstructs, <Package> Classes, <Package> CompositeStructures."
    "<Package> Deployments" has one or more package import cycles involving "<Package> AuxiliaryConstructs, <Package> Classes, <Package> CompositeStructures, <Package> Components."
    "<Package> Interactions" has one or more package import cycles involving "<Package> AuxiliaryConstructs, <Package> Classes, <Package> CommonBehaviors."
    "<Package> StateMachines" has one or more package import cycles involving "<Package> AuxiliaryConstructs, <Package> Classes, <Package> CommonBehaviors."

      • Fixes for those require fixing the spec and metamodel
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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

Errors with types of association ends not conforming to their subsetted ends

  • Key: UML24-16
  • Legacy Issue Number: 14635
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    The type of AuxiliaryConstructs::Templates::RedefinableTemplateSignature::classifier does not comform to the type of the subsetted end redefinitionContext : Classifier
    The type of Classes::Interfaces::InterfaceRealization::contract does not comform to the type of the subsetted end supplier : NamedElement
    The type of CompositeStructures::Ports::A_ownedPort_encapsulatedClassifier::encapsulatedClassifier does not comform to the type of the subsetted end encapsulatedClassifier : EncapsulatedClassifier
    The type of Activities::IntermediateActivities::Activity::group does not comform to the type of the subsetted end group : ActivityGroup
    The type of Activities::IntermediateActivities::ActivityGroup::inActivity does not comform to the type of the subsetted end inActivity : Activity
    The type of Activities::CompleteActivities::ActivityNode::inInterruptibleRegion does not comform to the type of the subsetted end inInterruptibleRegion : InterruptibleActivityRegion
    The type of Classes::Interfaces::Interface::ownedAttribute does not comform to the type of the subsetted end ownedAttribute : Property
    The type of CommonBehaviors::Communications::Class::ownedReception does not comform to the type of the subsetted end ownedReception : Reception
    The type of CommonBehaviors::Communications::Interface::ownedReception does not comform to the type of the subsetted end ownedReception : Reception
    The type of Components::BasicComponents::ComponentRealization::realizingClassifier does not comform to the type of the subsetted end realizingClassifier : Classifier
    The type of CompositeStructures::InternalStructures::A_ownedConnector_structuredClassifier::structuredClassifier does not comform to the type of the subsetted end structuredClassifier : StructuredClassifier
    The type of Activities::CompleteStructuredActivities::StructuredActivityNode::structuredNodeInput does not comform to the type of the subsetted end structuredNodeInput : InputPin
    The type of Activities::CompleteStructuredActivities::StructuredActivityNode::structuredNodeOutput does not comform to the type of the subsetted end structuredNodeOutput : OutputPin
    The type of Activities::IntermediateActivities::ActivityPartition::subpartition does not comform to the type of the subsetted end subpartition : ActivityPartition
    The type of Activities::IntermediateActivities::ActivityPartition::superPartition does not comform to the type of the subsetted end superPartition : ActivityPartition
    The type of Deployments::Artifacts::Manifestation::utilizedElement does not comform to the type of the subsetted end supplier : NamedElement

      • Fixes for those require fixing the spec and metamodel
  • Reported: UML 2.3 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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 constraint on stereotype associations

  • Key: UML24-28
  • Legacy Issue Number: 14961
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    18.3.3 Semantics contains the following:

    “Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is

    owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by

    the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than

    the other class/metaclass.”

    However this is not represented in a formal Constraint and the last sentence in particular is not relevant to associations between 2 stereotypes.

  • Reported: UML 2.3 — Tue, 12 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    The offending paragraph is actually in 18.3.6, not 18.3.3 as stated in the issue.
    There are two aspects to the resolution: rewording of the paragraph, and adding a formal constraint.
    The paragraph is clearly (through the repeated use of the word “opposite”) intended to convey that stereotypes can participate in binary associations. This is consistent with the corresponding limitation in MOF. The rewording recognizes this.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

remove BehavioredClassifier::ownedTrigger

  • Key: UML24-26
  • Legacy Issue Number: 14931
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    can someone explain what is the purpose of "ownedTriggers" in BehavioredClassifier (page 435 of UML 2.3 spec) and how it should be used?
    There is nothing in the spec about it. The description is : "References Trigger descriptions owned by a Classifier".

    If it is intended to be container (or filter) of event types which can be consumed by this classifier behaviors, maybe it should be derived (from all owned behaviors)?
    The samantics section talks about "event pool" of the object at runtime, is it related?

  • Reported: UML 2.3 — Fri, 8 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    In general, the event pool of an object holds events that may be dispatched to triggers of that object. However, those triggers are generally part of a state machine or activity related to the object (either as its type or as a classifier behavior of its type). The specification does not describe what the semantics of dispatching an event directly to an ownedTrigger is, since there is not response behavior associated with such triggers. And a trigger directly owned by a behaviored classifier cannot also be owned in the normal way by a state machine or activity.
    Indeed, it is not clear that owned triggers have any purpose in UML 2 as it stands, and their inclusion without any explicit semantics is confusing. Therefore, it is agreed that BehavioredClassifier::ownedTrigger should be removed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

lowered multiplicity

  • Key: UML24-25
  • Legacy Issue Number: 14929
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Redefined with lowered multiplicity. It is not possible to have correct Java implementation of that, as inherited class must have getter with same name which return type is not collection, but single element. We (and Eclipse) simply ignoring these redefinitions or adding constraint which checks value number in collection.

    OccurrenceSpecification::covered [1] redefines InteractionFragment::covered [0..*]
    Transition::redefinitionContext [1] redefines RedefinableElement::redefinitionContext [0..*]
    State::redefinitionContext [1] redefines RedefinableElement::redefinitionContext [0..*]
    StateInvariant::covered [1] redefines InteractionFragment::covered [0..*]
    Extension::ownedEnd [1] redefines Association::ownedEnd [0..*]
    Region::redefinitionContext [1] redefines RedefinableElement::redefinitionContext [0..*]

  • Reported: UML 2.3 — Fri, 8 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Merged with 6200

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue on generalization

  • Key: UML24-21
  • Legacy Issue Number: 14862
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    While looking over Use Cases for other changes, I realize that I’m not sure about how inheritance (generalization) works. It appears that only constraints and features are inherited. Features include structural and behavioral features, and structural features include associations.

    This seems to exclude dependencies and other directed relationships and other potentially named elements in the namespace.

    I must have something wrong, but this means that

    · include and extends are not inherited;

    · realizations are not inherited;

    · nested qualifiers are not inherited;

    · general dependencies are not inherited

  • Reported: UML 2.3 — Mon, 14 Dec 2009 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Clause 9 is clear that it is members that are inherited. Include and extend are members. Dependencies (including
    Realizations) are not inherited. Qualifiers are owned by Properties which are inherited.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

is composite and subsets not derived composite property:

  • Key: UML24-24
  • Legacy Issue Number: 14927
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    2) is composite and subsets not derived composite property:

    ProtocolTransition::preCondition:Constraint [0..]
    Profile::metaclassReference:ElementImport [0..*]
    Profile::metamodelReference:PackageImport [0..*]

    Transition::guard:Constraint [0..]
    ProtocolTransition::postCondition:Constraint [0..]
    Operation::postcondition:Constraint [0..*]
    Operation::precondition:Constraint [0..*]
    Behavior::precondition:Constraint [0..*]
    Operation::bodyCondition:Constraint [0..]
    Behavior::postcondition:Constraint [0..*]

  • Reported: UML 2.3 — Thu, 7 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    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 is vague about which Element should own Comments

  • Key: UML24-27
  • Legacy Issue Number: 14960
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    For example, if a comment appears on a Class diagram for a Package and is attached to one of the classes then should it be owned by the Class or the Package?

    What if there is no Package shown and it is attached to several Classes from multiple Packages?

  • Reported: UML 2.3 — Tue, 12 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.3: Errors in example serialization for Profiles in Chapter 18

  • Key: UML23-129
  • Legacy Issue Number: 14448
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    There are many errors in the example XMI serialization for the profile and the profile application and the xsd in section 18.3.6:

    The UML namespaces (in the definitions and the hrefs) refer to version 2.0 (and in some places inconsistently to 2.1) and should be correct for the current version

    The profile definition is missing a definition of a namespace and prefix for xmi

    The ownedMember tag should be packagedElement to be consistent with how superstructure is serialized.

    The isComposite, lower and upper tags are not valid in a superstructure serialization (and upper is not valid in an infrastructure serialization).

  • Reported: UML 2.2 — Mon, 5 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The examples are corrected to follow the rules. We remove the schema example altogether because it presupposes that we are publishing an XML Schema for UML, and we are not doing so. The text just preceding the schema example is incomprehensible and unnecessary so is deleted.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

errors in OCL statements of Additional Operations?

  • Key: UML23-128
  • Legacy Issue Number: 14439
  • Status: closed  
  • Source: University of Bayreuth ( Thomas Buchmann)
  • Summary:

    shouldn't the OCL statement for the Utility [1] return a collection: collect(dependency|dependency.supplier)

    instead of

    collect(dependency|dependency.client) ?

    and in the OCL statement for the Utility [2] shouldn't it be (classifier.clientDependency->...)

    instead of

    (classifier.supplierDependency->...) ?

    Please clarify.

  • Reported: UML 2.2 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Value of a Property

  • Key: UML23-132
  • Legacy Issue Number: 14560
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    In several places of §7.3.44 one speaks about the value(s) of a property. However, there is no property on the Property meta-class that map to this value, except the defaultValue property. On the other hand, it is stated that "If a property is derived, then its value or values can be computed from other information " but nothing make mandatory the specification of how this value is computed.

    "isDerived", "defaultValue" and the missing "valueSpecification" property of the Property meta-class cannot be totaly independent.

    Suggested resolution :

    • Add an optional valueSpecification property to the Property meta-class with the type ValueSpecification
    • Change defaultValue to be derived according to the following constraint: {OCL}

      defaultValue = if self.isDerived then self.valueSpecification else NULL endif

  • Reported: UML 2.2 — Wed, 14 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    There is some confusion in the issue. In the UML 2.5 text it is made clear that the phrase “value of a property”
    describes the state of instances of the classifier. The property has no value except in the context of an instance.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface-redefinedInterface should subset Classifier-redefinedClassifier

  • Key: UML23-131
  • Legacy Issue Number: 14554
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    In UML 2.3 and earlier, Interface-redefinedInterface subsets RedefinableElement-redefinedElement. However, since Interface specializes Classifier, the property should subset Classifier-redefinedClassifier instead, which will in turn subset RedefinableElement-redefinedElement

  • Reported: UML 2.2 — Mon, 12 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    It is legal for Interface::redefinedInterface to have a subset relation with Classifier::redefinedClassifier, even if the latter is not a derived union. Such a relation simply means that, even though there are two distinct associations, any redefinedInterface must also be a redefinedClassifier – but that there may be redefinedClassifiers (of an interface) that are not redefinedInterfaces.
    Of course, if it is desired that an interface only be able to redefine another interface, then the simplest thing to do would be to just add a constraint to Interface that all redefinedClassifiers must be interfaces. Actually, the proper way to do this is to redefined the OCL operation RedefinableElement::isConsistentWith.
    On the other hand, if we make redefinedClassifier a derived union, then we also need to add non-derived subsetting associations to all the subclasses of Classifier, not just Interface. And this would result in a definite semantics change. For example, right now a class can, seemingly, realize any classifier.
    RedefinableElement::isConsistentWith is false by default, and needs to be “must be overridden for subclasses of RedefinableElement to define the consistency conditions”. Class and Interface would therefore need to override isConsistentWith in order to define the meaning of redefinition of specific kinds of classifiers. Redefinition of classifiers was introduced in order to allow behaviors, which are Classifiers, to redefine other behaviors.
    This is possibly a bigger problem. The model for redefinable elements sets up a relatively simple but quite flexible mechanism for establishing the consistency of the redefinition of various kinds of elements. But this simply has not been used properly in the specification of most kinds of redefinable elements. However, section 7.3.24 does have a simpler error, redefinedInterface cannot subset Element::redefinedElement since it doesn?t exist. See figure 7.9 and figure 7.16. Rather than address the meaning of interface redefinition in this resolution, the error should be corrected so that at least the redefineInterface contributes to a valid subset as suggested in the issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

'false' is not a member of VisibilityKind

  • Key: UML23-142
  • Legacy Issue Number: 15281
  • Status: closed  
  • Source: yahoo.com ( Scott Forbes)
  • Summary:

    under Attributes -
    visibility: VisibilityKind [1]
    Default value is false.

    'false' is not a member of VisibilityKind. I assume 'private' is intended, though I notice some tools have gone for 'public'.

  • Reported: UML 2.2 — Mon, 7 Jun 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Guard of activity edge should be optional

  • Key: UML23-141
  • Legacy Issue Number: 15251
  • Status: closed  
  • Source: IBM ( Mattias Mohlin)
  • Summary:

    The standard specifies the guard of an activity edge like this:

    guard : ValueSpecification [1..1] = true

    Hence it is required that every activity edge has a guard. This should be changed to [0..1] to make the guard optional.
    The standard should also say that if a guard is not present it means the same as a "true" guard.

    Note that the guard of a state machine transition is optional, so this change will make things more consistent

  • Reported: UML 2.2 — Thu, 6 May 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Bug in Core::Abstractions::Super::Classifier::hasVisibilityOf

  • Key: UML23-140
  • Legacy Issue Number: 15221
  • Status: closed  
  • Source: Titian Software ( Tomasz Biegacz)
  • Summary:

    In Core::Abstractions::Super::Classifier::hasVisibilityOf there is
    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

    This is wrong because “NamedElement” doesn’t have “visibility” attribute. In fact “Feature” doesn’t have “visibility” attribute as well, so all of the properties and operations for Classifier needs to be public. That’s why I think that for now “hasVisiblityOf” should be fixed to:
    Classifier::hasVisibilityOf(n: NamedElement) : Boolean;
    pre: self.allParents()>collect(c | c.member)>includes
    hasVisibilityOf = true

    but maybe it should be considered to add visibility attribute to Feature.

  • Reported: UML 2.2 — Fri, 23 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Ordered derived unions

  • Key: UML23-130
  • Legacy Issue Number: 14552
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    When you specify a property as an ordered derived union, with the implied derivation of union-ing the subsetting properties, how do you specify the order of the resulting union?

  • Reported: UML 2.2 — Wed, 7 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This problem actually occurs in the UML spec itself, in the definition of ExceptionHandler::output_pins
    which relies on the ordering of Action::output, which is a derived union.
    We can specify a determinate order for the common case where all of the subsetting properties are class
    owned and there is single inheritance: which is the case for Action::output. In other cases, we can just say
    that the order is undefined.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Package Extension

  • Key: UML23-135
  • Legacy Issue Number: 15019
  • Status: closed  
  • Source: vtmw ( Peter Hammer)
  • Summary:

    The term "Package Extension" on page 142 seems to be obsolet and possibly may be omitted

  • Reported: UML 2.2 — Mon, 1 Feb 2010 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Wrong Spelling for "development"

  • Key: UML23-134
  • Legacy Issue Number: 14889
  • Status: closed  
  • Source: Lockheed Martin ( John Watson)
  • Summary:

    In the first table of section C.2, the first row, <<buildComponents>>, in the column called "Description" the word development is misspelled in the phrase ”for the purpose of system level decelopment activities"

  • Reported: UML 2.2 — Tue, 22 Dec 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Cyclick dependency

  • Key: UML23-133
  • Legacy Issue Number: 14563
  • Status: closed  
  • Source: asd-software ( Jiri Schubert)
  • Summary:

    1)
    In paragraph "7.3.8 Classifier (from Kernel, Dependencies, PowerTypes)" is constraint:
    [4] self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self)))

    2)
    inheritableMembers() is query with definition:
    [4] Classifier::inheritableMembers(c: Classifier): Set(NamedElement);
    pre: c.allParents()->includes(self)
    inheritableMembers = member->select(m | c.hasVisibilityOf(m))

    3)
    hasVisibilityOf() is query with definition:
    [5] 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

  • Reported: UML 2.2 — Thu, 15 Oct 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Invalid type for NamedElement.namespace

  • Key: UML23-138
  • Legacy Issue Number: 15209
  • Status: closed  
  • Source: Titian Software ( Tomasz Biegacz)
  • Summary:

    For NamedElement there is:

    namespace: NamedElement [0..1]

    when it should be

    namespace: Namespace [0..1]

  • Reported: UML 2.2 — Mon, 19 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Invalid type for Slot.value

  • Key: UML23-137
  • Legacy Issue Number: 15208
  • Status: closed  
  • Source: Titian Software ( Tomasz Biegacz)
  • Summary:

    For Slot there is:

    value : InstanceSpecification [*]

    when it should be

    value : ValueSpecification [*]

  • Reported: UML 2.2 — Mon, 19 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    See issue 10005 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor bug in Namespace::importMembers() query

  • Key: UML23-139
  • Legacy Issue Number: 15216
  • Status: closed  
  • Source: Titian Software ( Tomasz Biegacz)
  • Summary:

    There is:

    importMembers = self.excludeCollisions(imps)>select(imp | self.ownedMember>forAll(mem |
    mem.imp.isDistinguishableFrom(mem, self)))

    when it should be

    importMembers = self.excludeCollisions(imps)>select(imp | self.ownedMember>forAll(mem |
    imp.isDistinguishableFrom(mem, self)))

  • Reported: UML 2.2 — Wed, 21 Apr 2010 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Contents of Dependencies package

  • Key: UML23-136
  • Legacy Issue Number: 15020
  • Status: closed  
  • Source: vtmw ( Peter Hammer)
  • Summary:

    Fig. 7.15 contains two misplaced

    {subsets}

    -clauses.

    In the two associations between Dependency and NamedElement,

    {subsets target}

    only makes sense for property supplier; the same holds for

    {subsets source}

    and property client.

  • Reported: UML 2.2 — Mon, 1 Feb 2010 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Japan Superstructure PAS Ballot Comments - comment 6

  • Key: UML23-101
  • Legacy Issue Number: 14263
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GT Regarding Description, Notation and Semantics section, It is difficult to distinguish MetaClass name from general term, since there are several confusing occurrences which are shown in lower case letter. It seems those are inconsistent.

    Clarify their usages through the entire specification.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolution:
    Context is often required to distinguish use of names - sometimes the name means both the metaclass and the common meaning of the term. Ideally, the spec should have notational conventions for these and follow them, but this would be too large an undertaking to incorporate into version 2.3 of UML.
    The Japanese National body provided the following clarification on this issue:
    "Could you just confirm the capitalization?
    We have to translate this standard to establish the Japanese Industrial Standard (JIS) after ISO standardization. In that case, unclear usage of the capitalization will make us confused."
    In many cases the capitalization is an editorial matter. There is not enough time to make a detailed proposal for making capitalization more consistent in time for this RTF.
    Should leave this issue of consistent capitalization open for discussion in future RTF for detailed proposals to be considered for resolution in the next UML version..
    Revised Text:

    Disposition: Deferred

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 5

  • Key: UML23-100
  • Legacy Issue Number: 14262
  • Status: closed  
  • Source: Anonymous
  • Summary:

    JP5 4,5 GE There is no terms, definitions and symbols.

    Remove the clause "4 Terms and definitions" and "5 Symbols".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Leave section 4 for future revisions to add terms and definitions. Issue 14259 replaces section 5 with a new Notational Conventions section. see Issue 14259 (JP 2) resolution.
    Revised Text:

    Disposition: Duplicate of 14259

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 15

  • Key: UML23-109
  • Legacy Issue Number: 14272
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Fig. 13.15, 13.17, 14.12, 14.16~31, …, 16.10 E The annotations with red characters and a red arrow which outside the framework are not parts of example. They are class names and/or their attributes. Also, the arrow symbol is same as UML notation. Thus, those annotations lead misunderstand.
    *Add annotation convention to somewhere.

    • Unify the arrow symbol, someone are white hatching, others are red hatching.
  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Suggest adding description of red annotations to section 5, Notational Conventions.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 11

  • Key: UML23-105
  • Legacy Issue Number: 14268
  • Status: closed  
  • Source: Anonymous
  • Summary:

    12.4, E There is no subheading representing a particular diagram.

    Add subheading "Activity Diagram".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Since the section 12 is titled Activities, it serves as the context for sub-section 12.4
    Revised Text:

    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 10

  • Key: UML23-104
  • Legacy Issue Number: 14267
  • Status: closed  
  • Source: Anonymous
  • Summary:

    TL It is unclear whether the names of diagrams, e.g. Class Diagram, are within normative part or informative part of the standard.

    State clearly whether the names of diagrams, e.g. Class Diagram, are within normative part or informative part of the standard.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    RTF does not see why Japan thinks the names might be anything but normative - they are in Annex A clearly marked as Normative. Resolution to Issue 14265 (JP 8) results in all annexes being labeled as normative or informative.
    Revised Text:

    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 17

  • Key: UML23-111
  • Legacy Issue Number: 14274
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex I TH This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition. Remove Annex I or make it informative Annex.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    agreed, Annex I is no longer in UML 2.3
    Revised Text:

    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 16

  • Key: UML23-110
  • Legacy Issue Number: 14273
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Table 16.1 E Many people may misunderstand the annotations inside table 16.1 are notations of graphical nodes. Remove annotations inside table 16.1.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolution:
    add explanation of annotations.
    Revised Text:
    See Issue 14272 revision, which adds explanation of graphical annotations.

    Disposition: Duplicate of 14272

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 7

  • Key: UML23-102
  • Legacy Issue Number: 14264
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GE There are a lot of sentences which start with Metaclass name (in upper case letter) without preceding letter. In that case, It is difficult to distinguish Metaclass name from general term.

    Clarify their usages through the entire specification. When sentence starts with metaclass name, put certain preceding letter, for example article, and make it distinguishable.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Context is often required to distinguish use of names - sometimes the name means both the metaclass and the common meaning of the term. Ideally, the spec should have notational conventions for these and follow them, but this would be too large an undertaking to incorporate into version 2.3 of UML. Leave Issue open for consideration in future Revisions.
    Revised Text:

    Disposition: Deferred

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 13

  • Key: UML23-107
  • Legacy Issue Number: 14270
  • Status: closed  
  • Source: Anonymous
  • Summary:

    16.4 E There is no subheading representing a particular diagram.

    Add subheading "Use Case Diagram".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Since the section 16 is titled "Use Cases", it serves as the context for sub-section 16.4
    Revised Text:

    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 12

  • Key: UML23-106
  • Legacy Issue Number: 14269
  • Status: closed  
  • Source: Anonymous
  • Summary:

    15.4 E There is no subheading representing a particular diagram.

    Add subheading "State Machine Diagram"

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Since the section 15 is titled "State Machines", it serves as the context for sub-section 15.4.
    Revised Text:

    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 8

  • Key: UML23-103
  • Legacy Issue Number: 14265
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GT Distinction between normative and informative part is unclear.

    Make distinction between normative and informative part.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Ensure that all annexes are labled as "normative" or "informative"
    All statements in the body of the spec (unless explicitly stated as informative) are considered as normative. The formal semantics of use of term "may" from resolution to Issue 14259 (jp 2) clarifies its use as in normative statements.
    Eg: In Section "Notation" in 7.3.3 Association" the sentence:
    "Users may conceptualize the dot as showing that the model includes a property of the type represented by the classifier touched by the dot."
    is a normative statement.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 14

  • Key: UML23-108
  • Legacy Issue Number: 14271
  • Status: closed  
  • Source: Anonymous
  • Summary:

    17.3.1 1st paragrap, Semantics section. (There are several "physical" in the section) TH According to the standard, "Model" is restricted to "physical system". However, It is required to apply to conceptual/logical system.

    Remove "physical". Otherwise, add "conceptual/logical" before "system".

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    agreed to remove prefix "physical" before "system" in Section 17.3.1, para 1

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan Superstructure PAS Ballot Comments - comment 18

  • Key: UML23-112
  • Legacy Issue Number: 14275
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex J GE This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as only OMG document but not ISO standard.
    Remove Annex J.

  • Reported: UML 2.2 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Resolution:
    Agree, this annex is no longer in UML 2.3
    Revised Text:
    Annex J already removed in UML 2.3.

    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Irritating occurrence of subsystem stereotype in use case example diagrams

  • Key: UML241-22
  • Legacy Issue Number: 16494
  • Status: closed  
  • Source: in.tum.de ( Florian Schneider)
  • Summary:

    Referenced UML Superstructure Version: 2.4 beta2

    Issue:

    In chapter 16 on use cases, a <<subsystem>> stereotype is applied to the subject (or system boundary) in three figures:

    • Figure 16.5 - Example of the use cases and actors for an ATM system (p. 614)
    • Figure 16.8 - Example of a use case for withdrawal and transfer of funds (p. 616)
    • Figure 16.11 - Use cases owned by a package (p. 621)

    According to Table B.1 - UML Keywords (p. 712), that specific stereotype is only applicable to Component. The subject of a use case is of type Classifier.

    So the named diagrams are not syntactically wrong but slightly irritating to the reader because there is no indication that in these examples, the use case subject is actually a more specific type of a classifier, namely a component. The diagrams could lead to misinterpretations like "it is allowed to use the subsystem stereotype for any use case subject".

    The textual description for Figure 16.5 does not clarify but only states "For example, the use cases shown in Figure 16.5 on page 614 apply to the “ATMsystem” classifier"
    Regarding Figure 16.8 the accompanying text makes no clarification.
    Figure 16.11 is even more confusing as it seems to be the case that the component being subject to the use cases is part of a package. Also the package name "ATMtopPkg" does not seem to be a good name for a package.

    Recommendation:

    1) Add textual description to explain the origin of the <<subsystem>> stereotype on the three diagrams
    or
    remove subsystem stereotype as UML examples should not include constructs of any profile (even if it is one of the standard profiles)

    2) Rename "ATMtopPkg" in Figure 16.11 (e.g. to ATMNetwork)

  • Reported: UML 2.4 — Wed, 17 Aug 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Merged with 18071

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.4: NamedElement.ownedRule could be ordered

  • Key: UML241-21
  • Legacy Issue Number: 16493
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Graphically, Constraints appear independently so the unordered
    characteristric of NamedElement.ownRule seems sensible. However in a textual
    rendering ordering is appropriate.

    For instance, Constraints may sensibly be layered so that simple Constraints
    come first and act as guards against redundant evaluation of later
    Constraints.

    For instance, when auto-generating a specification such as the OCL
    specification, a specific ordering is required in the generated output.

    Please change to

    {ordered}

    .

  • Reported: UML 2.4 — Mon, 15 Aug 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    The ownedRule property is actually on Namespace, not NamedElement.
    In general, it is not appropriate to add constraints to the abstract syntax in order to capture presentation issues, like the
    textual rendering of an order. Further, the UML semantics provide no requirement that ownedRules be evaluated in
    any particular order, so, as far as UML is concerned, there is no underlying meaning to such ordering.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

property.opposite

  • Key: UML241-19
  • Legacy Issue Number: 16412
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    It seems there is an issue with derived Property.opposite.

    Spec says:

    / opposite : Property [0..1] In the case where the property is one navigable end of a binary association with both ends navigable, this gives the other end.

    By description, it should keep reference to opposite navigable end, but OCL works only when navigable end is owned by class.
    It does not work when navigable end is owned by association:

    Constraint #1:
    [1] If this property is owned by a class associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end.
    opposite = if owningAssociation->isEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)>any() in if otherEnd.owningAssociation>isEmpty() then otherEnd else Set{} endif else Set {} endif

    Any comments?
    Which one is correct? Property description or constraint text?

  • Reported: UML 2.4 — Mon, 1 Aug 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    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

ProfileApplication::appliedProfile as "importedProfile" instead of "appliedProfile"

  • Key: UML241-18
  • Legacy Issue Number: 16400
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    I noticed that all normative UML2.x infrastructure and superstructure documents have the same bug:

    In ProfileApplications, under Associations, the following property is incorrect:

    • importedProfile: Profile [1]
    References the Profiles that are applied to a Package through this ProfileApplication.
    Subsets PackageImport::importedPackage

    It should describe the following property ProfileApplication::appliedProfile : Profile[1] as follows:

    appliedProfile : Profile[1]
    References the Profile that is applied to a Package through this ProfileApplication.
    Subsets DirectedRelationship::target

    In the UML2.xInfrastructure metamodel and the 2.4 beta2 merged metamodel
    the documentation for ProfileApplication::appliedProfile should be changed from:

    References the Profiles that are applied to a Package through this ProfileApplication.

    to:

    References the Profile that is applied to a Package through this ProfileApplication.

    This affects the following documents:

    UML2.4 Infrastructure & Superstructure beta2 (ptc/2010-11-16 and ptc/2010-11-14)
    UML2.3 Infrastructure & Superstructure (formal/2010-05-03 and formal/2010-05-05)
    UML2.2 Infrastructure & Superstructure (formal/2009-02-04 and formal/2009-02-02)
    UML2.1.2 Infrastructure & Superstructure (formal/2007-11-04 and formal/2011-11-02)
    UML2.1.1 Infrastructure & Superstructure (formal/2007-02-06 and formal/2007-02-05)
    UML2.0 Infrastructure & Superstructure (formal/2005-07-04 and formal/2005-07-05)

    This affects the following normative files:

    http://www.omg.org/spec/UML/20101101/UML.xmi
    http://www.omg.org/spec/UML/20101101/Infrastructure.xmi
    http://www.omg.org/spec/UML/20090901/Infrastructure.cmof
    http://www.omg.org/spec/UML/20061012/Infrastructure.cmof
    http://www.omg.org/spec/UML/20061012/Infrastructure.cmof

    The same bug is also in the Documents/Specifications/2.4/Deliverable files in SVN revision 21132

  • Reported: UML 2.4 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    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

ChangeEvent::changeExpression should be of type ValueSpecification

  • Key: UML241-25
  • Legacy Issue Number: 16896
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    Subsection Associations is not in synch with the abstract syntax depicted in Figure 13.12.

    In the abstract syntax, change expression is typed by ValueSpecification, whereas in Association section it is described as Expression.

    Possible resolution:

    Change changeExpression : Expression

    to

    changeExpression : ValueSpecification.

  • Reported: UML 2.4 — Wed, 14 Dec 2011 05:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    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

Validity duration of implicitly assigned parameters in SignalEvent/CallEvent

  • Key: UML241-24
  • Legacy Issue Number: 16649
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    The textual syntax of CallEvent and SignalEvents states the following:

    "<call-event> :: <name> [‘(‘ [<assignment-specification>] ‘)’]
    <assignment-specification> ::= <attr-name> [‘,’ <attr-name>]*

    <assignment-specification> is optional and may be omitted even if the operation has parameters."

    Does this mean that the parameters of the event are still assigned to attributes of the context object? If so, how long are those implicitly assigned
    attribute values stored in the context object? Since this is just a workaround to be able to express guard conditions that evaluate whether a transition can fire based
    on the recieved trigger, I would assume, the implicitly assigned attribute values are kind of transient or temporarly and will become invalid (or deleted) after all guards of the outgoing state are evaluated. Otherwise, I would like have this paragraph stated
    clearer. It is a vital and crucial part how to deal with triggering events and with guard that refer to those trigger events.

  • Reported: UML 2.4 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    There is no implication in this notation of “transient” or “temporary” assignment. The values are assigned to the given
    attributes, which retain those values until reassigned. However, the exact mechanism for accomplishing the intent
    behind this notation is not formalized in the specification. The UML 2.5 specification now includes the following
    clarification (from Subclause 13.3.4):
    “<assignment-specification> is optional and may be omitted even if the Operation has Parameters. No standard mapping
    is defined from an assignment specification to the UML abstract syntax. A conforming tool is not required to
    support this notation. If it does, it may provide a mapping to standard UML abstract syntax, e.g., by implicitly inserting
    Actions to carry out the behavior implied by the notation.”
    Disposition: Closed - No Change
    Report

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XMI in small caps

  • Key: UML241-17
  • Legacy Issue Number: 16363
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    On page 177, Clause 12, second paragraph, in the middle, XMI is written
    in small case, as "...whose xmi serialization...", maybe it's recomended
    to write in upper case as in the rest of the document.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    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

Core Package versus Construct Package

  • Key: UML241-16
  • Legacy Issue Number: 16362
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    On page 14, Figure 7.3 of the OMG Unified Modeling Language (OMG UML),
    Infrastructure document, I think there's a small error in the picture.

    The picture details the Core package, as explained in the text. But
    the name in the top of the package is written as "Construct" (please
    note that I'm talking about the name of the whole package, the left-
    hand side one in the picture, and not the name os the sub-package
    Construct itself).

    It gets a little bit confusing that the name of the whole package
    is written as "Construct" instead of "Core".

    Please note also that the Figure "Part II, Figure 2" on page 27 is
    the same. And Figure 9.1 on page 29. And Figure 10.1 on page 91. And
    11.1 on page 103. And maybe others that I couldn't find now.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    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 Appendix A : Figure A.3 Two Diagrams of Packages”

  • Key: UML241-20
  • Legacy Issue Number: 16483
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In “Figure A.3 Two Diagrams of Packages” the left most diagram has a header that says:

    “i) Package symbol (as part of a larger diagram diagram)”

    This text should be (as far as I can figure out)

    “i) Package symbol (as part of a larger package diagram)”

    Similarly, the paragraph before the diagram has the following text

    “Figure A.3 illustrates that a package symbol for package P (in some containing package CP) may show the same contents as the class diagram for the package. i) is a diagram for package CP with graphical symbols representing the fact that the CP package contains a package P.”

    To clarify this, make the following one word change

    “Figure A.3 illustrates that a package symbol for package P (in some containing package CP) may show the same contents as the class diagram for the package. i) is a package diagram for package CP with graphical symbols representing the fact that the CP package contains a package P.”

  • Reported: UML 2.4 — Tue, 2 Aug 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Accept the proposals

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XML Metadata Interchange (XMI) - p9

  • Key: UML241-15
  • Legacy Issue Number: 16361
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    On page 9 of the OMG Unified Modeling Language (OMG UML), Superstructure
    document, there is the same error (or maybe, typo) as in the Infrastructure
    document. It's in the seventh bullet at the beginning of the page, where
    it's written:

    XMI Metadata Interchange (XMI)

    Maybe the correct text would be:

    XML Metadata Interchange (XMI)

    That is, XML instead of XMI at the beginning of the phrase.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    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

XML Metadata Interchange (XMI)

  • Key: UML241-14
  • Legacy Issue Number: 16360
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    On page 5 of the OMG Unified Modeling Language (OMG UML), Infrastructure
    document, I think there's a small error (maybe a typo). It's in the last
    line of this page, where it's written:

    XMI Metadata Interchange (XMI)

    Maybe the correct text would be:

    XML Metadata Interchange (XMI)

    That is, XML instead of XMI at the beginning of the phrase.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    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

Implicit parameter assignment may cause name clashes

  • Key: UML241-23
  • Legacy Issue Number: 16648
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    The textual syntax of CallEvent and SignalEvents states the following:

    "<call-event> :: <name> [‘(‘ [<assignment-specification>] ‘)’]
    <assignment-specification> ::= <attr-name> [‘,’ <attr-name>]*

    <attr-name> is an implicit assignment of the corresponding parameter of the operation to an attribute (with this name)
    UML Superstructure Specification, of the context object owning the triggered behavior"

    This may lead to a situation where name clashes can occurr, if the context object already contains an identically named attibute.
    How should situations like a name clashes be resolved?

  • Reported: UML 2.4 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    The corresponding wording in the UML 2.5 specification is (from Subclause 13.3.4):
    “<assigned-name> is an implicit assignment of the argument value for the corresponding Parameter of the Operation
    to a Property or Variable of the context object for the triggered Behavior.”
    The “assigned-name” is the name of a Property or Variable that the context object already contains, not a definition of
    a new attribute. There is therefore no possibility of “name clash”.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Number of Compliance Levels

  • Key: UML241-13
  • Legacy Issue Number: 16359
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    In the OMG Unified Modeling Language (OMG UML), Infrastructure document,
    it is said that this document, and the Superstructure document, should be
    used in conjunction (page 9) as the two volumes cross-reference each other
    and the specifications are fully integrated.

    But on page 2 of the OMG Unified Modeling Language (OMG UML), Infrastructure
    document we can find 2 compliance levels. And on page 2 of the OMG Unified
    Modeling Language (OMG UML), Superstructure document (ptc/2010-11-14 version
    2.4) we can find 4 compliance levels. Which is rioght ? Two our four ? As
    both documents are integrated shouldn't them have the same explanation for
    compliance levels ?

    It gets a little confusing to understand this.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    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

Presentation options of statemachine transitions: Figure 15.45 is ambiguous or wrong

  • Key: UML241-2
  • Legacy Issue Number: 16002
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    Figure 15.45 of superstructure v2.3 illustrates the representation of deferred triggers on states. The transition between states "Get Cups" and "Pour coffee" specifies a trigger "light goes out" which is also identified as a deferred trigger of state "Get Cups". Does "light goes out" trigger the transition, or is it deferred? If the figure is not wrong, it would probably be helpful to add a comment in the text (note that figure 15.45 is not referenced in the text).

  • Reported: UML 2.4 — Tue, 1 Feb 2011 05:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Indeed, this is a very confusing example and is also wrong as the submitter points out. Also, there should
    be some explanation of this diagram.
    Replace this diagram with a simpler one and add some explanatory text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Can a Generalization really be in multiple GeneralizationSets?

  • Key: UML241-1
  • Legacy Issue Number: 15993
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    According to the abstract syntax, Generalization::generalizationSet has upper bound *.

    According to the text:

    Package PowerTypes A generalization can be designated as being a member of a particular generalization set.

    There is only one place where the possibility of many sets is mentioned, where it says:

    “The generalizationSet association designates the collection of subsets to which the Generalization link belongs. All of the Generalization links that share a given general Classifier are divided into subsets (e.g., partitions or overlapping subset groups) using the generalizationSet association. Each collection of subsets represents an orthogonal dimension of specialization of the general Classifier.”

    The first of these sentences implies that a Generalization can belong to many (“collection of”) GeneralizationSets. The second sentence contains a phrase “subsets (e.g., partitions or overlapping subset groups)” that makes little sense. Rephrasing “subset groups” as “subsets” gives us “e.g., partitions or overlapping subsets” which seems to imply that the GeneralizationSets may overlap. But then “Each collection of subsets represents an orthogonal dimension of specialization” translates to “each collection of GeneralizationSets represents an orthogonal dimension…” which is obviously wrong. Rephrasing as “Each GeneralizationSet represents an orthogonal dimension …” makes more sense: but if they are orthogonal, how can they overlap?

    Then, in the notation and further explanations, there is no discussion whatsoever of the possibility of a generalization belonging to many GeneralizationSets.

    I think this is clearly an error in the metamodel.

  • Reported: UML 2.4 — Thu, 27 Jan 2011 05:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    The text that the issue complains about is no longer in the spec. It’s clear that a Generalization can belong
    in more than one GeneralizationSet: “The generalizationSet property designates the GeneralizationSets to
    which the Generalization belongs.”
    However, there is a misleading phrase in the Notation that could be improved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No Rules for Element Names

  • Key: UML241-5
  • Legacy Issue Number: 16115
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    UML specification does not provide exact rules for element names. For example, namespace "provides a means for resolving composite names, such as name1::name2::name3." What are the rules for the name1/2/3? Could we use spaces, dashes, digits?
    For the class name we should: "capitalize the first letter of class names (if the character set supports uppercase)." But what are the rules for the class name? "A use case is shown as an ellipse, either containing the name of the use case or with the name of the use case placed below the ellipse." But what are the rules for the use case name?

  • Reported: UML 2.4 — Sun, 17 Apr 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    There are no rules for names in UML. The UML standard does not restricted what characters can be used in a name
    or how the name is constructed.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 15.32

  • Key: UML241-4
  • Legacy Issue Number: 16111
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I downloaded (and partially read) the UML Superstructure file "10-05-05.pdf" from your site. That's one of two defining documents of UML 2.3.

    Figure 15.32 shows the "Typing password" state from a Statechart diagram. It defines two "entry" actions: setEchoInvisible and setEchoNormal. Clearly, the second action should be an exit action, not an entry action. Can you correct this error in the next version of the document? It's a minor error, but you'll agree with me that it's a bad example this way, I suppose.

  • Reported: UML 2.4 — Fri, 18 Mar 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Agreed. This is diagram 14.5 in the new text.
    Fix the diagram by replacing the second “entry” label with the label “exit”.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 15.32

  • Key: UML241-8
  • Legacy Issue Number: 16169
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Figure 15.32 shows the "Typing password" state from a Statechart diagram. It defines two "entry" actions: setEchoInvisible and setEchoNormal. Clearly, the second action should be an exit action, not an entry action. Can you correct this error in the next version of the document? It's a minor error, but you'll agree with me that it's a bad example this way, I suppose

  • Reported: UML 2.4 — Fri, 18 Mar 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Merged with 16111

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo: "joint" should say "join"

  • Key: UML241-7
  • Legacy Issue Number: 16164
  • Status: closed  
  • Source: asu.edu ( Joe Mooney)
  • Summary:

    Typo: say join and not joint.

    The notation for a fork and join is a short heavy bar (Figure 15.25). The bar may have one or more arrows from source
    states to the bar (when representing a joint).

  • Reported: UML 2.4 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    It should indeed be “join” and not “joint”. Correct the text appropriately

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities: Modifications to the approved resolution of 10815

  • Key: UML22-1141
  • Legacy Issue Number: 12433
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Modifications to the approved resolution of 10815. It should use a different keyword for decision input flows than the existing one for decision input behaviors. It should include an update to the notation figure, and to the keyword index.

  • Reported: SysML 1.0 — Fri, 9 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Revise the resolution to 10815 as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Diagram metaclass shall be introduced and shall be subclass of Element

  • Key: UML22-1122
  • Legacy Issue Number: 10819
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Diagram metaclass shall be introduced and shall be subclass of Element, because every tool need to add Diagrams into packages (and uses hacks to do that) , Dependencies between diagrams is usable also. Stereotypes for diagrams are also used and even represented in DiagramFrame notation

  • Reported: UML 2.1 — Fri, 23 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This is definitely outside the scope of an RTF. However, it is also very much against one of the fundamental architectural principles of UML, that the abstract and concrete syntaxes are to be kept distinct. For instance, it should be possible to provide a UML concrete syntax that is completely textual and, hence, has no notion of diagram. Finally, the question of defining concrete syntaxes for MOF-based modeling languages and the issue of how these relate to the models themselves is being addressed by a separate RFP (the “Diagram Definition RFP”). Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Setting structural features of a data type

  • Key: UML22-1121
  • Legacy Issue Number: 10816
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Document: Unified Modeling Language: Superstructure, Version 2.1.1 (formal/2007-02-03)
    Sections: 11.3.12 (ClearStructuralFeatureAction) and 11.3.53 (WriteStructuralFeatureAction)

    (This issue surfaced during work on the Semantics of a Foundational Subset for Executable UML Models submission.)

    Background:

    Use the term "structured" data type to refer to a data type that is not a primitive type or an enumeration. Such a data type may have attributes, which can be read and written by the read and write structural feature actions (for the purposes of this discussion, consider clear structural feature action to be a kind of write structural feature action).

    Semantically, the main difference between a data value that is an instance of a structured data type and an object that is an instance of a class is that a data value is passed "by value" while an object is passed "by reference". That is, a data value is itself a true value that can be passed as a parameter value to behavior and can flow on "object" flow edges ("object flow" really isn't a better name than "data flow", but the way...). On the other hand, an object exists with its own identity in the extent of their class at a specific locus, and only references to an object can be passed as values.

    Thus, there may be many references all to the same object. As a result of this, any change to the attributes of an object via one reference will be reflected in future reads of that attribute via different references to that object.

    In the case of a structured data value, however, a change to one of its attributes will only be reflected in the value actually being acted on. If that value is not then itself passed on, this change will not be visible in any other data value. Unfortunately, write structural feature actions do not have output pins. The assumption seems to be that such writes always happen "in place". This works for objects that have their own identity, but there is no clear "place" for which the change can happen for structured data values.

    Note that this would still be an issue even if variables were allowed in fUML (and so it is an issue in full UML 2 with variables, too). To change a value in a variable, one needs to use a read variable action. If the value in the variable is a structured data value, then the read variable action will place a "by value" copy of the data value on the output pin of the action (since data values don't have identity or references, it can't really do anything else...). Therefore, a write structural value action acting on the output of a read variable action will make a change to this copy, not the value in the variable. But then, since the write structural value action has no output pin, there is no way to get the changed copy back into the variable (or use it in any other way, for that matter.)

    Proposed resolution:

    Add an output pin to write structural feature actions. If the "object" being acted on is really an object (that is, an instance of a class), then the input reference to that object is just place on the output pin. But if the "object" being acted on is a data value (that is, an instance of a structured data type), then the value placed on the output pin is a copy of the input data value, but with the given structural feature value appropriately updated.

    (Note that the output pin is not strictly necessary for a true object update, but it seems simpler to always have the output pin. In the case of a write to an object, the output pin can simply be ignored – though it might sometimes be convenient even in this case for "chaining" actions on an object.)

  • Reported: UML 2.1 — Fri, 9 Mar 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 7.14: "Type" does not show its inheritance from "PackageableElement"

  • Key: UML22-1124
  • Legacy Issue Number: 10828
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    In the Superstructure spec 2.1.1, in figure 7.14, the "Type"
    metaclass is shown right below the "PackageableElement" metaclass,
    but without any inheritance arrow between them. This is not wrong,
    since a class diagram is not obliged to show all existing
    relaitonships.

    However, it would ease the understanding and be consistent if in this
    case, the inheritance arrow between these two metaclasses was shown
    in that figure.

  • Reported: UML 2.1 — Sat, 17 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This strikes me as a matter of taste; someone else might object to the generalization being shown in this diagram since it would clutter the diagram. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ConnectorEnd shall have references to provided or required interfaces

  • Key: UML22-1123
  • Legacy Issue Number: 10820
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    ConnectorEnd shall have references to provided or required interfaces. It helps to use assembly connectors in composite structure diagrams between parts and ports, connector will be able to display two compatible interfaces using "ball in socket" notation.
    Now it is impossible to implement that, because there are no references to interfaces.

  • Reported: UML 2.1 — Fri, 23 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: There are two problems with this issue: (a) The ball-and-socket notation is unique to the components chapter, so this issue cannot be resolved in general for ConnectorEnd, but would have to be addressed specifically in the components chapter by introducing a subtype of ConnectorEnd. More importantly, though, (b) connectors do not have a semantic relation to interfaces. They connect ports or parts based on their compatability. The compatability between interfaces is a derived notation, and does not require metamodel support. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

constraining Classifiers

  • Key: UML22-1134
  • Legacy Issue Number: 11243
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    It should be possible to specify multiple constraining classifiers for ClassifierTemplateParameter.
    For example, Java programming language allows to specify multiple interfaces as constraining types of template parameter, I see no reasons why UML can't allow several constraining types.

    Resolution:

    17.5.8
    Change multiplicity of "constrainingClassifier" from [0..1] to [0..*].

  • Reported: UML 2.1.1 — Mon, 6 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

defaultClassifier of ClassifierTemplateParameter

  • Key: UML22-1133
  • Legacy Issue Number: 11240
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Problem:

    "defaultClassifier" of ClassifierTemplateParameter shall redefine "default" of TemplateParameter and restrict type to Classifier.

    "default" shall be not accessible in ClassifierTemplateParameter.

    Resolution:

    Add

    {redefines default} to end of "defaultClassifier"property description in chapter 17.5.8 ClassifierTemplateParameter

    Add {redefines default}

    in metamodel association. Unfortunately diagram of abstract syntax of ClassifierTemplateParameter is not included into 17.5 Templates chapter.

    It should be added also.

  • Reported: SysML 1.0 — Wed, 1 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Remove this redundant association

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.11 p 182

  • Key: UML22-1129
  • Legacy Issue Number: 11087
  • Status: closed  
  • Source: UPM ( Juan Pedro Silva)
  • Summary:

    All rolenames in non-navigable associations in the UML metamodel should be stated, to allow reaching from one element of the association to the other using OCL. Currently, this is limited to un-ambigous type names if the rolename is not stated. For example, in section "9.3.11 Port (from Ports)", Port has required and provided interfaces, and has no rolename on both associations. There is no current way, using OCL, of getting from one Interface to a Port that provides or requires it, as "self.port" is ambigous because it doesn't specify if the programmer is looking for Ports providing or requiring such Interface. The situation repeats in many other associations.

  • Reported: UML 2.1.1 — Thu, 31 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: It is not required for the specification to name such associations. Navigation is not that hard if this is really desired: find all ports and select the subset that has the appropriate interface. Also, OCL is not constrained by navigability. Discussion: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong notation description

  • Key: UML22-1128
  • Legacy Issue Number: 11007
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    "A component realization is notated in the same way as the realization dependency (i.e., as a general dashed line with an open arrow-head). ", BUT
    A Realization dependency is shown as a dashed line with a triangular arrowhead at the end that corresponds to the realized element

  • Reported: SysML 1.0 — Wed, 16 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.8

  • Key: UML22-1127
  • Legacy Issue Number: 11004
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    In UML 2.1.1 L3 metamodel (and the UML 2.1.1 Superstructure spec) EncapsulatedClassifier.ownedPort is declared to be derived. No derivation is provided and it seems unlikely that one was intended. For a list of other properties declared derived for which there is no derivation, see the 2006-12-09 entry here: http://syseng.nist.gov/se-interop/plugfest/tools/changelog

  • Reported: UML 2.1.1 — Mon, 14 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This derivation is given: EncapsulatedClassifier.ownedPort is all ownedAttributes that are of type Port. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 449 chapter 13.3.24 (Signal (from Communications)

  • Key: UML22-1126
  • Legacy Issue Number: 11003
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    there is a mistake in document formal/07-02-03 (UML Superstructure,
    v2.1.1) on page 449 chapter 13.3.24 (Signal (from Communications)). A
    Signal does not have an association to a signal of type Signal. It is
    probably a mix-up with SignalEvent

  • Reported: SysML 1.0 — Mon, 14 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Duplicate of issue 10960 Revised Text: N/A Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 superstructure -- figure 9.4 is duplicate of figure 9.3

  • Key: UML22-1125
  • Legacy Issue Number: 10992
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Figure 9.4 in formal/07-02-05 is a duplicate of figure 9-3. There should be a different diagram in place of figure 9-4 that shows the ports metamodel.

  • Reported: SysML 1.0 — Tue, 8 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed in 2.1.2 Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change multiplicity of ClassifierTemplateParameter role

  • Key: UML22-1136
  • Legacy Issue Number: 11400
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Problem:
    The same Classifier could be used only in one template parameter as "constrainingClassifier", it brokes usage of ClassifierTemplateParameters.

    Solution:
    Change multiplicity of ClassifierTemplateParameter role from "1" to "*" on association between ClassifierTemplateParameter and Classifier in Figure 17.18 - Classifier templates

  • Reported: UML 2.1.1 — Thu, 13 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any ownedBehavior should be able to have AcceptEventAction

  • Key: UML22-1135
  • Legacy Issue Number: 11265
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Section 13.3.31, Trigger indicates the receipt of an event by and active object can either directly cause the occurrence of a behavior, or is delivered to the classifier behavior. This is insufficient. An Event should be able to be handled by any active AcceptEventAction in any thread of control in any running method Activity that is an ownedBehavior of the receiving object. This is how events are commonly handled in business process models and BPEL. It allows an active object to indicate when it is able to accept a call or signal event at a specific point in an already running method activity. If there are more than one such AcceptEventAction, then the AcceptEventAction that handles the event is arbitrary.

  • Reported: UML 2.1.1 — Thu, 9 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

composite values

  • Key: UML22-1132
  • Legacy Issue Number: 11239
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    UML 2.1.1

    Problem:

    Duration value and TimeExpression value can't be owned by Duration or TimeExpression.

    Solution:

    Make Duration "expr" and TimeExpression "expr" properties composite.
    Change Figure 13.13 SimpleTime to reflect these ownerships.

  • Reported: SysML 1.0 — Wed, 1 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9 composite structures

  • Key: UML22-1131
  • Legacy Issue Number: 11164
  • Status: closed  
  • Source: Student at IFI UIO Norway ( Tormod Vaksvik Håvaldsrud)
  • Summary:

    Figure 9.3 : Is it riht that a connector can hold more than 2 ConnectorEnds? It is stated that it can hold: 2..*

  • Reported: SysML 1.0 — Fri, 20 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Yes, it is possible that a connector have more than 2 ends, in case it is an n-way connector. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"representation"

  • Key: UML22-1130
  • Legacy Issue Number: 11089
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Classifier from Kernel packages has "representation" property of type InformationItem.
    Classifier from Collaborations package has "representation" property of type CollaborationUse.

    After package merge these properties conflict, one of them shall be renamed.

  • Reported: SysML 1.0 — Tue, 5 Jun 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TimeEvent

  • Key: UML22-1138
  • Legacy Issue Number: 11409
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    TimeEvent has "when" property for time value.

    13.3.27 TimeEvent

    • when: TimeExpression [1] Specifies the corresponding time deadline.

    However in Figure 13.13 - SimpleTime Time Event has association with ValueSpecification.

    Model shall correspond to text, so Figure 13.13 shall be fixed.

  • Reported: UML 2.1.1 — Fri, 14 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 14.5 - Messages.

  • Key: UML22-1137
  • Legacy Issue Number: 11401
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Problem:
    Only one MessageEnd could have the same Message as "message", because of multiplicity [0..1] near MessageEnd on association between Message and MessageEnd in Figure 14.5 - Messages.

    Solution:
    Change multiplicity [0..1] near MessageEnd on association between Message and MessageEnd to [0..2] in Figure 14.5 - Messages.

  • Reported: UML 2.1.1 — Thu, 13 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.7

  • Key: UML22-1140
  • Legacy Issue Number: 11625
  • Status: closed  
  • Source: Volvo Technology Corporation ( Hans Blom)
  • Summary:

    nestedClassifier should subset Namespace::ownedMember. There is no ownedMember in Element, i.e. Element::ownedMember is incorrect.

  • Reported: UML 2.1.1 — Mon, 22 Oct 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This is a subset of the problem raised in issue 10829 Revised Text: N/A Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figures 9.4 identical to figure 9.3

  • Key: UML22-1139
  • Legacy Issue Number: 11524
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Figures 9.4 should show the Port metaclass, but it is identical to Figure 9.3, Connectors

  • Reported: UML 2.1.1 — Fri, 28 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed in an earlier release Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Flowing data into decision input behaviors

  • Key: UML22-1120
  • Legacy Issue Number: 10815
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Document: Unified Modeling Language: Superstructure, Version 2.1.1 (formal/2007-02-03)
    Sections: 12.3.22, DecisionNode

    (This issue surfaced during work on the Semantics of a Foundational Subset for Executable UML Models submission.)

    Background

    There is no direct way to flow a supporting value into the decision input behavior of a decision node.

    Suppose one wants to set up a decision node with a decision input behavior that, say, takes an object as an input and tests whether an attribute of that object has a certain value. Further, suppose that value is given by an input parameter of the enclosing activity. The value of the parameter is provided via an activity parameter node, but there is no direct way to connect an object flow from the activity parameter node to the test for the decision node.

    Currently, a decision input behavior can only have a single input parameter, which will get the object flowing into the decision node that is to be tested. And, since it is a separate behavior from the enclosing activity, a flow from the enclosing activity can't be connected into the decision behavior. Of course, it would be possible to save the parameter value into an attribute of the enclosing activity, and then read that attribute in the decision behavior – but this seems awfully round about!

    Note that there is no problem using a Conditional Node since, in that case, the test is not a separate behavior, and data can flow from the enclosing action into the test. It is just with (the supposedly simpler) Decision Node that there is a problem.

    Proposal

    Decision nodes may optionally have one additional incoming edge identified as the "decision input". If there is no decision input behavior, tokens offered on the decision input edge are made available to the guards on outgoing edges to determine whether the offer on the other incoming edge is passed along that edge. If there is a decision input behavior and a decision input edge, the token offered on the decision input edge is passed to the behavior (as the only argument if the regular incoming edge is control flow, as the second argument if it is object flow). Decision nodes with the additional decision input edge will offer tokens to outgoing edges only when one token is offered on each incoming edge.

  • Reported: UML 2.1 — Fri, 9 Mar 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Adopt as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Composite Structures

  • Key: UML22-1119
  • Legacy Issue Number: 10814
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 9.4 duplicates 9.3

  • Reported: UML 2.1.1 — Sat, 10 Mar 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed in 2.1.2 Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

issue regarding required and provided interfaces

  • Key: UML22-1107
  • Legacy Issue Number: 10354
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    There appears to be an issue with required and provided interfaces of Components in the UML2 Super Structure specification 2006-04-02 section 8.3.1., p.151 .

    In the OCL and the paragraph discussing required and provided interfaces there is no mention of inheriting provided or required interfaces from the supertypes of the component.
    Should we also consider required or provided interfaces of inherited ports?
    Should we also consider supertypes of realizing classifiers?

    The fact that Components don't consider supertypes is contrary to how Ports get required and provided interfaces on p187. Ports consider supertypes of the classifiers that type them when collecting required and provided interfaces.

  • Reported: UML 2.1 — Tue, 19 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2: Semantics of isOrdered need to be clarified

  • Key: UML22-1106
  • Legacy Issue Number: 10151
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Text should read something like:

    isOrdered : Boolean For a multivalued multiplicity, this
    attribute specifies whether the values in an instantiation of this
    element are maintained in the order that they where insertedsequentially
    ordered. Default is false.

  • Reported: UML 2.1 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Actually, the original description is more general, since the ordering can be based on different ordering criteria, not just based on the order of insertion. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ptc/06-04-02/Pg 188

  • Key: UML22-1118
  • Legacy Issue Number: 10788
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Where the spec currently says:

    “If the port was typed by a class, the interaction point object will be an instance of that class. The latter case allows elaborate specification of the communication over a port. For example, it may describe that communication is filtered, modified in some way, or routed to other parts depending on its contents as specified by the classifier that types the port.”

    Consider whether this should in fact be defined as a semantic variation point.

  • Reported: UML 2.1 — Tue, 27 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: The dynamic semantics of a port, when it is typed by a class, is already a semantic variation point. Most of the text above is an example, rather than a definition of behavior. The only normative text above is that the interaction point object will be an instance of the type of the port, if the port is typed by a class. That aspect is currently used by tools to give dynamic semantics to ports in a domain-specific manner. If such is not desired, the modeler can always close the semantic variation point as to the meaning of this construct to behave as desired, e.g., to reduce to the case where the type of the port is an interface. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.32

  • Key: UML22-1117
  • Legacy Issue Number: 10783
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    It should be possible to set the upperBound of a MultiplicityElement to 0 (it's currently forbidden by the constraint [1]). Example : if a class A is associated to a class B with a multiplicity of "0..*" (on the role of B). It should be possible to derive from the class A a class C of which the multiplicity of the role of B is always "0".

  • Reported: UML 2.1.1 — Wed, 21 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A notation for Trigger

  • Key: UML22-1116
  • Legacy Issue Number: 10777
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    My new question is about the notation for Trigger. In on ehand, I understand the notation as described in section 13.3.31 (p. 475) for specifyng the trigger of a transition in a statemachine (even if it is not so clear because the notation for Trigger refers in fact to the notation of event (p475) ?). But how is it possible to describe the Trigger owned by a classifier? What is the notation for a class to specify which Trigger a class is owning?
    In previous version of UML, it was clear in my head (it does no harm just this once that the description of the behavioral features (either Operations, or Receptions) of a class was implicitly the description of what kind of events a class may reponse to. But now, one hand a class specify its behavioral features, but what happen with its Triggers? Is the description of the behavioral features of a class the implicit description of its Triggers? But in this case, as Trigger are linked to Events, what is the need this intermediate concept of Triggers?

  • Reported: UML 2.1 — Thu, 15 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: There is no notation for trigger independent of its specific notation in a behavioral feature. (Note that this notation reduces to the specific notation for the associated event.) For example, in state machines, a notation is defined for representing triggers on states or transitions. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Action semantic clarification

  • Key: UML22-1102
  • Legacy Issue Number: 9875
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Action semantic clarification. In Activities, Action, Semantics, bullet [1], third sentence, after "offered", insert "all necessary".

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities -StartClassifeirBehaviorAction and classifier behaviors

  • Key: UML22-1101
  • Legacy Issue Number: 9872
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    StartClassifeirBehaviorAction and classifier behaviors. StartClassifeirBehaviorAction should support passing values to the classifier behavior.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - isSingleExecution default

  • Key: UML22-1100
  • Legacy Issue Number: 9871
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    isSingleExecution default. Default of isSingleExecution is in text, but not in metamodel diagram.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This is already resolved in UML 2.1.1 (formal/2007-02-03). Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profile Structure Diagrams are missing from Annex A

  • Key: UML22-1105
  • Legacy Issue Number: 10044
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 18.4 describes what are called "Structure Diagrams" for depicting profiles, stereotypes and their associated metaclasses.
    However such diagrams are not included in the Normative Appendix A (Figure A.5 does show 'Structure Diagram' but only as an abstract diagram type).

    Proposed resolution:
    For clarity use the term 'Profile Diagram in section 18.4
    Add Profile Diagram to Annex A as a 14th UML2 Diagram Type.

  • Reported: SysML 1.0b1 — Mon, 31 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing inheritance in 9.3.12

  • Key: UML22-1104
  • Legacy Issue Number: 10000
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure 9.2 shows that Property inherits from ConnectableElement - which is not included in the Generalizations section of 9.3.12 (though it is in the metamodel

  • Reported: SysML 1.0b1 — Wed, 26 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The submitter is correct; see revised text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No default value specified for Generalization::isSubstitutable

  • Key: UML22-1103
  • Legacy Issue Number: 9963
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    No default value specified for Generalization::isSubstitutable.
    This is the only Boolean attribute in the whole specification without a default value

  • Reported: SysML 1.0b1 — Tue, 25 Jul 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    For consistency and correctness, add a default value as the summary mentions.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

consistent descriptions of semantics of event consumption needed

  • Key: UML22-1115
  • Legacy Issue Number: 10776
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Pr. Dr. François Terrier)
  • Summary:

    make consistent the descriptions of semantics of event consumption in section 13.3.4 and in section 13.3.2

  • Reported: UML 2.1 — Thu, 15 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Section 13.3.2 is generic and does not define details of the semantics of event consumption. In fact it states that this is handled by BehavioredClassifier, section 13.3.4. I do not see any inconsistency between these two sections. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

section 13.3.2 – doc ptc/2006-04-02, v.2.1

  • Key: UML22-1114
  • Legacy Issue Number: 10775
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Pr. Dr. François Terrier)
  • Summary:

    Issue a: ) in behaviour description (section 13.3.2 – doc ptc/2006-04-02, v.2.1) precise more formally and explicitely which elements can have behaviors, and how the behavior context is defined.

    Typically clarification should say something like:

    • [A] Any subclasses of BehavioredClassifier (that is: Collaboration, Class, Actor, UseCase) can have a Behavior and its context is defined through the “context” association
    • [B] Any subclasses of BehavioralFeature (that is: xxx to be listed xxx) can have a Behavior and its context is defined through the “specification” association
    • [C] Additionally, Transitions and States can have a Behavior and its context is defined by the first BehavioredClassifier reached through their “owned” relation
    • [D] A Behavior can stand alone and be its own context (e.g. as equivalent to a C/C++ program)

    è Is it here necessary to add a context association from the Behavior to itself…? or should we consider that in this case it is always owned by a modelling element (eg a package) that defines its context… and should we explicitly define to which kind of element this can be considered and add these elements to the list of the [C] situation ?

  • Reported: UML 2.1 — Thu, 15 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: The issue is somewhat confusing in its wording when it asks what “elements can have behaviors”. In one reading, only BehavioredClassifier can have behaviors. Probably the issue means to ask what “elements can own behaviors”. It would be not in the style of the UML specification to summarize in a central location such information, as this would conflict with the object-oriented style of the specification, or it would cause a maintenance difficulty. Behavior::context clearly defines how the context object is determined, independent of the type of behavior or its owner. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Uses notation "Subsets Element::ownedElement" and similar

  • Key: UML22-1113
  • Legacy Issue Number: 10731
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Uses notation "Subsets Element::ownedElement" and similar. I believe this should be "Element.ownedElement", as :: is a separator for path. Please check the document throughout.

  • Reported: UML 2.1.1 — Wed, 14 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: In one of the earlier revisions, the decision was made to use the “::” operator as a qualifier and not the “.” operator. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2: Behavior without a specification should not be a classifier behavior

  • Key: UML22-1112
  • Legacy Issue Number: 10655
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Section 13.3.3, in the description of Behavior::specification says: "If a behavior does not have a specification, it is directly associated with a classifier (i.t., it is the behavior of the classifier as a whole."

    This appears to be incorrect. Assuming the "associated classifier" is the context Classifier: a Behavior might not be an ownedBehavior of any Classifier and has no context. For example, and Activity in a Package. Such a Behavior could not have a specification, but is not the behavior of any associated classifier.

    An ownedBehavior of a context Classifier can be explicitly designated as the behavior of the classifier using the BehavioredClassifier::classifierBehavior property. So there should be no need to define implicit classifier behaviors.

    Finally, a BehavioredClassifier might contain any number of ownedBehaviors that factor out reusable, private functions that are used in the implementations of other ownedBehaviors. These behaviors could be invoked using CallBehaviorActions and do not need specification operations. These behaviors would need a parameter for self if they need to refer to information in the context classifier.

  • Reported: UML 2.1 — Fri, 9 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The issue correctly points to that the text in Behavior::specification is misleading

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 13.8 shows the wrong diagram

  • Key: UML22-1109
  • Legacy Issue Number: 10469
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    diagrams for UML 2.1.1 - Figure 13.8 shows the wrong diagram

  • Reported: UML 2.1 — Wed, 22 Nov 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This was fixed in an earlier release. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.25

  • Key: UML22-1108
  • Legacy Issue Number: 10383
  • Status: closed  
  • Source: Bergson Technology ( Marc Hamilton)
  • Summary:

    SignalEvent notation interpretes Signal as an Operation. Details: A SignalEvent is associated to a Signal. The notation of SignalEvent contains an <assignment-specification> that consists of a list of <attr-name>. Quote: "<attr-name> is an implicit assignment of the corresponding parameter of the signal to...". Signal is however a Classifier and has no parameters. Either Signal should be an Operation or the notation of SignalEvent must utilize the explicit assignment of "corresponding attributes of the signal". In the latter case, this assignment should include the attribute name of the signal since the attributes of a Classifier are not ordered.

  • Reported: UML 2.1 — Fri, 6 Oct 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The issue is correct. What is meant was the attributes of the signal

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13 SimpleTime

  • Key: UML22-1111
  • Legacy Issue Number: 10643
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    What the time model needs is the concept of an optional time reference that can be attached to a time observation (e.g. to model a spacecraft/ground station situation). The MARTE profile has done some excellent work on this and it should be taken into account when resolving the issue

  • Reported: UML 2.1.1 — Mon, 5 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: The simple time model is just that: a very simple model to attach time specifications to observations, for example. When a more sophisticated handling of time is required, profiles such as the MARTE profile should be used. The proposal is not to attempt to enhance the simple time model but only fix problems with that model. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.2

  • Key: UML22-1110
  • Legacy Issue Number: 10513
  • Status: closed  
  • Source: UFRJ (Federal Uniersity of Rio de Janeiro) ( Felipe Gomes Dias)
  • Summary:

    In the UML Superstructure 2.1 available in the download section, the picture 13.8 is the same as the picture 13.7, in the page 463 of the document. The picture 13.8 should be explaining about the classes "Behavior" and "Constraint", as shown in the UML Superstructure 2.0 version.

  • Reported: UML 2.1 — Fri, 15 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed in an earlier release; also duplicate of10469 Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2: No notation for BehavioredClassifier::ownedTrigger

  • Key: UML22-1084
  • Legacy Issue Number: 9407
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    UML2 provides a number of different ways to initiatiate execution of some behavior, and for specifying what behaviors are offered for invocation. Behaviors provide a realization of these specifications.

    The simplest is a BehavioredClassifier can respond to invocations of its ownedBehaviors through a CallOperationAction. The ownedBehavior is a method of a specification Operation which defines the client interface, external view, signature, contract (whatever one likes to call it) of the behavior.

    If the ownedBehavior is an Activity, then the activity may contain any number of AcceptEventAction or AcceptCallAction/ReplyAction actions to enable the activity to control when and how additional behavior may be invoked by clients in the context of some broader, perhaps long-running activity. Both AcceptEventAction and AcceptCallAction have trigger: Triger properties whose event: Event could be a SignalEvent or CallEvent respectively. A BehavioredClassifier should indicate to clients its ability to receive the corresponding SignalEvent or CallEvent by including an ownedTrigger designating the event it is prepared to receive.

    However, there is no notation specified for BehavioredClassifier::ownedTrigger. In addition, there are other ways to specify the ability to receive signal and/or call events that may make ownedTrigger redundant. The ability to receive a SignalEvent can be denoted by an ownedReception: Reception in a Class. The notation for an ownedReception is a <<signal>> Operation where the operation name is the Signal name, and the in parameters provide the values for the signal's ownedAttributes. There can be no inout, out, or return parameters, and no raisedExceptions. An ownedOperation is all that is needed to indicate the ability to receive a CallEvent.

    The metamodel for ownedTrigger needs to be reconciled with ownedOperation and ownedReception. Perhaps the notation should provide a way to distinguish operations that invoke behaviors and operations that indicate the ability to respond to call events as <<trigger>> operations.

  • Reported: UML 2.0 — Wed, 1 Mar 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: A classifier declares its “willingness” to handle events by its behavioral features. Currently there are two such features: Operations and Receptions. The former declares that the classifier will handle call events, the latter that the classifier handles signal events. These are the only kinds of events that can be caused by other objects. The issue requests another mechanism to accomplish the same thing without explaining why a second mechanism is required to accomplish what behavioral features already accomplishing. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2/Templates -- single argument?

  • Key: UML22-1083
  • Legacy Issue Number: 9398
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    A TemplateParameterSubstitution corresponds to exactly one template parameter, but the metamodel allows multiple actual arguments to be supplied for the parameter. There does not seem to be any compelling reason for multiple arguments to be provided for a single template parameter in a substitution (nor are the semantics of this clearl). Therefore, the multiplicity of TemplateParameterSubstitution::actual and Template ParameterSubstitution::ownedActual should be restricted to [1].

  • Reported: UML 2.0 — Fri, 24 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use the new 'dot' notation in examples

  • Key: UML22-1082
  • Legacy Issue Number: 9373
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Currently there is only one example of its use. However most of the examples have taken an unadorned line to indicate that both ends are owned by the respective classes: now the same diagram indicates both ends are owned by the association. Though tools may be at liberty to hid the adornments the spec itself should be extremely precise in the examples and show the adornments explicitly since otherwise the diagrams are ambiguous.
    Note that the conventions in 6.5.2 explicitly apply only to the diagrams for the metamodel itself (see line 1 of 6.5.2).

  • Reported: UML 2.0 — Thu, 23 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This is a duplicate of issue 9372

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Join node edge constraint

  • Key: UML22-1099
  • Legacy Issue Number: 9867
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Join node edge constraint. Join node should have a constraint between the incoming and outgoing flow kinds (control vs data).

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Constraint [2] in Section 12.3.34 (JoinNode) of formal/2007-02-03 already says “If a join node has an incoming object flow, it must have an outgoing object flow, otherwise, it must have an outgoing control flow.” Since the intent is to allow a join node to have both incoming control and object flows, it is not clear what other constraint might be needed. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Offer ordering on joins

  • Key: UML22-1098
  • Legacy Issue Number: 9866
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Offer ordering on joins. Is the ordering of offers from joins the same as they were offered to the join?

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    According to the Semantics in Section 12.3.34 (JoinNode) of formal/2007-02-03: “Tokens are offered on the outgoing edge in the same order they were offered to the join.” Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Multiple activity parameters nodes for a single inout

  • Key: UML22-1097
  • Legacy Issue Number: 9865
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Multiple activity parameters nodes for a single inout. Can there be multiple activity parameters nodes for a single inout parameter? If not, the node will have both incoming and outgoing edges, which violates constraint [3] of ActivityParameterNode.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    There is nothing that prevents a single inout parameter having multiple activity parameter nodes, one with outgoing flows and one with incoming flows. Further, the semantics for activity parameter nodes deals with this case consistently. However, there are actually no limits on the number of activity parameter nodes for a parameter at all, without clear semantics for the general case.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A notation for Trigger

  • Key: UML22-1088
  • Legacy Issue Number: 9750
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    My new question is about the notation for Trigger. In on ehand, I understand the notation as described in section 13.3.31 (p. 475) for specifyng the trigger of a transition in a statemachine (even if it is not so clear because the notation for Trigger refers in fact to the notation of event (p475) ?). But how is it possible to describe the Trigger owned by a classifier? What is the notation for a class to specify which Trigger a class is owning?
    In previous version of UML, it was clear in my head (it does no harm just this once that the description of the behavioral features (either Operations, or Receptions) of a class was implicitly the description of what kind of events a class may reponse to. But now, one hand a class specify its behavioral features, but what happen with its Triggers? Is the description of the behavioral features of a class the implicit description of its Triggers? But in this case, as Trigger are linked to Events, what is the need this intermediate concept of Triggers?

  • Reported: SysML 1.0b1 — Thu, 18 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This issue is an identical duplicate, submitted by the same author, as issue 10777

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.13 - connectors

  • Key: UML22-1087
  • Legacy Issue Number: 9619
  • Status: closed  
  • Source: Unisys ( Paul Koerber)
  • Summary:

    Connectors cannot be properly represented in a UML model using only constructs available in Compliance Level 1. The Connector class is part of the InternalStructures package which is in Level 1. The class that can own Connectors is StructuredClassifier through the ownedConnector association. This class is also in Level 1 but is abstract. All non-abstract subclasses of StructuredClassifer (such as Collaboration and EncapsulatedClassifier) are in Level 2. Because of this there is no class that can own Connector instances in a model that uses only Level 1 constructs. Therefore Connectors can’t be used in a Level 1 compliant model

  • Reported: UML 2.1 — Mon, 8 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: This was a decision made in the design of UML 2. A tool that wants to offer internal structure with only compliance level 1 would have to at least define a profile that introduces a concrete subtype of StructuredClassifier. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Semantics of fork node wording

  • Key: UML22-1096
  • Legacy Issue Number: 9864
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Semantics of fork node wording. The semantics for fork node should say it copies the tokens onto outgoing edges. The wording currently used is the same as initial node and decision node, which do not copy tokens ("offered to all outgoing edges")

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The Semantics for ForkNode (formal/2007-02-03, Section 12.3.30) begins: “Tokens arriving at a fork are duplicated across the outgoing edges.” The fact that tokens are duplicated by a fork node is emphasized several times in the subsequent text. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ReadLinkAction

  • Key: UML22-1095
  • Legacy Issue Number: 9859
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    ReadLinkAction. In Actions, ReadLinkAction, Semantics, second paragraph, before the fourth sentence (the one starting "The multiplicity of"), add the sentence "The order of the retrieved values in the output pin is the same as the ordering of the values of the links." This aligns with the text added to ReadStructuralFeatureAction and ReadVariableAction by issue 8036 in the UML 2.1 RTF.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Weight notation

  • Key: UML22-1094
  • Legacy Issue Number: 9857
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Weight notation. In Activities, ActivityEdge, Notation, Package CompleteActivities subheading, the text in the first paragraph about weight notation is inconsistent with the figure below it.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Correct text as below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Weight description

  • Key: UML22-1093
  • Legacy Issue Number: 9856
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Weight description. In Activities, Attribute and Semantics sections, the description of weight in these are not the same. Should be as in the Semantic section.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Fix the Associations and Semantics headings under Section 12.3.5, ActivityEdge

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-1092
  • Legacy Issue Number: 9855
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    StructuredActivityNode. In Activities, StructuredActivityNode, Semantics, Package CompleteStructuredActivities subheading, first sentence, replace "An object node attached to" with "The contents of an input pin of".

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The remainder of the paragraph discusses both input and output pins on structured activity nodes. Both input and output pins are “accessible” within the structured activity node, in the sense that data can flow out of the input pin and into the output pin. Thus, the sentence should refer to all pins, not just input pins.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.11

  • Key: UML22-1091
  • Legacy Issue Number: 9821
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Semantics of ports needs to be define with regard to interfaces having attributes and associations

  • Reported: UML 2.1.1 — Mon, 12 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Attributes and associations of interfaces do not affect the semantics of ports, and thus, no further definition is required. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.11

  • Key: UML22-1090
  • Legacy Issue Number: 9814
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Could you clarify the semantics of port according to its visibility property, i.e. clarify the following sentence: "A port by default has public visibility. However, a behavior port may be hidden but does not have to be."

  • Reported: UML 2.1.1 — Fri, 9 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The last sentence was added to clarify that a port is not necessarily public, and to highlight that often behavior ports are hidden. However, as the issue submitter points out, that “clarification” is probably more confusing than it is worth. It would be better placed in the description section, but that would require explaining behavior port there. Best to drop.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.2

  • Key: UML22-1089
  • Legacy Issue Number: 9813
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    In Figure 9.4, the role name "required" of the association between Port and Interface is not at the right place.

  • Reported: UML 2.1.1 — Fri, 9 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: In the current version of the spec, the name is at the correct place. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.24 Signal (from Communications)

  • Key: UML22-1086
  • Legacy Issue Number: 9576
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Replace • signal: Signal [1] The signal that is associated with this event. with * ownedAttribute: Property[*] The owned attributes of the signal

  • Reported: UML 2.1.1 — Sun, 16 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 467, Section 13.3.24

  • Key: UML22-1085
  • Legacy Issue Number: 9514
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    On page 467, Section 13.3.24, a Signal is said to have one association:

    signal : Signal[1] The signal that is associated with this event.

    I don't understand this. A signal is associated with another signal?
    Which one? Why? Could that be incorrect?

    Perhaps a cut-and-paste error, because on the same page, Section 13.3.25,
    a SignalEvent is said to have one association:

    signal : Signal[1] The specific signal that is associated with
    this event.

  • Reported: UML 2.0 — Wed, 5 Apr 2006 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Duplicate of issue 9576

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 18.15 does not reflect the example before

  • Key: UML23-53
  • Legacy Issue Number: 13860
  • Status: closed  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    Figure 18.15 does not reflect the example before. The property names "wrap" and "resolution" do not match. Moreover, a link is missing from :Extension to :Class which has the "metaclass" and "extension" as a role names

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

The XMI document contains elements which should be

  • Key: UML23-52
  • Legacy Issue Number: 13857
  • Status: closed  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    The XMI document contains "<ownedMember>" elements which should be "<packagedElement>" due to the change in the abstract syntax (see Fig. 18.2). Actually, Eclipse UML support correctly exports "<packagedElement>". The same holds for all other XMI documents.

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

chapter 2.2, p.3 Last paragaph, second sentence

  • Key: UML23-47
  • Legacy Issue Number: 13846
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    chapter 2.2, p.3 Last paragaph, second sentence: "Note that each of the four packages..." There are more than four packages.

  • Reported: UML 2.2 — Mon, 30 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

"Associations" part of the "9.10.3 Slot" chapter/section

  • Key: UML23-46
  • Legacy Issue Number: 13834
  • Status: closed  
  • Source: Thales Rail Signalling Solutions ( Stoica Alexandru)
  • Summary:

    In the "Associations" part of the "9.10.3 Slot" chapter/section the text : "• value : InstanceSpecification [*]" should be changed to : "• value : ValueSpecification [*]" according to the diagram provied at page 54.

  • Reported: UML 2.2 — Wed, 25 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

In paragraph 4, the text should read "Class has a derived association ...". Currently, the sentence is missing "a".

  • Key: UML23-44
  • Legacy Issue Number: 13799
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    In paragraph 4, the text should read "Class has a derived association ...". Currently, the sentence is missing "a".

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

In paragraph 2, the package reference to InfrastructureLibrary::Constructs::Class omits intermediate package "Core"

  • Key: UML23-43
  • Legacy Issue Number: 13798
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    In paragraph 2, the package reference to InfrastructureLibrary::Constructs::Class omits intermediate package "Core".

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

18.3.6 Typo in Profile section

  • Key: UML23-50
  • Legacy Issue Number: 13853
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Third paragraph below Figure 18.8, second word: isStrict instead of isStric

  • Reported: UML 2.2 — Sun, 5 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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: Fig. 7.15: subsets at wrong side

  • Key: UML23-49
  • Legacy Issue Number: 13852
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Subsets target and subsets source at the associations from Dependency to NamedElement are at the wrong side. They are property strings of the association ends supplier and client.

  • Reported: UML 2.2 — Thu, 2 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 13.2 shows class InfrastructureLibrary::Profiles::Element. Section 13 doesn't define a class named Element.

  • Key: UML23-41
  • Legacy Issue Number: 13796
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Figure 13.2 shows class InfrastructureLibrary::Profiles::Element. Section 13 doesn't define a class named Element. The "Generalizations" on p. 185 says it generalizes Core::Basic::Element. Is that correct? Other classes in Core::Profiles generalize a class from Core::Constructs

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Figure 13.2 shows an association between ProfileApplication and Profile that has role "appliedProfile

  • Key: UML23-42
  • Legacy Issue Number: 13797
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Figure 13.2 shows an association between ProfileApplication and Profile that has role "appliedProfile". The text on p. 196 states that the role is "importedProfile". The respective statements of subsetting also do not correspond.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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: Chapter 2.2 Compliance levels

  • Key: UML23-48
  • Legacy Issue Number: 13847
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    p.4, fig 2.2. The package L0 is missing which should also be merged into L1.

  • Reported: UML 2.2 — Mon, 30 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

In the Attributes section, "integer" should be capitalized

  • Key: UML23-45
  • Legacy Issue Number: 13800
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    In the Attributes section, "integer" should be capitalized

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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: 18.3.2

  • Key: UML23-51
  • Legacy Issue Number: 13855
  • Status: closed  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    Remove the $ character in 'extension$_' stereotypeName

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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 Profiles Issue: Stereotypes extending multiple metaclasses are ill-formed as metamodel equivalents

  • Key: UML23-23
  • Legacy Issue Number: 13482
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    (This is quite a nasty and significant issue that arose from discussions of issues raised on the UPDM profile. It may well be declared as Urgent.)

    (start of issue)

    The Profiles chapter claims in a few places (with an example in Figure 18.16) that it’s possible to have a single Stereotype extend many metaclasses. However this is contradicted by the description of Stereotype semantics defined by means of a MOF metamodel equivalent (in Figure 18.4) which shows a ‘base_Interface’ 1..1 composite ownership property on the Home Stereotype. Which makes intuitive sense since you cannot have a free-floating stereotype instance (unattached to any element). However in the case of a Stereotype extending 2 metaclasses this would result in it having 2 mandatory composite owners (e.g. for the example in Figure 18.16 base_Class and base_Component) – which is not permitted (you could never have a valid model since an instance can only ever have one composite owner) and would not make sense (it would require each instance of the Stereotype to be attached to 2 distinct model elements – each property is mandatory).

    This 1..1 property is also reflected in the XMI serialization of a Profile (in 18.3.6) that makes the multiplicity of the base_Interface property 1..1 (by default). And in the Profile XSD where the xsd:element and xsd:attribute are again 1..1 (by default).

    Note that this issue also arises when a Stereotype inherits from another Stereotype and they both extend different metaclasses. This situation could however be addressed in the restricted case that one metaclass is a specialization of the other and by declaring that one property redefined the other. For example assume we modify Figure 18.16 to have an additional Stereotype SuperClock which generalizes Clock and extends Class (instead of Clock directly extending Class). We could then define that Clock::base_Component

    {redefines} SuperClock::base_Class. Thus the Stereotype Clock ends up with only one composite owner property.



    It seems there are two main options, one with variants, for addressing the general problem:



    A) Prohibit a stereotype extending more than one metaclass. Or restrict to the special case above where one base_X property can redefine the other.

    I’m not sure how useful it is to have Stereotypes extending multiple metaclasses anyway since one could always declare common properties on an abstract Stereotype with specialized concrete stereotypes each extending a single metaclass. Extending multiple metaclasses also gives rise to potential problems of how to express constraints – which typically require navigation to the extended element and use of its properties: if there are multiple such navigations and different properties at the target element this becomes tortuous to say the least. However I’m sure there are such profiles out there so this will ‘break’ those (despite the fact that they are inherently ill-formed anyway according to profile semantics)

    B) Modify the ‘MOF equivalent metamodel’ and the XMI and XSD rendition of Profiles to make the base_X property 0..1 instead of 1..1. This would need to be combined with a somewhat-tortuous-to-express (especially if there are more than 2 metaclasses extended) constraint that exactly one of the base_X properties (including those inherited from other Stereotypes) must be non-empty. And this constraint could not be expressed in the XSD (not that XSDs are very good for validation anyway).

    C) A variant of B) is to make the base_X property optional only if the Stereotype extends more than one metaclass (including those inherited). This would minimize the impact for the vast majority of existing profiles. However there are complications. In particular it would require redefinition of properties from general stereotypes which extend a single metaclass. In the above extended example with SuperClock, since that extends only one metaclass then SuperClock::base_Class would be defined as 1..1 as in the current specification. However Clock, in addition to defining Clock::base_Component[0..1] would also require Clock::base_Class[0..1} {redefines}

    SuperClock::base_Class. This however only works because Component specializes Class. In the general case (for example if SuperClock extended Package) then redefinition would not be possible and SuperClock::base_package would have to be changed to be optional. This violates the general design principle that extending something should not change it.

    D) Due to the complications with C), a further variant of B) is to make explicit the multiplicity of the base_X property, in the same way that it can be made explicit for

    {required}

    stereotypes. So SuperClock::basePackage may be explicitly declared to be 0..1. If defaulted to 1..1 then that prohibits it from being specialized – except by a stereotype which extends a subclass of Package and {redefines) SuperClock::basePackage with a [0..1] property. So that makes the use of [1..1] for base_X the equivalent of declaring in Java that the Stereotype is ‘final’ and cannot be extended.

    To summarize the impact of these options on existing profiles:

    A) Requires a change only for Stereotypes that extend more than one metaclass (directly or indirectly) and probably requires new Stereotypes to be created to cover the multiple metaclasses. In those cases it will have an impact on models applying those Steretypes (to migrate to the new Stereotype) but this is a transformation that can be easily automated.

    B) Requires a change to the XMI serialization of all Stereotypes in all existing Profiles (though not models applying those profiles) and their XSD files

    C) Requires a change only for Stereotypes that extend more than one metaclass (directly or indirectly) and requires a change to the XMI serialization of their profiles and XSD but for those stereotypes only and possibly their general stereotypes (which could be in another Profile: I think though the only case I’m aware of that does this is UPDM itself which has not yet been Finalized).

    D) Has the same impact on existing profiles as C), but has the benefit of simpler and more predictable generation rules.

    Option A) has the advantage of retaining the current simple 1..1 structural constraint which is amenable to MOF and XSD validation without the need for OCL support. The other options make it harder to validate that an instance of a stereotype is applied to exactly one instance of a UML metaclass.

    (end of issue)

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The FTF agreed that this is an issue that needs to be resolved. The solution is to provide another example in
    the specification besides the single metaclass example given in Figure 12.15 for multiple metaclass extension
    and its MOF equivalent class. Furthermore, informal constraints need to be added to the Stereotype’s
    classifier description, stating that: The upper bound of a base property is always 1
    • The multiplicity of the base property in single metaclass extension is always 1..1
    • The multiplicity of all base properties in multiple metaclass extension is always 0..1, whereas only
    one base property is allowed to contain a value at any point during runtime

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2: conflicting specifications for how to calculate context for a Behavior

  • Key: UML23-17
  • Legacy Issue Number: 13476
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    According to 13.3.2 context is calculated as follows: “If the behavior is owned by a BehavioredClassifier, that classifier is the context; otherwise, the context is the first BehavioredClassifier reached by following the chain of owner relationships.” Also according to 13.3.2 ”When a behavior is instantiated as an object, it is its own context.” These two statements are contradictory.

  • Reported: UML 2.2 — Mon, 9 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The second quoted sentence is confusing, though the intended meaning is not contradictory with the calculation of the context classifier. The intent is that, when a Behavior without a context classifier is instantiated then, at runtime, the behavior instance acts as its own context object, even though it is not its own context classifier.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

use of "internal" transition is used incorrectly in many places where "local" should be used.

  • Key: UML23-16
  • Legacy Issue Number: 13325
  • Status: closed  
  • Source: IBM ( Adam Neal)
  • Summary:

    The use of "internal" transition is used incorrectly in many places where "local" should be used. The specification should be updated to correct this inconsistencies. For example, on page (575/748) of UML2.2, it states: "An entry pseudostate is used to join an external transition terminating on that entry point to an internal transition emanating from that entry point. An exit pseudostate is used to join an internal transition terminating on that exit point to an external transition emanating from that exit point" However, internal transitions are not meant to be used in this context and must be connected directly to a state. A 'local' transition is used to navigate to a subvertex which is more the use case being described here.

  • Reported: UML 2.2 — Fri, 23 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This misuse of the term “internal transition” was rectified in UML 2.5. An inspection of the text reveals no remaining
    cases.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

default multiplicty of association ends are defined more than one

  • Key: UML23-18
  • Legacy Issue Number: 13477
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the infrastructure 6.2.1 it says

    If no multiplicity is shown on an association end, it implies a multiplicity of exactly 1.

    However, in

    8.3.3 Associations

    The opposite ends of associations connected to the class are also listed in the same way. The sub clause states if the association is derived, or if it is a specialization of another association. The multiplicity of an association end is suppressed if it is ‘*’ (default in UML).

    It appears that the default is 1 and the default is also * which is confusing.

    I believe it should be clarified something like this.

    When an association is shown as an attribute/property, the default multiplcity is the same as the default attribute/property multiplictty (1)

    When an assocation or attribute is shown as a association (that is, on the end of a line), the default multiplicity should be

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The default multiplicity is always 1.
    This text appears only in the section describing the structure and conventions used by the specification itself. Superstructure has the following similar text:
    The “Attributes” sub clause of a concept description lists each of the attributes that are defined for that metaclass. Each attribute is specified by its formal name, its type, and multiplicity. If no multiplicity is listed, it defaults to 0..*.
    Which is inconsistent with the Infrastructure text for Attributes:
    The multiplicity of the attribute is suppressed it defaults to „1? (default in UML). In practice both documents are now explicit about all association multiplicities, and suppress only attribute multiplicities of [1].

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.4 Diagrams text on page 144

  • Key: UML23-25
  • Legacy Issue Number: 13591
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    text on page 144: "Package diagram The following nodes and edges are typically drawn in a package diagram: • Dependency • Package • PackageExtension • PackageImport" Search in the document for "PackageExtension" produces a single result on this same page, which means that the term "PackageExtension" is no longer defined. Most likely, the text above should have "PackageMerge" instead, smth like: Package diagram The following nodes and edges are typically drawn in a package diagram: • Dependency • Package • PackageMerge • PackageImport

  • Reported: UML 2.2 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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 Beta1 Figure 12.18 is misleading about Parameter::effect : ParameterEffectKind [0..1]

  • Key: UML23-24
  • Legacy Issue Number: 13543
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Specification: UML 2.1 Beta 1 (2008/05/01)

    Section: 12.2 Activities (Abstract Syntax), Figure 12.18

    Summary:

    This figure shows Parameter::effect : ParameterEffectKind in a way that suggests that its multiplicity is [1..1] when in fact it is [0..1]. Also, the figure incorrectly shows an Eclipse ECore stereotype, <<eAttribute>>.

    Proposed Resolution:

    In Figure 12.18:

    • Remove the <<eAttribute>> stereotype notation for the Parameter::effect attribute
    • Show the multiplicity of the attribute explicitly, i.e.: effect : ParameterEffectKind [0..1]
  • Reported: UML 2.2 — Tue, 24 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This issue is obsolete. The attribute Parameter::effect is shown on Figure 9.9 in the UML 2.5 specification, and the
    problems identified in the issue have already been resolved.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 12.95 - "Fork node example"

  • Key: UML23-28
  • Legacy Issue Number: 13659
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Figure 12.95 - "Fork node example" shows "Fill Order" twice, while it should show - as explained right above - that when "Fill Order" is completed, "Ship Order" and "Send Invoice" get control.

  • Reported: UML 2.2 — Thu, 5 Mar 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    See issue 10818 (resolved in UML 2.3) for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 : Lifeline identity for InteractionUse

  • Key: UML23-27
  • Legacy Issue Number: 13653
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Section 14.3. 18 says “An InteractionUse refers to an Interaction. The InteractionUse is a shorthand for copying the contents of the referred Interaction where the InteractionUse is.” What is the relationship of the Lifelines in the used interaction to those in the using interaction? Are they supposed to be the very same lifeline instances, or are they matched by name?

  • Reported: UML 2.2 — Mon, 2 Mar 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    UML 2.5 added constraints on covered lifelines of interactionUse stating “Lifelines are common if they have
    the same selector and represents associationEnd values.” It also clarified that selector values are constrained
    to be LiteralString or LiteralInteger
    However, it is necessary to fix some Bugs in the new lifeline and interactionUse constraints. Fix constraint
    interaction_uses_share_lifeline of lifeline and all_lifelines of interactionUse to ensure coverage of Literal-
    Integer Selector value. Also Fix selector_int_or_string constraint to properly cover both LiteralInteger and
    LiteralString options for Selector value.
    This resolution also incorporates the change from Issue 18465, which proposes changing
    : “x.oclIsKindOf(T)->notEmpty()” To: “x.oclIsKindOf(T)’’

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In the XMI, Ownerships::Element erroneously includes an association for ownedComment.

  • Key: UML23-22
  • Legacy Issue Number: 13481
  • Status: closed  
  • Source: N/A ( Rob Grainger)
  • Summary:

    In the XMI, Ownerships::Element erroneously includes an association for ownedComment. Similarly, the XMI for this package includes an association A_ownedComment_owningElement. These more properly belong in the Comments package of Abstractions.

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

In the XMI, Ownerships::Element fails to include a superClass attribute for Elements::Element

  • Key: UML23-21
  • Legacy Issue Number: 13480
  • Status: closed  
  • Source: N/A ( Rob Grainger)
  • Summary:

    In the XMI, Ownerships::Element fails to include a superClass attribute for Elements::Element

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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.8.3 XMI fails to include a "lower" attribute

  • Key: UML23-20
  • Legacy Issue Number: 13479
  • Status: closed  
  • Source: N/A ( Rob Grainger)
  • Summary:

    The XMI for the various operations integerValue, booleanValue, stringValue and unlimitedValue fails to include a "lower" attribute, so the default of [1..1] is assumed.

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

The UML XMI fails to include an ownedRule for the Constraint specified for an OpaqueExpression

  • Key: UML23-19
  • Legacy Issue Number: 13478
  • Status: closed  
  • Source: N/A ( Rob Grainger)
  • Summary:

    The UML XMI fails to include an ownedRule for the Constraint specified for an OpaqueExpression

  • Reported: UML 2.2 — Wed, 11 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

"Table 7.3 - Graphic paths included in structure diagrams" on pp.143-144

  • Key: UML23-26
  • Legacy Issue Number: 13592
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    "Table 7.3 - Graphic paths included in structure diagrams" on pp.143-144 includes PackageImport but does not include ElementImport, described in "7.3.15 ElementImport (from Kernel)". It is also missing on p.144 in: "Package diagram The following nodes and edges are typically drawn in a package diagram: • Dependency • Package • PackageExtension • PackageImport" It should look smth like: "Package diagram The following nodes and edges are typically drawn in a package diagram: • Dependency • Package • PackageMerge • PackageImport • ElementImport

  • Reported: UML 2.2 — Fri, 27 Feb 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Statemachine diagram in section 15.3.12 diagram 15.42 (and the text above)

  • Key: UML23-15
  • Legacy Issue Number: 13324
  • Status: closed  
  • Source: IBM ( Adam Neal)
  • Summary:

    In the Statemachine diagram in section 15.3.12 diagram 15.42 (and the text above) it is specifying the use of 'final' to define that a redefinable element (state or transition in this case) can not be redefined. However, there is no other mention of this 'final' in the rest of the document (maybe its leftover from before?). RedefinableElement's have an isLeaf attribute which is used to determine this property. Therefore we should probably use

    {leaf}

    .

  • Reported: UML 2.2 — Fri, 23 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 12380

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Propagate RTF 2.3 changes to Infrastructure

  • Key: UML23-88
  • Legacy Issue Number: 14116
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    "Some of the resolutions that affected the superstructure doc in RTF 2.3 also have implications for Infrastructure. Please do the proper changes to Infrastrcture to keep the two documnets in sync"

  • Reported: UML 2.2 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This is confirmed. All the relevant changes are proposed below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need to copy down merged content to make constraints parse in receiving package

  • Key: UML23-87
  • Legacy Issue Number: 14115
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    "Currently in the metamodel:

    1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::attribute

    2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else.

    A question: is the subsetting in 1 valid?

    The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::attribute is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel.

    So to make things consistent, as Nic said, we should:

    • Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier
    • Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute.

    in addition:

    • don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures?
    • Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration".
    • So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. "
  • Reported: UML 2.2 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    For chapter 8, this resolution incorporates part of the resolution from the accepted resolution 7364, but modifies it in order to copy down the merged class and features required for the OCL constraint to parse in the context of the receiving package.
    For chapter 9, it sorts out InternalStructures::Classifier, which was introduced according to this "copy down" principle, but is not documented properly. Also Collaborations::Classifier inherits more than is necessary, so to simplify the overall documentation of Classifier in chapter 9, we can make both InternalStructures::Classifier and Collaborations::Classifier just specialize Kernel::Namespace.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove InputPint from StructuredActivities

  • Key: UML23-86
  • Legacy Issue Number: 14114
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    My inclination would be to remove StructuredActivities::InputPin, and have it only in CompleteStructuredActivities, with OutputPin in both StructuredActivities and CompleteStructuredActivities. The constraints, if they are in the model at all in their unformalized form, should only be on the InputPin and OutputPin classes in CompleteStructuredActivities. Then we can deal as a separate issue with the proper constraints for flows into and out of OutputPins and InputPins at L1 and L2."

  • Reported: UML 2.2 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Make InputPin only coming from CompleteStructuredActivities (and remove it from StructuredActivities in the metamodel).
    Then, for OutputPin sections add "Package CompleteStructuredActivities" as a subheading for the constraint (and move it in the metamodel to the counterparts in that package).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

BNF of Constructs::Property

  • Key: UML23-85
  • Legacy Issue Number: 14093
  • Status: closed  
  • Source: n/a ( Jonas Gorski)
  • Summary:

    The BNF of Constructs::Property defines <Visibility> ::= '+' | '-' clearly missing the package and protected visibilities. This Contradicts the Superstructure in 7.3.44, where the BNF states all four visibilites.

  • Reported: UML 2.2 — Fri, 24 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Ambiguity in the names of the stereotypes in the standard profiles

  • Key: UML23-84
  • Legacy Issue Number: 14092
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Specification: UML Superstructure, v2.2

    Section: Annex C, Standard Profiles

    It is not clear what the names actually are of the stereotypes in the standard profiles of UML. The stereotypes are listed in Annex C as they would be applied (using guillemet notation). However, Subclause 18.3.8 has the style guideline: “The first letter of an applied stereotype should not be capitalized.” Due to the above style guideline, this leaves it ambiguous as to whether the actual stereotype model element is named “metaclass” or “Metaclass”. This affects XMI serialization of an application of the stereotype, because the XML element for the stereotype should use the actual stereotype model element name.

    Indeed, as a classifier, the normal practice would be for its name to be capitalized but it would then still be allowable to display this on the diagram using a lower case letter, as in «metaclass». Unfortunately, there is no normative XMI for the standard profiles, so there is currently no way to resolve this based on the normative standard.

  • Reported: UML 2.2 — Wed, 22 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The resolution is to provide normative XMI for the standard profiles, and to fix up the document accordingly. In order to do this properly we need to resolve 13306 by shipping a normative version of the UML metamodel expressed in UML. Having done this we can resolve 14092 by shipping standard profiles that refer to this normative UML metamodel.
    We change the convention so that references to stereotypes are shown with upper case letters, and change all the examples accordingly, fixing errors as we go.
    We permit lower case references but remark that they are stylistically obsolete.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The primitive types in the UML 2.3 infrastructure.xmi are private; they should be public

  • Key: UML23-91
  • Legacy Issue Number: 14192
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    In the SysML 1.2 RTF, we found a small bug in the normative UML 2.3 infrastructure.xmi here:
    https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Specification/Deliverables/UML2.3%20Normative%20XMI.zip

    The bug is described at the bottom of the SysML 1.2 RTF wiki page where I described how I adapted Maged’s excellent instructions for generating the normative UML 2.3 xmi to SysML 1.2.
    It was a bit more complicated for SysML 1.2 because we added an OCL constraint in SysML issue 11091 that required the same “copy down” package merge trick we did for UML issue 7364.
    Fortunately for SysML, it was easier for us since we had to mimick what we did in UML. Nonetheless, we should do something to avoid these annoying last-minute surprises.

  • Reported: UML 2.2 — Thu, 13 Aug 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Difference between OCL and text in constraint [2] of 15.3.15

  • Key: UML23-90
  • Legacy Issue Number: 14135
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Constraint [2] in 15.3.15 says:

    [2] A transition with kind external can source any vertex except entry points.
    context Transition inv:
    source.oclIsKindOf(Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::entryPoint implies kind = TransitionKind::local)

    • Is the text and OCL saying that same thing? I think the text is saying "A implies not B", while the OCL is saying "B implies C", where:

    A : kind = TransitionKind::external
    B : source.oclIsKindOf(Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::entryPoint
    C: kind = TransitionKind::local (this is not the oppsite of "A" as there is a third kind of transition "internal")

  • Reported: UML 2.2 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This constraint should be fixed to match the text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove redundantant constraint [2] in 7.3.4

  • Key: UML23-89
  • Legacy Issue Number: 14123
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    "Actually, reading 7.3.8 Classifier [8], I realize that the constraint in the resolution 9374 is superfluous since [8] already prevents a Class from specializing an AssociationClass or an Association from specializing an AssociationClass.

    So, the options are:

    1) leave the constraint editorially fixed as we did and file an issue to remove it at the next RTF
    2) cancel the editorial fix and editorially remove the (superfluous) constraint from 9374

    Either way is fine with me but I think that option (2) is better than (1)."

  • Reported: UML 2.2 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.2 Issue - availability of PrimitiveTypes for UML models

  • Key: UML23-73
  • Legacy Issue Number: 13993
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The introduction to section 17.4 states the following:

    A number of primitive types have been defined for use in the specification of the UML metamodel. These include

    primitive types such as Integer, Boolean, and String. These types are reused by both MOF and UML, and may potentially

    be reused also in user models.

    However the XMI for UML provides the definitions only as CMOF types not as UML types – so they cannot reliably/interchangeably be used/reused or referenced from user models. There would also need to be a normative URI defined for them.

  • Reported: UML 2.2 — Mon, 15 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Indeed for better interchange of UML user models, there needs to be a normative PrimitiveTypes package (with a normative URI) with the common primitive types that can be referenced by UML XMI documents.
    Additionally, since such primitive types are also needed by almost all CMOF-based metamodels, a PrimitiveTypes CMOF package is needed. Unfortunately, the PrimitiveTypes package provided in the InfrastructureLibrary is meant to be package merged vs. referenced by metamodels. Since only few metamodels merge it (still resulting in private copies), the rest duplicate these primitive types in their context.
    This resolution proposes moving the PrimitiveTypes package out of InfrastructureLibrary.cmof and into its own independent package (PrimitiveTypes.cmof). This package can then be referenced instead of copied (through package merge) by metamodels. Additionally, the package can also be exported in UML XMI as PrimitiveTypes.xmi, to be referenced by user models.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

lowerBound/upperBound constraints and derivations wrong

  • Key: UML23-72
  • Legacy Issue Number: 13992
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Issue on UML 2.2 Superstructure, Section 7.3.32:

    1. There are 2 constraints numbered [1]

    2. The 2nd of these is: lowerBound()->notEmpty() implies lowerBound() >= 0.

    However the way lowerBound() is defined (operation [4]) means it can never be empty: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif

    It makes more sense to have the constraint condition apply to the stored lowerValue. i.e. lowerValue()->notEmpty() implies lowerBound() >= 0

    3. Likewise constraint [2] should be: upperValue()->notEmpty() implies upperBound() >= lowerBound()

    4. Note that this omits the test currently in constraint for lowerValue notEmpty since lowerBound will then default to 1 – and it’s necessary to have the constraint check that upperValue is not less.

    5. /upper and /lower are defined as [0..1]. However since they are defined in terms of upper/lowerValue – which always has a value - then they will never be empty so should be declared as [1].

  • Reported: UML 2.2 — Mon, 15 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    1. This is no longer relevant in UML 2.5.
    2. Actually, lowerBound can be empty, because lowerValue.integerValue() will be empty if lowerValue does
    not have an integer value. Redefining lowerBound() to check if lowerValue.integerValue() is null, rather
    than just lowerValue, would ensure that lowerBound always was non-empty. With this change, simply
    lowerBound() >=0 would be sufficient for the constraint. (But see also the resolution to Issue 17583.)
    3. Similarly changing the definition of upperBound() to check upperValue.unlimitedValue() would mean
    that upperBound() >= lowerBound() would be sufficient as the constraint.
    4. Actually, including the constraint upperValue->notEmpty() is not correct. Because if the upperValue is
    empty, then upperBound() defaults to 1, which still needs to be greater than or equal to lowerBound().
    5. Actually, upper and lower are defined in terms of upperBound() and lowerBound(), not upperValue
    and lowerValue. Modified as described above, those operations will always return a value. So, the return
    parameters for upperBound() and lowerBound() should have multiplicity 1..1, as well as the attributes upper
    and lower.
    This also resolves Issue 17808.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2: Missing semantics in definition of RedefinableTemplateSignature with multiple parents

  • Key: UML23-81
  • Legacy Issue Number: 14065
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In RedefinableTemplateSignature.Associations we have this

    extendedSignature : RedefinableTemplateSignature[*] The template signature that is extended by this template signature. Subsets RedefinableElement::redefinedElement.

    It should read “The template signatures that are extended ...”

    Similarly the constraint says:

    The inherited parameters are the parameters of the extended template signature.

    And should read “extended templates signatures”.

    More seriously, the semantics says nothing about what happens when more than one of the extended template signatures have parameters with the same name. Is it an error? Are they merged (in which case what happens if they are different types)? Are they all there in which case what is the syntax for differentiating them? (e.g. Super1::T : Class, Super2::T : Class)

  • Reported: UML 2.2 — Fri, 10 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Correct the plurals, and explain that qualified names will be used to differentiate in the case of clashes. Fix
    the logic of qualified names so that template parameters have them. This is a bit tricky because TemplateParameter,
    TemplateSignature, TemplateableElement and ParameterableElement do not specialize NamedElement.
    The approach adopted is to change the allNamespaces() operation on NamedElement so that if the
    template is a namespace, it is used as the enclosing namespace for the ParameterableElement, which is in
    fact guaranteed to be a NamedElement because all specializations of ParameterableElement are

  • Updated: Fri, 6 Mar 2015 20:58 GMT

remove StructuredActivities::ActivityGroup

  • Key: UML23-80
  • Legacy Issue Number: 14063
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The fact that StructuredActivityNode specializes ExecutableNode but does not specialize Action in figure 12.21 is intentional. The StructuredActivities package is merged into L2, and at this level it is intended that “simple” structured nodes be usable on activities without being actions themselves, without pins, etc. This is to support a “procedural” style of the use of actions (along with the use of variables, sequence nodes and value pins).

    It is only in CompleteStructuredActivites (figure 12.22) that StructuredActivityNode specializes Action. CompleteStructuredActivities is merged into L3. As a result, at this level, StructuredActivityNode ends up specializing both ExecutableNode and Action, even though this is redundant. But I don’t think it is avoidable if the structured nodes are to be kept as non-actions in StructuredActivities and L2.

    Finally, the extra ActivityGroup element that appears on figure 12.21 seems to be completely irrelevant. ActivityGroup already has an association with Activity as originally defined in FundamentalActivities, so the merge increment doesn’t seem to add anything. And, as you note, StructuredActivityNode doesn’t even specialize it. My (unresearched) guess is that there was a change at some point to have StructuredActivityNode specialize FundamentalActivities::ActivityGroup rather than the StructuredActivities::ActivityGroup merge increment, and then the latter was just never removed (and remained unnoticed in its little corner of the diagram!).

    So, I think the class description text is OK, but there should be an issue filed to remove StructuredActivities::ActivityGroup – it is probably more than should be done “editorially”. But this is not particularly urgent, since the extra ActivityGroup merge increment on figure 12.21 doesn’t actually hurt anything in the end.

  • Reported: UML 2.2 — Tue, 7 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    See issue 15264 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profile::allOwningPackages

  • Key: UML23-83
  • Legacy Issue Number: 14083
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    I noticed that in section 18.3.6 (as well as Infrastructure 13.1.6) the addition operation allOwningPackages is defined in the namespace of NamedElement and not Profile. In the metamodel, this operation is defined in InfrastructureLibrary::Profiles::NamedElement, which is a class that is not defined in the spec doc in clause 18 (neither in clause 13 in InfrastructureLibrary).

    Shouldn't there be a section NamedElement in clause 18 (superstructure) and clause 13 (infrastructure libary) to define this additional operation, as implemented by the metamodel now? (since the operation is already defined in that namespace)

  • Reported: UML 2.2 — Thu, 16 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Properties need not be owned

  • Key: UML23-82
  • Legacy Issue Number: 14066
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Based on UML 2.2 Diagram 9.2, it appears that Property is optionally part of StructuredClassifer. Now I understand that Properties may also be part of other things (such as associations and interfaces). But it appears that in all such places such ownership is optional.

    As Properties are features, looking at the multiplicity on Feature, we see Feature:featuring Classifier is 0..*. This means that Properties (and other features) need not be part of anything.

    So can you have a “free-floating” property? Where can you put it? Since Properties are not packagable, they can’t be owned by Packages.

    There are (at least) two ways of solving this (I prefer the first)

    1) Make properties packageable. This gives us the advantage of making a package or model-library of constants properties.

    2) Fix the hole and make properties required to be owned by something.

    A nearly identical argument arises from Connectors which also may be free-floating, but are not packageable.

    In SysML there is some interest in making connectors packageable (possibly as we care not about code-generation in the UML sense) as it would allow us to use Binding connectors (a SysML type of connector that declares equivalence) in package or class (in SysML, Block) diagrams

    Again there are two ways of solving this (I prefer the first)

    1) Make connectors packageable.

    2) Fix the hole and make connectors required to be owned by something.

    A more general solution may be to just apply the solution strategy to features as a whole, which would minimize the changes.

  • Reported: UML 2.2 — Thu, 9 Jul 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The issue is incorrect to state that properties/connectors need not be owned. They both inherit Element::mustBeOwned(),
    which means that they must have an owner.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operation-interface should subset Feature-featuringClassifier and NamedElement-namespace

  • Key: UML23-71
  • Legacy Issue Number: 13991
  • Status: closed  
  • Source: The MathWorks ( Mr. Salman Qadri)
  • Summary:

    In UML, Operation-interface should subset Feature-featuringClassifier and NamedElement-namespace, just like Operation-class and Operation-datatype. This is needed since the opposite of Operation-interface, which is ‘Interface-ownedOperation’ subsets ‘Classifier-feature’ and ‘Namespace-ownedMember’.

  • Reported: UML 2.2 — Mon, 15 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This issue affects the XMI and the specification document of the UML2 superstructure.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2.2 chapter 16 : Actor constraint [1] has invalid OCL

  • Key: UML23-70
  • Legacy Issue Number: 13948
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Actor constraint [1] says: self.ownedAttribute->forAll ( a | (a.association->notEmpty()) implies ((a.association.memberEnd.size() = 2) and (a.opposite.class.oclIsKindOf(UseCase) or (a.opposite.class.oclIsKindOf(Class) and not a.opposite.class.oclIsKindOf(Behavior))))

    But Actor has no ownedAttribute property, so this constraint is ill-formed.

  • Reported: UML 2.2 — Mon, 8 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 10780

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2: error in definition of Class::nestedClassifier

  • Key: UML23-76
  • Legacy Issue Number: 14021
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Class::nestedClassifier currently reads:

    nestedClassifier: Classifier [*] References all the Classifiers that are defined (nested) within the Class. Subsets Element::ownedMember

    Element::ownedMember does not exist. It should say Subsets Namespace::ownedMember.

  • Reported: UML 2.2 — Tue, 23 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    See issue 10829 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

confusion re diagram on p. 83

  • Key: UML23-75
  • Legacy Issue Number: 13995
  • Status: closed  
  • Source: SocialCanvas ( Paul Quinn)
  • Summary:

    The diagram on page 83 states that Classifier generalises Namespace, but the text of 9.19.1 states that Classifier (as specialized) generalises Classifier. Which is it? Should it be both?

  • Reported: UML 2.2 — Tue, 16 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Currently is it possible for a Classifier to specialize the same classifier directly more than once

  • Key: UML23-79
  • Legacy Issue Number: 14035
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Currently is it possible for a Classifier to specialize the same classifier directly more than once, that is, generalization.general contains duplicates. There should probably be a constraint to make this invalid.

  • Reported: UML 2.2 — Mon, 29 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This seems harmless. Also, there might be scenarios where the same pair of classifiers are related by more than one
    generalization each associated with different GeneralizationSets. Prohibiting this might also invalidate existing models
    unnecessarily.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

nestedClassifier

  • Key: UML23-77
  • Legacy Issue Number: 14023
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    the definition of nestedClassifier is misleading. Maybe something like: "Classifier definitions owned by the class. Subsets NameSpace::ownedMember" would be better.

  • Reported: UML 2.2 — Tue, 23 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Rephrase the metamodel documentation, and remove a difficult-to-parse and redundant sentence from the
    semantics.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 9.9 should classifier be added to the diagram on p 50?

  • Key: UML23-74
  • Legacy Issue Number: 13994
  • Status: closed  
  • Source: SocialCanvas ( Paul Quinn)
  • Summary:

    The diagram on page 50 shows that a Classifier is generalized from Type , whereas the accompanying text states that Classifier is generalized from Type AND Classifier (as Specialized). Should Classifier (as Specialized) be added to the diagram? Thanks, Paul

  • Reported: UML 2.2 — Tue, 16 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

type mismatch

  • Key: UML23-78
  • Legacy Issue Number: 14034
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Classifier::parents() is defined as "parents = generalization.general". However there is a type mismatch: the operation return type is a Set whereas the expression is a Bag. It should be defined as "parents = generalization.general->asSet()".

  • Reported: UML 2.2 — Mon, 29 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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.48 on page 412

  • Key: UML23-32
  • Legacy Issue Number: 13718
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    Spec. version 2.2 ptc/2008-05-xx

    Regarding section 12.3.48 on page 412, I believe that both StructuredActivityNode::node and StructuredActivityNode::edge should also subset Namespace::ownedElement.

  • Reported: UML 2.2 — Fri, 13 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Agreed, except that the reference would normally be to just Element::ownedElement, especially since this is inherited from multiple immediate superclasses of StructuredActivityNode.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 7.1 shows no dependency

  • Key: UML23-34
  • Legacy Issue Number: 13789
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Paragraph 1: The text states that Figure 7.1 shows a dependency between Profiles and Core. Figure 7.1 shows no dependency.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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 2.3 para 1 needs to be re-written

  • Key: UML23-33
  • Legacy Issue Number: 13788
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Paragraph 1, which appears to be copied from the Superstructure, is incorrect in this context. The Superstructure has compliance levels L0-L3, but the infrastacture only has L0 and LM. The paragraph needs to be rewritten.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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 13 "Core::Profiles" inconsistency

  • Key: UML23-40
  • Legacy Issue Number: 13795
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    The section title is "Core::Profiles". In Figure 1 on p. 27, "Core" and "Profiles" are top-level, sibling packages (and the previous paragraph states as much). Which is correct?

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Should the definition of Element state that it reuses the definition of Element from Abstractions::Elements?

  • Key: UML23-39
  • Legacy Issue Number: 13794
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Should the definition of Element state that it reuses the definition of Element from Abstractions::Elements?

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

The "Generalizations" heading is missing before the "ValueSpecification" bullet.

  • Key: UML23-37
  • Legacy Issue Number: 13792
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    The "Generalizations" heading is missing before the "ValueSpecification" bullet.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Paragraph 5: The text states that class Comment has no generalizations

  • Key: UML23-36
  • Legacy Issue Number: 13791
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Paragraph 5: The text states that class Comment has no generalizations. This conflicts with Figure 9.10 on p. 37.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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 7.3.3 : incorrect text about aggregationKind in associations

  • Key: UML23-31
  • Legacy Issue Number: 13662
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The following paragraph appears in 7.3.3: “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. The diamond shall be noticeably smaller than the diamond notation for associations. An association with aggregationKind = composite likewise has a diamond at the aggregate end, but differs in having the diamond filled in.”

    aggregationKind is a property of Property, not of Association, so this paragraph is incorrect.

  • Reported: UML 2.2 — Fri, 6 Mar 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Table 12.1 - "Graphic nodes included in activity diagrams",

  • Key: UML23-29
  • Legacy Issue Number: 13660
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Table 12.1 - "Graphic nodes included in activity diagrams", the row "ActivityNode" states: "See ExecutableNode, ControlNode, and ObjectNode." But the "ExecutableNode" row is missing in the table. The action needed is to insert another row in the table for "ExecutableNode" with smth like "See Action, StructuredActivityNode". But the "StructuredActivityNode" row is not present in the table as well. So insert another row for "StructuredActivityNode" with notation taken from p.419, Figure 12.133 "Notation for structured nodes".

  • Reported: UML 2.2 — Fri, 6 Mar 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    See issue 11162 (resolved in UML 2.3) for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Generalizations" for StructuredActivityNode on p. 417

  • Key: UML23-30
  • Legacy Issue Number: 13661
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    "Generalizations" for StructuredActivityNode on p. 417 include: • Action • ActivityGroup • ExecutableNode • Namespace but "Figure 12.21 - Structured nodes" on page 313 shows StructuredActivityNode and Action as siblings (generalization for both is ExecutableNode). So either "Action" should be removed from Generalizations for StructuredActivityNode on p. 417 or the diagram on p. 313 to be updated to show different relations between these nodes.

  • Reported: UML 2.2 — Fri, 6 Mar 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Two issues regarding Figure 10.2: 1

  • Key: UML23-38
  • Legacy Issue Number: 13793
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Two issues regarding Figure 10.2: 1) What is the "<<eAttribute>>" stereotype that's applied to Comment::body? I can't find a definition for it elsewhere in the document. 2) Why aren't the NamedElement::name and Comment::body attributes suffixed with "[0..1]"?

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Parameter is part of the BehavioralFeatures package.

  • Key: UML23-35
  • Legacy Issue Number: 13790
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Should this section be numbered 9.1.2? Parameter is part of the BehavioralFeatures package.

  • Reported: UML 2.2 — Wed, 18 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Validator issues with TestCase 2

  • Key: UML23-65
  • Legacy Issue Number: 13930
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    looked at the 7 OCL constraint failures reported in Test Case 2. There are 5 different kinds of constraints that failed. In summary I found:

    • In 2 of these it appears that the model, valid.xmi, is wrong.
    • In 2 the OCL is wrong. One can be fixed. The other should be removed from the UML spec.
    • In 1 I made a mistake when correcting an unrelated problem in the OCL.

    I'll update the Validator. If my conclusions below are correct, someone should update valid.xmi too.

    Details below:

    (Model 'TestCase2')
    Summary of Model Content:
    Total objects: 94.
    UML objects: 94
    SysML objects: 0
    The model: <uml:Model TestCase2, id=1>
    Object Inventory
    Summary of Warnings:

    • Referent not found: 0
    • Unresolved URI used for object identification: 0
    • Set members not unique: 0
    • Missing mandatory value: 0
    • No class with name specified: 0
    • Property not found: 0
    • Cannot infer class of object: 0
    • Multiplicity violation: 0
    • Type violation: 0
    • Invalid stereotype application: 0
    • No object for stereotyping: 0
    • Creation of abstract class: 0
    • OCL constraint violation: 7 <================
    • OCL execution errors: 3
    • OCL errors while evaluating derived attribute: 0
    • OCL errors due to missing derived attribute specifications: 315
    • Identical XMI attribute xmi:id used by multiple XML elements: 0
    • Expected a uml:PrimitiveType: 0
    • XMI attribute xmi:id references excessive space chars: 0

    OCL constraint violation (7)
    There are 5 variations of this error:

    1 instances of this:
    The constraint Property.redefined_property_inherited() was violated.
    View Instance 1

    2 instances of this:
    The constraint NamedElement.has_no_qualified_name() was violated.
    View Instance 1

    1 instances of this:
    The constraint Constraint.value_specification_boolean() was violated.
    View Instance 1

    1 instances of this:
    The constraint Interface.visibility() was violated.
    View Instance 1

    2 instances of this:
    The constraint RedefinableElement.redefinition_context_valid() was violated.
    View Instance 1

    The constraint Property.redefined_property_inherited() was violated.
    This one on instance 84, a Property named "redefiningProperty"

    The constraint is:
    redefinedProperty->notEmpty() implies
    redefinitionContext->notEmpty() and
    redefinedProperty->forAll(rp|redefinitionContext->
    collect(fc | fc.allParents())>asSet()>
    collect(c| c.allFeatures())>asSet()>includes(rp))

    ... 84.redefinedProperty is not empty, but 84.redefinitionContext is empty.

    In as far as this constraint is what was intended, the validator is doing the right thing. The file should specify a redefinition context. If you believe the contraint or my conclusion is incorrect, let me know. Otherwise, shall I'll write an issue against the testcase?

    The constraint Interface.visibility() was violated.
    This one on instance 29:

    The constraint is:
    self.feature->forAll(f | f.visibility = #public)

    self.feature contains one instance, named "operation1", and its visibility is not set. In as far as this constraint is what was intended, the validator is doing the right thing. If you believe the constraint or my conclusion is incorrect, let me know.

    The constraint NamedElement.has_no_qualified_name() was violated.

    This one is my mistake. I corrected an error in the derivation of qualified names, and in an unrelated act, placed that "self.name" text before the endif below. It was Set{} and should be Set{}. I'll fix the OCL in Validator and put out a new version.

    result = if self.name->notEmpty() and
    self.allNamespaces()>select(ns | ns.name>isEmpty())->isEmpty()
    then self.allNamespaces()->iterate( ns : Namespace;
    result : String = self.name | ns.name.concat(self.separator()).concat(result))
    else self.name endif <=== should be Set{}

    The constraint Constraint.value_specification_boolean() was violated.

    The constraint is:
    self.specification.booleanValue().oclIsKindOf(Boolean)

    The function booleanValue():
    result = value

    It looks like this intends to perform runtime evaluation of the OCL string in the specification property (which should more accurately be specification.body, anyway). Technically, I could do this, but there is no way to describe the evaluation in OCL, and I wouldn't really want to execute arbitrary code on my server.

    I will mark this OCL as an error, and have it return True. This OCL should be removed from the UML spec.

    The constraint RedefinableElement.redefinition_context_valid() was violated.

    After some digging I found that the definition of isRedefinitionContextValid, which is called by this was:

    redefinitionContext->
    exists(c | c.allParents()->
    includes(redefined.redefinitionContext))

    But redefined.redefinitionContext is a Collection, so the use of includes here is not correct. It should be:

    redefinitionContext->
    exists(c | c.allParents()->
    oclIntersection(redefined.redefinitionContext)->notEmpty())

    Things work fine with this correction.

  • Reported: UML 2.2 — Tue, 12 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The problems highlighted by the issue have already been resolved in the specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

current definition of a 'local' transition does not allow the case to have a local transition

  • Key: UML23-64
  • Legacy Issue Number: 13920
  • Status: closed  
  • Source: International Business Machines ( Mr. Adam Neal)
  • Summary:

    To properly and unambiguously constrain which Region 'should' own a transition, requires that the transition kind be used (further work on issue 10498). The current definition of a 'local' transition does not allow the case to have a local transition whose target is a composite state and source is nested within that composite state. It should be possible to assign this kind of transition local semantics, i.e., the composite state will not be exited nor entered; only the nested configuration of composite state will be affected as a result of exiting the nested source state and establishing a configuration for the composite state itself, i.e., the target.

  • Reported: UML 2.2 — Tue, 5 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Update the text to explicitly include the possibility. Also, remove the reference to local self-transitions and
    replace them with an explanation about the representation of internal transitions

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figures 9.17 and 9.19 and related text

  • Key: UML23-59
  • Legacy Issue Number: 13909
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Figures 9.17 and 9.19 and related text show that an Engine requires Power on the same port as it provides a powertrain. This makes no sense conceptually – an engine does not require power from its powertrain, it delivers power to its powertrain. Modify the examples so they make sense.

  • Reported: UML 2.2 — Thu, 30 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

what's the difference > between weight=1 and weight=*?

  • Key: UML23-58
  • Legacy Issue Number: 13898
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    I agree with the resolution, but I > ask myself what's the difference > between weight=1 and weight=? Edge weight controls how many offers must be accepted by the target of the edge for any tokens to traverse the edge at the same time ("the minimum number of tokens that must traverse the edge at the same time."). The default weight=1 lets just one offer be accepted for a token to traverse (all tokens might be offerred to the ObjectFlow, but it's OK if only one is accepted, it traverses). Weight=2 requires two to be accepted, or none traverse. Weight = * requires all tokens currently at the source to be accepted for any to traverse. If for some reason the target of the ObjectFlow can't accept all the tokens required by the weight (maybe the target is full), the object flow can't accept any. In the example Ed was concerned with, there's no reason for the target of an ObjectFlow to reject offers, so weight=1 causes all the tokens at the source to move at once, as if weight=. Weight=* gives a different execution of the join in Figure 12.45 than weight=1 (refered to in the Semantics of ActivityEdge). Normally the join would take one token from Bids For Proposal when the Ready to Award Bid event occurs (or at least I thought it would, the join semantics isn't clear on that I notice), but with weight=, the join must take all the tokens in Bids For Proposal. The semantics of weight= is slightly bent, because you would think it means an infinite number of tokens must traverse at the same time. It actually means whatever number of tokens are at the source must traverse at the same time (it's using "*" like a wildcard instead of infinity, not so good). The wording of the paragraph in Semantics of ActivityEdge could be improved if you'd like to file issue. In particular: - Where it says "When the minimum number of tokens are offered" it should say "accepted" instead of "offered". - The sentence starting "An unlimited weight" should continue "means that all the tokens at the source must be accepted for any of them to traverse the edge". Conrad

  • Reported: UML 2.2 — Sat, 25 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Clarify that weight gives the minimum number of tokens that must be accepted by the target of an ActivityEdge for any tokens to traverse the edge, and that weight=UnlimitedInteger means the minimum number of tokens is the number currently at the source of the ObjectFlow.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify that input pins do not accept more tokens than their actions can immediately consume

  • Key: UML23-63
  • Legacy Issue Number: 13914
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that input pins do not accept more tokens than their actions can immediately consume

  • Reported: UML 2.2 — Mon, 4 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The Activities, (12.3.2) Action, Semantics, item 1, says
    The object flow prerequisite is satisfied when all of the input pins are offered all necessary tokens and accept them all at once, precluding them from being consumed by any other actions. This ensures that multiple action executions competing for tokens do not accept only some of the tokens they need to begin, causing deadlock as each execution waits for tokens that are already taken by others.
    The "necessary tokens" in the first sentence above are the ones needed to execute the actions (meeting the minimum multiplicity), but should include any additional ones offered up the maximum multiplicity. Only these are accepted by the input pins, then immediately consumed by the action. The second sentence gives the motivation, which is to avoid having tokens in input pins that are not immediately consumed. This would prevent those tokens from being used to execute other actions, potentially creating deadlock or starvation. Deadlock is discussed more in issue 7221 of the UML 2.0 FTF report (http://doc.omg.org/ptc/04-10-01).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The OCL for /required interfaces of Component is using ports.provided instead of ports.required

  • Key: UML23-62
  • Legacy Issue Number: 13912
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The OCL for /required interfaces of Component is using ports.provided instead of ports.required

  • Reported: UML 2.2 — Thu, 30 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Clarification need on circle plus notation for containment

  • Key: UML23-67
  • Legacy Issue Number: 13933
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    It is not clear when the circle plus notation is available for showing containment. Can it be used for showing nested class, packages, ownedBehaviors, etc.? Any containment association in the metamodel?

  • Reported: UML 2.2 — Fri, 15 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 13936

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Color errors on figures in UML 2.2

  • Key: UML23-66
  • Legacy Issue Number: 13931
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    Here are some (hopefully editorial) errors in the figures in the recent UML 2.2 release, document 09-02-02. A conscientious OCUP candidate brought the first of these to my attention.

    Figure 6.2: What is the significance of the red color of the symbols and arrows? If none, they should be black.

    Figure 14.1: The <<merge>> arrows are black, as is most of the rest of the figure, but the <<import>> arrows are red. This confuses at least one conscientious OCUP candidate who wrote in asking the significance of the color in the figures. i.e. Are <,import>> arrows supposed to be Red?

    Now I'm going back in the spec and checking all of the Abstract Syntax sections for color. Here we go...

    Part I, Figure 1, on page 21, also has red <<import>> arrows.

    Figure 8.1: Here, one of the <<merge>> arrows is red.

    Figure 9.1: The StructuredActivities box outline is maroon.

    Figure 10.1: Red <<import>> arrow

    Figure 11.1: Red <<import>> arrows

    Figure 12.1: Two boxes have red outlines and yellow fill. (Ouch!) Lots of red arrows.

    Figure 15.2: Red <<import>> arrows

    Figure 17.1: Red <<import>> arrows

    Figure 18.1: Red <<import>> arrows

    That's all I found. Hopefully it won't take a bunch of votes to turn all of these lines black

  • Reported: UML 2.2 — Thu, 14 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Figure 7.38 needs to be revised

  • Key: UML23-69
  • Legacy Issue Number: 13947
  • Status: closed  
  • Source: Hendryx & Associates ( Stan Hendryx)
  • Summary:

    Figure 7.38 needs to be revised. The arrowhead on the dependency of Figure 7.38 is on the wrong end. The example it illustrates is not consistent with software engineering practices and is consequently ambiguous and misleading and should be revised. These errors lead to endless confusion and debate among UML modelers as to the correct usage of the standard notation for dependencies. p.62 Notation, says, "The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier)." The example of Fig. 7.38 says, "the Car class has a dependency on the CarFactory class. In this case, the dependency is an instantiate dependency, where the Car class is an instance of the CarFactory class." These sentences should be revised. Suggested wording: "the Car class depends on on the CarFactory class. In this case, the dependency is an instantiate dependency, where the Car class is instantiated by the CarFactory class. That is, the Car class depends on the CarFactory class to produce instances of Car, i.e., to produce cars."

  • Reported: UML 2.2 — Thu, 4 Jun 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 11489

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity groups should be named

  • Key: UML23-68
  • Legacy Issue Number: 13943
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Activity groups should be named. Interruptible Regions in particular. Nodes, Edges, and some Activity Groups are already named, such as Activity Partitions.

  • Reported: UML 2.2 — Sun, 31 May 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Activity Groups specialize NamedElement intead of Element.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 2.2 Example feature support statement references Note (4) and Note (5)

  • Key: UML23-57
  • Legacy Issue Number: 13868
  • Status: closed  
  • Source: individual ( Robert Dunn)
  • Summary:

    Page 24 of PDF. Table 2.2 Example feature support statement references Note (4) and Note (5). Notes only number 1 - 3. There is no Note (4) nor Note (5).

  • Reported: UML 2.2 — Wed, 15 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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 Level 1 diagram does not make sense with respect to figure 2.2

  • Key: UML23-56
  • Legacy Issue Number: 13867
  • Status: closed  
  • Source: individual ( Robert Dunn)
  • Summary:

    Page 19 and 20 of PDF. Description of Level 1 diagram does not make sense with respect to figure 2.2. "...packages merged into Level 0 and their contents are extended...," yet packages listed on figure 2.1 (Level 0 diagram) are not shown in figure 2.2 and no <<extend>> relationship is shown. Even a <<merge>> relationship between L1 and L0 would seem clear except for the defect noted next. "Note that each of the four packages shown in the figure...," but I see twelve packages shown in figure 2.2.

  • Reported: UML 2.2 — Wed, 15 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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 how the provided and required interfaces of a Port are calculated

  • Key: UML23-61
  • Legacy Issue Number: 13911
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Clarify how the provided and required interfaces of a Port are calculated when the type of a Port is a Component or a Class with Ports

  • Reported: UML 2.2 — Thu, 30 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Missing keyword?

  • Key: UML23-60
  • Legacy Issue Number: 13910
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Figure 9.19 shows some kind of "dependency" between interfaces, so if that means Usage, <<use>> keyword must be used

  • Reported: UML 2.2 — Thu, 30 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The issue is obsolete. The figure no longer appears in the spec.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Replace "extensionClock" with "extension_Clock" and "baseClass" with "base_Class"

  • Key: UML23-54
  • Legacy Issue Number: 13861
  • Status: closed  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    Replace "extensionClock" with "extension_Clock" and "baseClass" with "base_Class"

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

URIs do not refer to existing resources (404 errors) Annex H

  • Key: UML23-55
  • Legacy Issue Number: 13863
  • Status: closed  
  • Source: University of Kassel ( Michael Zapf)
  • Summary:

    URIs do not refer to existing resources (404 errors)

  • Reported: UML 2.2 — Thu, 9 Apr 2009 04:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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: 14.3.13 Interaction (from BasicInteraction, Fragments)

  • Key: UML23-14
  • Legacy Issue Number: 13256
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Text from the specs states: "Description An interaction is a unit of behavior that focuses on the observable exchange of information between ConnectableElements. ..." "Semantics Interactions are units of behavior of an enclosing Classifier. Interactions focus on the passing of information with Messages between the ConnectableElements of the Classifier." One issue is that in several other places of the specs interactions are described as being "owned" - not "enclosed" - by Classifier, e.g below on p. 492 we read "The classifier owning an Interaction may be specialized, and ..." Another question I have is that semantics of interaction as described now is focusing on passing of information between ConnectableElements of that specific Classifier - but traces of interaction include OccurrenceSpecifications of possibly several participants represented by LifeLines of one to many Classifiers. The case when Classifier interacts only with itself or a single other Classifier should be quite rare. When we have several Classifiers (represented by LifeLines) interacting, that interaction should include ConnectableElements of those several Classifiers involved, unless the "ConnectableElements of the Classifier" are considered to be some transitive closure of all ConnectableElements depicted on the interaction. In other words, I'd clarify both Description and Semantics of Interaction to something like: Interactions are units of behavior of an owning Classifier. Interactions focus on the passing of information with Messages between the ConnectableElements of the owning Classifier and ConnectableElements of other interacting Classifiers. All Classifiers participating in the interaction - including owner Classifier - are represented by LifeLines."

  • Reported: UML 2.2 — Wed, 14 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The requested change contradicts the Lifeline Constraint “same_classifier” which states:
    “The classifier containing the referened ConnectableElement must be the same classifier, or an ancestor, of the classifier
    that contains the intraction enclosing the Lifeline.”
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for ExecutionSpecification

  • Key: UML23-13
  • Legacy Issue Number: 13254
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Notation for ExecutionSpecification is described as: "Notation ExecutionOccurences are represented as thin rectangles (grey or white) on the lifeline (see “Lifeline (from BasicInteractions, Fragments)” on page 500). We may also represent an ExecutionSpecification by a wider labeled rectangle, ..." It seems that "ExecutionOccurences" above is typo as this paragraph is about ExecutionSpecifications, and thus text should read as: "Notation ExecutionSpecifications are represented as thin rectangles (grey or white) on the lifeline ..."

  • Reported: UML 2.2 — Wed, 14 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.39 PackageImport (from Kernel)

  • Key: UML23-6
  • Legacy Issue Number: 13137
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    There is some obvious copy/paste error: "Presentation options As an alternative to the dashed arrow, it is possible to show an element import by having a text that uniquely identifies the imported element within curly brackets either below or after the name of the namespace..." This 7.3.39 section is about package import - not element import - so that sentence should look like: "As an alternative to the dashed arrow, it is possible to show a package import by having a text that uniquely identifies the imported package within curly brackets either below or after the name of the namespace..."

  • Reported: UML 2.2 — Wed, 3 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.12 Dependency (from Dependencies)

  • Key: UML23-5
  • Legacy Issue Number: 13136
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Explanation to Figure 7.38 - An example of an instantiate dependency - states: "In the example below, the Car class has a dependency on the CarFactory class. In this case, the dependency is an instantiate dependency, where the Car class is an instance of the CarFactory class." (1) Logically and from the diagram itself, it should be opposite: CarFactory class has a dependency on the Car class. (2) Instantiate dependency does not mean that "Car class is an instance of the CarFactory class". That sentence most likely should read simply as "Car class is instantiated by the CarFactory class".

  • Reported: UML 2.2 — Wed, 3 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 11489

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Val(MyCar.Interaction [SVWB

  • Key: UML23-11
  • Legacy Issue Number: 13250
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Constraint [2] implies that: "The name of the NamedElement referenced by signature must be the same as that of the Message" The point is that the syntax describe for the signature in the Notation section (p503) cannot ensure that the Message name will be unique inside its Namespace (i.e. its owning Interaction)

  • Reported: UML 2.2 — Tue, 13 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    The message notation for message name was clarified in UML 2.5. The operation isDistinguishableFromwas overidden
    to always be True to avoid namespace problem. These changes address the concern raised in the issue.
    No change needed.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.14 Figure 12.29 on page 320

  • Key: UML23-10
  • Legacy Issue Number: 13193
  • Status: closed  
  • Source: Mamezou Co.,Ltd. ( Kenichi Kobayashi)
  • Summary:

    Incorrect: behavior can be shown similarly to Figure 12.29 on page 320, using keywords «precondition» and «postcondition». Correct: behavior can be shown similarly to Figure 12.29 on page 320, using keywords «localPrecondition» and «localPostcondition».

  • Reported: UML 2.2 — Fri, 26 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    This issue is incorrect. The annotations on a CallBehaviorAction that are being described are supposed to show the
    pre- and postconditions of the called behavior, not the local pre- and postconditions. This is stated more explicitly in
    the corresponding wording in the UML 2.5 beta specification, in Subclause 16.3.4, under “Call Behavior Actions”.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.24 MessageSort (from BasicInteractions)

  • Key: UML23-8
  • Legacy Issue Number: 13149
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    "MessageSort is an enumeration of the following values: ... • asynchSignal - The message was generated by an asynchronous send action.createMessage - The message designating the creation of another lifeline object." The "createMessage" should be on a separate line: • asynchSignal - The message was generated by an asynchronous send action. • createMessage - The message designating the creation of another lifeline object.

  • Reported: UML 2.2 — Tue, 9 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.3 CombinedFragment (from Fragments)

  • Key: UML23-7
  • Legacy Issue Number: 13148
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Explanation for: "Presentation Options for “coregion area” ... This means that in a given “coregion” area of a Lifeline all the directly contained fragments are considered separate operands of a parallel combined fragment. See example in Figure 14.12." The "Figure 14.12 - Continuation" - seems to have no example of coregion as expected. Example of coregion could be found on "Figure 14.22 - Sequence Diagrams where two Lifelines refer to the same set of Parts", p.519.

  • Reported: UML 2.2 — Mon, 8 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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" section of the Behavior metaclass

  • Key: UML23-9
  • Legacy Issue Number: 13188
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    In the "description" section of the Behavior metaclass, there is the following sentence: "A classifier behavior is always a definition of behavior and not an illustration". The consequences of this statement should be explained and especially its impact on the capability of using Interactions for that purpose. A constraint should be added to the specification of the BehavioredClassifier metaclass.

  • Reported: UML 2.2 — Mon, 22 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    In the UML 2.5 beta specification, this sentence still appears in Subclause 13.2.3, under the semantics of
    “Behaviored Classifiers”. However, it is not clear that the sentence is really necessary at all. In the same
    paragraph it says “For example, the classifierBehavior of a Collaboration (see sub clause 11.7) represents
    emergent behavior of all the parts. . . ” Certainly, it is common to use Interactions as Collaboration classifier-
    Behaviors, and it is not really clear what it means to “define” an emergent behavior anyway. The contrast
    of “definition of behavior not an illustration” thus seems methodological, and the sentence can be removed
    without changing the essential specification of classifierBehavior semantics.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter isn't package (Heading 2 level)

  • Key: UML23-2
  • Legacy Issue Number: 13092
  • Status: closed  
  • Source: ESL ( Janis Alksnis)
  • Summary:

    Parameter isn't package (Heading 2 level), but class (need to be Heading 3 level under Heading 2 "9.1. BehavioralFeatures package")

  • Reported: UML 2.2 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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

Super package should import NamedElement from the Visibilities package, not Namespaces

  • Key: UML23-1
  • Legacy Issue Number: 13091
  • Status: closed  
  • Source: ESL ( Janis Alksnis)
  • Summary:

    Figure 9.48 - The elements defined in the Super package As Classifier is associated to NamedElement's property of visibility, Super package should import NamedElement from the Visibilities package, not Namespaces

  • Reported: UML 2.2 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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 Interaction provided by the Semantic section inconsistent

  • Key: UML23-12
  • Legacy Issue Number: 13253
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The description of Interaction provided by the Semantic section sounds good by itself but is widely inconsistent with the meta-model, according Attributes sections, Association sections and Figures 14.x. For instance: the Semantic section mentions "ordered sets of occurences" that can not be found in the meta-model. It does exist an ordered property in the association between Lifeline and OccurenceSpecification but: first it's not exactly the same thing, second the related property cannot be found anywhere in the meta-classes!... My global feeling is that the chapter 14 of the meta-model is not mature, very (too much?) complex and ambiguous.

  • Reported: UML 2.2 — Wed, 14 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Semantics of interactions were clarified considerably.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.20 Actors in Interactions

  • Key: UML23-4
  • Legacy Issue Number: 13134
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It is common to model interactions with actors, e.g. to show scenarios how actors interact with the system. For example in the context of a collaboration it is possible to model lifelines that represent system actors. However it is not possible that they receive messages in an interaction. According to constraint [2] in chapter 14.3.20 each message must correspond to an operation or signal. But it is not allowed to have actors with operations or receptions.

  • Reported: UML 2.2 — Tue, 2 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    Merged with 11068

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 9.20

  • Key: UML23-3
  • Legacy Issue Number: 13093
  • Status: closed  
  • Source: ESL ( Janis Alksnis)
  • Summary:

    Figure 9.20 - The elements defined in the Expressions package Associations • operand: ValueSpecification[*] Specifies a sequence of operands. Subsets Element::ownedElement.

    {non-unique; ordered}
  • Reported: UML 2.2 — Fri, 21 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.3
  • Disposition Summary:

    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 Superstructure / CommonBehaviors / Incorrect types in text

  • Key: UML22-1081
  • Legacy Issue Number: 9352
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    TimeConstraint::specification and DurationConstraint::specification properties are shown as having the wrong type in the text (the diagrams are OK). They should be TimeInterval and DurationInterval respectively.

  • Reported: UML 2.0 — Thu, 2 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: This issue has been resolved in an earlier version of the specification. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.3.41 Parameter (from Kernel, AssociationClasses)"

  • Key: UML22-1080
  • Legacy Issue Number: 9337
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Please note however, that (as far as I can see) Parameter only occurs in Kernel, NOT in AssociationClasses. So the correct statement would be "Parameter (from Kernel). This might bear a relation to the already existing FTF issue 8117.

  • Reported: UML 2.0 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 issue: ownedMember xsi:type="uml:Stereotype" should be used

  • Key: UML22-1063
  • Legacy Issue Number: 9185
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ownedMember xsi:type="uml:Stereotype" should be used in XMI instance documents instead of ownedStereotype xsi:type="uml:Stereotype" (especially if it becomes a derived subset).

  • Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0: CMOF/UML mixup for profiles

  • Key: UML22-1062
  • Legacy Issue Number: 9184
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The end of the semantics section for Profiles informally describes a CMOF model equivalent to a Profile. This discussion in the spec about profiles and equivalent MOF metamodels could be confusing and potentially misleading. A profile is an instance of a UML2 model which is not a CMOF model. Therefore the MOF to XMI mapping rules do not apply for instances of a profile. The equivalent CMOF model is a means to explain and formalize how profiles are serialized and exchanged as XMI. The spec should make it clear that the equivalent MOF model is a model-to-model mapping being introduced as a means for describing how a profile is serialized and exchanged using XMI and how an XSD schema for validating instances of a profile is defined.

    The mapping from a profile to a CMOF model is incomplete. For example, there is no statement that an instance of a stereotype maps to an instance of a CMOF::Class. This mapping needs to be completed; e.g., by direct reference

    The Profile to CMOF mapping also needs to specify the XMI tags for persisting and exchanging profiles. According to the UML2 metamodel, instances of a Profile can't have Tags because an instance of a Profile is not a CMOF::Element, UML2 is not reflective. Tools will have to provide tag support for instances of stereotypes some other way. These properties can be left undefined and tools can provide values as needed. Another possible solution would be to specify how the XMI tag values and options for profile exchange would be defined, perhaps derived from other information in the profile. For example:
    nsURI = http://<profilePackagePath>/schemas/<profileName>.xmi
    nsPrefix = <profileName>
    all others use the XMI defaults

  • Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Required attributes

  • Key: UML22-1069
  • Legacy Issue Number: 9191
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Required attributes (i.e. those with a lower bound greater than 0) without a specified default must either be assigned a default or made non-required (see below). There should also be a statement in the specification to the effect that attributes whose values are set to their default need not be serialized.

    uml::Artifact::fileName is required, default is <unspecified>

    uml::Behavior::isReentrant is required, default is <unspecified>

    uml::BehavioralFeature::concurrency is required, default is <unspecified>
    uml::BehavioralFeature::isAbstract is required, default is <unspecified>

    uml::Class::isActive is required, default is <unspecified>

    uml::CombinedFragment::interactionOperator is required, default is <unspecified>

    uml::Comment::body is required, default is <unspecified>

    uml::ConditionalNode::isAssured is required, default is <unspecified>
    uml::ConditionalNode::isDeterminate is required, default is <unspecified>

    uml::DeploymentSpecification::deploymentLocation is required, default is <unspecified>
    uml::DeploymentSpecification::executionLocation is required, default is <unspecified>

    uml::ElementImport::visibility is required, default is <unspecified>

    uml::ExpansionRegion::mode is required, default is <unspecified>

    uml::Expression::symbol is required, default is <unspecified>

    uml::GeneralizationSet::isCovering is required, default is <unspecified>
    uml::GeneralizationSet::isDisjoint is required, default is <unspecified>

    uml::LiteralBoolean::value is required, default is <unspecified>

    uml::LiteralInteger::value is required, default is <unspecified>

    uml::LiteralString::value is required, default is <unspecified>

    uml::LiteralUnlimitedNatural::value is required, default is <unspecified>

    uml::LoopNode::isTestedFirst is required, default is <unspecified>

    uml::Message::messageKind is required, default is <unspecified>
    uml::Message::messageSort is required, default is <unspecified>

    uml::Model::viewpoint is required, default is <unspecified>

    uml::OpaqueAction::body is required, default is <unspecified>

    uml::OpaqueBehavior::body is required, default is <unspecified>

    uml::OpaqueExpression::body is required, default is <unspecified>

    uml::PackageableElement::visibility is required, default is <unspecified>

    uml::PackageImport::visibility is required, default is <unspecified>

    uml::Pseudostate::kind is required, default is <unspecified>

    uml::State::isComposite is required, default is <unspecified>
    uml::State::isOrthogonal is required, default is <unspecified>
    uml::State::isSimple is required, default is <unspecified>
    uml::State::isSubmachineState is required, default is <unspecified>

    uml::StructuredActivityNode::mustIsolate is required, default is <unspecified>

    uml::TimeEvent::isRelative is required, default is <unspecified>

    uml::Transition::kind is required, default is <unspecified>

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter::effect

  • Key: UML22-1068
  • Legacy Issue Number: 9190
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Parameter::effect is documented in the specification as having multiplicity 0..* (instead of 0..1 - this should have been addressed as part of Issue 8261).

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.1 XMI Issue

  • Key: UML22-1065
  • Legacy Issue Number: 9187
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    uml::EncapsulatedClassifier::ownedPort should be derived (from the owned attributes that are instances of Port) so as to be consistent with Package::ownedType, Package::nestedPackage, and Profile::ownedStereotype (see issue 9181).

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0: Inconsistencies in profile example XMI

  • Key: UML22-1064
  • Legacy Issue Number: 9186
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the Home Example for Profiles in chapter 18, the body of the text and the examples use different conventions for naming ExtensionEnds "base$Interface", "base_Interface", and "baseInterface" all appear in various places. The spec says it should be base$Interface (although this is not a valid identifier in many common programming languages including Java).

  • Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

parameter of operation isRedefinitionContextValid() is inconistently named

  • Key: UML22-1073
  • Legacy Issue Number: 9195
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The parameter of operation isRedefinitionContextValid() is inconistently named in the specification, which in turn cause package merge problems (parameters do not match). The parameter should be consitently named 'redefined', and the OCL for the associated constraints updated accordingly.

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Compliance package L2 does not merge StructuredActions in the metamodel

  • Key: UML22-1072
  • Legacy Issue Number: 9194
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Compliance package L2 does not merge StructuredActions in the metamodel. Also, CompleteActions (merged by L3) does not currently merge StructuredActions.

    In general, higher compliance levels should merge lower compliance levels; the merge relationships in the specification should be reorganized to reflect this.

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Resolved by the solution to issue 9182

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The following properties should not subset DirectedRelationship::target

  • Key: UML22-1071
  • Legacy Issue Number: 9193
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The following properties should not subset DirectedRelationship::target since they subset Dependency::supplier, which already subsets DirectedRelationship::target:

    ComponentRealization::realizingClassifier
    Deployment::deployedArtifact
    InterfaceRealization::contract
    Manifestation::utilizedElement
    Substitution::contract

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The following properties should not subset DirectedRelationship::source

  • Key: UML22-1070
  • Legacy Issue Number: 9192
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The following properties should not subset DirectedRelationship::source since they subset Dependency::client, which already subsets DirectedRelationship::source:

    ComponentRealization::abstraction
    Deployment::location
    InterfaceRealization::implementingClassifier
    Substitution::substitutingClassifier

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Artifact::fileName

  • Key: UML22-1067
  • Legacy Issue Number: 9189
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Artifact::fileName appears in the metamodel but is not documented in the specification.

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

uml::Extension::ownedEnd should not subset uml::Association::ownedEnd

  • Key: UML22-1066
  • Legacy Issue Number: 9188
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    uml::Extension::ownedEnd should not subset uml::Association::ownedEnd since it already (implicitly) redefines it.

    There should be a constraint that states that it is invalid for a property to subset a property with the same name.

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 12.18: Small typo: "subsets ownedMember" not "ownedmember"

  • Key: UML22-1079
  • Legacy Issue Number: 9235
  • Status: closed  
  • Source: LIANTIS GmbH ( Constantin Szallies)
  • Summary:

    Figure 12.18: Small typo: "subsets ownedMember" not "ownedmember"

  • Reported: UML 2.0 — Mon, 12 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This was resolved in some previous revision. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 161

  • Key: UML22-1078
  • Legacy Issue Number: 9232
  • Status: closed  
  • Source: LIANTIS GmbH ( Constantin Szallies)
  • Summary:

    Figure 9.7: property "representation" subsets "collaborationUse" not "occurrence"? "Classifier" has no property named "occurrence"!

  • Reported: UML 2.0 — Mon, 12 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue has already been fixed in the current version of the specification. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue regarding "Action::effect : String"

  • Key: UML22-1075
  • Legacy Issue Number: 9197
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    What has become of the dropped property : "Action::effect : String" ? ( referenced in Ballot 7319 )

  • Reported: UML 1.3 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Transition guards cannot currently be evaluated because they have no contex

  • Key: UML22-1074
  • Legacy Issue Number: 9196
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Transition guards cannot currently be evaluated because they have no context. Transition should be made a specialization of Namespace and Transition::guard should subset Namespace::ownedRule

  • Reported: UML 2.0 — Tue, 29 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

StateMachine::extendedStateMachine should have a multiplicity of 0..*.

  • Key: UML22-1077
  • Legacy Issue Number: 9224
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    StateMachine::extendedStateMachine should have a multiplicity of 0..*. It currently does in the text, but it is shown with a multiplicity of 0..1 in Figure 15.3.

  • Reported: UML 2.0 — Thu, 8 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Behavior::context

  • Key: UML22-1076
  • Legacy Issue Number: 9198
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Behavior::context is derived (ensure that this is indicated in the diagram and the text); it should also be read-only.

  • Reported: UML 2.0 — Thu, 1 Dec 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 issue: Package Primitive Types not merged

  • Key: UML22-1058
  • Legacy Issue Number: 9180
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package PrimitiveTypes is not merged into UML2 and there is no nsURI for InfrastructureLibrary. So there's no way to reference UML primitive types in any UML2 model including profiles. Resolve by merging PrimitiveType into L0.

  • Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix A: Diagrams

  • Key: UML22-1057
  • Legacy Issue Number: 9179
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    There's no diagram kind for deployment diagrams

  • Reported: UML 2.0 — Sat, 26 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.1 of ptc/04-10-14

  • Key: UML22-1056
  • Legacy Issue Number: 9146
  • Status: closed  
  • Source: Red Hat ( John Verhaeg)
  • Summary:

    Page 13 of section 7.2.1 of the "Unified Modeling Language (UML) Specification: Infrastructure" (ptc/04-10-14) states:

    "There are minor differences in the design rationale for the other two packages."

    There are actually 4 packages being discussed, with the first being PrimitiveTypes. So, either "two" should be changed to "three" when referring to the "other" packages, or the two packages (amongst the "other" three being discussed) containing the "minor differences in design rationale" should be identified.

  • Reported: UML 2.0 — Thu, 10 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.36 Operation

  • Key: UML22-1055
  • Legacy Issue Number: 9143
  • Status: closed  
  • Source: Paranor AG ( Earl Waldin)
  • Summary:

    The BNF for the textual specification of an operation does not allow one to specify the multiplicity of an operation's return type. The current BNF is [<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’ [‘:’ [<return-type>]

    {‘ <oper-property> [‘,’ <oper-property>]* ‘}’] It should allow the multiplicity to be specified in a manner similar to that for a property. For example: [<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’ [‘:’ [<return-type>] [‘[‘ <multiplicity> ‘]’] ‘{‘ <oper-property> [‘,’ <oper-property>]* ‘}

    ’]

  • Reported: UML 2.0 — Tue, 8 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8 Issue - Component Realization-Classifier multiplicity

  • Key: UML22-1054
  • Legacy Issue Number: 9142
  • Status: closed  
  • Source: Cutter Information ( Oliver Sims)
  • Summary:

    Issue: The multiplicity on the relationship from Realization to Classifier is 1. This seems wrong - it should be 1 or more.

    Rationale:
    A component realization consisting of only a single classifier would be very odd - although not impossible for a Hello World component perhaps.

  • Reported: UML 2.0 — Sat, 10 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions, Figure 156

  • Key: UML22-1053
  • Legacy Issue Number: 9123
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 156, I think LinkEndCreationData and QualifierValue aren't supposed to be on this diagram: - The associations to/from these aren't in the entries for CreateLinkObjectAction of LinkEndCreationData, - endData is inherited from CreateLinkAction and isn't changed. - The qualifier association would clash with the one inherited fromn LinkEndData in CompleteActivities. There is nothing in the spec on why qualifier is specialized this way. - The multiplicity on qualifier would require qualifiers, even when there aren't any.

  • Reported: UML 2.0 — Thu, 27 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.1 Regressions

  • Key: UML22-1052
  • Legacy Issue Number: 9122
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The following regressions were introduced in ballot 10:

    Issue 8134

    DeployedArtifact should NOT specialize Kernel::NamedElement since it already specializes Dependencies::NamedElement, and adding a redundant generalization violates the uniqueness constraint on Classifier::general (in the merged result).

    Issue 8136

    DeploymentSpecification should NOT specialize Artifacts::Artifact since it already specializes Nodes::Artifact, and adding a redundant generalization violates the uniqueness constraint on Classifier::general (in the merged result).

    Issue 8457

    The proposed new Figure 124 introduces an undesired (generalization) dependency between Kernel and Dependencies. The preferred resolution would be for Artifact (not Kernel::Namespace) to specialize Dependencies::NamedElement. Figure 124 should be:

    The proposed new Figure 77 introduces an undesired (generalization) dependency between Kernel and Dependencies. The preferred resolution would be for Component (not Kernel::Namespace) to specialize Dependencies::NamedElement. Figure 77 should be:

    Issue 8468

    UseCase::extend must NOT subset Classifier::feature because Extend is not a specialization of Feature. Likewise, UseCase::include must NOT subset Classifier::feature because Include is not a specialization of Feature.

  • Reported: UML 2.0 — Thu, 27 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Realization classifier

  • Key: UML22-1051
  • Legacy Issue Number: 9119
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The Realization classifier should not be redefined in UML::Components::BasicComponents. In a component realization, the direction of the dependency is reversed, i.e. the client (source) of the dependency is the component abstraction and the supplier (target) of the dependency is the realizing classifier; this conflicts with other specializations of Realization (e.g. InterfaceRealization).

    -> A new specialization ('ComponentRealization') should be introduced instead, upon which the 'abstraction' and 'realizingClassifier' properties would be defined. This could be achieved by simply renaming Realization to 'ComponentRealization' in UML::Components::BasicComponents and adding a generalization from it to UML::Classes::Dependencies::Realization.

  • Reported: UML 2.0 — Wed, 26 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 issue: redefining isComposite on association ends

  • Key: UML22-1050
  • Legacy Issue Number: 9117
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The association ends IntervalConstraint::specification, TimeConstraint::specification, and DurationConstraint::specification should be composite, since, redefining an isComposite = true property with one where isComposite = false causes problems in the XMI generation. More on isComposite redefinition : 1) LinkEndCreationData::qualifier should be composite.

    2) It should be considered inconsistent for a non-composite property to redefine a composite property. The body expression for Property::isConsistentWith(RedefinableElement) should be updated as follows:
    This should probably be disallowed in general.

  • Reported: UML 2.0 — Thu, 27 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Classifier::parameter, Operation::parameter, and ConnectableElement::parame

  • Key: UML22-1049
  • Legacy Issue Number: 9110
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Classifier::parameter, Operation::parameter, and ConnectableElement::parameter should be renamed to templateParameter (they redefine ParameterableElement::templateParameter) to make it clear that these are template parameters (in fact not related to the Parameter metaclass). ParameterableElement::owningParameter should also be renamed to owningTemplateParameter, for consistency.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Component::realization should NOT be derived

  • Key: UML22-1048
  • Legacy Issue Number: 9109
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Component::realization should NOT be derived

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename ActivityGroup::activity to containingActivity

  • Key: UML22-1047
  • Legacy Issue Number: 9108
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    StructuredActivityNode inherits two properties with the same name, ActivityNode::activity and ActivityGroup::activity.

    -> Rename ActivityGroup::activity to containingActivity.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename OpaqueAction::output to outputPin.

  • Key: UML22-1046
  • Legacy Issue Number: 9107
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    OpaqueAction::output (non-derived) invalidly redefines Action::output (derived union).

    -> Rename OpaqueAction::output to outputPin.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Make ActivityGroup::containedNode a derived union

  • Key: UML22-1045
  • Legacy Issue Number: 9106
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    ActivityNode::inGroup is a derived union but its opposite, ActivityGroup::containedNode, is not.

    -> Make ActivityGroup::containedNode a derived union. As a result, ActivityPartition::containedNode, StructuredActivityNode::containedNode, and InterruptibleActivityRegion::containedNode will invalidly redefine ActivityGroup::containedNode, so rename ActivityPartition::containedNode to node, rename StructuredActivityNode::containedNode to ownedNode, rename InterruptibleActivityRegion::containedNode to node, and replace

    {redefines containedNode}

    with

    {subsets containedNode}

    on all three.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Make ActivityGroup::containedEdge a derived union

  • Key: UML22-1044
  • Legacy Issue Number: 9105
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    ActivityEdge::inGroup is a derived union but its opposite, ActivityGroup::containedEdge, is not.

    -> Make ActivityGroup::containedEdge a derived union. As a result, ActivityPartition::containedEdge and StructuredActivityNode::containedEdge will invalidly redefine ActivityGroup::containedEdge, so rename ActivityPartition::containedEdge to edge, rename StructuredActivityNode::containedEdge to ownedEdge, and replace

    {redefines containedEdge}

    with

    {subsets containedEdge}

    on both.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

compliance levels L2 and L3

  • Key: UML22-1039
  • Legacy Issue Number: 9098
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    In (merged) compliance levels L2 and L3, ExtensionEnd::lower (non-derived) invalidly redefines feature MultiplicityElement::lower (derived).

    -> Either remove this redefinition (of the default value) or add a Profiles package to UML and redefine ExtensionEnd::lower to be derived.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change type of WriteStructuralFeatureAction::value to ValueSpecification

  • Key: UML22-1038
  • Legacy Issue Number: 9097
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    TimeObservationAction::now (type TimeExpression) invalidly redefines WriteStructuralFeatureAction::value (type InputPin) because TimeExpression is not a specialization of InputPin.

    -> Change type of WriteStructuralFeatureAction::value to ValueSpecification?

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change type of WriteStructuralFeatureAction::value

  • Key: UML22-1037
  • Legacy Issue Number: 9096
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    DurationObservationAction::duration (type Duration) invalidly redefines WriteStructuralFeatureAction::value (type InputPin) because Duration is not a specialization of InputPin.

    -> Change type of WriteStructuralFeatureAction::value to ValueSpecification?

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0: separate profile application from profile importing

  • Key: UML22-1061
  • Legacy Issue Number: 9183
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package::appliedProfile should not subset packageImport. Why not? A profile can be imported without being applied, but any applied profile is also implicitly imported in order to make the namespace visible. (The current assumption that a package import implies a profile application does not allow importing of profiles without application – which might be required just for namespace purposes.)

    The simplest solution is to define ProfileApplication to be a subclass of DirectedRelationship with a meta-association (Profile::appliedProfile : Profile) indicating the applied profile

  • Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0: invalid package merge diagrams for compliance points

  • Key: UML22-1060
  • Legacy Issue Number: 9182
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The diagrams in section 2 describing the compliance levels of UML 2, should show:

    (1) have a separate package for each level (instead of the "UML" package); e.g., L2 for level 2.

    (2) each package except L0 should also merge the package belonging to the immediately preceding level (e.g., L2 should merge package L1).

  • Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 issue: Profile::ownedStereotype should be derived

  • Key: UML22-1059
  • Legacy Issue Number: 9181
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Profile::ownedStereotype should be derived (just like Package::/ownedType) from those ownedMembers which are Stereotypes.

  • Reported: UML 2.0 — Mon, 28 Nov 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename LinkAction::input to inputPin

  • Key: UML22-1043
  • Legacy Issue Number: 9104
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    LinkAction::input (non-derived) invalidly redefines Action::input (derived union).

    -> Rename LinkAction::input to inputPin.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename OpaqueAction::input to inputPin

  • Key: UML22-1042
  • Legacy Issue Number: 9103
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    OpaqueAction::input (non-derived) invalidly redefines Action::input (derived union).

    -> Rename OpaqueAction::input to inputPin.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename InformationFlow::source

  • Key: UML22-1041
  • Legacy Issue Number: 9100
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    InformationFlow::source (non-derived) invalidly redefines DirectedRelationship::source (derived union).

    -> Rename InformationFlow::source to informationSource and remove

    {redefines source}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename InformationFlow::target

  • Key: UML22-1040
  • Legacy Issue Number: 9099
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    InformationFlow::target (non-derived) invalidly redefines DirectedRelationship::target (derived union).

    -> Rename InformationFlow::target to informationTarget and remove

    {redefines target}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename ActivityPartition::subgroup to subpartition

  • Key: UML22-1036
  • Legacy Issue Number: 9095
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    ActivityPartition::subgroup (non-derived) invalidly redefines ActivityGroup::subgroup (derived union).

    -> Rename ActivityPartition::subgroup to subpartition, replace

    {redefines subgroup}

    with

    {subsets subgroup}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Replace {redefines redefinedElement}

  • Key: UML22-1035
  • Legacy Issue Number: 9094
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    State::redefinedState (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

    -> Replace

    {redefines redefinedElement}

    with

    {subsets redefinedElement}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Replace {redefines redefinedElement}

  • Key: UML22-1034
  • Legacy Issue Number: 9093
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Transition::redefinedTransition (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

    -> Replace

    {redefines redefinedElement}

    with

    {subsets redefinedElement}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Replace {redefines redefinedElement}

  • Key: UML22-1033
  • Legacy Issue Number: 9092
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Region::extendedRegion (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

    -> Replace

    {redefines redefinedElement}

    with

    {subsets redefinedElement}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

body expression for Property::isConsistentWith(RedefinableElement)

  • Key: UML22-1026
  • Legacy Issue Number: 9085
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The body expression for Property::isConsistentWith(RedefinableElement) is incorrect; it should be:

    result = redefinee.oclIsKindOf(Property) and
    let prop : Property = redefinee.oclAsType(Property) in
    (prop.type.conformsTo(self.type) and
    ((prop.lowerBound()>notEmpty() and self.lowerBound()>notEmpty()) implies prop.lowerBound() >= self.lowerBound()) and
    ((prop.upperBound()>notEmpty() and self.upperBound()>notEmpty()) implies prop.lowerBound() <= self.lowerBound()) and
    (self.isDerived implies prop.isDerived))

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

following imports from merged packages to unmerged packages should be remov

  • Key: UML22-1025
  • Legacy Issue Number: 9084
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    UML::Deployments::ComponentDeployments -> UML::CommonBehaviors
    UML::StateMachines::ProtocolStateMachines -> UML::CommonBehaviors
    UML::UseCases -> UML::CommonBehaviors

    UML::AuxiliaryConstructs::InformationFlows -> UML::CompositeStructures
    UML::AuxiliaryConstructs::Models -> UML::CompositeStructures
    UML::Classes::AssociationClasses -> UML::CompositeStructures
    UML::CommonBehaviors::Communications -> UML::CompositeStructures
    UML::Interactions::Fragments -> UML::CompositeStructures
    UML::StateMachines::BehaviorStateMachines -> UML::CompositeStructures
    UML::StateMachines::ProtocolStateMachines -> UML::CompositeStructures

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Superstructure Fig 2.2 Incomplete

  • Key: UML22-1024
  • Legacy Issue Number: 9080
  • Status: closed  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    The current version of the UML 2 Superstructure specification
    (formal/05-07-04) has a diagram for the (top-level) package merges
    comprising L1 (Figure 2.2). The packages that are shown as merged in
    the diagram are: BasicActivities, BasicInteractions, Interfaces and
    UseCases. The definitional XML file for L1, however, actually merges
    BasicActivities, BasicInteractions, UseCases, Communicatiions and
    InternalStructures

  • Reported: UML 2.0 — Fri, 14 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This is resolved by the resolutions to issues 9180 and 8459 (ballot 12).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.4

  • Key: UML22-1023
  • Legacy Issue Number: 9077
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The statement "Interaction Overview Diagrams are specialization of Activity Diagrams that represent Interactions." is misleading. An Interaction Overview Diagram is not a special activity diagram. It just re-uses the activity notation.

  • Reported: UML 2.0 — Wed, 12 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Common Behaviors

  • Key: UML22-1020
  • Legacy Issue Number: 9007
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Description section of Common Behaviors, CallConcurrencyKind, how can "Multiple invocations of a behavioral feature" occuring simultaneously have a "first behavioral feature". Full text: "Multiple invocations of a behavioral feature may occur simultaneously to one instance, but only one is allowed to commence. The others are blocked until the performance of the first behavioral feature is complete. It is the responsibility of the system designer to ensure that deadlocks do not occur due to simultaneous blocks."

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    While nit-picking, the issue submitter is correct

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions

  • Key: UML22-1019
  • Legacy Issue Number: 9006
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 143 should show MultiplicityElement as being from Kernel (the MDL file accidentally used a copy).

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue was fixed in a previous revision. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.3.22 InstanceSpecification

  • Key: UML22-1022
  • Legacy Issue Number: 9023
  • Status: closed  
  • Source: Anonymous
  • Summary:

    on reading UML Superstructure I found a little mistake regarding chapter
    >7.3.22 InstanceSpecification. This inconsistency seems although to be
    >corrected within UML Infrasturcture.
    >UML Superstructure, page 79, InstanceSepcification - Associations
    >classifier : Classifier [0..*] ...
    >
    >UML Infrastructure, page 66, InstanceSpecification - Associations
    >classifier : Classifier [1..*]
    >
    >I guess the specification within UML Infrasturcture is true. However I
    >hope to get some kind of confirmation from you (as I want to be sure).

  • Reported: UML 2.0 — Wed, 28 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 504 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-1021
  • Legacy Issue Number: 9010
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that multiple arrows coming out of an object-node-in-the-middle notation has the semantics of multiple edges coming out of an output pin.

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-1018
  • Legacy Issue Number: 9003
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Association.memberEnd should specialize Relationship:relatedElement. Programs accessing the repository with RelatedElement should get the elements being associated

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-1017
  • Legacy Issue Number: 9000
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Figure 195, subsetting opposite Variable should be of namespace, rather than owner

  • Reported: UML 2.0 — Sun, 25 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Invalid stereotype in StandardProfile

  • Key: UML22-1016
  • Legacy Issue Number: 8996
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Page 671 (ormal/05-07-04),<< script>> is in StandardProfileL1, but its base element, Deployments::Artifact isn’t in L1.

  • Reported: UML 2.0 — Thu, 22 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8459 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / miscellaneous figure-text discrepancies

  • Key: UML22-1015
  • Legacy Issue Number: 8993
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There are a few discrepancies between the figures and the latest Superstructure text (formal/05-07-04) that need to be fixed:

    (1) figure 15.2 contains State::doAcvity – it should be State::doActivity (the textual description of this item uses correct spelling)

    (2) resolutions to issues 6185 and 7342 indicate that Behavior::context should be derived and that it should subset "redefinitionContext". This needs to be fixed in figure 13.6. Also, the description in the text for this item on page 417 should be updated to show that "context" is derived ("/context").

    (3) the association end Pseudostate::state shown in figure 15.2 is not documented. It should be.

  • Reported: UML 2.0 — Thu, 22 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 500 -501 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename Package::ownedMember

  • Key: UML22-1028
  • Legacy Issue Number: 9087
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Package::ownedMember (non-derived) invalidly redefines Namespace::ownedMember (derived union).

    -> Rename Package::ownedMember to packagedElement and replace

    {redefines ownedMember}

    with

    {subsets ownedMember}

    . Update all references to ownedMember (e.g. in sample profiles XMI) as appropriate.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename Constraint::namespace

  • Key: UML22-1027
  • Legacy Issue Number: 9086
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Constraint::namespace (non-derived) invalidly redefines NamedElement::namespace (derived union).

    -> Rename Constraint::namespace to context, replace

    {redefines namespace, subsets context}

    with

    {subsets namespace}

    on it, and remove Constraint::context.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 510 - 512 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename ActivityEdge::redefinedElement

  • Key: UML22-1030
  • Legacy Issue Number: 9089
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    ActivityEdge::redefinedElement (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

    -> Rename ActivityEdge::redefinedElement to redefinedEdge, replace

    {redefines redefinedElement}

    with

    {subsets redefinedElement}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename Component::ownedMember

  • Key: UML22-1029
  • Legacy Issue Number: 9088
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Component::ownedMember (non-derived) invalidly redefines Namespace::ownedMember (derived union).

    -> Rename Component::ownedMember to packagedElement and replace

    {redefines ownedMember}

    with

    {subsets ownedMember}

    . Update any references to ownedMember as appropriate.

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Replace {redefines redefinedElement}

  • Key: UML22-1032
  • Legacy Issue Number: 9091
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    StateMachine::extendedStateMachine (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

    -> Replace

    {redefines redefinedElement}

    with

    {subsets redefinedElement}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename ActivityNode::redefinedElement

  • Key: UML22-1031
  • Legacy Issue Number: 9090
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    ActivityNode::redefinedElement (non-derived) invalidly redefines RedefinableElement::redefinedElement (derived union).

    -> Rename ActivityNode::redefinedElement to redefinedNode, replace

    {redefines redefinedElement}

    with

    {subsets redefinedElement}

    .

  • Reported: UML 2.0 — Wed, 19 Oct 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 6.5

  • Key: UML22-1012
  • Legacy Issue Number: 8987
  • Status: closed  
  • Source: Vtron ( Minghua Liu)
  • Summary:

    "“Part I. Structure” defines the static, structural constructs (e.g., classes, components, nodes artifacts) used in various structural diagrams, such as class diagrams, component diagrams, and deployment diagrams. Part II - “Behavior” specifies the dynamic, behavioral constructs (e.g., activities, interactions, state machines) used in various behavioral diagrams, such as activity diagrams, sequence diagrams, and state machine diagrams. “Part ~~~~ I. Structure” defines auxiliary constructs ~~~~~~~~~~~~~~ (e.g., information flows, models, templates, primitive types) and the profiles used to customize UML for various domains, platforms, and methods" The words underlined shoude be "Part III - Supplement.

  • Reported: UML 2.0 — Wed, 7 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 should specify default property ownership for association ends

  • Key: UML22-1011
  • Legacy Issue Number: 8978
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    UML2 should define the defaults for property ownership and the explicit meaning of navigation notation. It should also provide notation for overriding these defaults in order to specify explicity the classifier that owns a property without relying on navigability. This recognizes a common notation practice and will result in predictable metamodel interchange. I general, the UML2 spec should attempt to avoid situations like the pair EF and IJ in figure 21, and instead use sensible defaults. If the default isn't what the model wants, then there should be notation to explicitly say what is needed. This will limit semantic variation points or unspecified notation meaning that may result in interchange and interoperability issues.

    The diagram conventions used in Superstructure section 6.5.2 tie navigability and property ownership together in a manner that is consistent with the notaiton used in Basic and EMOF. However section 7.3.1 Notation for Association says:

    Various options may be chosen for showing navigation arrows on a diagram. In practice, it is often convenient to suppress
    some of the arrows and crosses and just show exceptional situations:
    • Show all arrows and x’s. Navigation and its absence are made completely explicit.
    • Suppress all arrows and x’s. No inference can be drawn about navigation. This is similar to any situation in which
    information is suppressed from a view.
    • Suppress arrows for associations with navigability in both directions, and show arrows only for associations with oneway
    navigability. In this case, the two-way navigability cannot be distinguished from situations where there is no navigation
    at all; however, the latter case occurs rarely in practice.

    This is fine, but given a UML2 diagram what are we to assume if all navigations are not explicit as in the first bullet? Wouldn't such such a model be ambiguous? Should UML2 specify which one of these conventions are implied by the notation? The last bullet represents common practice as well as the conventsions used in the UML2 specification. Perhaps the UML2 spec should to be specific about what the notation means and not leave this up to the reader.

    Later in the spec (page 42) under Issue 6243, Figure 22 shows a class containing a property with non-primitive type and indicates this is an ownedAttribute of the class, and can be shown as an association too as described in Basic and EMOF. What it doesn't say is what the notation

    by itself means. We know ClassA can navigate to b, but we don't know anything about who owns the properties and therefore where the ends go in an instance of the metamodel. Are they both ownedEnds of the Association? Is b an ownedAttribute of ClassA and a is an ownedEnd? Since there is currently no notation for specifying which classifier owns the properties, the notation should specify the default owners. Otherwise different tools may produce different XMI as it is not clear when a property on an association end is an ownedEnd of the association or an ownedAttribute of one of the associated classes.

    The conventions in 6.5.2 should be the definitive notation for navigation arrows (with x on the ends options to make non-navigable explicit), and also specifies the default for property ownership. That is, the bullet lists in 7.3.1 should be replaced with those in 6.5.2 for association navigability and property ownership.

    Then a notation should be specified for explicitly stating property ownership when the default is not appropriate.

  • Reported: UML 2.0 — Fri, 26 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 430 references invalid metaclass

  • Key: UML22-1002
  • Legacy Issue Number: 8947
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Figure 430 references an 'IntegerExpression' metaclass that doesn't exist. Either such a metaclass (and others for other kinds of expressions?) should be added, or the example should be changed to use a different type of expression.

  • Reported: UML 2.0 — Tue, 2 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.5

  • Key: UML22-1001
  • Legacy Issue Number: 8946
  • Status: closed  
  • Source: Bergson TA ( Marc Hamilton)
  • Summary:

    A Property is a ConnectableElement, which currently is (should be?) a TypedElement. The Description in 9.3.5 however states: "A ConnectableElement is an abstract metaclass representing a set of instances that play roles of a classifier. Connectable elements may be joined by attached connectors and specify configurations of linked instances to be created within an instance of the containing classifier. Note on p.84 states: "When used to specify the existence of an entity in a modelled system, an instance specification represents part of that system." In 9.3.12. it says:"When an instance of the containing classifier is created, a set of instances corresponding to its properties may be created either immediately or at some later time. These instances are instances of the classifier typing the property. A property specifies that a set of instances may exist; this set of instances is a subset of the total set of instances specified by the classifier typing the property. A part declares that an instance of this classifier may contain a set of instances by composition." So, the concepts must be related. I propose that a ConnectableElement is a specialization of InstanceSpecification, not just a TypedElement. Current problems in practise: A TypedElement is not a PackageableElement and it thus cannot be imported in some other namespace. This makes is hard to create orthogonal views of architectures (e.g. logical vs. execution) in which 'roles' (parts!) are shared. On the other hand, using InstanceSpecifications instead of "Parts" makes it impossible to refer them in interactions. Besides, the meaning of an InstanceSpecification in the context of a classifier is unclear in contrast to the Property.

  • Reported: UML 2.0 — Tue, 2 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: The concept of connectable element is not an instance specification, so it would be a mistake to make it a specialization of InstanceSpecification. As the issue also points out, doing so would cause problems with interactions (where connectable elements are heavily used) as well as with their meaning. The issue really at hand appears to be that ConnectableElements are not packageable elements. The reason is that they have really no meaning outside of the context of the classifier they are owned by and thus would not be packaged separately. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Navigability Impact on Tools

  • Key: UML22-1006
  • Legacy Issue Number: 8963
  • Status: closed  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    The notion of navigability for association ends may be interpreted as
    limiting the ability of UML tools to traverse associations with
    non-navigable ends. However, discussion among RTF members indicates
    that UML tools need not be specifically limited in their ability to
    traverse non-navigable ends. To prevent confusion about the impact of
    non-navigable ends among tool developers studying the specification, the
    ability of UML repositories and other tooling to ignore navigability
    limitations should be explicitly stated.

  • Reported: UML 2.0 — Thu, 11 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 XMI DTD requirement

  • Key: UML22-1005
  • Legacy Issue Number: 8957
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In section 6.5.1 of both the RFP for the UML 2 Superstructure and the RFP for the UML 2 Infrastructure it is required that

    Proposals shall specify an XMI DTD for the UML metamodel.

    This was based on the assumption that such schemas carry sufficient information for tool vendors to construct facilities for meaningful interchange of models. Unfortunately, due to the introduction of certain more complex features such as package merge in UML 2.0, these schemas are not sufficient. On the other hand, the XMI for the individual compliance levels (Lm, L0, L1, L2, and L3) is sufficient for the interchange objective. Therefore, instead of the XMI schemas, it is proposed to make the latter normative for the UML 2 Superstructure and Infrastructure specs.

  • Reported: UML 2.0 — Wed, 10 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This is resolved by the resolution to 3898 and the explanatory text for 8678.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 issue: {unrestricted} described in text but not BNF

  • Key: UML22-998
  • Legacy Issue Number: 8935
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In section 7.3.49 of Super, and 9.2.2 of Infra,

    {unrestricted} is given as a notation option: "A modifiable structural feature is shown using {unrestricted}

    as part of the notation for the structural feature."
    However unrestricted is is not included in the BNF for Property (in 7.3.44).
    It does not seem useful as a keyword since it is the default; nor is 'unrestricted' a very suggestive term for the meaning.

    Proposed Resolution:
    Delete the above sentence from 7.3.49 of Super, and 9.2.2 of Infra.

  • Reported: UML 2.0 — Tue, 19 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Superstructure / Actions / Missing package heading

  • Key: UML22-997
  • Legacy Issue Number: 8933
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In section 11.3.21, (Actions, LinkAction), the second constraitns section should include the phrase (CompleteActions) at the end

  • Reported: UML 2.0 — Mon, 18 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Undocumented properties

  • Key: UML22-1010
  • Legacy Issue Number: 8976
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The following properties appear in the metamodel diagrams but are not documented in the spec:

    UML::Classes::Kernel::Property::class
    UML::Components::BasicComponents::Connector::contract
    UML::Components::BasicComponents::Realization::abstraction
    UML::Components::BasicComponents::Realization::realizingClassifier
    UML::Interactions::BasicInteractions::Lifeline::coveredBy

  • Reported: UML 2.0 — Thu, 25 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 494 - 495 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 591,592

  • Key: UML22-1009
  • Legacy Issue Number: 8968
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Constraint 9 and 10 state that entry and exit points are only allowed in the topmost region of a statemachine. On page 592 the entry/exit point semantic describes that these points are also allowed on composite states (see also issue 6075). I think the constraints don't take into account that composite states are also allowed.

  • Reported: UML 2.0 — Wed, 17 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Core::Constructs::Operation

  • Key: UML22-1008
  • Legacy Issue Number: 8966
  • Status: closed  
  • Source: Vienna University of Technology ( Lorenz Froihofer)
  • Summary:

    This is a question or an issue for the UML 2.0 Superstructure and Infrastructure Revision Task Force (http://www.omg.org/issues/uml2-rtf.html An operation, e.g. Core::Constructs::Operation does no longer contain the isAbstract attribute (compared to UML version 1.5). I could not find a note in any of the classes within the inheritance hierarchy stating that this is a change to the 1.x versions. Was this attribute intentionally dropped for version 2.0? If yes, what is the suggested replacement?

  • Reported: UML 2.0 — Tue, 9 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This ability is still there, since the attribute isAbstract is inherited from BehavioralFeature (which is a superclass of Operation) as defined in CommonBehaviors. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interaction::lifeline should be ordered

  • Key: UML22-1007
  • Legacy Issue Number: 8964
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    Interaction::lifeline should be ordered so as to dictate the ordering of lifelines (in a diagram for example).

  • Reported: UML 2.0 — Fri, 12 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Classes Notation for association end ownership

  • Key: UML22-1004
  • Legacy Issue Number: 8956
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML 2.0 has separated the concepts of navigability from association end ownership. However there is as yet no explicit notation for specifying who owns an association end. An explicit notation is required and, possibly, a set of default notational conventions for the most frequent cases.

  • Reported: UML 2.0 — Wed, 10 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 489 - 490 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

connection point reference

  • Key: UML22-1003
  • Legacy Issue Number: 8955
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Is this known issue, that just one ConnectionPointReference can point into same connection point?
    It's not possible to create two SubMachineStates with ConnectionPointReferences assigned with same StateMachine, because meta Association between PseudoState (connection point) and ConnectionPointReference has multiplicity [0..1].

    This destructs all concept of reusable StateMachines

  • Reported: UML 2.0 — Wed, 10 Aug 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Collaboration use issues (02)

  • Key: UML22-1014
  • Legacy Issue Number: 8990
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    2) The caption of Figure 106 still refers to "collaboration occurrence" (should be "collaboration use")

  • Reported: UML 2.0 — Thu, 22 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Collaboration use issues (01)

  • Key: UML22-1013
  • Legacy Issue Number: 8989
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    (1) All the dependencies in Figure 109 of ptc/04-10-02 are pointing in the wrong direction. Note that constraint [1] of CollaborationUse says:
    "All the client elements of a roleBinding are in one classifier and all supplier elements of a roleBinding are in one collaboration..."

    which implies that the supplier elements (the ends with the arrow, according to the notation subsection of Dependency) are the roles in the collaboration and the client elements are the parts that are playing specific roles of that collaboration. The figure actually shows the inverse of that.

  • Reported: UML 2.0 — Thu, 22 Sep 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 498 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.18 and 12.3.35

  • Key: UML22-1000
  • Legacy Issue Number: 8939
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Add constraint to conditional and loop node that the result output pins have no outgoing edges

  • Reported: UML 2.0 — Mon, 25 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.14

  • Key: UML22-999
  • Legacy Issue Number: 8938
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    BNF for transition specifies that a trigger is mandatory. That's not the case, e.g. for the initial state transition.

  • Reported: UML 2.0 — Fri, 22 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p. 732: Show examples of new stereotype notation

  • Key: UML22-987
  • Legacy Issue Number: 8852
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    8) p. 732: Show examples of new stereotype notation. Add the following including new Figure 463:
    "Finally, the two alternate notational forms are shown.

    • Other notational forms for showing values
      AlarmClock is valid for OS version 1.1, is POSIX-compliant and it has a starting operation called Start. The compartment form of notation is shown on the left and the in-symbol form on the right (note that not all properties of Clock are shown on the right."
  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 468 - 469 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p. 732: Change example to be consistent with new definition of Clock

  • Key: UML22-986
  • Legacy Issue Number: 8851
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    7) p. 732: Change example to be consistent with new definition of Clock. Replace figure 462 with:

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 466 -467 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.5

  • Key: UML22-994
  • Legacy Issue Number: 8919
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Description
    Section Associations (CompleteActivities): weight specifies the number of tokens instead of objects consumed from the source node on each traversal. It's a common property for object flow as well as for control flows.

  • Reported: UML 2.0 — Wed, 6 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 163

  • Key: UML22-993
  • Legacy Issue Number: 8901
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Fig. 93: The only message of the notation abstraction is that some components offer and some components require an interface. That the same as in a component diagram. Fig. 93 shows an internal view of a component. A composite structure diagram must show how the components are wired together. For examples that :BackOrder uses :Customer and NOT :Organization or vice versa. I propose to not use the notation abstraction.

  • Reported: UML 2.0 — Thu, 30 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Introducing a minimalist resolution, to just fix the incorrectly used terminology.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Make instance model consistent with new definition of Clock

  • Key: UML22-983
  • Legacy Issue Number: 8848
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    4) p. 730: Make instance model consistent with new definition of Clock. Replace Figure 458 with:

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 463 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p. 729: Extend the Clock example to show metaclass property

  • Key: UML22-982
  • Legacy Issue Number: 8847
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)3) p. 729: Extend the Clock example to show metaclass property and the use of Boolean. Replace Figure 456 with:

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 462 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p. 731: Make example consistent with new definition of Clock.

  • Key: UML22-985
  • Legacy Issue Number: 8850
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    6) p. 731: Make example consistent with new definition of Clock. Replace Figure 461 with:

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8849 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p. 731: Make this example consistent with the new definition of Clock

  • Key: UML22-984
  • Legacy Issue Number: 8849
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    5) p. 731: Make this example consistent with the new definition of Clock. Replace Figure 459 with:

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 464 - 465 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.37 ObjectFlow

  • Key: UML22-989
  • Legacy Issue Number: 8859
  • Status: closed  
  • Source: Sapiens Deutschland GmbH ( Helmut Barthel)
  • Summary:

    On page 418, Constraints (BasicActivities), you write: "[1] Object flows may not have actions at either end." In contrast, on page 420, Notation, the description of the upper right part of figure 281 is: "Two object flow edges linking object nodes and actions(!!)." After many cycles of re-reading the Activities chapter I got convinced that the constraint is really meant as-is. So, the notation mentioned above likely means the "standalone pin notation" from page 433. If so, you should make it very clear, that this notation maps to two Pin instances (one at either action) and ONE ObjectFlow instance in-between, in the model (just like the alternative notation in the same figure shows). In addition, you should add this clarification throughout the Activities chapter. In addition, on page 433, regarding the explanation of the standalone pin notation, you should add, that it maps to ONE object flow edge in-between the two pins, in the model.

  • Reported: UML 2.0 — Tue, 7 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Superstructure / Actions / incorrect form for subsetting

  • Key: UML22-996
  • Legacy Issue Number: 8932
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The Actions chapter uses the convention "Specialized from" in describing properties that are specialized in a metaclass, instead of the "Subsets " convention used throughout the rest of the document. The former should all be changed to follow the conventional form.

  • Reported: UML 2.0 — Mon, 18 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.9

  • Key: UML22-995
  • Legacy Issue Number: 8930
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Semantics section, last sentence: Recursive reference to semantics section of ActivityParameterNode.

  • Reported: UML 2.0 — Mon, 18 Jul 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

pp. 733-734: Add association as valid graphic path

  • Key: UML22-988
  • Legacy Issue Number: 8853
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    Recommended changes:
    9) pp. 733-734: Add association as valid graphic path. Add the following row to Table 24:

    Unidirectional Association See "Profile (from Profiles)" on page 720

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TimeExpression

  • Key: UML22-991
  • Legacy Issue Number: 8894
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    TimeExpression should hold time value, but there is no attribute for that. Maybe TimeExpression should be inherited from OpaqueExpression and hold value in "body"?

  • Reported: RAS 2.2 — Mon, 20 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 472 - 478 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OpaqueAction

  • Key: UML22-990
  • Legacy Issue Number: 8867
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    should specialize input and output, so opaque actions can have pins.

  • Reported: UML 2.0 — Tue, 14 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 471 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

abstract Action in Activity diagram

  • Key: UML22-992
  • Legacy Issue Number: 8896
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    4. The same situation is with abstract Action in Activity diagram. OpaqueAction also can't be used, because can't have Pins.
    How to draw "human friendly" action (activity)? The only way is to use CallBehaviorAction?

  • Reported: RAS 2.2 — Mon, 20 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8867 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p. 728: New presentation options. Replace the following paragraph

  • Key: UML22-981
  • Legacy Issue Number: 8846
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Recommended Changes to UML 2.0 Profiles to Support SysML

    Source: SysML Partners (Partners@SysML.org)
    Nature: Revision
    Severity: Significant
    Summary:
    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)

    2) p. 728: New presentation options. Replace the following paragraph:
    "The values of a stereotype that has been applied to a model element can be shown as part of a comment symbol tied to the model element. The values from a specific stereotype are optionally preceded with the name of the applied stereotype within a pair of guillemets, which is useful if values of more than one applied stereotype should be shown."
    with the following text:
    "The values of a stereotype that has been applied to a model element can be shown in one of three ways:
    ·As part of a comment symbol tied to the symbol representing the model element
    ·In compartments of a graphic node representing the model element.
    ·Above the name string within a graphic node or before the name string otherwise
    In the case where a compartment or comment symbol is used, the user may elect to show the stereotype name in guillemets before the name string in addition to in the compartment or comment.
    They are displayed as name/value pairs, thus:
    <namestring>'='<valuestring>
    If a stereotype property is multi-valued then the valuestring is displayed as a comma-separated list:
    <valuestring>::=<value>

    {','<value>}

    Certain values have special display rules:
    ·As an alternative to a name/value pair, when displaying the values of boolean properties diagrams may use the convention that if the namestring is displayed then the value is True, otherwise the value is False;
    ·If the value is the name of a NamedElement then optionally its qualifiedName can be used.
    If compartments are used to display stereotype values then an additional compartment is required for each applied stereotype whose values are to be displayed. Each such compartment is headed by the name of the applied stereotype in guillemets. Any graphic node may have these compartments.
    Within a comment symbol, or if displayed before/above the symbols's namestring, the values from a specific stereotype are optionally preceded with the name of the applied stereotype within a pair of guillemets, which is useful if values of more than one applied stereotype should be shown.
    When displayed in compartments or comment symbol at most one name/value pair can appear on a single line. When displayed above/before a namestring the name/value pairs are separated by semicolons and all pairs for a given stereotype are enclosed in braces."

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 460 - 461 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p. 721: Allow stereotypes to have properties that are typed by metaclasses

  • Key: UML22-980
  • Legacy Issue Number: 8845
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    SysML extends the use of Profile notation and requires that stereotypes can reference UML metaclasses. In order to satisfy the needs of SysML, the following changes need to be made to the the UML 2.0 Superstructure Profiles chapter. "Convenience documents" in .fm and .pdf formats, which redline the proposed changes to the Profiles chapter, are provided as attachments to this issue submission. (See
    UML2-Super-Profiles-ConvenienceDoc-050525.fm and UML2-Super-Profiles-ConvenienceDoc-050525.pdf.)
    . Change paragraph 4 to:
    "As part of a profile, it is not possible to have an association between two stereotypes or from a metaclass in the reference metamodel to a stereotype, although a unidirectional association from a stereotype to a metaclass, or equivalently typing a stereotype property by a metaclass, is allowed. The effect of new (meta) associations between stereotypes can be achieved in limited ways either by:"

  • Reported: RAS 2.2 — Thu, 2 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 7756 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Can't specify mutator semantics for derived properties

  • Key: UML22-968
  • Legacy Issue Number: 8769
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    It is currently not possible to specify the effect of setting derived properties that are not read-only. As a result, derived properties are under-specified in the model because the semantics of updating them cannot be modeled or stated formally.

  • Reported: RAS 2.2 — Fri, 6 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.37

  • Key: UML22-967
  • Legacy Issue Number: 8766
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It's a common modeling scenario that an object flow with an outpin pin at the source must target an action directly (without a pin). For example a decision node with an incoming object flow - the object is necessary for the guard condition -, but one or more of the target actions don't need that object. Due to the constraint that object flows don't have actions at either end I must model an input pin. For example in case of a CallOperationAction an operation with an additional parameter must be defined even if I don't use it. It's just for modeling purposes. I've assumed before reading the constraint in the specification that an object flow can target an action directly. In that case it's semantic is the same as for the control flow. That works perfect for me. I would propose to weaken the constraint for object flows that actions as targets are allowed. The object token enables the action and gets lost. Any other solution with the same semantic is also acceptable.

  • Reported: RAS 2.2 — Thu, 5 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MessageEnd

  • Key: UML22-976
  • Legacy Issue Number: 8784
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    MessageEnd is MessageOccurrenceSpecification that redefines "event" as MessageEvent.
    DestructionEvent and CreationEvent are not subclasses of MessageEvent, so can't be on message end, so how to map "create message" and "destroy message"?

  • Reported: RAS 2.2 — Wed, 18 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExecutableNode should be abstract in Figure 195. It is in Figure 197.

  • Key: UML22-975
  • Legacy Issue Number: 8782
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ExecutableNode should be abstract in Figure 195. It is in Figure 197.

  • Reported: UML 2.0 — Sun, 15 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8239 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12 and 13

  • Key: UML22-979
  • Legacy Issue Number: 8826
  • Status: closed  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    Figure numbers 306,307,308,309 appear in both the Activities chapter (12) and the Common Behavior chapter (13)

  • Reported: UML 2.0 — Thu, 26 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect Communication Domain Model

  • Key: UML22-978
  • Legacy Issue Number: 8825
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    Fig. 308 does not contain the correct domain model. The current model that
    appears in Fig. 308 is a duplicate of Fig. 307.

  • Reported: RAS 2.2 — Thu, 26 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8292 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Obsolete term EventOccurrence still used in multiple places

  • Key: UML22-977
  • Legacy Issue Number: 8824
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    1) 14.3.25 OccurrenceSpecification, the change in class name was from EventOccurrence to OccurrenceSpecification. This change needs to be noted in this document. Also, the reason why the change was made.
    2) EventOccurrence is still being use in the toBefore and toAfter association descriptions of OccurrenceSpecification.
    3) EventOccurrence is still be referenced in other areas:
    a) in the last word of the Example text on page 476,
    b) In the Notation text on Page 489,
    c) In the fifth paragraph of the overview on Page 497
    d) Multiple times on Page 509 and 510
    e) First paragraph on Page 528
    f) Multiple times on Page 531
    g) Multiple times on Fig. 347

  • Reported: RAS 2.2 — Thu, 26 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 453 - 457 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation of Attributes and Associations subsections

  • Key: UML22-972
  • Legacy Issue Number: 8774
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Notation of Attributes and Associations subsections in the whole specification should be consistently follow the rules: Every entry must include * attribute/association end name * its type * its multiplicity: you should NOT omit this even if it maps to the default value of *. Also, both upper and lower multiplicities should be provided; i.e., NOT "[*]" but "[0..*]") * ALL modifiers such as subsets and redefines. When referencing other association ends, use the following convention: "<metaclass-name>::<association-end-name> (do NOT use the "." notation for this) * if something is derived, the explanation should be given how it is derived and an OCL formula might have to be provided.

  • Reported: RAS 2.2 — Tue, 10 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Most of these issues have been resolved through numerous editorial changes that were intended to ensure consistency. The exceptions are:
    „h the use of * instead of 0..* – simply not worth the effort given that the two are equivalent. It will take a lot of effort to do this with no real value; chances are that this will NEVER get done. There is no point in keeping the issue open.
    „h The derivation specification already has another open issue.
    Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 330

  • Key: UML22-971
  • Legacy Issue Number: 8773
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Typo in fig. 192: Association from BehavioralFeature to Parameterset: should be ownedMember instead of ownedmember (uppercase).

  • Reported: UML 2.0 — Tue, 10 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue refers to an older version of the specification. It is fixed in the meantime. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.48

  • Key: UML22-970
  • Legacy Issue Number: 8772
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Semantic sections mentions the order of structural features of the specified classifier. The list of structural features is ordered for a class, but unordered for a classifier.

  • Reported: UML 2.0 — Mon, 9 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions

  • Key: UML22-969
  • Legacy Issue Number: 8770
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    The third sentence of the Actions chapter implies that most of the actions are specialization of the one that supports implementation-dependent semantics. Should be reworded.

  • Reported: UML 2.0 — Fri, 6 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Actions should be able to overlap partitions, to support multiple participa

  • Key: UML22-974
  • Legacy Issue Number: 8781
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Actions should be able to overlap partitions, to support multiple participants

  • Reported: UML 2.0 — Sun, 15 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1 Page: 156 ff

  • Key: UML22-973
  • Legacy Issue Number: 8778
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Fig. 86, 87, and 89 have no dividing line between name compartment and internal view compartment

  • Reported: UML 2.0 — Thu, 12 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This dividing line is optional. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OpaqueAction

  • Key: UML22-966
  • Legacy Issue Number: 8759
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    In chapter 11.3.26 OpaqueAction is described as subclass of Pin. It
    > should be subclass of Action.

    That's a bug. Please raise an issue.

    > Can OpaqueAction be used as default Action type in Activity diagrams
    > and be as replacement of old-style user defined ActionStates in UML 1.4?

    It sounds like you are asking for a new feature. I don't see that the RTF will accept this default. You can always do this woth a profile.

  • Reported: RAS 2.2 — Tue, 3 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 591

  • Key: UML22-965
  • Legacy Issue Number: 8753
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The semantics section describes that the transition from an initial pseudostate may have an action. There should be a constraint in the constraints section that actions are allowed, but no triggers and guards. Instead of action it should be named behavior.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 442 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify caption of Figure 56

  • Key: UML22-961
  • Legacy Issue Number: 8746
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify caption of Figure 56. The wording of caption of Figure 56 gives the impression that it is a general notation to provided/required interfaces, especially because it is in the Presentation Option section. Discussion during FTF was that this is only an example, rather than a general notation.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Interactions

  • Key: UML22-960
  • Legacy Issue Number: 8745
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Messages to self. Are curved arrows in interactions (sending to self) still supported in UML 2? See Figure 3-56 in UML 1.5 (doc.omg/org/formal/03-03-01). If not, how are messages to self shown?

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify first constraint on InputPin and OutputPin, move "only" to before "

  • Key: UML22-953
  • Legacy Issue Number: 8734
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify first constraint on InputPin and OutputPin, move "only" to before "when".

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

LoopNode should move rather than copy values to/from loop variables

  • Key: UML22-952
  • Legacy Issue Number: 8733
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    LoopNode should move rather than copy values to/from loop variables. Otherwise, tokens will be dangling tokens. Same for ConditionalNode bodyOutput, etc.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In Figure 210, put merge before Use Part to merge the incoming flows

  • Key: UML22-951
  • Legacy Issue Number: 8732
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Figure 210, put merge before Use Part to merge the incoming flows

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 431 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exceptions thrown across synchronous invocations

  • Key: UML22-950
  • Legacy Issue Number: 8730
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Exceptions thrown across synchronous invocations. Clarify that exceptions are thrown across synchronous invocations, not asynchronous ones. Or introduce an attribute to tell whether it is thrown across call boundaries.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiple exception handlers

  • Key: UML22-949
  • Legacy Issue Number: 8729
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Multiple exception handlers. Clarify that one exception handler is executed if multiple match, and it is undefined which

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Actions, CallBehaviorAction, third sentence,

  • Key: UML22-955
  • Legacy Issue Number: 8736
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Actions, CallBehaviorAction, third sentence, should be limited to synchronous calls

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The Syle Guidelines for Stereotype

  • Key: UML22-954
  • Legacy Issue Number: 8735
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The Syle Guidelines for Stereotype says "The values of an applied stereotype are normally not shown." This is application-dependent. Sentence should be removed

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CollaborationUse: Constraint 1,

  • Key: UML22-959
  • Legacy Issue Number: 8744
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    CollaborationUse: Constraint 1, allows parameters from different operations to be coordinated. Is that intended?

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue appears to refer to an earlier version of the specification. It is impossible to identify in the current version what this issue concerns. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ConditionalNode and LoopNode test and bodies should be ExecutableNodes

  • Key: UML22-958
  • Legacy Issue Number: 8740
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ConditionalNode and LoopNode test and bodies should be ExecutableNodes

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExpansionRegion

  • Key: UML22-957
  • Legacy Issue Number: 8739
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ExpansionRegion, clarify that tokens in input pins and expansion nodes are destroyed when the expansion node completes

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ControlFlow

  • Key: UML22-956
  • Legacy Issue Number: 8737
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ControlFlow should say that if it targets an action, or control pin of action, then the action requires a control token to start executing

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Last element in transition BNF

  • Key: UML22-964
  • Legacy Issue Number: 8752
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Last element in transition BNF should be <behavior-expression> instead of <activity-expression>. The term is used on the next side.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Update as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for connector end multiplicities.

  • Key: UML22-962
  • Legacy Issue Number: 8747
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Notation for connector end multiplicities. Notation of ConnectorEnd, first paragraph says the multiplicities shown are the association multiplicities. What about the connector end multiplicities?

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue has been fixed in the current version of the specification. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ParameterSet, first line: "inputs *or* outputs".

  • Key: UML22-963
  • Legacy Issue Number: 8749
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    ParameterSet, first line: "inputs or outputs".

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In Activities, Figure 176, Action should be abstract

  • Key: UML22-942
  • Legacy Issue Number: 8718
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Activities, Figure 176, Action should be abstract

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profile Semantics, pag 723

  • Key: UML22-941
  • Legacy Issue Number: 8706
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    "A reference metamodel typically consists of metaclasses that are either
    imported or locally owned. All metaclasses that
    are extended by a profile have to be members of the same reference
    metamodel. A tool can make use of the information
    about which metaclasses are extended in different ways, for example to
    filter or hide elements when a profile is applied, ..."

    The specification must be explicit about the mechanism used to hide/filter
    reference metamodel elements. The SysML Partners are trying to do exactly
    this with SysML but it's not clear from the above paragraph or any other
    part of the Profiles section how to do it.

  • Reported: RAS 2.2 — Thu, 28 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12

  • Key: UML22-935
  • Legacy Issue Number: 8680
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    "Any object nodes declared as outputs are passed out of the containing activity." Only tokens can be passed, not nodes. I suggest: "The last token from each output Activity Parameter Node is offered on the corresponding output of the calling action."

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

token

  • Key: UML22-934
  • Legacy Issue Number: 8679
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    "All tokens offered on the incoming edges are accepted." 1- The edges of of the terminated Activity or of the Activity Final Node? 2- In general, it is not possible to accept all tokens offered. For instance, a same token in an ObjectNode could cause two token offers throughtwo forks. Yet, only one of these offered tokens can be accepted, causing the other to be no longer offered. I suggest to delete this sentence.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

String is primitive but has structure.

  • Key: UML22-944
  • Legacy Issue Number: 8720
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    String is primitive but has structure. Section 17.4 (PrimitiveTypes) has String, even though the definition of primitive type in Section 7.3.43 excludes any structure: "A primitive type defines a predefined data type, without any relevant substructure (i.e. it has no parts). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically."

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

``conditional node or conditional node'' delete one.

  • Key: UML22-937
  • Legacy Issue Number: 8683
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    ``conditional node or conditional node'' delete one.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

add the rule of ``natural termination''

  • Key: UML22-936
  • Legacy Issue Number: 8681
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    I suggest to add the rule of ``natural termination'': An activity terminates when it has a token in each of its output Activity Parameter Nodes. This removes the need for Activity Final Nodes in most cases, and makes UML less error-prone, since it is an error to terminate without a token in each output Activity Parameter Node. It also makes the languages more consistent, since this rule is used for loops.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Solid triange notation for Association

  • Key: UML22-948
  • Legacy Issue Number: 8728
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Solid triange notation for Association. Association, Examples, shows a solid triangle notation that is not mentioned in the notation section. It says it indicates the order of reading, but association generally don't have an order or reading, the end names express the order of reading. I thought it showed the order of the association ends (Association.memberEnd is ordered), because there's no other notation for that.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The create stereotype on Usage dependency

  • Key: UML22-947
  • Legacy Issue Number: 8727
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The create stereotype on Usage dependency. The create stereotype on Usage dependency is defined in standard stereotypes (Table 25) and in retired stereotypes (Table 28). It is used in Figures 103 and 121.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue was resolved in an earlier revision. The “create” stereotype is now defined in the table in appendix C section C.1. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.2

  • Key: UML22-939
  • Legacy Issue Number: 8690
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    In figure 195, p332, StructuredActivityNode and Action inherit from ExecutableNode. In figure 196, p333, StructuredActivityNode inherits from Action. => StructuredActivityNode inherits two times of Action. A priori, you could delte the inheritance link between StructuredActivityNode and ExeutableNode in figure 195

  • Reported: UML 2.0 — Thu, 7 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Delete sentence

  • Key: UML22-938
  • Legacy Issue Number: 8685
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    " One frequent case is a total ordering of clauses, in which case the result is determinate." The clauses themselves can be nondeterministic, making this sentence false (although the idea is clear). Delete.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Element to Constraint navigation

  • Key: UML22-946
  • Legacy Issue Number: 8726
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Element to Constraint navigation. The "constrainedElement" association between Constraint and Element is unidirectional from Constraint to Element. That means implementations are not required to provide efficient navigation from an element to the constraints on it. Can't see how an API could do without this.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    This is a duplicate of issue 8020 Revised Text: N/A Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Disjointness should be independent of generalization

  • Key: UML22-945
  • Legacy Issue Number: 8723
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Disjointness is applicable to classes that are not specializations of the same class. It should be independent of generalization

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Same as issue 8014 Revised Text: N/A Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics for instances applies to InstanceSpecification?

  • Key: UML22-943
  • Legacy Issue Number: 8719
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Semantics for instances applies to InstanceSpecification? Clarify whether the semantics for instances specified in other chapters applies to InstanceSpecification. For example, will deleting an InstanceSpecification delete other instances it owns by association composition?

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

policy to describe the Associations sub section of a meta class description

  • Key: UML22-940
  • Legacy Issue Number: 8696
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    what is the official policy to describe the Associations sub section of a meta class description (using EBNF style):

    /?<end-name> : <associated-class-name> : <cardinality> (= <DefaultValue>)? <FeaturesList>? <tab> <Description>

    where:

    <end-name> ::= String

    <associated-class-name> ::= String

    <cardinality> ::= [<n>, <m>]

    <DefaultValue> ::= String

    <FeaturesList> ::=

    {<Features>}

    <Features> ::= <FeatureKind>} | {<FeatureKind>, <Features>

    <FeatureKind> ::= subsets <property-name> | redefined <end-name> | union | ordered | bag | sequence | readOnly | unrestricted

    <property-name> ::= String

    <n> ::= Integer

    <m> ::= Integer | * and m >= n

    <tab> is a tabulation

    ps: ? means it is optional part.

  • Reported: RAS 2.2 — Tue, 12 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 -- Need explanations of XMI structure and usage

  • Key: UML22-933
  • Legacy Issue Number: 8678
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Appendix G is intended to contain the XMI for UML. However, there is no explanation of the meaning of its various parts, or its structure, or how it is to be used. This information should be included in the introduction to the XMI appendix in both the Infrastructure (Appendix A) and the Superstructure (Appendix G).

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

token movement

  • Key: UML22-932
  • Legacy Issue Number: 8677
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    The verbs ``flow'', ``pass'', ``traverse'' seem used interchangeably to describe token movement. I suggest to reserve ``flow'' for a complex path (So e.g. p.309 should be: ``Activity edges are directed connections, that is, they have a source and a target, along which tokens may

    {\bf pass}

    ). , ``pass'' for an elementary move, and to replace ``traverse'' by ``pass''. (p.303, 304, 309, 310, etc.)

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

output tokens (02)

  • Key: UML22-931
  • Legacy Issue Number: 8676
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    In, e.g.: [4] The output tokens are now available Replace ``available'' by ``offered''. Also p.310, p.330, p.342, etc.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12

  • Key: UML22-927
  • Legacy Issue Number: 8670
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    there should be a consistent convention as whether unused Paragraphs must be omitted or filled with ``None''. We suggest the first, and thus to delete the Paragraphs pp.110, 163, 216, 217, 220-262, 280, 285, 298, 301, 304, 311-320, 323, 331, etc.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix F

  • Key: UML22-926
  • Legacy Issue Number: 8619
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The following classifiers show no inheritance hierarchy because the link (inheritance arrow) is missing: Classifier (from Templates), Classifier (from PowerTypes), Interface (from Communications), BehavioredClassifier (from Interfaces), Behavior (from CompleteActivities), Activity (from BasicActivities), Activity (from StructuredActivities), and Activity (from CompleteActivity). In addition, Classifier (from UseCases) and Classifier (from Dependencies) are just kind of sitting there without showing any inheritance. It is strange to see classifiers on a diagram with no relationships expressed.

  • Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: E.1

  • Key: UML22-925
  • Legacy Issue Number: 8617
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Remove the extra space beginning the paragraphs of #4, 6, 9, 10, 11, 12, and 14. There is also an extra space in #10 in "sequence /communication."

  • Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 412 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

text p.297

  • Key: UML22-930
  • Legacy Issue Number: 8674
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    The text p.297: [1] An action execution is created when all its object flow and control flow prerequisites have been satisfied (implicit join). Exceptions to this are listed below. The flow prerequisite is satisfied when all of the input pins are offered tokens and accept them all at once, precluding them from being consumed by any other actions. contains, I believe, the problems: 1. Flows need not be connected by input pins, so ``inputs'' must replace ``input pins''. 2. The current text implies that all offered tokens are consumed when an action starts, which is not intended, we believe (specially if two offers are incompatible). 3. ``precluding them from being consumed by any other actions'' does not belong here. We suggest: To start, the action must have at least one token per input. When starting, it accepts simultaneously exactly one token per input, then creates an action execution.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 12 (03)

  • Key: UML22-929
  • Legacy Issue Number: 8672
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    ``Result pin'', ``Output pin'' or even ``Result output pin'' seem used interchangeably throughout the text. Replace by ``Output pin''.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 12 (02)

  • Key: UML22-928
  • Legacy Issue Number: 8671
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    A section ``Use'' containing methodological indications about the use of the construct should be added. Currently, such remarks are randomly spread into ``Description'', ``Semantics'', etc.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: UML is methodology independent; there should not be any methodological advice in the spec at all. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix C Table 27

  • Key: UML22-920
  • Legacy Issue Number: 8610
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Description column for <<systemModel>> Capitalize SystemModel when using the stereotype name. Is the description for <<metamodel>> worded correctly?

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    agreed - fix

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix C Table 26

  • Key: UML22-919
  • Legacy Issue Number: 8609
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Column Description for <<realization>> Change spelling to <<implementationClass>> to agree with the spelling in <<type>>. It's unfortunate that the column Name breaks the stereotype label so that one can't tell if the stereotype lable is one or two words. - Description for <<specification>> change to "...such as attributes and methods which are useful..." Place column headings on all pages.

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: D.1

  • Key: UML22-922
  • Legacy Issue Number: 8613
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    EJBService has incorrect stereotype name shown inside guillemets. In description for EJBBusiness, change "level methods" to "level method."

  • Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    agreed - fix

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.8

  • Key: UML22-921
  • Legacy Issue Number: 8611
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Constraints 9 and 10 exclude composite states from using entry or exit points. Entry/exit points are allowed on composite states as mentioned on page 592 (see Issue 6075).

  • Reported: UML 2.0 — Sat, 19 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Remove constraints [9] and [10] as entry/exit point are essentially allowed on any region.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: D.3

  • Key: UML22-924
  • Legacy Issue Number: 8615
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Correct spelling of "oferred" to "offered" in Description of NETProperty. The Description of NETAssembly is an incomplete sentence that doesn't make a lot of sense. Rewrite

  • Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    agreed- fix

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: D.2

  • Key: UML22-923
  • Legacy Issue Number: 8614
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Correct spelling of "oferred" in Description of COMInterface. Complete cells (Parent, Tage, and Constraints) for COMTLB

  • Reported: UML 2.0 — Mon, 21 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    agreed - fix

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18

  • Key: UML22-915
  • Legacy Issue Number: 8605
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    General comments - The format of the Generalizations statement is not the same as previous chapters. For sub-sections that are empty either delete them or change the wording to "None."

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue N/A for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.4

  • Key: UML22-914
  • Legacy Issue Number: 8604
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Place a "." in the Reference cell for row Metaclass of table 23 and ProfileApplication of table 24

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.3.8

  • Key: UML22-913
  • Legacy Issue Number: 8603
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation or a note that OCL notation is not available to Constraint [2]. Typo - Change "stereotypes is shown" to "stereotypes are shown" in 3rd line of 2nd para of Notation. - Change 3rd sent of 1st para below bullets under Icon presentation to "Some tools may use different images for the icon replacing the box." In fig. 447 lower case stereotypes "clock" and "creator, clock" to agree with naming convention and figs. 461 & 462. In para immediately following fig. 457, I believe the statement should be: "Note that the extensionEnd must be composite, and that the derived "isRequired" attribute in this case is false. Fig. 458 needs the derived slash infront of the isRequired attribute for :Extension. Typos - Lower case the stereostype name "clock" in sentence immediately fololowing fig. 458, immediately preceding fig. 460 and sentences preceding and following fig. 462. Lower case the stereotype name "creator" in the sentence following fig. 461.

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix C Table 25

  • Key: UML22-918
  • Legacy Issue Number: 8608
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Suggest that the column headings are found on each page of the table. Typos - In the description of <<focus>> capitalize the first "Auxiliary." - In the description of <<implementationClass>> capitalize the word "Class" when used following "Implementation" as indicated by the statement "The actual name of the stereotype is the same as the stereotype label except that the first letter of each is capitalized." (Assuming you meant the first letter of each word of each stereotype label.) - Ditto with "Model Library." - Ditto with "Type." - In the description of <<modelLibrary>> correct spelling of "inteded" to "intended."

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 405 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix B (02)

  • Key: UML22-917
  • Legacy Issue Number: 8607
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Table number does not fit with other tables in this Supersturcture and Appendixes. (Appendix C starts with Table 25.)

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix B

  • Key: UML22-916
  • Legacy Issue Number: 8606
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - 2nd sent. of last para pg 745, rewrite as "...to indacate that it is a constructor..." - 3) under Notation Placement, delete the word "to." Check capitalization of keyword "buildcomponent" because pgs 771 and 777 spell it "buildComponent."

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.3.7

  • Key: UML22-912
  • Legacy Issue Number: 8602
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - under Associations change "is" to "are."

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.3.3

  • Key: UML22-911
  • Legacy Issue Number: 8600
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - 3rd sent, 2nd para under Description, change "changed" to "change." Association type:Stereotype[1] does not show the redefines statement in fig. 446. Additional Operations [1] "which was 1" statement does not agree with the last statement under Description. Fig. 446 shows a directional arrow from ExtensionEnd to Stereotype. This disagrees with first sentence of paragraph 2 of Description.

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    There is no disagreement with first sentence of paragraph 2 of Description.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.3.2

  • Key: UML22-910
  • Legacy Issue Number: 8599
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The derived attribute isRequired default multiplicity is not supported by fig. 446. Please verify all mutliplicities between fig 446 and text for this concept agree. The association ownedEnd:ExtensionEnd[1] does not show that it redefines ownedEnd in the fig.446. Statement under attributes implies that the lower and upper bound must = 1 but Additional Operations [3] does not suppport this. Fig. 448 notation does not agree with text. If MOF notation is different, then clarify.

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8453 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.2

  • Key: UML22-909
  • Legacy Issue Number: 8598
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - remove the extra slash below line between Class and Extension in fig. 446

  • Reported: UML 2.0 — Fri, 18 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.3.2

  • Key: UML22-908
  • Legacy Issue Number: 8596
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The definition of the attribute indicated that multiplicity may be [0..1], yet this is not supported by fig. 446 no by the association ownedEnd:ExtensionEnd[1]. Further, fig 446 does not indicate that the association ownedEnd:ExtensionEnd[1] redefines Association::ownedEnd. Additional Operations [3] says that a lower bound of 1 makes isRequired true, but the statement discussing attributes implies that the lower bound = upper bound. Shouldn't the Additional Operation [3] also indicate this? Notation in fig. 448 does not agree with the text description of the proper notation unless the notation for a MOF model is different than for UML in which case the text should explain that fig. 448 is not a UML notated diagram.

  • Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.6

  • Key: UML22-893
  • Legacy Issue Number: 8517
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete sub-section Attributes or change wording to "None." Change definition of association parameter:TemplateParameter to "The complete set of ordered formal template parameters for this template signature." This is indicated by fig. 427. I believe Constraint [2] should say "parameters are the owned parameter." Change wording of 2nd sent. of 2nd para of Semantics to "Either the parameter that owns the parametered element, or the element that is owned, directly or indirectly, but the template subclasses of TemplateSignature can add additional rules constraining what a parameter can reference in the context of a particular kind of template." I see no subclasses for TemplateSignature in the diagrams--just composite parts. The paragraph under ClassifierTemplates needs enhancement. What figure is being referenced? If it is fig. 429, that diagram does not support the text paragraph.

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 379 - 380 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.5

  • Key: UML22-892
  • Legacy Issue Number: 8516
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delelte sub-section Attributes or change wording to "None." Change association name from "binding":Tto "templateBinding" to agree with fig. 428 or change fig. 428 association name from "templateBinding" to "binding."

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.4

  • Key: UML22-891
  • Legacy Issue Number: 8515
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Notation, the last sentence says to see "ParameterableElement (from Templates)" on page 679 (and its subclasses)." What subclasses? I find none listed or diagrammmed in any figure. Delete sub-section Attributes or change wording to "None." Typo - Delete the second word ("the") of the second para of Semantics.

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.7

  • Key: UML22-895
  • Legacy Issue Number: 8527
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The classifier for the association parameter:ParameterableElement[0..1] does not agree with fig. 429. The classifier is titled ClassifierTemplateParameter in the figure. In addition, the figure does not support that this association redefines ParameterableElement::parameter Fig. 413 shows an additional association: representation:InformationItem[*]. Please add this to the sub-section Typos - 2nd line, 1st para under Section, rewrite as "parameterable element so that a classifier can be exposed as a formal template paramenter, and provided as ...." - 1st line, under sub-section Description, put a comma after Kernal::Classifier. - 3rd line, 3rd para under sub-section Semantics insert the word "of" between "specialization" and "this anonymous." - Last sent., para 2 of Collaboration under sub-section Semantics, change the word "used" to something "identified" or "defined" or "decided." "We have used that..." is not very understandable. - Last para. of Collaboration under sub-section Semantics: change "produce" to "producer" and "NrokeredSale" to "BrokeredSale." Delete "And anyway," and change "Parameters, by the very nature..." to "Parameters, by their very nature..."

  • Reported: UML 2.0 — Wed, 9 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 382 - 383 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.1

  • Key: UML22-894
  • Legacy Issue Number: 8518
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In fig. 412 the PrimitiveTypes package is sitting alone with no dependencies or navigation lines yet it is on the same level as Kernal, BasicActivities, BasicInteractions, and InternalStructures. If all of the other packages don't import elements from PrimitiveTypes, I would suggest offsetting the PrimitiveTypes package or putting it in a separate figure. Question - Why not develop PrimitiveTypes as an enumeration with Boolean, Integer, String, UnlimitedNatural, and UserDefinedKind or UserDefinedList as the elements of the enumeration?

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.15

  • Key: UML22-901
  • Legacy Issue Number: 8588
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    It is very confusing to have two very similar concepts with the same name (17.5.14 and 17.5.15). Could the two concepts be combined into one, combining figure 440 with 441 and the text? If not, consider changing the name of one of the concepts. Association parameter:ParameterableElement is not what is diagrammed in fig. 441. Instead fig. 441 shows parameter:OperationTemplateParameter[0..1] with no redefinition mentioned.

  • Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.14

  • Key: UML22-900
  • Legacy Issue Number: 8587
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Be consistent with the capitalization of "Operation" in sub-section Semantics

  • Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Indeed. Change the first case to lower case initial letter.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.12

  • Key: UML22-897
  • Legacy Issue Number: 8529
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The classifier name for the association nameExpression: in fig. 438 is StringExpression not Expression as indicated by text. In addition, the figure indicates that nameExpression:StringExpression[0..1] subsets ownedElement. Typo - under sub-section Notation in para "With alias:" change "is" in the first sent. to "are."

  • Reported: UML 2.0 — Wed, 9 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Indeed. These errors must be fixed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.8

  • Key: UML22-896
  • Legacy Issue Number: 8528
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The redefines statement of association parameteredElement:Classifier[1] is not supported in fig. 429. Delete sub-section Constraints or change wording to "None." Change spelling of alloswSubstitutable to allowSubstitutable in 2nd sent. of last para of sub-section Notation.

  • Reported: UML 2.0 — Wed, 9 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 384 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.1.2

  • Key: UML22-907
  • Legacy Issue Number: 8595
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Requirement 4 - delete the "of" immediately preceding the word "specializations." - Requirement 9 - Change the word "constraint" to "constrain."

  • Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.20

  • Key: UML22-906
  • Legacy Issue Number: 8593
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:
  • Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This seems to be a leftover from a previous edit. Remove the association item.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12 Activities

  • Key: UML22-899
  • Legacy Issue Number: 8544
  • Status: closed  
  • Source: Universidad Peruana de Ciencias Aplicadas (UPC) ( ILVER ANACHE PUPO)
  • Summary:

    In Figure 178 and 183 there is two different inheritance relationships. In 178 the class ControlNode is a direct parent for classes ActivityFinalNode and InitialNode. These two classes are a direct descendant from FinalNode in figure 183. These introduce two different inheritance taxonomy with different meaning.

  • Reported: UML 2.0 — Fri, 11 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8237 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.13

  • Key: UML22-898
  • Legacy Issue Number: 8530
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 438 shows an additional associaton: owningExpression:StringExpression[0..1] that subsets owner

  • Reported: UML 2.0 — Wed, 9 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Indeed. This item needs to be added.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.17

  • Key: UML22-903
  • Legacy Issue Number: 8590
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 442 does not show that the association parameter:ConnectableElementTemplateParameter redefines anything.

  • Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See the discussion to issue 8528. We will add a clarification to the diagram.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.16

  • Key: UML22-902
  • Legacy Issue Number: 8589
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig 441 for the association parameteredElement:Operation[1] does not mention that the association redefines TemplateParameter::parameteredElement.

  • Reported: UML 2.0 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 389 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.19

  • Key: UML22-905
  • Legacy Issue Number: 8592
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to the constraint or a note that OCL notation is not available

  • Reported: UML 2.0 — Wed, 3 May 2000 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 392 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.18

  • Key: UML22-904
  • Legacy Issue Number: 8591
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 442 does not show that association parameteredElement:ConnectableElement redefines anything

  • Reported: UML 2.0 — Tue, 9 May 2000 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See the discussion on issue 8590.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.2.2

  • Key: UML22-883
  • Legacy Issue Number: 8507
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Not all of the sub-package names given in the sub-section Generalizations are shown in fig. 413. Add them or ellipses. Change capitalization of "information Item" and "Information Items" in sub-section Description to agree. If Information Item is an abstraction shouldn't the name appear in italics in fig. 413? Change last sent. of para 1, sub-section Description to "...for representing information in a very abstract way, one which cannot be instantiated." Change "taken" to "made" in first sent. of para 2 of Descriptions. Delete sub-section Attributes or change wording to "None." Add OCL notation to constraints [1] and [2] or a note that OCL notation is not available. Constraint [1] contains an enumeration list but this is not diagrammed as part of fig. 413. The constraint reads like a guard whose condition is that the InformationItem can only be of the enumerationKind listed in the constraint. Why not diagram it that way? Typos - 1st sent., Para 2 of sub-section Semantics, change "item" to "items." - 2nd sent., Para 3 of sub-section Semantics, reword to "specifying this detailed information belongs to the represented classifier." Question - Why is the multiplicity in fig. 418 0..1? Suggest removing all multiplicities from diag. 418 as they add nothing to it.

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.2.1

  • Key: UML22-882
  • Legacy Issue Number: 8506
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Change first sent. under sub-section Description to "...one or more information items circulates from its sources to its targets." Subject of phrase is singular (one or more) and needs the singular verb. Add OCL notation to the constraints or state that OCL notation is not available. Constraint [1] reads like an enumeration. Why is it not diagrammed showing an enumeration. Reword the except clause to "...and InstanceSpecification except when the classifier of the InstanceSpecification is a relationship (i.e., it represents a link)." Constraint [2] change "target" to "targets" and delete the prepositional phrase "if any." (Or explain how information can flow if there isn't at least one source and one target.)

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Expansion region description

  • Key: UML22-872
  • Legacy Issue Number: 8488
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Expansion region description: "The number of output collections at runtime can differ from the number of input collections." Drop "at runtime".

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The sentence is supposed to be about modeling time, rather than runtime.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExpansionRegioin example, Figure 261: concurrent => parallel

  • Key: UML22-871
  • Legacy Issue Number: 8487
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ExpansionRegioin example, Figure 261: concurrent => parallel

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, ExpansionRegion (05)

  • Key: UML22-870
  • Legacy Issue Number: 8486
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    <pre> In ExpansionRegion, clarify the interaction of elements from multiple input collections (ie, there is none). Clarify that the region operates on each collection in the specified mode. From Jim R: If there are N input collections (note there may also be plain scalar inputs, whose value remains constant in each of the executions), then one value from the same position in each of them represents a "slice". The slice is not actually formed into an object or a single value. The body of the region is executed once for each slice. Each of its pins gets the value from the given position in the corresponding input collection. Each execution is independent and concurrent, therefore the values from different positions do not interact. If the body interacts with an outside object, then there is a high possibility of conflict among the concurrent executions, so that is not usually recommened, although it is not forbidden by the UML2 rules. If it does happen, you can't assume any particular order of execution or even that two executions won't hit the same slot at the same time (in this, it is the same as all other uses of concurrency in UML). If each execution keeps to its own subset of values (for example, by indexing into a collection using the input position for that execution), then things might be OK; otherwise it's probably a real bad idea to use this construct. It works best when the computations are purely internal, in that case the concurrency poses no problems at all and permits total freedom in implementation; those kinds of computations are pretty common in practice. </pre>

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

mustIsolate:

  • Key: UML22-879
  • Legacy Issue Number: 8500
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    mustIsolate: The wording of UML 2 for StructuredActivityNode.mustIsolate refers to individual nodes instead of all the nodes in the group: If the mustIsolate flag is true for an activity node, then any access to an object by an action within the node must not conflict with access to the object by an action outside the node. A conflict is defined as an attempt to write to the object by one or both of the actions. If such a conflict potentially exists, then no such access by an action outside the node may be interleaved with the execution of any action inside the node. The UML 1.5 wording was better: Because of the concurrent nature of the execution of actions within and across procedures, it can be difficult to guarantee the consistent access and modification of object memory. [Examples snipped] In order to avoid these problems, it is necessary to isolate the effects of a group of actions from the effects of actions outside the group. This is indicated by setting the mustIsolate attribute to "true" on a group action. If a group action is isolated, then any object used by an action within the group cannot be accessed by any action outside the group until the group action as a whole completes. Any concurrent actions that would result in accessing such objects are required to have their execution deferred until the completion of the group action. In the first example above, if the read actions on the temperature and pressure attributes are wrapped in a group action with mustIsolate set to "true", then the temperature and pressure values read are assured to be consistent, since no changes can intervene between the two reads. Similarly, if an isolated group is used for the second action, then the update is assured to be consistent, since no action outside the group can change the list until the update is complete. Note" The term "isolation" is used here in the sense used in traditional transaction terminology. An execution engine may achieve any required isolation using locking mechanisms, or it may simply sequentialize execution to avoid concurrency conflicts. Isolation is different than the property of "atomicity", which is the guarantee that a group of actions either all complete successfully or have no effect at all. Atomicity generally requires a rollback mechanism to prevent committing partial results. This is beyond the scope of what can be guaranteed by the basic action semantics.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No notation

  • Key: UML22-878
  • Legacy Issue Number: 8499
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In ConditionalNode: "A notational gloss is provided for this frequent situation." There is no notation

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of isAssured/isDeterminant in conditional node

  • Key: UML22-875
  • Legacy Issue Number: 8493
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Semantics of isAssured/isDeterminant in conditional node, the phrase "concurrently yield a value" sounds it is referring to tests that complete at the same instant in time. Would be clearer to drop "concurrently", since it isn't the concurrency that isAssured/isDeterminant is concerned with, it's the results.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add constraint in LoopNode

  • Key: UML22-874
  • Legacy Issue Number: 8491
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint in LoopNode that loop variable inputs should not have edges coming out of them. Otherwise, the value could leave the pin in the middle of the loop.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-873
  • Legacy Issue Number: 8490
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Loop node owns output pins as loop input variables, but pins must be owned by actions under the input/output associations in UML 2 (not in UML 1.5).

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The filer is referring to the loop variable pins.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.3

  • Key: UML22-890
  • Legacy Issue Number: 8514
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Notation, the last sentence says to see "ParameterableElement (from Templates)" on page 679 (and its subclasses)." What subclasses? I find none listed or diagrammmed in any figure.

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.3

  • Key: UML22-889
  • Legacy Issue Number: 8513
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete sub-section Attributes or change wording to "None." Add that the association boundElement also subsets Element::owner as shown in fig. 428. Change the association name from "template":TemplateSignature to "signature" in the text or change fig. 428 association name from "signature" to "template." The Examples sub-section makes no sense. ClassifierTemplate and PackageTemplate are not to be found in this document. Do you mean Classifier (pg 689) and Package (pg 696)? This section is TemplateBinding but no specializations are listed or referenced. Clarify this sub-section, in particular provide page numbers for the sections to which the reader is referred. Or change the name of Classifier to ClassifierTemplate and Package to PackageTemplate. If name change is made then change the names in all figures that contain these template names

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 376 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.1

  • Key: UML22-888
  • Legacy Issue Number: 8512
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add associaton owningSubstitution:TemplateParameterSubstitution[0..1] that subsets Element:owner as shown in fig. 428.

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.4

  • Key: UML22-885
  • Legacy Issue Number: 8509
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    PprimitiveTypes strike me more as an enumeration or list than a package. Consider changing them to an enumeration or list. Boolean is derived from George Boole and is generally capitalized whenever used. Please be consistent in capitalization of "Boolean" when using the word as an adjective. Sometimes on page 673 it is capitalized ("The Boolean condition") but other times it is not ("boolean type," "boolean attribute," and "boolean expression"). Delete sub-sections Attributes, Associations, and Constraints or change the wording to "None.

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.3.1

  • Key: UML22-884
  • Legacy Issue Number: 8508
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    If model is an abstraction of the physical system shouldn't the name in fig. 419 be in italics? Attribute viewpoint:String[*] does not have the same multiplicity as shown in fig. 419 which is the default multiplicity of [0..*] as indicated on page 14 of this document. Delete sub-sections Associations and Constraints or change the wording to "None." Add the word "open" between small and triangle in 1st sent. of Notation. Typo - 2nd sent of sub-section Notation, change "is" to "are."

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 371 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.2

  • Key: UML22-887
  • Legacy Issue Number: 8511
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete the sub-sections Attributes and Constraints or change the wording to "None." Association templateBinding:TemplateBinding[*] subsets Element::ownedElement according to fig. 428. Change wording in para 3, sent. 2 of sub-section Semantics to "...by expanding the templates to which it binds, since..." The Examples sub-section makes no sense. ClassifierTemplate and PackageTemplate are not to be found in this document. Do you mean Classifier (pg 689) and Package (pg 696)? This section is TemplateableElement but no specializations are listed or referenced. Clarify this sub-section, in particular provide page numbers for the sections to which the reader is referred.

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 374 0f ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17.5.1

  • Key: UML22-886
  • Legacy Issue Number: 8510
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete sub-sections Attributes and Constraints or change wording to "None." Add the association owningDefault:TemplateParamenter[0..1] that subsets owner. Fig. 427 shows this.

  • Reported: UML 2.0 — Tue, 8 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the semantics of minimum multiplicity > 0 for streaming parameters

  • Key: UML22-881
  • Legacy Issue Number: 8503
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that the semantics of minimum multiplicity > 0 for streaming parameters that it is required sometime during execution

  • Reported: UML 2.0 — Mon, 7 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 209 of Activites

  • Key: UML22-880
  • Legacy Issue Number: 8502
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 209 of Activites, and entry in index: <<singleCopy>> should be replaced with <<singleExecution>>.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    In Activities, Activity, Figure 209, replace "singleCopy" with "singleExecution".

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add constraints on conditional and loop nodes (02)

  • Key: UML22-877
  • Legacy Issue Number: 8497
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraints on conditional and loop nodes that body outputs are pins on action contained in the body part of the clauses

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 361 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add constraints on conditional and loop nodes

  • Key: UML22-876
  • Legacy Issue Number: 8496
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraints on conditional and loop nodes that decider is an output pin of an action in the test body, and that its type is boolean

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Conformance / inconsistencies

  • Key: UML22-853
  • Legacy Issue Number: 8459
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Summary:

    There are two fundamental inconsistencies in the way that conformance is defined:
    · BasicActions and BasicInteractions, which are defined at L1, both reference Signal and Event, defined in CommonBehaviors::Communications, which is defined at L2.
    · Profiles are defined as L2 but Appendix C defines a profile for level L1. Clearly, if L1 is to support profiles, the definition of profiles needs to be defined at that level as well or a lower level.

    Recommendation:

    For the first item, move CommonBehaviors::Communications from L2 to L1

    For the second item, a minimal impact resolution is to retain the L1 system as such, but to include it as part of compliance level L2. In general, the standard profiles should be specified explicitly as belonging to the appropriate compliance levels in section 2.4

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 335 - 336 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / missing merges

  • Key: UML22-852
  • Legacy Issue Number: 8458
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Compliance level L3 references, but does not merge:

    Superstructure::Logical View::UML::CommonBehaviors

    Superstructure::Logical View::UML::CompositeStructures

    There are a number of diagrams in the UML2 Rose model that contain unlabeled dependencies between packages. In particular, Activities, Interactions, StateMachines, and UseCases have dependencies to CommonBehaviors that are unlabeled. See diagram UML/Behavior Packages and UML/UML Top-Level Packages.

    Since CommonBehaviors does not contain any classes, it does not necessarily need to be merged into any compliance level. Instead, the packages it contains are merged as needed.

    Recommendation:

    Remove all unlabeled dependencies between packages, or mark them as either package imports or package merges as needed.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / improper subsetting

  • Key: UML22-851
  • Legacy Issue Number: 8457
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The following properties (in the subsets constraints) are unresolved in their unmerged, containing package. The problem is that the properties in these subsets constraints are not defined in the unmerged package. They will be defined in the various compliance levels once the packages have been merged. However, the package merge rules (and the desire to be able to check OCL constraints on unmerged packages) require all references to be resolved before the merge.

    Superstructure::LogicalView::UML::CompositeStructures::InternalStructures::Property::_structuredClassifier

    {subsets classifier}

    Superstructure::LogicalView::UML::Components::BasicComponents::Component::realization

    {subsets clientDependency}

    Superstructure::Logical View::UML::Deployments::Artifacts::Artifact::manifestation {subsets clientDependency}

    Recommendation:

    These are either resolved by including the proper superclass in the unmerged package so that the properties are visible, or copying the associations from another merged package in order to make the properties visible.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 330 - 333 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / invalid subset rule too strict

  • Key: UML22-855
  • Legacy Issue Number: 8462
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The redefinition rule [4] of Property on page 127 of ptc/04-10-02 restricts a navigable property from being redefined by a non-navigable property. Unfortunately, this rule is violated in many parts of the model.

    Recommendation:

    As a practical resolution for this problem, it is suggested that this constraint be removed since it does not seem to provide any benefits and yet prevents the realization of the agreed design intent

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Kernel / excessive restriction on redefinition

  • Key: UML22-854
  • Legacy Issue Number: 8461
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    In section 7.3.44 on pg. 130 of ptc/04-10-02 there is a constraint that states: “All redefinitions shall be made explicit with the use of a

    {redefines <x>}

    property string.” Unfortunately, this is violated in numerous places in the metamodel. This results in numerous inconsistencies in the metamodel.

    Recommendation:

    As a practical resolution with minimal impact, it is recommended that this restriction be removed. This means that the use of the same association end name for a given association end implies a redefinition of the corresponding association end in an ancestor class.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.3

  • Key: UML22-861
  • Legacy Issue Number: 8469
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Typo: Constraint 3 contains the word "IntectionFragment". Should be InteractionFragment

  • Reported: UML 2.0 — Sat, 5 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.6

  • Key: UML22-860
  • Legacy Issue Number: 8468
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete sub-section Attributes or change wording to "None." For the associations include:Include[*] and extend:Extend[*], the "Specialized Classifier.feature" is not shown in fig. 401. Add OCL notation to constraints [2] and [3] or indicate the OCL notation is not available. Add an ending ")" to Additional Operation OCL notation--one missing. Typo - 1st sent. of para 3 of Semantics, change "describe" to "Describes." There is no association or navigable link between UseCase and Actor shown in fig. 401. Add appropriate link(s).

  • Reported: UML 2.0 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, ExpansionRegion (04)

  • Key: UML22-869
  • Legacy Issue Number: 8485
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In ExpansionRegion, clarify that that input pins on expansion regions (introduced by merge with CompleteStructuredActivities) provide values that are constant across the execution of the region, and that output pins are not allowed.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, ExpansionRegion (03)

  • Key: UML22-868
  • Legacy Issue Number: 8484
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ExpansionRegion: require that all input collections have the same number of elements at runtime.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, ExpansionRegion (02)

  • Key: UML22-867
  • Legacy Issue Number: 8483
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ExpansionRegion: remove "If an expansion region has outputs, they must be collections of the same kind and must contain elements of the same type as the corresponding inputs." Inputs and outputs of expansion regions do not need to correspond, this was intended to refer to the pins that flows to the output. Add general constraints on types of source and targets of object flows rather than have the a special case for expansion nodes.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.5

  • Key: UML22-859
  • Legacy Issue Number: 8467
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the generalization "NamedElement (from Kernal)" on page xxx (page 100 I believe). This generalization is shown in fig. 401 and mentioned in the Description sub-section. Delete sub-sections Attributes and Constraints or change wording to "None." In sub-section Semantics, I'm not certain that the following statement is reflected in fig. 401 "Since the primary use of the include relationship is for reuse of common parts, what is left in a base use case is usually not complete in iteself by dependent on the included parts to be meaningful. This is relfected in the direction of the relationship, indicating that the base use case depends on the addition but not vice versa." Reword 2nd sent of para 2, Semantics, to "All of the behavior of the included use case is executed...." or "The included use case behavior is executed at a single..."

  • Reported: UML 2.0 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.4

  • Key: UML22-858
  • Legacy Issue Number: 8466
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 401 shows 2 associations: extend:Extend{*] and useCase:UseCase[1]. Define these in the sub-section Associations. Delete sub-section Attributes or change the wording to "None."

  • Reported: UML 2.0 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see page 342 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.3

  • Key: UML22-857
  • Legacy Issue Number: 8465
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Generalizations add the generalization "NamedElement (from Kernal)" on page xxx" (page 100 I believe). This generalization is diagrammed in fig. 401. Delete sub-section Attributes or change wording to "None."

  • Reported: UML 2.0 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Indeed. This was a missed generalization.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Common Behaviors / missing multiplicites

  • Key: UML22-856
  • Legacy Issue Number: 8463
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    In figure 318 on page 463, the multiplicities of DurationObservationAction::duration and TimeObservationAction::now are not specified. This results in violations of the redefinition rules for these association ends.

    Recommendation:

    Set the multiplicities for these association ends to 1, to conform to the multiplicity of WriteStructuralfeatureAction::value association end that they redefine

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities, ExpansionRegion

  • Key: UML22-866
  • Legacy Issue Number: 8482
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ExpansionRegion, clarify wording in description: expansion nodes are not input pins.

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities

  • Key: UML22-865
  • Legacy Issue Number: 8481
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    <pre> ExceptionHandler, clarify working of constraint [1]: "[1] The exception body may not have any explicit input or output edges." It should say the exception handler and its input object node are not the source or target of any edge. </pre>

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ValueSpecificationAction, Attribute section, is missing the return pin

  • Key: UML22-864
  • Legacy Issue Number: 8478
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ValueSpecificationAction, Attribute section, is missing the return pin

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions

  • Key: UML22-863
  • Legacy Issue Number: 8477
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 141, remove import from IntermediateActions to Communications. Add an import from BasicActions to Communications

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Common Behavior

  • Key: UML22-862
  • Legacy Issue Number: 8476
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Common Behavior: why does Figure 326 refer to Signal from Communications, but not Operation form Communications? (it looks like Communications can refer to Kernel:Operations rather than defining its own).

  • Reported: UML 2.0 — Sun, 6 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.14

  • Key: UML22-841
  • Legacy Issue Number: 8443
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association guard:Constraint[0..1] subsets ownedElement. Need to add this to the definition. Association replacedTransition:Transition[0..1] redefined redefinedElement. Need to add this to the definition. Association /redefinitionContext:Classifier[1] subsets redefinitionContext. Need to add this to the definition. Also need to add OCL notation. Constraint [2] - delete last paranthesis. Add OCL notation or a note that OCL cannot express constraint [7]. Add OCL notation or a note that OCL cannot express Additional operation [1]. Typos - pg. 626, para 4, sent 2, add "s" to transition. - pg. 627, 1st bullet under sub-section Example, first sent, delete the final "s" in "states." Why aren't he bulleted statements under sub-section Enabled (compound) transitions constraints? The activities named in fig. 396 ("MinorReq = ID;" and "MajorReq = ID:") are not the same format as indicated in Table 20 ("MinorReq := Id;") - the colon is missing before the equal sign in the figure.

  • Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix A

  • Key: UML22-840
  • Legacy Issue Number: 8440
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A use case diagram is a structural diagram. Similar to operations in classes in shows the structure of the system services. Therefore a use case is a specialized Classifier and not Behavior like model elements of all other behavior diagrams (interaction, activity, and state machine).

  • Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.11

  • Key: UML22-837
  • Legacy Issue Number: 8416
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Attributes are derived and need this noted. Also add OCL notation to the derived attributes as per the "How to Read this Specification" (page 14)indicates will be done. isComposit=(region>1) - modified from page 14. isOrthogonal=(region>=2) ??? isSimple=((region=0) and (submachineState=0)) ??? isSubmachineState=(SubmachineState>0) I question the multiplicity of the association connection:ConnectionPointReference[*]. Shouldn't it be [0..*] because the association wouldn't exist if the state was simple or compound. Ths association also subsets ownedMember and that needs to be added to the definition. According to fig. 354, the multiplicity for connectionPoint:Pseudostate is 0..8 and this association subsets ownedElement. I question the multipliticy of the association deferrableTrigger:Trigger[*]. Do all state have MULTIPLE deferrable triggers? First paragraph on page 605 says "a state may specify a set or event types that may be deferred in that state." Associations doActivity:Behavior[0..1], entry:Behavior[0..1], and exit:Behavior[0..1] all subset ownedElement according to fig. 354. Association redefinedState:State[0..1] redefines redefinedElement. This needs stating in the definition. I question the multiplicity of region:Region[*]. If the state is a simple state it has no regions (page 600). Change the multiplicity to [0..*] here and in fig. 354. Association /redefinitionContext:Classifier[1] subsets redefinitionContext and needs mentioning in the definition. Add OCL notation to constraint [3]. OCL font format doesn't appear correct for constraint [4]. Constraint [7] repeats constraint [1] but is just worded and expressed slightly differently. Should bulleted statements on page 605 immediately above Entering a non-orthogonal state be added as constraints? Should an exit point be added to the ATM state machine in fig. 391?

  • Reported: UML 2.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.11

  • Key: UML22-836
  • Legacy Issue Number: 8415
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    No mention of figures 387 and 390 are made in the text. Reference figure 387 on pages 600 (Composite state) and page 606 (Entering an orthogonal composite state). Reference figure 390 at end of paragraph 2 on page 613. Typos - In sentence under Exiting an orthogonal state, change "is" in last sentence to "are." - Under Composite state (pg 609) Upper case Decomposition compartment. - Page 606, Under Exiting non-orthogonal state, change "from a composite state..." to "from a simple composite state..." to agree with the line just above Simple state in sub-section Description on page 600. - Page 606, first paragraph, change "il defined" to "ill defined." - Page 612, under Examples, change "sub state machine" to "submachine state." - Page 614, first line, change "In Figure 391 this state machine" to "In Figure 391 the state machine of figure 389 an figure 390." - Page 614, first line of Rational change "Submachine states...has been..." to "State machines...have been...."

  • Reported: UML 2.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Minor typos and consistency with figures.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Action Semantics Section: 9.5

  • Key: UML22-835
  • Legacy Issue Number: 8413
  • Status: closed  
  • Source: Codesic Consulting, Inc. ( Jeff Barnes)
  • Summary:

    The JumpAction->Inputs section documents jumpOccurrence:RuntimeInstance[1..1]. The second sentence of the documentation contains a typo that makes the meaning of the documentation unclear. Please re-write the second sentence.

  • Reported: UML 1.4.2 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Appendix C.1

  • Key: UML22-839
  • Legacy Issue Number: 8439
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    script is an artifact stereotype on compliance level L1. Artifact is an element on level L2. That's a mismatch.

  • Reported: UML 2.0 — Wed, 2 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Indeed. The entry should be moved to compliance level L2.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.12

  • Key: UML22-838
  • Legacy Issue Number: 8433
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete sub-section Attributes or change line to "None." Association connectionPoint:Pseudostate[*] subsets ownedMember. According to fig. 354, there is an association submachineState:State[*] that needs to be added and defined in the text. Association extendedStateMachine:StateMachine[*] redefines:redefinableElement I think. Figure 355 is overwritten by fig. 356 and this association is hard to read. In fig. 355, classifier StateMachine is not generalized or connected to any other classifier in the figure. Draw appropriate connections or make the StateMachine classifier a separate figure. Correct spelling of "conectionPoint" in OCL notation for constraint [3]. Add OCL notation to Additional Operations [1], [3], and [4] or otherwise note that OCL notation is not available for these operations. Typos - Para immediately above Run-to-completion and concurrency (pg. 671), change "... the invoked object complete..." to "...the invoked object completes..." - Page 619, 7th para. change "is" to "are." - Page 612, 1st para, last sent., does the capitalization of "verifyTransaction" need changing? - Personal preference for easier understanding place commas in "for, e.g., classes" on page 623 in sub-section Rational (second such labeled sub-section). Complete the sentence/paragraph for the last paragraph under StateMachine extension.

  • Reported: UML 2.0 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specification: Action Semantics Section: 9.5

  • Key: UML22-834
  • Legacy Issue Number: 8412
  • Status: closed  
  • Source: Codesic Consulting, Inc. ( Jeff Barnes)
  • Summary:

    Figure 27 illustrates a directed association from JumpHandler to HandlerAction. Yet the documentation on page 115 says there is a reference from HandlerAction to JumpHandler (jumpHandler 1..1). Where is the association from HandlerAction to JumpHandler? The multiplicity at the (non-navigable) JumpHandler end of A_HandlerAction_JumpHandler is 0..*.

  • Reported: UML 1.4.2 — Tue, 1 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.10

  • Key: UML22-833
  • Legacy Issue Number: 8411
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete sub-section Attributes or change line to "None." Fig. 354 shows that association transition:Transition[*] subsets ownedMember as does association subvertex:Vertex[*]. Fig. 355 shows that association extendedRegion:Region[0..1] redefines redefinedElement and that association /redefinitionContext:Classifier[1] subsets redefinitionContext. Within subsections Additional constraints and Additional operations stateMachine often appears with a lower case "m." Typo - delete the apostrophy starting the sentence in Additional constraing [2].

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.9

  • Key: UML22-832
  • Legacy Issue Number: 8410
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Font style is not consistent in the list of literal values for PseudoStateKind. Delete sub-sections Attributes and Associations or change line to "None."

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Minor editorial – follow suggestions

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.16

  • Key: UML22-843
  • Legacy Issue Number: 8445
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The multiplicities for the association definitions do not agree with those shown in fig. 354. Typo - Additional operation [1], change "sate" to "state." Question - Are the "?" and "-- no other valid cases possible" legal OCL notation?

  • Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 319/320 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.15

  • Key: UML22-842
  • Legacy Issue Number: 8444
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to the constraints or a note that OCL notation is unavailable for these constraints. Typos - first bullet of sub-section Semantics, change "occur" to "occurs." - second bullet of sub-section Semantics, cange "stat" to "state." If a transition of kind external leaves the border of the composite state, how can it end at the composite state itself? Please provide a figure to illustrate this.

  • Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Collaborations / improper subset

  • Key: UML22-850
  • Legacy Issue Number: 8456
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    In figure 100 of ptc/04-10-02, the association end Classifier::representation subsets “Classifier::occurrence” and should subset “Classifier::collaborationUse”. The fix should also be applied to the Associations specification for Classifier in the Composite Structures chapter on page 175.

    Recommendation:

    Change figure 100 as specified above.

    In the entry for Associations of Classifier on page 175, replace the parenthesized expression:

    Subsets Classifier.occurrence

    By the expression:

    Subsets Classifier.collaborationUse

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profiles::ObjectNode has wrong default multiplicity

  • Key: UML22-849
  • Legacy Issue Number: 8454
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    ObjectNode::upper should have default multiplicity unbounded (“*”) in order of object nodes to be multi-valued by default.

    Recommendation:

    Redefine inherited MultiplicityElement::upper to have default “*” in ObjectNode.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profiles::ExtensionEnd has wrong default multiplicity

  • Key: UML22-848
  • Legacy Issue Number: 8453
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    ExtensionEnd should have a default multiplicity of 0..1 which differs from the inherited MultiplicityElements::lower which defaults to 1. I think therefore that there needs to be an override by ExtensionEnd redefining lower with a different default.

    Recommendation:

    Redefine inherited MultiplicityElement::lower to have default 0 in ExtensionEnd.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OK, that is a more accurate specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Should Profiles::Image be an Element?

  • Key: UML22-845
  • Legacy Issue Number: 8449
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Should Image a subclass of Element? Image and diagram interchange may benefit from reflective capabilities inherited from MOF. Having Image, and all UML metaclasses be a subclass of Element may make it easier for MOF based tools to reflectively navigate the visual notation.

    Recommendation:

    Make Profiles::Image a subclass of Element

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 323/324 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.7

  • Key: UML22-844
  • Legacy Issue Number: 8446
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Inconsistent in the spelling of pre- and post-condition vs pre condition and post condition. Other sections use pre- and post-condition. Association postCondition:Constraint[0..1] subsets ownedElement and preCondition:Constraint[0..1] subsets guard according to fig 357. Question: Why doesn't association postCondition:Constraint subset guard instead or inaddition to ownedElement? For other concepts where pre- and post-conditions exist, they both subset guard

  • Reported: UML 2.0 — Thu, 3 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove redundant superclass for Element

  • Key: UML22-847
  • Legacy Issue Number: 8452
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Abstractions::Comments::Comment is a subclass of Abstractions::Comments::Element which is a subclass of Abstractions::Ownerships::Element. The resolution to issue 6279 redefines package merges such that the Element superclass of Element should be removed.

    Recommendation:

    Delete Abstractions::Comments::Element, and make Comment a subclass of Ownerships::Element. Move the associations from Comments::Element to Ownerships::Element

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OCL for Property::opposite() is incorrect:

  • Key: UML22-846
  • Legacy Issue Number: 8451
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    OCL for InfrastructureLibrary::Core::Constructs::Property::opposite() should it be:

    opposite =

    if owningAssociation->empty() and association.memberEnd->size() = 2 then

    let otherEnd = (association.memberEnd - self)->any() in

    if otherEnd.owningAssociation->empty() then otherEnd else Set{} endif

    else Set {}

    endif

    Recommendation:

    Fix the operation definition.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.8

  • Key: UML22-831
  • Legacy Issue Number: 8409
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Change "Pseudostate are" to "Pseudostates are" in sub-section Description. Fig. 354 says that the association stateMachine:Statemachine[0..1] subsets namespace. Also correct "Statemachine" to S"tateMachine." Fig 354 also shows an association state:State[0..1] that subsets owner. Correct the number of parantheses for constraints [1], [4], and [6]. Bold the word "and" in constraint [3.

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Minor editorials – change following suggestions

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.7

  • Key: UML22-830
  • Legacy Issue Number: 8408
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - "In a protocol state machine, several transitions can refer to the same operation as illustrated below." Change below to "Figure 366" as the figure is above the text in the current version. Para. above Unreferred Operations, change "stat" to "state." Association "\referred:Operation[0..*]" needs the slash direction changed to "/" and the multiplicity of fig. 357 doesn't agree with that listed in the text. Change "No additional attributes" to "None."

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Minor editorials

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.26

  • Key: UML22-817
  • Legacy Issue Number: 8350
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Place a period "." at the ent of i) and iii); In first line of Style guidelines sub-section, change "are" to "is."

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.25

  • Key: UML22-816
  • Legacy Issue Number: 8349
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The associations toBefore:GeneralOrdering and toAfter:GeneralOrdering use "EventOccurrence" in the definition. OccurrenceSpecification appears to be the renamed "EventOccurrence." The class EventOccurrence is not defined as a concept in this document. However, the name is still used in many places. EventOccurrence occurs in the following places: figures 307, 308, and 347; pages 509 (weak sequencing # 3), 544, 549, and 794; and in the Frame row, Notation column of tables 14, 16, 18, and 19. Either change the class name or define the concept

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.1

  • Key: UML22-823
  • Legacy Issue Number: 8401
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Delete the word "of" from the first sent. of sub-section Descriptions. Delete sub-section Attributes or state "None" instead of "No additional attributes." The multiplicities for the associations entry:Pseudostate[1..*] and exit:Pseudostate[1..*] don't agree with figure 354. Change the word "refreshens" to "references" in association definition for state:State[0..1]. In sub-section Semantics, last words of para 2, change "pseudo states" to "pseudostates." Under sub-section Presentation Options change Figure "362" to "361" in the para talking about entry point and change Figure "361" to "362" in the para talking about exit point. Just thought I'd mention that when I printed a hardcopy (PDF using Adobe Acrobat Reader 6.0), the submachine state symbol in fig. 359 had a bold outline and the entry circle is normal weight whereas the submachine state symbol line weight in figs. 360-362 are normal weight as is the example on pg, 638. The exit circle in fig. 360 and on pg. 638 is in bold line weight. There also appears to be a difference in the line weights in the softcopy version.

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1

  • Key: UML22-822
  • Legacy Issue Number: 8387
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Fig. 87 on page 157 shows a composite structure diagram. Therefore the horizontal line below the component name is missing (see 9.3.13 for composite structure notation).

  • Reported: UML 2.0 — Sun, 27 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This line is optional. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.6

  • Key: UML22-829
  • Legacy Issue Number: 8407
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Change "No additional attributes" to "None." The association conformance:ProtocolConformance[*] subsets ownedElement. Please add a specialization statement to the definition. Fig. 357 shows another association: interface:Interface[0..1] that subsets namespace. Add to associations or delete from fig. Constraint [3] is missing two ending parantheses but they may be found in constraint [4] as it has two extra. Delete the very small dot in front of the list of specifications in sub-section Semantics. "Depending on the context" is confusing in light of constraint [1] and "or they can be different" needs further explanation. Totally reword and redefine this paragraph. I, unfortunately, don't know enough to help you further. Typos - Reword to "Protocol state machine interpretation can be: Change "sub-statemachines" to "sub-state machines" in first line of next to last para in sub-section Semantics. In last para of sub-section Semantics, last word of second sent. should be "machines."

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.42

  • Key: UML22-828
  • Legacy Issue Number: 8406
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    In the ReplyAction specification, the association replyValue is specified as an OutputPin which is inconsistant with the specification of this association on Figure 152 (p 241) where it is specified as an InputPin to ReplyAction. The specification page 300 should be changed to InputPin instead of OutputPin.

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8197 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.20

  • Key: UML22-812
  • Legacy Issue Number: 8345
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    According to fig. 329 the association interaction:Interaction[1] subsets namespace and the association argument:ValueSpecification[*] is ordered and subsets ownedElement. Correct text to reflect fig. Constraint [3] change the last word from "Parameter" to "Argument." In sub-section Semantics, para. 4, delete the dash . Typo - First para., pg 540, put a space between "as" and "well" In sub-section Notation, begin a new paragraph with the second sent. of the current 3rd paragraph

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.19

  • Key: UML22-811
  • Legacy Issue Number: 8343
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Change class name for the association selector to OpaqueExpression (as per fig. 328) or change class name on fig. 328. Interaction:Interaction[1] subsets namespace according to the fig. Mention the specialization in the text definition. Typo - First sent. of Semantics change "OccurrenceSpecification" to "OccurrenceSpecifications."

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.24

  • Key: UML22-815
  • Legacy Issue Number: 8348
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Change the name of the enumeration list to MessageSortKind on fig. 329, as the section heading, and in sub-section Description

  • Reported: UML 1.4.2 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.21

  • Key: UML22-814
  • Legacy Issue Number: 8347
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In sub-section Description, change enumerator name from MessageSort to MessageKind

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Notice that the Issue refers the wrong section. The correct section number is 14.3.22.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.21

  • Key: UML22-813
  • Legacy Issue Number: 8346
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Since the description say that a MessageEnd represents what can and not what must occur at the end of a message and fig. 329 shows the multiplicity of the association to be 0..1, change the multiplicity of messate:Message from [1] to [0..1].

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.5

  • Key: UML22-827
  • Legacy Issue Number: 8405
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - For consistency, spell as "pre- and post-conditions" in the Semantics sub-section

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.5

  • Key: UML22-826
  • Legacy Issue Number: 8404
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - In sub-section Description, change "abide" to "abides." Under sub-section Attributes, change "No additonal attributes" to "None." According to fig. 357, associations specificMachine:ProtocolStateMachine[1] subsets source, subsets owner and generalMachine:ProtocolStateMachine[1] subsets target. Mention these specializations in the definitions. Change sent. under sub-section Constraints to "None."

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.4

  • Key: UML22-819
  • Legacy Issue Number: 8352
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Be consistent in the use of the period (.) ending the statement in the reference column of the tables. Place a period at the end of the sentence under sub-section Graphic Paths, pages 554 and 561. First line, page 556 shange shows to show.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.29

  • Key: UML22-818
  • Legacy Issue Number: 8351
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association invariant:Constraint[1] subsets ownedElement and association covered:Lifekube[1] redefines (not subsets/specializes) covered according to fig. 328. Typos - Last sentence of sub-section Semantics, change has to have and is to are.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.4

  • Key: UML22-821
  • Legacy Issue Number: 8357
  • Status: closed  
  • Source: CEA ( Gerard Sebastien)
  • Summary:

    p 346, keyword «singleExecution» is used for activities that execute as a single shared execution. p 347, keyword «singleCopy» is used in figure is used to specify single execution. Anyway use an uppercase for the first letter of the keyword, as done for Precondition and Postcondition.

  • Reported: UML 2.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Pre and postconditions use lowercase first letter like all keywords, see Figure 207.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.5

  • Key: UML22-820
  • Legacy Issue Number: 8356
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    The specification says: "If isReplaceAll is false and the structural feature is unordered and nonunique, then adding an existing value has no effect." This should be replaced by: "If isReplaceAll is false and the structural feature is unordered and UNIQUE, then adding an existing value has no effect."

  • Reported: UML 2.0 — Fri, 25 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.3

  • Key: UML22-825
  • Legacy Issue Number: 8403
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Change "No additonal attributes." to "None."

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.2

  • Key: UML22-824
  • Legacy Issue Number: 8402
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 354 shows the association owningState:State[*]. Please add this to the sub-section or delete it from the diagram. Also, explain how a state can have multiple final states as indicated by the multiplicity in the figure. In the sub-section Semantics, the first sentence seems to contradict constraint number [4]. Please clarify more fully how a final state may be entered if there can be no entry behavior.

  • Reported: UML 2.0 — Mon, 28 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.17

  • Key: UML22-810
  • Legacy Issue Number: 8341
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Change the name of this enumeration to InteractionOperatorKind and add "break" to the list of Literals in the text

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.16

  • Key: UML22-809
  • Legacy Issue Number: 8340
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - 2nd sent. under sub-section Description change represent to represents. Add specialization notes to definitions for associations. Association fragment:InteractionFragment subsets ownedMember according to fig. 331 and is ordered. Typo - End the 2nd paragraph under sub-section Semantics with a period. Association guard:InteractionConstraint subsets ownedElement.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.15

  • Key: UML22-808
  • Legacy Issue Number: 8339
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Separate the associations into packages. Add the specialization for subsets namespace to enclosingOperand:InteractionOperand[0..1] and subets ownedElement for enclosingInteraction:Interaction[0..1] as shown in the appropriate figures.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.2

  • Key: UML22-797
  • Legacy Issue Number: 8323
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Multiplicity of the association does not agree with fig. 330. Change fig. to agree with text definition

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13

  • Key: UML22-796
  • Legacy Issue Number: 8322
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    General comments: Add OCL notation to the constraints where possible. If not possible state that OCL notation is not available for the constraint. Either delete sub-section headings where there is no data for the sub-section or add the word "None." Make certain that the multiplicities for the associations agree between the text and the associated figures. There is inconsistency in representation of 0..* on figures, sometimes the figures use * to mean 0..* (according to the text definitions) and then sometimes 0..* is used. Several times the figures will note that an association is a redefinition of or subsets a class but the text does not mention this. Be certain to add the appropriate statement to the text definition.

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue N/A for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.30

  • Key: UML22-795
  • Legacy Issue Number: 8320
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The generalization "Dependencies" is not listed in fig. 316 under NamedElement. Add this to the figure. The association port:Port[*] is not diagrammed anywhere. Either remove this association from the text or add it to a figure. The sub-section Changes from UML 1.x indicates that the corresponding metaclass was changed from Event but names listed in the BNF definition are all children or grandchildren of the metaclass Event in fig. 317. I believe something needs to change or be clarified but I don't know what.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.13

  • Key: UML22-807
  • Legacy Issue Number: 8338
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Separate the associations into appropriate packages which are identified. Multiplicity of association lifeline:LifeLine[0..*] is not diagrammed as 0..*. The association is diagrammed as subsets ownedMember. The association event:MessageEnd is not diagrammed anywhere. If such an association exists, it should probably be diagrammed in fig. 329. Association message:Message[*] subsets ownedMember in fig. 329. Association action:Action[*] subsets ownedElement in fig. 330. Typos - 2nd paragraph, pg 527, 2nd sent. should be "Similarly the deteailed actions...are often omited in Interactions,..." Delete the word "are" from 1st sent. of 3rd para under Notation

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.14

  • Key: UML22-806
  • Legacy Issue Number: 8337
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Both associations are shown in fig. 331 as "subsets ownedElement" so please add this specialization to the definition text or remove notes from the figure.

  • Reported: UML 2.0 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.4

  • Key: UML22-799
  • Legacy Issue Number: 8325
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Attribute sub-section heading needs to be changed to Associations. Fig. 331 shows message:NamedElement[0..*] as an association

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.3

  • Key: UML22-798
  • Legacy Issue Number: 8324
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association operand:InteractionOperand[1..*] subsets ownedElement according to fig. 332. Please add appropriate specializes comment to text. Typo - In the last sentence of sub-section Semantics for Loop change wording from "The loop construct represent..." to "The loop construct represents..."

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.10

  • Key: UML22-803
  • Legacy Issue Number: 8329
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Under sub-section Notation, start 3rd paragraph with "For ExecutionSpecification..." In the last sentence of paragraph 3 of Notation write " "(and start and finish associations refer to the very same OccurrenceSpecification)."

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.8

  • Key: UML22-802
  • Legacy Issue Number: 8328
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Correct Semantics sub-section sentence to "An execution event represents the start or finish of the execution of an action or a behavior."

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.6

  • Key: UML22-801
  • Legacy Issue Number: 8327
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    If DescriptionEvent has a constraint that no other OccurrenceSpecification may appear below the OccurrenceSpecification that references the DescructionEvent on a given Lifeline in an InteractionOperand then a similar constraint should be added to the CreationEvent. "No other OccurrenceSpecification may appear above an OccurrenceSpecification which references a CreaationEvent on a given Lifeline in an InteractionOperand."

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.5

  • Key: UML22-800
  • Legacy Issue Number: 8326
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 331 does not show package name for the generalization InteractionFragment. Typo - Change paragraph 3 of Notation to "A Continuation that is alone in an InteractionFragment is considered to be at the end of the enclosing InteractionFragment."

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.29

  • Key: UML22-794
  • Legacy Issue Number: 8319
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    To be consistent with other multiplicities in fig. 318, add the association multiplicity to the figure. Mention that the association redefines value as shown in the figure. I am not familiar with BNF notation but should "<timeobservation>" be spelled "<timeObservation>?"

  • Reported: UML 2.0 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.28

  • Key: UML22-793
  • Legacy Issue Number: 8318
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    To be consistent with other multiplicities on the figure, add the multiplicities for the associations. Also mention that each association redefines minimum or maximum

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see ptc/2006-04-01 p 261

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.27

  • Key: UML22-792
  • Legacy Issue Number: 8317
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Description change "represent" to "represents." Under sub-section Notation, reword "Often a TimeExpression is a non-negative integer" to "Often a TimeExpression is an UnlimitedNatural number." Saying that often a TimeExpression is a non-negative integer implies that it may, at times, be a negative integer

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see ptc/2006-04-01 p 260

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.12

  • Key: UML22-805
  • Legacy Issue Number: 8331
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Change wording of definitions for associations to: "The OccurrenceSpecification referenced that comes before the OccurrenceSpecification referenced by after" and "The OccurrenceSpecification referenced that comes after the OccurrenceSpecification referenced by before"

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.3 & 14.3.11

  • Key: UML22-804
  • Legacy Issue Number: 8330
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The Description for the concept Gate identifies the different roles gates play as formal, actual, and expression. Fig. 332 uses the terms formal and actual in the association names but not expression. I think expression is very descriptive and suggest changing the name of the association from cfragmentGateGate to expressionGate:Gate. This would require changing figure 332 and the text for CombinedFragment.

  • Reported: UML 2.0 — Wed, 23 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.26

  • Key: UML22-791
  • Legacy Issue Number: 8316
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add package name SimpleTime to association when:TimeExpression[1]. Fig. 318 shows that this association redefines when. Add the association for the package Communications as shown in fig. 317. This is when:ValueSpecification[1] that subsets ownedElement.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Resolved by resolution to issue 8894.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.24

  • Key: UML22-790
  • Legacy Issue Number: 8315
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 317 shows signal:Signal[1] as an association of SignalEvent, not an attribute. Either correct text or figure. Delete the "." leading the first paragraph under the sub-section Notation

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.3

  • Key: UML22-776
  • Legacy Issue Number: 8297
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Multiplicities for the associations need to be added to the text for raisedException:Classifier[0..*], and changed in the associated diagrams to reflect the correct multiplicity (1 for method:Behavior (according to the text) and not * as shown in fig. 311 and 0..* for fig. 315). Unless "specializes" means the same thing as "redefines" change either the text for raisedException:Classifier from specializes to redefines or change fig 315. from redefines to specializes. Regardless, less confusion would occur if the text and the figure used the same word.

  • Reported: UML 2.0 — Fri, 18 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.2

  • Key: UML22-775
  • Legacy Issue Number: 8295
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Specialization mentioned for the association context:BehavioredClassifier[0..1] is not shown on figure 311. Multiplicities for ownedParameter:Parameter in the text do not agree with fig. 311. According to the text the ownedParameter:Parameter references a list of parameters "that can be given" which implies that no parameters may be given and therefore the multiplicity should be [0..*]. This is not what is shown in fig. 311. Multiplicities for remaining associations listed do not agree between the text and the diagrams (fig. 311 & 313). Multiplicities should probably be [0..*] which are not what are shown in figs. 311 & 313. Add the specialization for the association redefinedBehavior:Behavior in the text to agree with fig. 311. Specializations listed for the associations precondition:Constraint and postcondition:Constraint do not agree with fig. 313. Figure 313 shows that these associations subset ownedRule. Add OCL notation to the constraints where possible or indicate that OCL notation is not available.

  • Reported: UML 2.0 — Thu, 17 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    In the recent version of the specification, the specialization for context:BehavioredClassifier has already been added. The multiplicities mentioned above are all “” which is equivalent to “0..”. To correct the remaining mismatch between text and diagram:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.14

  • Key: UML22-784
  • Legacy Issue Number: 8308
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation or a note that OCL is unable define a notation for the constraints.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.12

  • Key: UML22-783
  • Legacy Issue Number: 8307
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    To be consistent, add the multiplicity for duration:Duration[1] to figure 318. Also, fig. 318 indicates that the association redefines value. Please indicate this in the text. I am not familiar with BFN but should "<urationobservation>" be "<durationObservation>"?

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.4

  • Key: UML22-778
  • Legacy Issue Number: 8301
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Generalizations change "Class" to "Classifier." Figures use italics for displaying the concept name so you need to mention that BehavioredClassifier is an abstract class. Under sub-section Associations add package name BasicBehaviors before the first two associations. Add the multiplicity which should probably be [0..*] and if this is correct then change fig. 311 to agree with [0..*] or 1 as is currently indicated by the text. If the multiplicity is as indicated in fig. 311 , then change the text to agree. For the association ownedTrigger:Trigger[0..*], fig. 316 does not indicate this multiplicity. Make the two agree. Add OCL notation or a note that OCL can not supply notation. The sub-section Semantics describes two BehavioredClassifiers - an immediate event and an input event pool. Possibly consider making these children of BehavioredClassifiers or of Event (fig. 316), i.e. ImmediateEventOccurrence and InputEventPool, instead of just Event. If this is done then two additional concepts would need to be added.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.8

  • Key: UML22-780
  • Legacy Issue Number: 8303
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Description change "each of its instance" to "each of its instances." The multiplicity for the association ownedReception:Reception in the text does not agree with fig. 314. If it is [0..*} both text and fig. 314 need changing. Specializes Classifier.feature is not shown in fig. 314 as a specialization of Class but rather as a subset of Interface. Correct either the fig. 314 or text.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.7

  • Key: UML22-779
  • Legacy Issue Number: 8302
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the specializes or subsets comment to the association to agree with fig. 317. Question: If the default value of a Boolean expression is true and its value changes to false would there be a corresponding changeExpression? To me the description and semantics imply that the default value for all Boolean expressions is set at false and this isn't true (e.g., MutliplicityElement attribute isUnique; Port attribute isService). Therefore, what happens when those values change?

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.23

  • Key: UML22-789
  • Legacy Issue Number: 8314
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Description change wording to the following: "A signal is a specification of a type of send request instances that communicated..." and "The data...are representedas attributes..."

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.22

  • Key: UML22-788
  • Legacy Issue Number: 8313
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraint [2] or the note that ICL notation is not definable

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.9

  • Key: UML22-782
  • Legacy Issue Number: 8305
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Reword the last sentence under sub-section Semantics. Assuming is not good. State clearly that the ending point in time and the starting point in time would swap. Change "assuming" to "because." Under sub-section Notation, change "Often a Duration is a non-negative integer expression..." to "Often a Duration is an UnlimitedNatural number..." Use of the word "often" implies that the notation could be expresses as a negative integer which, for Duration is an impossibility (at least in our universe

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.10

  • Key: UML22-781
  • Legacy Issue Number: 8304
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figure 318 shows an association of specification:DurationInterval[1] that redefines specification. Add this to the text or delete the association from the figure. Delete the "." after "DurationConstaint in Figure 320 caption.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.19

  • Key: UML22-786
  • Legacy Issue Number: 8311
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The multiplicity of the attribute language:String[*] in the text does not agree with that shown in fig. 311. Change fig. 311 to agree with the text. Delete the sub-section heading Examples are there none.

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.15

  • Key: UML22-785
  • Legacy Issue Number: 8309
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The association multiplicity in the text does not agree with fig. 314. If multiplicity is [0..*], both text and figure need to be changed

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.20

  • Key: UML22-787
  • Legacy Issue Number: 8312
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to or a note that OCL can not define the constraints

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.36

  • Key: UML22-777
  • Legacy Issue Number: 8298
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    BNF of a operation defines name and type of a parameter as mandatory fields. But both are optional

  • Reported: UML 2.0 — Tue, 22 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.35

  • Key: UML22-755
  • Legacy Issue Number: 8255
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I forgot to mention that "ordered" needs to be added to the following associations: results:OutputPin[0..*], loopVariable:OutputPin[0..*], and loopVariableInput:InputPin[0..*] as shown in fig. 196.

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Also added subsets statements to results, loopVariable, and loopVariableInput.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3

  • Key: UML22-754
  • Legacy Issue Number: 8254
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add sections for front end node and back end node as mentioned in LoopNode

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.35

  • Key: UML22-753
  • Legacy Issue Number: 8253
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Correct multiplicities of associations so that the figures (195 and 196) agree with text. Add subsets statments to descriptions as shown in fig. 96. Typo - 5th para, 1st sent of Semantic sub-section change "body sections has" to "body section has." Delete sub-sections Notation and Examples as there are none.

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Multiplicities are in consistent format. Headers issue is duplicate with 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.48

  • Key: UML22-767
  • Legacy Issue Number: 8273
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Notation, say see fig. 307

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.48

  • Key: UML22-766
  • Legacy Issue Number: 8272
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In sub-section Description, structured activity node is noted as possibly having pins in CompleteStructuredActivities but no pins show any relationship to StructuredActivityNode in fig. 196. The association variable:Variable[0..1] is diagrammed (fig. 195) as belonging to the StructuredActivities package which does not agree in multiplicity and which does indicate that ownedMember is subsetted. A third association is also diagrammed in fig. 195. The association activity:Activity[o..1]. The figure also shows that this association redefines Activity. Figure 196 shows an association of containedEdge:ActivityEdge[?..*]. The figure shows multiplicity as * but in too many cases this should be shown as 0..* In addition, fig. 196 indicates that this association redefined contaniedEdge. Add OCL notation to constraints. In 3rd para of sub-section Semantics, last sentence add the verb "are" between tokens and left. Under the sub-section notation change the word enclosed to enclosing and add the appropriate notation symbology as it is not found in the descriptions of the children of StructuredActivityNode (conditionalNode, loopNode, or sequenceNode as shown in fig. 195) or in section 12.4.

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12

  • Key: UML22-771
  • Legacy Issue Number: 8280
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    General comments. Change the multiplicities on the figures to reflect 0..* instead of only . Some of the figures show it the 0.. way but most do not. If the text lists associations as [0..*] the associated figures should agree. Add OCL notation where possible and where there is no OCL notation available so note it. Delete sub-section headings where there is nothing under them or state None. For specialized concepts, if there is no new information to impart change the word from none to the phrase no new if there was some information in the original concept description sub-section. Generalizations are often not diagrammed in the appropriate Abstract Syntax package diagrams. For instance, the concept ControlNode generalized ActivityNode (from BasicActivities. Even though ActivityNode (the parent) is found in other packages, ControlNode (the child) is not. Should mention be made that ControlNode generalizes ActivityNode from the StructuredActivities package when ContronNode isn't in this package? If so, explain more fully in the How to Read This Specification Section (6.5) about the direct generalizations of a concept being generalized to all packages to which the parent belongs. Where a generalization is diagrammed not all of the "from" packages are listed as indicated in the concept text. Add all package names to the parent namespace or use ellipses to indicate that the list is longer than the namespace allows.

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.4

  • Key: UML22-770
  • Legacy Issue Number: 8279
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - remove the dash from between page and the number when referencing. ActivityNode Notation cell delete ExecutableNode and ControlNode as they just refer the reader elsewhere. ControlNode Notation cell delete FinalNode as it just refers reader elsewhere. Add ActivityNode and FlowNode. ExeceptionHandler Notation cell does not exactly agree with fig. 253. In fig. 253 the small square sits across the HandlerBodyNode instead of abutting it.

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.38

  • Key: UML22-758
  • Legacy Issue Number: 8258
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The multiplicity of association (CompleteActivities) inState:State[0..*] does not agree with fig. 189. Add OCL notation to constraint (BasicActivities) [1]. Add OCL notation to contraints (CompleteActivities. Add "(BasicActivities)" to the 1st Semantics sub-section

  • Reported: UML 2.0 — Tue, 8 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.37

  • Key: UML22-757
  • Legacy Issue Number: 8257
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraints. In the Semantics (CompleteActivities) sub-section, third para change receiving to multireceiving and is to are. In Examples sub-section, the example describing fig. 286, last line indicates that the selection specifies that a query operatiion that takes an Order evaluates the customer object via the Order.customer:Party association. This is not what is diagrammed in the right side of fig. 286.

  • Reported: UML 2.0 — Tue, 8 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL is duplicate with 6346.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profiles:Extension End

  • Key: UML22-756
  • Legacy Issue Number: 8256
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Profiles:Extension End - the spec needs to be clear on the behaviour of the

    {required}

    property of an extension if the extending stereotype in question
    has subclasses. Are those sub-stereotypes also required?

  • Reported: UML 1.4.2 — Tue, 8 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.2

  • Key: UML22-765
  • Legacy Issue Number: 8271
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 196 shows no relationship between concepts immediately under Action (StructuredActivityNode and ActivityEdge) and any of the other concepts in the diagram. There are no connecting lines. If this is truly the case, break this single diagram into two or, as I think (after reading section 12.3.47) there should be some relationship shown between the concepts on the right side of the diagram and those on the extreme left, add lines to show the appropriate relationships.

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.47

  • Key: UML22-764
  • Legacy Issue Number: 8270
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fo the association executableNode:ExecutableNode[*] mention that it redefines containedNode as shown in diagram 195

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Also added ordered to the property string.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 super/templates/

  • Key: UML22-763
  • Legacy Issue Number: 8265
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The definition of Classifier and ClassifierTemplateParameter indicates that there may be additional constraint placed on the parameter. Examples and notation also indicate that. However, there is no defined way to express that constraint in the metamodel (at the very least it is not obvious and is very open for interpretation). The metamodel must provide a meta-association from ClassifierTemplateParameter to Classifier to represent the constraining classifier.

  • Reported: UML 1.4.2 — Thu, 10 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 232/233 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.43

  • Key: UML22-760
  • Legacy Issue Number: 8262
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The association condition:Constraint[0..*] does not have the same multiplicity as fig. 192. Also the fig. indicates that the association subsets ownedElement. Add OCL notation to constraints

  • Reported: UML 2.0 — Tue, 8 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.41

  • Key: UML22-759
  • Legacy Issue Number: 8261
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The attribute effect:ParameterEffectKind[0..1] does not display this multiplicity in fig. 192. Reword the definition of attribute isStream:Boolean[1..1]=false to "Tells whether an input parameter may accept valuses or an output parameter post values while the behavior is executing." parameterSet:ParameterSet[0..*] listed as an attribute is an association. Please move it to the Association sub-section. The multiplicity for parameterSet:ParameterSet[0..*] does not agree with fig. 192. Add OCL notation to the constraints. Under sub-section Notation the last sent. says to "See notation for Operations." but gives no reference location. Is this supposed to be at page 105?

  • Reported: UML 2.0 — Tue, 8 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.49

  • Key: UML22-774
  • Legacy Issue Number: 8294
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-section Associations and Constraints change None to No new

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8232 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.46

  • Key: UML22-773
  • Legacy Issue Number: 8293
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    For sub-sections Associations and Constraints change the None to No new.

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8231 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.1

  • Key: UML22-772
  • Legacy Issue Number: 8292
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figures 307 and 308 are identical. Fig. 308 does not show what the text is describing as the Communication Domain Model(especially the paragraph on pg 457 starting with "As shown in Figure 308..."). Fig. 307 (and current 308) multiplicity for the association execution:BehaviorExecution is diagrammed as * but I wonder if it shouldn't be 0..* since the text indicates that an object may or may not cause the execution of a behavior. In the paragraph immediately following fig. 309, I believe that "The execution of a send action results in a send request, which results in a signal event occurrence (not a call event occurrence as stated). Minor editing call - In the first line on page 457, change synchronously and asynchronously to synchronous and asynchronous.

  • Reported: UML 2.0 — Wed, 16 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 240/241 of ptc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/templates/inexplicable constraint on defaults

  • Key: UML22-762
  • Legacy Issue Number: 8264
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The definition of TemplateParameter states that the parameter cannot own at the same time its parametered element and default element. The ownership of those two elements is mutually exclusive. It is also expressed as an OCL constraint. However, there is no justification offered in the spec for this constraint and one is not obvious. The constraint should be removed.

  • Reported: UML 1.4.2 — Thu, 10 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Indeed, cannot see any justification for this. Remove the constraint.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.44

  • Key: UML22-761
  • Legacy Issue Number: 8263
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add package name to first Constraint sub-section. Left fig of fig. 295 needs an "s" on end. Shouldn't exception handler edges also be used in figures 296 and 303? If not, please clarify that the execption pin notation takes the place of the notation for the exception handler notation.

  • Reported: UML 2.0 — Wed, 9 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.51

  • Key: UML22-769
  • Legacy Issue Number: 8276
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under sub-sections Associations and Constraints change none to no new

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8232 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.50

  • Key: UML22-768
  • Legacy Issue Number: 8275
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add "See "ValuePin (from BasicAQctions)" on page 309." immediately under concept heading. Change None to No new under the sub-section Associations. Delete the word "these" in the 3rd sentence of sub-section Semantics. Delete sub-section Examples as there are none.

  • Reported: UML 2.0 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Empty section issue is duplicate with 8231. Headers issue is duplicate with 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.34

  • Key: UML22-752
  • Legacy Issue Number: 8252
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the package name IntermediateActivities to the first Associations sub-section. Add the subsets ownedElement statement (as shown in fig 193) to the association joinSpec:ValueSpecification[1..1]. Typo - remove the second a between containing and join in the 4th sent of the Notation sub-section 1st para. Change AcceptOrder behavior to SendInvoice behavior (as shown in fig 277) in the 1st sentence in the Examples sub-section. Add OCL notation to the constraints

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.33

  • Key: UML22-751
  • Legacy Issue Number: 8250
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The order cancellation request example lends itself to enhancement. Fig. 274 could be enhanced if there was drawn a fork from invoice providing multiple edges of "no payment needed" or "make payment" with the "no payment needed" edge directly entering the join. Another fork could also be added after the AcceptPayment activity with one outgoing edge labeled "refund payment" with an edge to an activity "IssueRefund" then an edge going to the join. The explanation would reiterate that a token transfer, once initiated (SendInvoice activity), that is outside of the region is not interruptable. That since the SendInvoice activity is outside the region, no matter when the CancelOrder interrupt activity is issued, the SendInvoice activity is issued. However, corrective activities are needed to be performed before the CloseOrder actvity can be accomplished. This would be to either issue the invoice stating no payment is due or to issue a refund once payment is received. Additionally, wouldn't the CancelOrder activity more likely go to the merge before the CloseOrder activity instead of directly to the Activity Final? Otherwise, logically thinking, some order is out there not closed (just canceled). But then maybe (probably??) I'm missing the point of the example in which case a better explanation of the example needs to be provided.

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.17

  • Key: UML22-738
  • Legacy Issue Number: 8234
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Multiplicity for StructuredActivities associations test:ActivityNode[0..*] and body:ActivityNode[0..*] and for CompleteStructuredActivities association bodyOutput:outputPin[0..*] do not agree with figures 195 and 196 respectively. Remove the second set of parantheses from the sub-section heading Associations ((CompleteStructuredActivities)).

  • Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.16

  • Key: UML22-737
  • Legacy Issue Number: 8233
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Package CompleteActivities is not supported by fig. 182 as a generalization for this concept. Change Figure 293 reference in sub-section Notation to either figure 294 or, more likely, figure 301.

  • Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.15

  • Key: UML22-736
  • Legacy Issue Number: 8232
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Change "None" to "No new" for sub-sections Attributes, Associations, and Constraints

  • Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8670 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.14

  • Key: UML22-735
  • Legacy Issue Number: 8231
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    For the Attributes, Associations, and Constraints sub-sections change "None" to "No new." This would be a good policy to follow for all "(as Specialized)" concepts where no new information is presented in the 'as Specialized" concept.

  • Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This was fixed as part of an editorial pass in a previous release. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MultiplicityElement BNF too restrictive

  • Key: UML22-731
  • Legacy Issue Number: 8226
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The BNF for Notation in 9.12 of Infra and 7.3.32 of Super does not allow specification of uniqueness-designator without preceding order-designator.
    This seems too restrictive and is in fact inconsistent with the example in Fig 59 of Super which just shows

    {unique}

    .

  • Reported: UML 1.4.2 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.13

  • Key: UML22-730
  • Legacy Issue Number: 8225
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 192 spells the association as ownedParameterSet (no "s"), does not express the same multiplitity as the text, and indicates that the association subsets ownedmember (need to capitalize the "M" in the figure). Make text and figure agree.

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.6 & 12.3.19

  • Key: UML22-741
  • Legacy Issue Number: 8237
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I'm confused. Fig. 178 shows ActivityFinalNode as a child of ControlNode in the BasicActivities sub-package, but in fig. 183 it is a "grandchild" of ControlNode and a child of FinalNod in the IntermediateActivities sub-package. Can a concept be both a child and a grandchild of the same higher-level concept, in this case ControlNode?

  • Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.19

  • Key: UML22-740
  • Legacy Issue Number: 8236
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 179 does not support generalizations of CompleteActivities, CompleteStructuredActivities, or IntermediateActivities packages. Add OCL notation

  • Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.18

  • Key: UML22-739
  • Legacy Issue Number: 8235
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The generalization from CompleteStructuredActivities is not supported by the figures. Typo - add a space before last sentence in para 2 of sub-section Description. (Before Note that... .) Change wording of definition of attribute isDeterminate:Boolean to "If true, the modeler asserts that at most only one of concurrent tests will succeed and therefore the choice of the clause is deterministic." The multiplicity of the CompleteStructuredActivities association result:OutputPin[0..*] is not what is shown on fig 196. Also change the definition to reflect that the association is ordered and subsets output. Delete sub-section headers Notation, Presentation Option, and Examples are there are none. Suggest changing wording in sent 5 para 4 of sub-section semantics to "If the isDeterminate attribute has a true value, the modeler asserts that at most only one of concurrent test sections will yeild a test value (the predecessor relationship may be used to enforce this assertion)."

  • Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.28

  • Key: UML22-746
  • Legacy Issue Number: 8242
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to the constraint

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6425 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.27

  • Key: UML22-745
  • Legacy Issue Number: 8241
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to the constraint. In sub-section Semantics, last sent. of para 1 change "concurrency" to "mode." Typo - In sub-section Presentation Option, put a space after Figure 259. On Page 399, change figure reference number to 261. In fig. 261, chane <<concurrent>> to <<parallel>>.

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Missing OCL issue is a duplicate of 6452. Empty section issues are duplicates of 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.23

  • Key: UML22-744
  • Legacy Issue Number: 8240
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add subsets note to association protectedNode:ExecutableNode[1..1] as shown on fig. 197. Add OCL notation to constraints. Under sub-section Presentation Option change "interrupting edge is a zig-zag adornment..." to "exception handler is a zig-zag adornment..." Delete sub-section heading Rationale as there is none. Typo - Under sub-section Changes from previous UML in para 2 put a space between first and second sentences.

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL is duplicate with 6346. Headers issue is duplicate with 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Used of "Redefines ...from Abstractions" in descriptions is misleading

  • Key: UML22-734
  • Legacy Issue Number: 8229
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    For example 11.7.2 of Infra: the name property states
    Redefines the corresponding attributes from Basic::NamedElement and Abstractions::Visibilities::NamedElement.

    However there is no redefinition occurring; nor would it make sense.

  • Reported: UML 1.4.2 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

BNF Notation for Operation is too restrictive

  • Key: UML22-733
  • Legacy Issue Number: 8228
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In 11.8.2 (Infra) and 7.3.36 (Super) the notation BNF requires a

    {<oper-property}

    any time there is a ':' after the operation name

  • Reported: UML 1.4.2 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incomplete BNF for Property

  • Key: UML22-732
  • Legacy Issue Number: 8227
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In BNF Notation for Property (11.3.4 of Infra, 7.3.44 of Super), <prop-modifier> is defined but never refered to

  • Reported: UML 1.4.2 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.24

  • Key: UML22-743
  • Legacy Issue Number: 8239
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Change type font to italics on fig. 195. Change association handler:ExceptionHandler [0..1] so that fig. 197 and text agree. Add the subsets ownedElement note as shown in fig 197.

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.22

  • Key: UML22-742
  • Legacy Issue Number: 8238
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL Notation to constraints. Typo - remove 2nd "a" from sent3 of para 2 of sub-section Notation. Delete sub-section headers Presentation Option and Style Guidelines as there are none.

  • Reported: UML 2.0 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Missing OCL issue is a duplicate of 6452. Empty section issues are duplicates of 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.38

  • Key: UML22-748
  • Legacy Issue Number: 8245
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I may be all wet (after all it is a Monday morning and raining here) but I think fig. 265 needs to be redrawn. The notation between the BuildComponent and InstallComponent activites is different than the notation between the InstallComponent and DeliverApplication activities yet the flow is basically the same. To agree with the left side of the flow between BuildComponent and InstallComponent activities, there should be a fork after the InstallComponent activity with an edge going to DeliverApplication activity and an edge going to a decisionNode. The decisionNode should have two edges exiting it. One labeled [more components to be installed] and going back to the InstallComponent activity; a second labeled [no more components to be installed] going to a Flow final node. The edge and the [no more components to be installed] label need to be removed from the edge going from the decisionNode to the DeliverApplication activity. Out of curiosity, why was a fork notation used and not the decisionNode with three control flow edges leading from it?

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.30

  • Key: UML22-747
  • Legacy Issue Number: 8243
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to the constraints

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6425 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.32

  • Key: UML22-750
  • Legacy Issue Number: 8248
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6425 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.31

  • Key: UML22-749
  • Legacy Issue Number: 8247
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraints. Reword last sentence in last paragraph of sub-section Semantics. The entire sentence is confusing and unclear

  • Reported: UML 2.0 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The missing OCL issue is a duplicate of 6425.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.1

  • Key: UML22-729
  • Legacy Issue Number: 8224
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Capitalize the "M" in ownedMember of the subsets not for the BehavioralFeature association ownedParameterSet:ParameterSet

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.12

  • Key: UML22-728
  • Legacy Issue Number: 8223
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Associated fig. 192 spells association name as ownedParameterSet (no "s"), does not show the same multiplicity, and shows that this association subsets ownedMember. Make fig and text agree.

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Multiplicity in fig. 192 is “*” and in associations section “[0..*]”. Both are the same.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.10

  • Key: UML22-727
  • Legacy Issue Number: 8222
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Associated fig. 184 does not show generalizations from FundamentalActivities for ActivityGroup or from Dependencies for NamedElement. The association activity:Activity[0..1] is not diagrammed in fig. 184. The description for the association represents:Element[0..1] needs rewording. Does it mean "An element constraining the behaviors invoked by the nodes in the partition" (constraining used as a verb) or "The element constraining behaviors that are invoked by the nodes in the partition (constraining used as the noun "constraining behaviors")? Fig. 184 shows additional associations: ContainedEdge:ActivityEdge[1..1] and containedNode:ActivityNode[1..1]. These need to be added to text. Add OCL notation to constraints.

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12

  • Key: UML22-726
  • Legacy Issue Number: 8220
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Use of the term edge(s)is confusing without the appropriate qualifier - "Control" or "Object." Suggest changing edge or edges to ControlEdge(s) and/or ObjectEdge(s) as appropriate

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.9

  • Key: UML22-725
  • Legacy Issue Number: 8219
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the multiplicity [1..] to the association. Reword the description of the association parameter:Parameter. It could be interpreted as "the same object node will accept as well as provide parameter values." If that's not the case, i.e., one node accepts and another not provides (which I think is what is meant) then change the "and" to "or." Add OCL notation to the constraints. Constraint [3] needs rewording to something like "Activity parameter nodes must have neither incoming nor outgoing edges" or "Activity parameter nodes must have only incoming or outgoing edges but not both." Wording depends on meaning of constraint. Please clarify semantics to address the following questions. Are input values placed as tokens on input activity parameter nodes at the beginning of flows? Since this node is at the beginning of the flow is that why it has no incoming edges? If it has no incomind edges, how are the values placed on the node? Para 1 of semantics says to see semantics at ObjectNode, Action, and ActivityParamenterNode. This is the semantics section for ActivityParameterNode. Delete that phrase or correct it to the proper reference semantics section. The package CompleteActivities does not show any diagrams with ActivityParameterNode. Delete those package references on pg. 366 or explain why that package is referenced.

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see pages 200/201 of prc/2006-04-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.4

  • Key: UML22-716
  • Legacy Issue Number: 8208
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    None of the multiplicities listed with the associations agree with the multiplicities diagrammed. Please correct either figures (probable) or the text. Associations in the text do not mention any subsets that are illustrated in the associated figures. There is no figure given for Activity in the IntermediateActivity Package but several references to that package (pg 343, 345. Please add a figure for that package for Activity or add Activity to one of the IntermediateActivity figures. Figure 211 is not discussed and appears to give no added value to the section unless figure 210 should contain an action to create a Trouble Ticket.

  • Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The multiplicities only differ in format.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.2

  • Key: UML22-715
  • Legacy Issue Number: 8207
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    According to fig. 187 the associations localPrecondition:Constraint[0..*] and localPostcondition:Constraint[0..*] are subsets of ownedElement. In addition, the multiplicity shown in the fig does not agree with the multiplicity of the text for either association. Para 1, pg 338, sentence 3 appears to have an extra word - tokens - before control tokens. If this isn't extra, then rewrite sentence to make it more clear. The Rationale is a very good description of what an Action is and I suggest placing that paragraph in the Description section. The paragraph for the rationale is not really a rationale or justification--it is a description.

  • Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.2

  • Key: UML22-714
  • Legacy Issue Number: 8206
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Remove duplicate redefines activity statement for association activity between StructuredActivityNode and Activity.

  • Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 7099 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.8

  • Key: UML22-721
  • Legacy Issue Number: 8215
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete the package name "(CompleteStructuredActivities)" after Attributes because ActivityNode is not part of that package according to the figures. Add subsets notations to the associations as shown in the figures. Change the multiplicities of the associations so that the figures and the text agree. Add OCL notation to the constraints

  • Reported: UML 2.0 — Wed, 2 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.7

  • Key: UML22-720
  • Legacy Issue Number: 8214
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add IntermediateActivities to the section header list of packages. Typo - remove "that" from the first sentence. Add appropriate subsets information to the associations as shown in the diagrams. Make the text and diagram multiplicities agree for the associations. Add OCL notation to the constraints

  • Reported: UML 2.0 — Wed, 2 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.6

  • Key: UML22-719
  • Legacy Issue Number: 8213
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete the headers Presentation Option and Style Guidelines as there are none. "In Figure 222, two ways to reach an activity final exist;..." the figure number needs to be changed to 223

  • Reported: UML 2.0 — Wed, 2 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.25

  • Key: UML22-683
  • Legacy Issue Number: 8170
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the superclass pointer "(from Kernal)" to fig. 143. No operations are indicated in fig 143. Constraint [2] appears to have an operation name missing or misspelled

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.24

  • Key: UML22-682
  • Legacy Issue Number: 8169
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    If this is not an action why is it discussed in Actions? Move to appropriate Chapter. Wouldn't the action be more like writing to LinkEndDestroyData? If it stays in this chapter please clarify the introduction and description especially explaining how this is different from LinkEndData. Also need to clarify/explain statement "Qualifer values are used in CompleteActions." I don't see a fit with that statement in this section. Attribute in fig 150 is isRemoveDuplicates:Boolean = false so change either the figure or the attribute name in the text. Add OCL notation to Constraints. Constraint [1] typo in "DestroyLinkActiuon" Constraint [2] needs to emphasize that the type UnlimitedNatural is >0. Delete the header Examples as there are none. Typo in Rationale - "LinkeEndDestructionData"

  • Reported: UML 2.0 — Sun, 2 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.35

  • Key: UML22-629
  • Legacy Issue Number: 8100
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The modifications made for multiple languages (Issue 3391) could often be taken by the reader to mean that multiple languages may exist simultaneously in a single opaque expression. An example is the attribute "language:String[0..*] specifies the languages in which the expression is stated" could be interpreted to mean that the expression could be stated in mixed languages. Additionally plurality of verbs and modifying expressions often do not agree with the plurality of the sentence subject. An example of this is "The languages of an opaque expression, is specified, is often..." Subject is the sentence is "languages" so verb should be "are." Furthermore, this statement implies that a single ("an") opaque expression may have more than one language ("languages").

  • Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1 - typo

  • Key: UML22-631
  • Legacy Issue Number: 8104
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Change "Components" to Component in ownedMember:PackageableElement[*] 1st sentence

  • Reported: UML 2.0 — Fri, 21 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1

  • Key: UML22-630
  • Legacy Issue Number: 8103
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add ending guillemets to specification in isIndirectlyInstantiated. Verify that OCL for /provided:Interface[*] is correct. 3rd and 4th lines don't look right to me

  • Reported: UML 2.0 — Fri, 21 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.34

  • Key: UML22-628
  • Legacy Issue Number: 8099
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The sentence "The contraint does not apply to the namespace itself, but may also apply to elements in the namespace." would be better if "also" was replaced with "instead."

  • Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.33

  • Key: UML22-627
  • Legacy Issue Number: 8098
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I am not an OCL expert (barely a novice) but it seems to me that Constraint [2] is incorrect in stating ">select(ns|ns.name>isEmpty())". Shouldn't that be >select(ns|ns.name>notEmpty()) because the constraint is saying that there is a name and all of the containing namespaces have a names (in other words, all of the containing namespaces are notEmpty).

  • Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.5

  • Key: UML22-637
  • Legacy Issue Number: 8112
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add Generalization TypedElement (from Kernal) to fig. 96.

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.3

  • Key: UML22-636
  • Legacy Issue Number: 8110
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Incorrect page number for reference for "Property" under Description

  • Reported: UML 1.4.2 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.2

  • Key: UML22-635
  • Legacy Issue Number: 8109
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Better choice of word in Changes from UML 1.x would be to change the "of" in last sentence to "that."

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.1

  • Key: UML22-632
  • Legacy Issue Number: 8105
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add component icon to fig. 90 <<component>> :ShoppingCart to be consistent with others in diagram

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.20.2

  • Key: UML22-633
  • Legacy Issue Number: 8107
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Either delete Issue 7240 note from page, make the correction, or explain why the correction was not made.

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.1

  • Key: UML22-634
  • Legacy Issue Number: 8108
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Page references are incorrect for "Property" and "StructuredClassifier".

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.9

  • Key: UML22-638
  • Legacy Issue Number: 8115
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add generalization for InvocationAction to fig 101 to agree with text on 187

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InfrastructureLibrary defines, but should not use package merge

  • Key: UML22-561
  • Legacy Issue Number: 7956
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The resolution to 7623 said to replace all «import» by «merge» in Infrastructure Figure 70. These changes should be reversed because they result in InfrastructureLibrary both defining and being defined by package merge making it very difficult to implement UML2.

    Any implementation would have to do these merges by hand in order to have an implementation of Constructs that could be used to implement package merge, EMOF CMOF, or any other UML2 compliance level.

  • Reported: UML 1.4.2 — Wed, 1 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

section 2.10.4.1 detailed semantics of collaborations

  • Key: UML22-557
  • Legacy Issue Number: 7948
  • Status: closed  
  • Source: Anonymous
  • Summary:

    My question concerns section 2.10.4.1 (detailed semantics of collaborations). The last part of the 4th paragraph starts as follows:

    "However, instances of different classifiers can play the role defined by the classifier role, as long as they have all the required properties."

    Allow me to illustrate my interpretation of this section by means of an example.

    Suppose there is a class A with 5 operations, o1, o2, o3, o4 and o5, and there is a class B with 3 operations, identical to o2, o3 and o4.
    Suppose there is a classifier role R in a collaboration, which has A as its base. The role can then specify a subset of the features of A. These features are then required by instances which play the role. Suppose this subset consists of o2 and o3. Then the quote from the spec above claims that instances of B are allowed to play role R. Is this correct so far?

    Then, the spec goes on:

    "Several classifier roles may have the same base classifier, even in the same collaboration, but their features and contained elements may be different subsets of the features and contained elements of the classifier. These classifier roles specify different roles played by (possibly different) instances of the same classifier."

    So, considering again role R from my example, suppose there is now a different classifier role Q, which also has A as its base. Suppose Q specifies o3 and o4 as the required subset of A's features.

    Now the last sentence from the spec quote seems to say that only (possibly different) instances of A can play roles R and Q. This would mean that an instance of B is NOT allowed to play either R or Q, which would contradict my example above.

  • Reported: UML 1.4.2 — Wed, 24 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.43

  • Key: UML22-554
  • Legacy Issue Number: 7942
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Notation for a primitive type should be <<primitiveType>> instead of <<primitive>>. That's more consistent to the general usage of keywords that they are identical to the metaclass name

  • Reported: UML 2.0 — Mon, 22 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interactions

  • Key: UML22-559
  • Legacy Issue Number: 7950
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In the description of the Graphic Paths for a Communication Diagram I can
    find no mention of what the lines between the Lifelines correspond to -
    although I did find this in the description of Message: "On Communication
    Diagrams, the Messages are decorated by a small arrow along the connector
    close to the Message
    name and sequence number in the direction of the Message." I assume this
    means that the lines correspond to a Connector model element.

    The Graphic Paths section should be updated to include this information and
    justification added as to why a Connector is needed in order for Messages to
    be shown between two lifelines on a Communication Diagram (this seems an
    overly tight constraint to me).

  • Reported: UML 1.4.2 — Fri, 26 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.44 - OCL incorrect

  • Key: UML22-558
  • Legacy Issue Number: 7949
  • Status: closed  
  • Source: Paranor AG ( Earl Waldin)
  • Summary:

    The OCL for the derivation of association /opposite for Property in section 7.3.44, page 126 is incorrect. It's derivation in section "Constraints" on page 126 as given as follows: [1] If this property is owned by a class, associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end. opposite = if owningAssociation->notEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)>any() in if otherEnd.owningAssociation>notEmpty() then otherEnd else Set{} endif else Set {} endif I think that the prose "this property is owned by a class" should translate into "class" and not "owningAssociation" in the above OCL. In other words, the prose does not agree with the OCL. So contraint [1] for opposite should read opposite = if class->notEmpty() and ... let ... in if otherEnd.class -> notEmpty() then ... else Set {} endif

  • Reported: UML 1.4.2 — Fri, 26 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6201 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.2.8

  • Key: UML22-555
  • Legacy Issue Number: 7946
  • Status: closed  
  • Source: INSA ( Jean Louis Sourrouille)
  • Summary:

    In my opinion, the sentence "When a language is reflective, there is no need to define another language to specify its semantics." is false. Any natural language is reflective. However, just take a dictionary of a language that you don't know, you will not understand anything. In fact, the semantics of UML is described in english, not in UML, which explains that you can understand the metamodel.

  • Reported: UML 1.4.2 — Tue, 23 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super Basic Interactions

  • Key: UML22-560
  • Legacy Issue Number: 7951
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Basic Interactions includes SendOperationEvent whose superclass is
    MessageEvent, which is in CommonBehaviors::Communications.

    The problem is that the Basic Interactions package is in Level 1, but
    CommonBehaviors::Communications is in Level 2.

    The same is true for SendSignalEvent. In fact Event itself is also in
    Communications so there's a problem with the whole set of Event subtypes
    defined in BasicInteractions.

    Also BasicActions::SendSignalAction references Communications::Signal

  • Reported: UML 1.4.2 — Fri, 26 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue was fixed in release 2.1.. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

An observed time value must be written into a structural feature

  • Key: UML22-562
  • Legacy Issue Number: 7967
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    TimeObservationAction is a specialized WriteStructuralFeatureAction. An observed time value must be written into a structural feature. If modeling activities with that kind of action it would be useful to be able to write the time value to a variable instead of a structural feature. The time value is often used temporarily

  • Reported: UML 2.0 — Fri, 3 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: These actions were removed as part of an earlier fix. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Classes

  • Key: UML22-556
  • Legacy Issue Number: 7947
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I see a problem in the definition of the InstanceSpecification of a new primitive like Real. The value is specified by a ValueSpecification. The UML metamodel of ValueSpecifications reflects the predefined primitive types of UML: LiteralInteger, LiteralString, and so on. This is an indirect dependency from the Kernel package to the AuxiliaryConstructs package. That dependency direction shouldn't be allowed. How to specify a value specification for a primitive type Real? I think that we need LiteralReal to do that.

  • Reported: UML 1.4.2 — Wed, 24 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8069 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.34

  • Key: UML22-691
  • Legacy Issue Number: 8178
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association result:OutputPin[1..1] is Specialized from Action:output according to fig. 155. Rewrite Constraint [4] as "The type of the object input pin is the type of the association class that owns the association end." Complete the Semantics section. Delete the header Examples as there are none

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.33

  • Key: UML22-690
  • Legacy Issue Number: 8177
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete Examples header as there are none

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue N/A for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.31

  • Key: UML22-689
  • Legacy Issue Number: 8176
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig 153 shows that the association result:OutputPin[1..1] is subsetted. Add OCL notation for constraint [1]. I believe the wording of constraint [1] might be better as: "The type of the result output pin is the type of the classifier."

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.26

  • Key: UML22-684
  • Legacy Issue Number: 8171
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The generalization in figure 142 doesn't agree with that mentioned in the section. Attributes are both ordered. Delete header Examples as there are none

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Example header is duplicate of 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.27

  • Key: UML22-694
  • Legacy Issue Number: 8182
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete the Examples header as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.36

  • Key: UML22-693
  • Legacy Issue Number: 8181
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraint [2]. Delete Examples header as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6452, 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.28

  • Key: UML22-686
  • Legacy Issue Number: 8173
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - In description delete provide and change accept to accepts. Add OCL notation to Constraints. Delete header Examples as there are none.

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL issue is a duplicate of 6452. Header issue is a duplicate of 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.29

  • Key: UML22-687
  • Legacy Issue Number: 8174
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Please clarify the relationship and differences between QualifierValue, LinkEndCreationData, LinkEndData, and LinkEndDestructionData especially since QualifierValue, LinkEndData, and LinkEndCreationData are all in the CompleteActions package. Constraint [2] change "are" to "is" Delete Examples header as there are none.

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.35

  • Key: UML22-692
  • Legacy Issue Number: 8180
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the specialized statement needed for the association result"OutputPin[1..1] as shown in fig. 155. Add semantics or delete the header. Delete the Examples header as there are none.

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.30

  • Key: UML22-688
  • Legacy Issue Number: 8175
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association exception:InputPin[1..1] is subsetted according to fig 158. Delete Examples heading as there are none

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Headers issue is duplicate with 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.27

  • Key: UML22-685
  • Legacy Issue Number: 8172
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Description should mention the multiplicity expressed in fig. 143. Delete the header Examples as there are none

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Optional inputs

  • Key: UML22-588
  • Legacy Issue Number: 8037
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    When does an action start when all its inputs are optional?

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Preserve order in result of read actions

  • Key: UML22-587
  • Legacy Issue Number: 8036
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of the various read actions (ReadStructuralFeatureAction, etc) should specify that the order of the retrieved collections is preserved in the values of the output pin.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interactions chapter refers to ActivityInvocations

  • Key: UML22-582
  • Legacy Issue Number: 8030
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Interactions chapter refers to ActivityInvocations The Interactions chapter still refers to ActivityInvocations, which was only in an intermediate draft of the original submission. I think it should be CallBehaviorAction or CallOperationAction, not sure.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The term ActivityInvocations only appears once, on page 563 of ptc/04-10-02.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Destruction semantics in StructuredClassifier

  • Key: UML22-583
  • Legacy Issue Number: 8031
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Destruction semantics in StructuredClassifier The destruction semantics in StructuredClassifier should include destruction of links created due to connectors between noncomposite properties

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 119 missing multiplicity

  • Key: UML22-585
  • Legacy Issue Number: 8033
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 119 missing multiplicity. Figure 119 (Connectors and parts in a structure diagram) is missing a multiplicity on the right side of the connetor

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Link maintenance in StructuredClassifier

  • Key: UML22-584
  • Legacy Issue Number: 8032
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Link maintenance in StructuredClassifier The semantics of StructuredClassifier should indicate that links are created/destroyed according to connectors when objects are added/removed from the connected properties. Extend Create/Destroy/ClearLinkAction and Add/Remove/ClearStructuralFeature with boolean properties that "turn on" this semantics.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see ptc/2006-04-01 p 94

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectNode, constraint 1 In ObjectNode

  • Key: UML22-591
  • Legacy Issue Number: 8040
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ObjectNode, constraint 1 In ObjectNode, Constraints (Complete Activities), the first constraint regarding upperbound should be removed. The size of the object node buffers can be any size.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DestroyObjectAction semantics

  • Key: UML22-590
  • Legacy Issue Number: 8039
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify the "owns" language in DestroyObjectAction to mean the objects related by composite associations

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IsReadOnly constriant

  • Key: UML22-589
  • Legacy Issue Number: 8038
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    done) IsReadOnly constriant Constraint on StructuralFeature::isReadOnly: if true and there is no intialization value, then the lower multiplicity must be zero.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for method

  • Key: UML22-586
  • Legacy Issue Number: 8035
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Need a notation for instances of the specification/method metaassociation (Figure 311).

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6150 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.1

  • Key: UML22-659
  • Legacy Issue Number: 8145
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add that retureInformation:OutputPin[1..1] is a specialization or subsets output as shown in fig. 152. Add OCL expression for constraint 1 or that the constraint cannot be expressed in OCL. Constraint [3] contains a typo in the 1st line "isUnmrashall" should be "isUnmarshall"

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Missing OCL is a duplicate of 6452.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.1

  • Key: UML22-658
  • Legacy Issue Number: 8144
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos and rewording requests Basic Concepts para 2 - Change "Behavior" to "Behaviors" Basic Concepts para 3 - Change "Operations" to "Operation calls" Intermediate Concepts para 1 sentence 1 - change "various action primitive actions" to "various primitive actions" Intermediate Concepts para 1 sentence 3 - rewrite to something like: S"pecifically, a single primitive action is defined so that it either carries out a computation or accesses object memory, but never both." Intermediate Concepts para 6 sentence 4 - Add verb in "multiplicity bound ignored" to "multiplicity bound is ignored" Intermediate Concepts para 6 last sentence - replace the pronoun "these" with the appropriate noun - I don't know if "these" refers to the points where the lower multiplicity bound is ignored or the points where the modeler has determined that the lower multiplicity bound is enforced. Intermediate Actions, Read Write Actions (page 230) para 3 sentence 1 - needs rewording: "ranging from" implies a "to" something which is not listed; "implementation-dependent" is a modifiying phrase but I don't know what it is modifying (the following comma may not be needed). My interpretation of the sentence meaning is: "Value specificationc cover various expressions ranging from implementation-dependent constants to complex expressions with possible side-effects."

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.15

  • Key: UML22-621
  • Legacy Issue Number: 8092
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I am confused by the statements that say "the name of the imported element must be qualified in order to to used and is not added to the importing namespace." Add a statement to clarify that if the name is qualified, how the element is referenced by another element.

  • Reported: UML 2.0 — Wed, 19 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.12

  • Key: UML22-620
  • Legacy Issue Number: 8091
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Issues 6164 and 6159 still have not been addressed. Figure 36 reads that the client CarFactory is dependent upon the supplier Car which is not what the text states.

  • Reported: UML 2.0 — Wed, 19 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The fix was not completed. Instead of VehicleType the text should refer to CarFactory.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.32 Page: 96-99

  • Key: UML22-626
  • Legacy Issue Number: 8097
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The document defines multiplicity as an "inclusive interval of non-negative integers" which is the same thing as Unlimited Naturals, but in several other places the "non-negative" qualifier for integer is left off leaving only integer as the definition of the lower bound and integers may be negative. Examples are Additional Operations [4]and in the second paragraph of semantics. Additional Operations [2] OCL is incorrect if the type for includesCardinality(c:Integer) is Integer because the third line says that includesCardinality = (lowerBound() <= C) and (UpperBound () >= C). Everywhere else it is stated that the upperBound is UnlimitedNatural NOT an integer. Remove the word "is" following specification in the second sentence of the first paragraph under Notation.

  • Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.32

  • Key: UML22-625
  • Legacy Issue Number: 8096
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Since the lower bound of multiplicity can not be negative by definition, shouldn't the type of /lower MultiplicityElement be UnlimitedNatural? Also, /upper is missing from the list of attributes

  • Reported: UML 2.0 — Thu, 20 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.22

  • Key: UML22-624
  • Legacy Issue Number: 8095
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figures 50 and 51 cause me confusion because Fig. 50 uses as the classifier name a type (String). Yet Fig. 51 shows "Other properties of the feature, such as type" on the second line of the slot streetNumber:Integer = 381. Should the classifier name in Fig. 50 be a type or something more like myAddress. Please clarify, especially that there is a difference, as indicated by the naming convertion, between the instance specification and the feature shown in the slot.

  • Reported: UML 2.0 — Wed, 19 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 6.5.1: Error in example

  • Key: UML22-616
  • Legacy Issue Number: 8086
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Error in example. Text for /isComposite : Boolean A state with isComposite = True is said to be a composite state. A composite state is a state that contains at leas one region> BUT the OCL says IsComposite = (region >1) which translates to is greater than one. Use the is equal to or greater than symbol or change the number to 0.

  • Reported: UML 2.0 — Fri, 14 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.10

  • Key: UML22-619
  • Legacy Issue Number: 8090
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    If constraind elements are those elements required to evaluate the constraint spedividation, why is the multiplicity for the specification: ValueSpecification[0..1]? Shouldn't the multiplicity be 1? If not, please clarify.

  • Reported: UML 2.0 — Tue, 18 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.20

  • Key: UML22-622
  • Legacy Issue Number: 8093
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Text says that Manager constitutes one GeneralizationSet but Figure 42 uses the word Employee. Please correct

  • Reported: UML 2.0 — Wed, 19 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The submitter is correct. This is a bug.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.8

  • Key: UML22-618
  • Legacy Issue Number: 8089
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The association package:Package[0..1] is listed as being an association of Classifier. However, the only figure to diagram this association is Figure 14 and the association is from Type not Classifier.

  • Reported: UML 2.0 — Fri, 14 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Stereotypes applying in UML 2.0

  • Key: UML22-623
  • Legacy Issue Number: 8094
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    I have some questions regarding stereotypes using in UML 2.0.

    1. How to declare user defined stereotype in the model? Should class with stereotype <<metaclass>> and metaclass name be created in the model? How to declare stereotype <<metaclass>>?

    2. Is some relationship between stereotyped model element and stereotype instance exist? Where stereotype instance should be created (contained) and how model element can collect all applied stereotypes?

  • Reported: UML 1.4.2 — Mon, 17 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.3

  • Key: UML22-617
  • Legacy Issue Number: 8088
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Clarification of subsetting is still confusing to me. The Note has an incomplete sentence for the last "sentence." I believe you need to remove the starting word "If."

  • Reported: UML 2.0 — Fri, 14 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.20

  • Key: UML22-678
  • Legacy Issue Number: 8164
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Superclass generalization is not written on fig. 144. Association argument:InputPin[0..*] multiplicity does not agree with fig. 144. Association argument:InputPin[0..*]in fig. 144 says it is ordered and subsets input. Add statements to the definition of the association. Under Constraints say none.

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.19

  • Key: UML22-677
  • Legacy Issue Number: 8163
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Bold the heading Associations. Delete the heading Examples as there are none. Constraint [2] of 11.3.18 says that input pin has no type but there is no such constraint mentioned for 11.3.19 (which is the section describing inputPin.

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.22 -- significant revision?

  • Key: UML22-680
  • Legacy Issue Number: 8166
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    If LinkEndCreationData is not an action, should it be in this part? Wouldn't the action be to read data from this element or write data to this element? LinkEndCreationData is found in two packages but the discussion/text only addresses its use from the IntermediateActions with no mention of its use in CompleteActions. If this section is to stay in this part then rewrite introduction, description, associations, constraints and semantics to address its use/application in CompleteActions. OCL notation for Constraint[2] does not say that the UnlimitedNatural must be >0 as is stated in the definition of the association insertAt:InputPin. Too many closing ")" for the number of opening "(" in Constraint [2] OCL notation Delete the Examples header as there are none.

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.21

  • Key: UML22-679
  • Legacy Issue Number: 8165
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Associated figures 148 & 150 do not diagram an direct association between LinkAction and InputPin. Please clarify, add to figures, or delete the association from the section. Constraint [2] OCL notation has an extra ending ) Semantics need to be rewritten clarifying how LinkAction and inputPin are associated. None of the figures containing the classifier LinkAction show an association with a multiplicity of 1..1. Delete heading Examples as there are none.

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.40

  • Key: UML22-696
  • Legacy Issue Number: 8185
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - removeAt:InputPin [0..1] Unlimitednatural needs correcting. Add specialization to association removeAt:InputPin [0..1] as shown in fig. 147. Constraint [1] needs OCL notation. Add that the Unlimited Natural number must be >0 to the constraint definition. Delete Examples header as there are none. Last statement in the Changes from previous UML is not supported by fig. 147. There is no other mention of RemoveAttributeValusAction in this version of the Superstructure

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Example header is duplicate of 8155. OCL is duplicate of 6346.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.38

  • Key: UML22-695
  • Legacy Issue Number: 8183
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete the Examples header as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.23 -- significant revision?

  • Key: UML22-681
  • Legacy Issue Number: 8167
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I read and understand little difference between LinkEndData and LinkEndCreationData or LinkEndDestructionData. If none of these elements are actions what are they doing in Actions? Wouldn't the action be to read to or write from these elements? Add the package CompleteActions name to the Description and mention that LinkEndData identifies one end of a link to be destroyed. Add "(IntermediateActions)" to the first Constraint header. I'm not certain that constraint (IntermediateActions) [3] multiplicity agrees with the association value:InputPin[0..1] mulitplicity The instruction under semantics to see LinkAction and its children needs to be rewritten. Through following all of the instructions to see different sections, I finally found semantics information in ReadLinkAction, CreateLinkAction, and DestroyLinkAction. Delete header Examples as there are none.

  • Reported: UML 2.0 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.14

  • Key: UML22-672
  • Legacy Issue Number: 8158
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In description, change "positive integer" to "unlimitedNumber greater than 0" Delete Examples hearder as there are none

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Example header is duplicate of 8155.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.18

  • Key: UML22-676
  • Legacy Issue Number: 8162
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I am confused by the request of issue 7179 to replace 'input' by 'target' in both constraints and then seeing 'input' replaced by 'target' only in the OCL notation. Please clarify. I am also confused by constraint [2] since part 11.3.19 InputPin says nothing about the type of inputPin. Delete the header Examples as there are none.

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.16

  • Key: UML22-674
  • Legacy Issue Number: 8160
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Constraint 1 says that the classifier cannot be abstract but fig. 146 shows the Classifier name in italics. Delete header Examples as there are none

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.17

  • Key: UML22-675
  • Legacy Issue Number: 8161
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Change "positive integer" in the Description section to "unlimitedNatural >0" Delete the header Example as there are none

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.15

  • Key: UML22-673
  • Legacy Issue Number: 8159
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete the header Examples as there are non

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.53

  • Key: UML22-709
  • Legacy Issue Number: 8198
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Put a line feed before Notation header. Delete Examples header as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.42

  • Key: UML22-708
  • Legacy Issue Number: 8197
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The text does not agree with fig. 152. Correct either the figure or the text. Fig shows that ReplyAction generalizes Actions (from BasicActions), that the association replyToCall is to CallEvent not Trigger, that the association replyValue is to InputPin not OutputPin and that this association subsets input from Actions, that the association returnInformation:InputPin subsets input from Actions. Constraint [1] uses the word "trigger" but figure would indicate that "call event" would be more correct. This constraint needs OCL notation. Semantics really don't agree with figure. [2] needs the word "to" added after meaning and the word trigger is still used when the figure would indicate call even is mor appropriate.

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL is duplicate with 6346. Figure 152 should use Trigger instead of CallEvent.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.43

  • Key: UML22-698
  • Legacy Issue Number: 8187
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association target:inputPin[1] subsets input from BasicActions according to figure 145

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.41

  • Key: UML22-697
  • Legacy Issue Number: 8186
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The association removeAt:InputPin[0..1] is subsets input from Actions according to fig. 157. Correct typo in Constraint [1] "removaeAt". Add OCL notation for the constraint. Constraint also needs to mention that the Unlimited Natural must be >0. Typo - Last line of para 1 of semantics - change "support" to "supports" Delete header Examples as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.2

  • Key: UML22-660
  • Legacy Issue Number: 8146
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the specialization (subsets) statement to result:OutputPin[0..*] as shown in fig. 152. Add OCL statements to Constraints. Constraint [2] needs clarification. Last part of sentence is confusing. Typo - Semantics, para 2, sentence 1 - Change "unmarshall" it "isUnmarshall"

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Missing OCL is a duplicate of 6452.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.9

  • Key: UML22-667
  • Legacy Issue Number: 8153
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to Constraints. Delete Examples heading as there are none

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issues 8155 and 6346 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.8

  • Key: UML22-666
  • Legacy Issue Number: 8152
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 144 shows a default for isSynchronous:Boolean = true but this is not indicated in the Attributes section. Associations result:OutputPin[0..*] multiplicity does not match fig. 144; change the description to: "An ordered list of output pins..." and add a statement about the specialization or subsets. Add OCL notation to Constraints.

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Multiplicity is in proper format. Lists are always ordered. OCL is duplicate with 6346.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.12

  • Key: UML22-670
  • Legacy Issue Number: 8156
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete Examples header as there are none

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.11

  • Key: UML22-669
  • Legacy Issue Number: 8155
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete Examples header as there are none

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed as part of a previous copy-edit pass of the spec. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.10

  • Key: UML22-668
  • Legacy Issue Number: 8154
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to Constraints. Typo - place a period at the end of the definition of the operation:Operation[1] association Add a subsets or specialization statement to the association target:InputPin[1] as is shown in fig. 144

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL is duplicate with 6346

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.6

  • Key: UML22-664
  • Legacy Issue Number: 8150
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    It seems to me that the OCL statement does not specify that the UnlimitedNatural needs to be >0. Add "The insertion point is ignored when replacing all values." as last sentence in para 2 of Semantics. Remove the header Examples as there are none.

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.7

  • Key: UML22-665
  • Legacy Issue Number: 8151
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL statements as appropriate for Constraints. Typo - Need a couple of line feeds before the header Notation

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Missing OCL is a duplicate of 6452.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.5

  • Key: UML22-663
  • Legacy Issue Number: 8149
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    It seems to me that the OCL statement does not specify that the UnlimitedNatural needs to be >0. Remove the header Examples as there are none

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.13

  • Key: UML22-671
  • Legacy Issue Number: 8157
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete Examples header as there are none.

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Connector multiplicity notation

  • Key: UML22-579
  • Legacy Issue Number: 8027
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Connector multiplicity notation The notation section of ConnectorEnd says multiplicities shown on connector lines represent the multiplicities of both the association and the connector: These adornments specify properties of the association typing the connector. The multiplicity indicates the number of instances that may be connected to each instance of the role on the other end. But these multiplicity can be different, and have separate elements in the metamodel.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Associations between interfaces

  • Key: UML22-578
  • Legacy Issue Number: 8025
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Associations between interfaces The wording of the caption in Figure 56 implies that association between interfaces have implication on required and provided interfaces. My udisjoinnderstanding from mailing list discussion is that this is only an example, not a semantics. Should be clarified in the caption that this is an example of applying associations to interfaces.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

create dependency Figures 103 and 121

  • Key: UML22-580
  • Legacy Issue Number: 8028
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    create dependency Figures 103 and 121 use create dependencies, which do not apply to the example. Standard stereotypes defines create for BehavioralFeature as: "Specifies that the designated feature creates an instance of the classifier to which the feature is attached. May be promoted to the Classifier containing the feature."

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Transitivity in composition

  • Key: UML22-573
  • Legacy Issue Number: 8015
  • Status: closed  
  • Source: NIST ( Mr. Evan K. Wallace)
  • Summary:

    Transitivity in composition: The semantics of Association say composite associations are transitive. Transitivity violates the single-owner rule for composition mentioned in the same paragraph. It also requires that the association have the same class on both ends.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

underlined association name

  • Key: UML22-581
  • Legacy Issue Number: 8029
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    underlined association name Figures 120 and 121 underline the association names, which doesn't seem consistent with the notation for instances in Figure 21.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The notation for instance specification seems clear that if an association name is shown on an instance specification, that this name would be underlined, see p.84: “It is not necessary to show an underlined name where it is clear from its connection to instance specifications that it represents a link and not an association.” (The diagram example in that section does not show the name.) Therefore, the above two figures are consistent with the notation defined for instance specifications. One could eliminate the association name, if so desired. Revised Text: Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-577
  • Legacy Issue Number: 8021
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Specializing one association end Suppose we have a class diagram like this: <pre>
    aend bend
    A ----------------------------- B
    ^ ^

     
     
     
     
    subbend
    {subsets bend}

    SubA -------------------------- SubB

    </pre>
    What metarelation is used between the lower left end and the upper left end (aend)? It is not redefined or subsetted.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add concept "StateInvariant"

  • Key: UML22-572
  • Legacy Issue Number: 7996
  • Status: closed  
  • Source: SINTEF ICT ( Richard Torbjørn Sanders)
  • Summary:

    Add concept "StateInvariant" in figure, with arrows to "mystate" and "

    {Y.p == 15}

    "

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pin/parameter matching constraints

  • Key: UML22-574
  • Legacy Issue Number: 8017
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Pin/parameter matching constraints: The wording for CallAction, constraints 2 and 3 should be consistent with the wording of constraint 3 for CallBehaviorAction and CallOperationAction

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Classes

  • Key: UML22-576
  • Legacy Issue Number: 8019
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Dependency should specialize source/target On Dependency, client and supplier should specialize source and target from DirectedRelationship. Source/target are derived unions, so can't be used otherwise

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: CB/ACT

  • Key: UML22-575
  • Legacy Issue Number: 8018
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    Matching by order difficult to implement Matching by order of the parameters of methods and operations and pins and parameters is difficult to implement in relation database implementations.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.9

  • Key: UML22-723
  • Legacy Issue Number: 8217
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the multiplicity [1..] to the association. Reword the description of the association parameter:Parameter. It could be interpreted as "the same object node will accept as well as provide parameter values." If that's not the case, i.e., one node accepts and another not provides (which I think is what is meant) then change the "and" to "or." Add OCL notation to the constraints. Constraint [3] needs rewording to something like "Activity parameter nodes must have neither incoming nor outgoing edges" or "Activity parameter nodes must have only incoming or outgoing edges but not both." Wording depends on meaning of constraint. Please clarify semantics to address the following questions. Are input values placed as tokens on input activity parameter nodes at the beginning of flows? Since this node is at the beginning of the flow is that why it has no incoming edges? If it has no incomind edges, how are the values placed on the node? Para 1 of semantics says to see semantics at ObjectNode, Action, and ActivityParamenterNode. This is the semantics section for ActivityParameterNode. Delete that phrase or correct it to the proper reference semantics section. The package CompleteActivities does not show any diagrams with ActivityParameterNode. Delete those package references on pg. 366 or explain why that package is referenced.

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.1

  • Key: UML22-722
  • Legacy Issue Number: 8216
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    If BasicActivities and StructuralActivities are orthogonal, why does the structural level require the basic level? This concept is not supported by fig. 175. Please forgive me if I've already sent this one in, but I hadn't marked my comment as submitted.

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8202 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.4

  • Key: UML22-641
  • Legacy Issue Number: 8120
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Correct statement under Constraints to read "No additional constraints."

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.10

  • Key: UML22-640
  • Legacy Issue Number: 8117
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I can't find appropriate figure for the generalization "Parameter (from Kernel, AssociationClasses)". Add appropriate OCL notation to Constraints

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.1

  • Key: UML22-647
  • Legacy Issue Number: 8132
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figure 124 does not show what the Generalizations "Classifier (from Kernel, Dependencies, PowerTypes)" indicates, or the association ownedProperty:Property, or the multiplicity listed for attribute filename:String[0..1]

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.1

  • Key: UML22-648
  • Legacy Issue Number: 8133
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo in 1st line of Notation. In Semantics, clarify which Appendix to see

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Both matters raised by this issue represent valid editorial clarifications to the text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.13

  • Key: UML22-644
  • Legacy Issue Number: 8129
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Under Notation change "name of the part" to rolename to differentiate it from the name of the part (as in composition).

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.13

  • Key: UML22-645
  • Legacy Issue Number: 8130
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig 121 uses the word "make" for the constructor. Unfortunately, this word could be misconstrued to be a noun and refer to the make of the car (Volvo, Audie, Ford) instead of the verb it is intend to be. Suggest changing "make" to "assemble."

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.13

  • Key: UML22-643
  • Legacy Issue Number: 8128
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Associations need derived symbol added to role:ConnectableElement and /part:Property (as shown in fig. 95), a statement that role is derived, and multiplicities added to all associations (as shown in fig. 95).

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see ptc/2006-04-01 page 140

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.9

  • Key: UML22-639
  • Legacy Issue Number: 8116
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to Constraints. Notation says to see "CallOperationAction" for an example, but no examples are given in that section

  • Reported: UML 2.0 — Mon, 24 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.2

  • Key: UML22-646
  • Legacy Issue Number: 8131
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    There is no explanation in the chapter or the section on StrucutredActivities as to why two StructuredActivities packages are drawn, both <<merge>> in fig. 94. Please clarify somewhere

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.12

  • Key: UML22-642
  • Legacy Issue Number: 8127
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In Examples, the reference page number to SturcturedClassifier is incorrect

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.4.1

  • Key: UML22-615
  • Legacy Issue Number: 8085
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Multiplicity is non-negative so shouldn't the lower bound be typed as an unlimited natural (a non-negative number) instead of an integer which can be negative? The upper bound is typed as an unlimited natural. This question also applies to Infrastructure (ptc/03-09-15, sections 9.11 and 9.12).

  • Reported: UML 2.0 — Wed, 12 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.6

  • Key: UML22-614
  • Legacy Issue Number: 8084
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    There appears to be a conflict between the Superstructure VisibilityKind and the Infrastructure VisibilityKind (ptc/03-09-15, section 9.20.2, pg 93). Superstructure lists the four found in vers 1.5 of UML but Infrastructure lists only public and private. What is the correct enumeration for VisibilityKind? Has the Superstructure refined the Infrastructure? If so, a clarification that Superstructure VisibilityKind is refining that from Infrastructure would be helpful.

  • Reported: UML 2.0 — Wed, 12 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.8.3

  • Key: UML22-610
  • Legacy Issue Number: 8080
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figure 98 shows an merged package P::A in the source package S. I do not see how P::A got merged when Figure 97 shows no merge between target P and source S or between source R and source S. The text says that packages P and Q are being merged by package R while package S merges on package Q (with the open ended arrow indicating Q as the target but the keyword <<merge>> at the end nearest S. The statement above Figure 98 says the transformed packages R and Q are shown but the figure has the packages labeled R and S. There appears to be no merge connection between P and S but a subpackage from P appears in S. The text and figures are very confusing and need clarification

  • Reported: UML 2.0 — Fri, 7 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.6.1

  • Key: UML22-609
  • Legacy Issue Number: 8079
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The each sentence in the third paragraph under semantics appears to have an incorrect "and" in them. I believe the and should be replaced by the word "or" in each sentence. The second paragraph seems to have a couple of misplaced hyphens.

  • Reported: UML 2.0 — Thu, 6 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.3

  • Key: UML22-613
  • Legacy Issue Number: 8083
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Second sentence in second paragraph under description is somewhat confusing. "The constraint does not necessilarily apply to the namespace itself, but may also apply to the elements in the namespace." The use of the word "also" bothers me. Do you mean "instead" rather than also. Wouldn't it make more sense, in the context of the first part of the sentence, that the constraint could instead apply to the elements in the namespace rather than the namespace. If you mean that a constraint could apply to both or the namespace or the element in the namespace then the statement needs to be reworded

  • Reported: UML 2.0 — Wed, 12 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The text does need to be reworded to eliminate such confusion.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.1.5

  • Key: UML22-612
  • Legacy Issue Number: 8082
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figure 115 shows the <<enumeration>> Color, but shouldn't that be labeled as ColorKind as shown in Figure 88 and specified in Conventions and Typography in 8.5?

  • Reported: UML 2.0 — Mon, 10 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.5

  • Key: UML22-607
  • Legacy Issue Number: 8076
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The phrase that starts "These constructs that are used..." is not a complete sentence and confusing. I believe that the word "that" needs to be deleted

  • Reported: UML 2.0 — Wed, 5 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

search for referenced item -- Section: 11.3.4

  • Key: UML22-606
  • Legacy Issue Number: 8075
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    A reference is made to the Operations Diagram in the Description section but no figure number (93) or page number (146) is given. It would save time and greatly decrease the frustration factor for this reader if I didn't have to search for the referenced item.

  • Reported: UML 2.0 — Wed, 5 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 68

  • Key: UML22-603
  • Legacy Issue Number: 8072
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Figure 68 does not show the

    {composite}

    notation for the attribute ownedType: Type

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

methods not defined under attributes

  • Key: UML22-602
  • Legacy Issue Number: 8070
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In all previous sections when a diagram shows a named association, the text defines these under the heading Associations. All of a sudden you've changed methods and are not defining these under attributes. A clarification as to why this is done would help those of us who are not UML experts.

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.1.2

  • Key: UML22-611
  • Legacy Issue Number: 8081
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Additional option [1] says that the query lowerBound () returns the lower bound of the multiplicity as an Integer. Why is the type Interger used instead of the type UnlimitedNatural? An integer can be a negative number but not so with naturals. My understanding is that multipliticity is not allowed to be less than 0.

  • Reported: UML 2.0 — Mon, 10 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.3

  • Key: UML22-605
  • Legacy Issue Number: 8074
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The description refers to the Classifiers Diagram but no figure number (Figure 84) or page number (page 127) is given. It would greatly facilitate the reading if the user did not have to search for this. In section 6.3 on How to Read this Specification, it is stated that extensive cross-references are given. This specification would be better if more cross-references were given, especially when a figure or section that is found elsewhere in the document is referenced. I sent in a request to clarify Chapter/Section 10.2. I have since found that an excellent clarification exists in Chapter 11.3. If this had be referenced in Chapter 10.2 it would have saved this reader several hours of confusion and frustration

  • Reported: UML 2.0 — Wed, 5 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.1

  • Key: UML22-604
  • Legacy Issue Number: 8073
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The last phrase in the sixth paragraph from the top which starts with "For n-ary associations..." is an incomplete prepositional phrase and the meaning is unclear

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Actor is a specialized Classifier and not BehavioredClassifier

  • Key: UML22-608
  • Legacy Issue Number: 8078
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Actor is a specialized Classifier and not BehavioredClassifier. Therefore an actor is not allowed to realize an interface. I propose to inherit Actor from BehavioredClassifier. It is useful to model actors with interfaces. The actor/subject communication requires the definition of signals/messages that can be sent from the subject to an actor.

  • Reported: UML 2.0 — Thu, 6 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see ptc/2006-04-01 p 108/109

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.1

  • Key: UML22-711
  • Legacy Issue Number: 8202
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Italicize activity as well as execution in sent 2 of para 1 under Actions and activities. Basic Activities describes basic and structured levels as orthogonal where either can be used without the other or both can be used to support modeling... . Yet StructuredActivities says that this level requires the basic level. Fig. 175 does not support this statement. Please clarify and fix.

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.54

  • Key: UML22-710
  • Legacy Issue Number: 8199
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete header Examples as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

{redefined } should be named {redefines }

  • Key: UML22-713
  • Legacy Issue Number: 8204
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary: {redefined <end-name>}

    should be named

    {redefines <end-name>}
  • Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Typo in the Superstructure spec; it does not occur in the Infrastructure.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property string {bag} is redundant

  • Key: UML22-712
  • Legacy Issue Number: 8203
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Property string

    {bag}

    is redundant. Use property string

    {nonunique}

    defined for MultiplicityElement instead

  • Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.5

  • Key: UML22-718
  • Legacy Issue Number: 8210
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add subsets (or specializes) or redefines statements to associations as indicated by the associated figures. Correct either the association multiplicity or the associated diagram multiplicity so that they agree. Italicize ActivityEdge in fig. 196. Add OCL notation to constraints. In Semantics (CompleteActivities) change "Edges" beginning paragraphs 3 and 4 to "ActivityEdges". In notation change stick-arrowhead to open arrowhead

  • Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.4

  • Key: UML22-717
  • Legacy Issue Number: 8209
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraints

  • Reported: UML 2.0 — Tue, 1 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6452 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.48

  • Key: UML22-703
  • Legacy Issue Number: 8192
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 241 shows the generalization of UnmarshallAction to be Actions (from Basic). Correct either figure or text. Association object:inputPin[1..1] subsets nput from Input and association result:OutputPin[1..1] subsets output from Output according to fig 241. Add OCL notation to constraints

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL is duplicate with 6346.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.46

  • Key: UML22-701
  • Legacy Issue Number: 8190
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraint [2]. My guess would be self.object.type=self.classifier.type (That's pure guess since I know very little OCL.) Delete header Examples as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6452, 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.45

  • Key: UML22-700
  • Legacy Issue Number: 8189
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL Notation to Constraints

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6452 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.52

  • Key: UML22-707
  • Legacy Issue Number: 8196
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete Examples header as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.51

  • Key: UML22-706
  • Legacy Issue Number: 8195
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete Examples header as there are none

  • Reported: UML 2.0 — Sun, 9 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.50

  • Key: UML22-705
  • Legacy Issue Number: 8194
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association value:ValueSpecification[1] does not express a specialization in the figure. Please correct either text or figure. Add OCL notation to constraints

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL request is duplicate of 6346.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.44

  • Key: UML22-699
  • Legacy Issue Number: 8188
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association target:inputPin[1] subsets input from Input according to fig 144. Add OCL notation to the constraints. Semantics [1] change "his" to "the".

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    OCL is duplicate with 6346.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.49

  • Key: UML22-704
  • Legacy Issue Number: 8193
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add OCL notation to constraints. Delete Examples header as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 6452, 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.47

  • Key: UML22-702
  • Legacy Issue Number: 8191
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Delete header Example as there are none

  • Reported: UML 2.0 — Mon, 31 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8155 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

unclear statement

  • Key: UML22-596
  • Legacy Issue Number: 8064
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The last part of the following statement makes no sense to me: "Understandability. While increasing the precision and conciseness, the specification techniques should also improve the readability of the specification. For this reason a less than strict formalism is applied, since a strict formalism formal technigues" It appears that part of the sentence got left out as there is no period

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    There is a word missing in this text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Text references Figure 8 and the correct figure number is 6

  • Key: UML22-595
  • Legacy Issue Number: 8063
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Text references Figure 8 and the correct figure number is 6

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    This is indeed an incorrect figure reference.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section is badly worded and does not make a lot of sense

  • Key: UML22-599
  • Legacy Issue Number: 8067
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Section is badly worded and does not make a lot of sense. I interpreted it as "Often an informal convention is used to show (a part of) a construct, e.g., the name of a class should be centered and in bold."

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

clarify what a directed association is

  • Key: UML22-598
  • Legacy Issue Number: 8066
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    am not an expert on UML and am reading this to learn about it. Could you please clarify what a directed association is. A search of the document does not yield any other reference to this term.

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Terminology Issue

  • Key: UML22-593
  • Legacy Issue Number: 8042
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    When we build a state machine (nee State chart diagram) to define the behavior of a Dog, say, each dog instance has its own state.

    In other words, each copy of the state machine diagram has it's own state. What is the official term for each-copy-of-the-state-machine, the entity that has state. We need to be able to say "The <state machine thing> for Fido is in the state 'Barking'" and "The <state machine thing> for Rover is in the state Sleeping".

  • Reported: UML 1.4.2 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Resolution: The submitter does not raise an issue against the specification, but asks a question for clarification. Such terminology might be useful in explaining the semantics, but is not required for the specification. Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

typing error in the statement :unrestricted ?

  • Key: UML22-600
  • Legacy Issue Number: 8068
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    believe there is a typing error in the statement :unrestricted: Indicated that there is no restriction no [should be to?] adding new values, changing a value, or removing values to an occurrence of a StructuralFeature

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

extra word in the last sentence of the paragraph under Attributes

  • Key: UML22-597
  • Legacy Issue Number: 8065
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    believe that there is an extra word in the last sentence of the paragraph under Attributes. "If the mulitplicity of the attribute is supressed if it is '1' (default in UML)." I believe the sentence should read "The multipliticy of the attribute is supressed if is is '1' (default in UML)."

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

section 9.20.2 VisibilityKind lists two types of visibility

  • Key: UML22-594
  • Legacy Issue Number: 8062
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In section 9.20.2 VisibilityKind lists two types of visibility-Public and Private. Yet the glossary (page 19) and Figure 80 on page 119 (and many other figures) list threePublic, Private, and Protected. Version 1.5 also defined a fourth type of visibility-Package. Please clarify and or enhance the definition of VisibilityKind in 9.20.2 to explain the differences between the glossary and the Figure.

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

StructuredActivityNode specialized multiplicity

  • Key: UML22-592
  • Legacy Issue Number: 8041
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of StructuredActivityNode still says "This constraint is modeled as a specialized multiplicity from ActivityNode and ActivityEdge to StructuredActivityNode". The FTF changed the metamodel for this to not use specialized multiplicity.

  • Reported: UML 2.0 — Thu, 30 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What happened to real numbers

  • Key: UML22-601
  • Legacy Issue Number: 8069
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The elements for numbers you define in the Literals package are LiteralInteger and LiteralUnlimitedNatural. What happened to real numbers? Natural numbers do no include decimals.

  • Reported: UML 2.0 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12

  • Key: UML22-724
  • Legacy Issue Number: 8218
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Use of the term edge(s)is confusing without the appropriate qualifier - "Control" or "Object." Suggest changing edge or edges to ControlEdge(s) and/or ObjectEdge(s) as appropriate

  • Reported: UML 2.0 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.4

  • Key: UML22-662
  • Legacy Issue Number: 8148
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association fromAction:Action[1] missing the specialization or subsets statement shown in fig. 159. Add OCL statements to constraints. Fig. 161 shows the association +action between i2:ActionInputPin and s1:ReadSetAction and between i4:ActionInputPin and s2:ReadSetAction but this is not an association defined for ActionInputPin in the text or shown on fig. 159. Either correct +action association to +fromAction or add +action as an association of ActionInputPin. I may be totally incorrect but shouldn't there be some link or association from the classifier bar:Signal?

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See revised text. The rest is duplicate with 6452.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.3

  • Key: UML22-661
  • Legacy Issue Number: 8147
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 142 does not list Dependencies as a generalization. Associations /input:InputPin[*] and /output:OutputPin[*] need the specialization or subset statement as shown in fig. 143 Association /context:Classifier[1] does not agree with multiplicity in fig. 142 Delete headers Examples and Rationale as these sections are blank

  • Reported: UML 2.0 — Thu, 27 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.10

  • Key: UML22-655
  • Legacy Issue Number: 8140
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig 124 shows that the Association utilizedElement:PackageableElement also subsets target

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.9

  • Key: UML22-654
  • Legacy Issue Number: 8139
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Constraints are not shown on fig 126 as other constraints have been shown on other figures. Under Notation, should "instance" be "instance specification?"

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.4

  • Key: UML22-657
  • Legacy Issue Number: 8143
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Table 8 Node Reference says Node has keyword options <<device>> and <<execution environment>> but these are not mentioned in the Node section nor are they diagrammed anywhere.

  • Reported: UML 1.4.2 — Wed, 26 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.6

  • Key: UML22-652
  • Legacy Issue Number: 8137
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig 126 does not show all generalizations listed; text for the Association deployment:Deployment[*] does not mention that the association specializes ownedElement as shown in the figure

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.11

  • Key: UML22-656
  • Legacy Issue Number: 8141
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The specialization of the association nestedNode:Node is not shown in fig. 125

  • Reported: UML 2.0 — Wed, 26 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    There is no nestedClassifier association end that applies to this case.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.4

  • Key: UML22-650
  • Legacy Issue Number: 8135
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The Associations for the Nodes Package text do not agree with Fig. 126.

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.8

  • Key: UML22-653
  • Legacy Issue Number: 8138
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I don't believe that fig 125 shows the composite association between nodes and ExecutionEnvironment as expressed in Semantics. Typo - add ending guillemets to <<J2EE container.

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.3

  • Key: UML22-649
  • Legacy Issue Number: 8134
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Kernel generalization is not shown in fig. 126

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.3.5

  • Key: UML22-651
  • Legacy Issue Number: 8136
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Generalization, Association, and Constraints in text don't agree with fig. 127

  • Reported: UML 2.0 — Tue, 25 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see ptc/2006-04-01 page148/149

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ReduceAction

  • Key: UML22-565
  • Legacy Issue Number: 7977
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    It has come to my attention that the removal of the ReduceAction (fair
    enough) requires the use of a variable (a very bad idea) to construct an
    alternative specification.

    To do something like Reduce(<data expression>, Add) in UML 1.5, you
    would have to say:

    • An activity/structure node with variable Sum.
    • The expansion region takes the collection as input and has no
      output. In this case, the output collection will have only one
      element in it.
    • In the region, edges coming from/going to the inputs/outputs take
      elements from the input collections and put elements in the output
      collections.
    • The region uses CallOperationAction with operation timeofLastCall to
      get the time and CallBehaviorAction on the (primitive)
      FunctionBehavior for addition and updates the variable.
    • After the region is complete, the variable has the sum in it.

    The 1.5 Action Model included variables so that those who "needed" them
    could have them. However, the introduction of variables changes the
    static-single-assignemnt nature of the language and would now require
    data-flow analysis of a developer model to work out what is happening.
    Before all we had to do was scan for Variable Actions and reject the
    developer model so proposed.

    In other words, those of us in the translation business did not need
    variables, and we could ignore those models that used them. Now we're
    stuck.

    Topic: ReduceAction

    UML 1.5 had ReduceAction, which repeatedly applied a function pairwise
    to elements of a collection until only only element is left. It did not
    constrain order or concurrency of application. It was replaced with
    ExpansionRegion UML 2, which requires commitment to order and
    concurrency.

  • Reported: UML 1.4.2 — Tue, 14 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Corrections to issue description:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Incorrect statement on port visibility

  • Key: UML22-564
  • Legacy Issue Number: 7973
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The updated UML spec p162 states:

    "UML Superstructure 2.0 Draft Adopted Specification

    A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. If the port
    symbol is placed overlapping the boundary of the rectangle symbol denoting that classifier this port is exposed (i.e., its
    visibility is public). If the port is shown inside the rectangle symbol, then the port is hidden and its visibility is as specified (it
    is protected by default)."

    This text was supposed to be removed by the FTF – the placement of the port is independent of its visibility. Port placement is merely a question of graphical convenience. Their visibility is indicated by the usual means as for all other properties (+, -, and #).

  • Reported: UML 1.4.2 — Fri, 10 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.7

  • Key: UML22-566
  • Legacy Issue Number: 7986
  • Status: closed  
  • Source: SINTEF ( Richard Sanders)
  • Summary:

    ... of an object. (missing period) ... destruction of the instance -> of the object ... that this instanceowns -> instance owns

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor error in BNF of an message argument

  • Key: UML22-563
  • Legacy Issue Number: 7970
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Minor error in BNF of an message argument: Instead <argument> ::= (<[parameter-name> ‘=’] write <argument> ::= ([<parameter-name> ‘=’]

  • Reported: UML 2.0 — Tue, 7 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.14

  • Key: UML22-568
  • Legacy Issue Number: 7988
  • Status: closed  
  • Source: SINTEF ( Richard Sanders)
  • Summary:

    ... <interactionconstraint> -> <InteractionConstraint> ... in Figure 335 -> Figure 335 or 352

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.16

  • Key: UML22-569
  • Legacy Issue Number: 7989
  • Status: closed  
  • Source: SINTEF ( Richard Sanders)
  • Summary:

    ... and InteractionOperand represent -> represents

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

StateInvariants/Continuations

  • Key: UML22-571
  • Legacy Issue Number: 7995
  • Status: closed  
  • Source: SINTEF ICT ( Richard Torbjørn Sanders)
  • Summary:

    StateInvariants/Continuations: add to figure a Continuation (e.g. Idle) that spans :Y and an additional lifeline :X

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Table 14

  • Key: UML22-570
  • Legacy Issue Number: 7990
  • Status: closed  
  • Source: SINTEF ( Richard Sanders)
  • Summary:

    Bottom of page: Node type "Stop" should be "Destruction event"

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.13

  • Key: UML22-567
  • Legacy Issue Number: 7987
  • Status: closed  
  • Source: SINTEF ( Richard Sanders)
  • Summary:

    ... needs not be the whole -> need not be

  • Reported: UML 2.0 — Sat, 18 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DataType attributes UML 2 Super (ptc/04-10-02)

  • Key: UML22-553
  • Legacy Issue Number: 7939
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    On Figure 13, DataType::ownedAttribute is specified as ordered but in the
    associations section on page 59, it is not specified as ordered.

  • Reported: UML 1.4.2 — Fri, 19 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.2 superstructure section 9.3.11 page 184: Port.isService

  • Key: UML22-458
  • Legacy Issue Number: 13083
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The definition of Port.isService appears to be redundant with the concept of public/private visibility. Is it valid for an isService=true Port to be private, or for an isService=false Port to be public? What about protected and package visibility for Ports?

  • Reported: UML 2.1.2 — Mon, 17 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    From Bran Selic:
    Please note that isService=false is intended for modeling so-called SPPs (service provision points) in UML-RT. SPPs are ports that are used by the implementation of a structured class to access run-time services of the underlying support layers. In contrast to ports for which isService=true, SPPs are implementation specific – in other words, they are not part of the services that a component publishes to its clients. On the other hand, they must be public ports or you will not be able to connect to them from the outside.

    It is a subtle distinction but an important one. The notion of implementation-specific interfaces is one that has, unfortunately, been generally missed in programming languages. It is a key element of layering.

    If you remove this capability, you will certainly invalidate a lot of models based on this notion.

    Revised Text:
    None.

    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Could you please clarify what does the UML2 specifications intend for "provided port" and "required port"?

  • Key: UML22-456
  • Legacy Issue Number: 12985
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Could you please clarify what does the UML2 specifications intend for "provided port" and "required port"? Intuitively, it seems that a port could provide (respectively require) the interface which types it. This is in contradiction with the UML2 definition of port. Nevertheless, I belive a port should be able to require the interface tpeing it: the type of a port and its role (provide/require) should be decoupled. This is basically what the graphical front-end of Rhapsody does. It is also the same approach used for SysML ports, where direction is decoupled from the type of the port.

  • Reported: UML 2.1.2 — Thu, 23 Oct 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The idea of decoupling the type from the interface is addressed by 13080. The clarification is addressed here by the text revisions below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency in Superstructure 2.2 p. 550

  • Key: UML22-455
  • Legacy Issue Number: 12915
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    There seems to be an inconsistency in the spec.

    Supersturcture v2.2 ptc/2008-05-xx
    p 550

    The spec mentions:
    A state with isSimple=true is said to be a simple state. A simple state does not have any regions **and it does not refer to any submachine state machine.**

    It also says in the constraints section ( constraint [4] ) :
    A simple state is a state without any regions. isSimple = region.isEmpty()

    The constraint seems to be missing the part about not refering to any submachine state machine.

  • Reported: UML 2.1.2 — Tue, 7 Oct 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The submitter is correct. Add the missing constraint to the isSimple() operation of State by adding that the
    isSubmachineState attribute has to be false

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InstanceSpecifications

  • Key: UML22-454
  • Legacy Issue Number: 12912
  • Status: closed  
  • Source: University of Kassel ( Carsten Reckord)
  • Summary:

    To better express links with InstanceSpecifications, InstanceSpecification should be able to reference Slots owned by other InstanceSpecifications similar to an Association's memberEnd. Currently, when modelling an object diagram with a link like the one in fig. 7.54 on p.85, the specification is unclear on which of the involved InstanceSpecifications (Don, Josh, assoc) should own which Slots (father, son). Assuming that the involved association ends are ownedAttributes of the respective classes (Person), one would expect the object specifications (Don, Josh) to have Slots for these ends. Similarly one would expect the link InstanceSpecification to somehow reference its ends. Since a Slot can only belong to one InstanceSpecification, this is currently only possible by duplicating Slots and InstanceValues between object and link InstanceSpecifications (at least that is how e.g. Rational does it). This leads to two problems. First there is of course a lot of redundancy and chances for inconsistency. Second, and more importantly, there is no easy way to navigate from an object InstanceSpecification to the "connected" link InstanceSpecifications. On type level, an association can reference member ends that are owned by other classifiers. For the sake of consistency and simplicity, we would suggest something similar on the instance level for the InstanceSpecification-Slot relationship, i.e. a memberSlot referencing Slots owned by other InstanceSpecifications (maybe in a specialized LinkSpecification). I have created some diagrams to better illustrate the problem, albeit for a different example: - The example: http://www.reckord.de/uml/example.png - What it currently looks like on the meta level: http://www.reckord.de/uml/example-metaobjects.png - What it could look like: http://www.reckord.de/uml/example-meta-fixed.png

  • Reported: UML 2.1.2 — Mon, 6 Oct 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 9961

  • Updated: Fri, 6 Mar 2015 20:58 GMT

specificMachine association should be changed to be type StateMachine

  • Key: UML22-453
  • Legacy Issue Number: 12855
  • Status: closed  
  • Source: NASA ( Alexander Murray)
  • Summary:

    The specificMachine association of metaclass ProtocolConformance is of type ProtocolStateMachine, which would seem to prohibit the specificMachine from being a BehaviorStateMachines::StateMachine. However, the text sections of section 15.3.5, including the Description and Semantics sections, are very clear that the conforming StateMachine may be a BehavioralStateMachine::StateMachine, which make sense. So the specificMachine association should be changed to be type StateMachine. Also, Figure 15.5 should be similarly changed.

  • Reported: UML 2.1.2 — Wed, 17 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The protocol conformance relationship was explicitly intended to model relationships between protocol state machines
    (this is clearly stated in the spec). It is unclear what would be the precise meaning of that type of relationship between
    different kinds of state machines, but, whatever it might be, it is likely to be complex, dealing with issues such as
    behavioral equivalence. This is still an open research topic with many different approaches and not something one
    should standardize as yet.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p269-p270 Constraint

  • Key: UML22-452
  • Legacy Issue Number: 12851
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    [2] The type and ordering of the result output pin are the same as the type and ordering of the open association end.
    let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

    "AssociationEnd" -> "Propertye"

    [3] The multiplicity of the open association end must be compatible with the multiplicity of the result output pin.
    270 UML Superstructure Specification, v2.2
    let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

    "AssociationEnd" -> "Propertye"

    [4] The open end must be navigable.
    let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

    "AssociationEnd" -> "Propertye"

    [5] Visibility of the open end must allow access to the object performing the action.
    let host : Classifier = self.context in
    let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

    "AssociationEnd" -> "Propertye"

  • Reported: UML 2.1.2 — Fri, 12 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 6462 (resolved in UML 2.3) for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

operation allConnections

  • Key: UML22-451
  • Legacy Issue Number: 12850
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    1)>[1] The operation allConnections results in the set of all AssociationEnds of the Association.

    "AssociationEnds" is "Properties", isn't it?

  • Reported: UML 2.1.2 — Fri, 12 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

TYPO p.54 Additional Operations

  • Key: UML22-450
  • Legacy Issue Number: 12848
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    [3] The query allParents() gives all of the direct and indirect
    ancestors of a generalized Classifier.
    Classifier::allParents(): Set(Classifier);
    allParents = self.parents()>union(self.parents()>collect(p |
    p.allParents())

    It seems to be lack of the last parenthesis.

  • Reported: UML 2.1.2 — Wed, 10 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Indeed, there is a missing closing parenthesis.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Classifier has association end "attribute"

  • Key: UML22-446
  • Legacy Issue Number: 12844
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    Classifier has association end "attribute". The association should have the opposite
    side of "attribute". Such association end should be "Classifier::attribute".
    In the case of "Class", "Datatype", "StructuredClassider" (however, there is a typo),
    "Signal", such element have "Classifier::attribute" association end.
    However, Interface and Artifact don't have such association end.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

Typo 9.3.13 p190

  • Key: UML22-445
  • Legacy Issue Number: 12843
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    ownedAttribute : Property[0..*]
    References the properties owned by the classifier. (Substes StructuredClassifier:: role,
    Classifier.attribute...
    ~~~~~~~~~~~~~~~~~~~~
    Classifier::attribute?

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Metaclass Property is denoted in Interfaces Package on p.36

  • Key: UML22-449
  • Legacy Issue Number: 12847
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    However, according to the class description for Property,
    Property is "from Kernel and AssociationClass".
    Property is defined in Interfaces Package.
    Therefore, it seems Property is "from Kernel, Interfaces and AssociationClass".

  • Reported: UML 2.1.2 — Wed, 10 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

7.3.33 p100

  • Key: UML22-448
  • Legacy Issue Number: 12846
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    "clientDependency: Dependency[*]
    Indicates the dependencies that reference the client."

    This explanations is described in "Attribute" clause, not Associations" of NemedElment.
    It seems to be in incorrect clause.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

Property 7.3.44 p125

  • Key: UML22-447
  • Legacy Issue Number: 12845
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    "A property related to a classifier by ownedAttribute represents an attribute..."
    and in its semantics
    "When a property is owned by a classifier other than an association via ownedAttribute, then it represents an attribute of
    the class or data type."

    However, in the case of "StructuredClassifier", "Signal", "Artifact",
    "Interface".
    "attribute" is not necessary

    The specification should modified as followings.

    p125 L7:
    "A property related to a classifier by attribute represents an attribute,"

    and

    p128 L17
    "When a property is owned by a classifier other than an association, then it represents an attribute of the classifier."

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The issue is not correct. All attributes are in fact owned via a property called ownedAttribute, different in each case,
    but this is true for all subclasses of Classifier including Interface, Signal, Artifact, etc. So the text is correct.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.3.44 additional operation P128

  • Key: UML22-444
  • Legacy Issue Number: 12842
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    [4]The query isAttribute() is true if the Property is defined as an attribute of
    some classifier.
    context Property::isAttribute(p : Property) : Boolean
    post : result = Classifier.allInstances->exists(C|c.attribute->includes(p))

    This OCL means there is at least one element of Property.
    Then, it is better to represent as "not classifier->isEmpty, not "Classifer.allinstances"
    like opertation [3]. It is better to represent similar style in a same block.

    This issue relates to aleady mentioned issue(Issue 11120). However, it is not exactly same.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 11120

  • Updated: Fri, 6 Mar 2015 20:58 GMT

first paragraph of section 7.8 UML kernel

  • Key: UML22-399
  • Legacy Issue Number: 12436
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    The first paragraph of section 7.8 suggests that the UML kernel is the merge of Core::Abstractions packages. To obtain Classifier in the UML kernel, we would have to merge Classifiers, Super and Generalizations from Core::Abstractions. How is this possible given that: a) there are no generalization relationships among Classifier metaclasses in these Abstractions packages b) there are two matching operations:

    {Super,Generalizations}

    ::Classifier::parents (a) means that Generalizations::Classifier::parents cannot redefine Super::Classifier::parents. Even if there were a generalization, the resulting merged model would be ill-formed because it would include a generalization self-loop. (b) means that the merge is ill-formed because it violates constraint #4 defined in the general package merge rules in 11.9.3 (p. 164) POSSIBLE WORKAROUND: - split Core::Abstractions::Super in two packages: Super and SuperParents which only defines Classifier::parents - ditto for Core::Abstractions::Generalizations - if Super is to be merged but Generalizations isn't, then merge SuperParents as well. - if both Super and Generalizations are to be merged, then merge GeneralizationsParent but not SuperParents This is a kludge but that's the only short-term workaround I can find for this bug at this time.

  • Reported: UML 2.1.2 — Sun, 11 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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: 7.3.7 and 8.3.1

  • Key: UML22-398
  • Legacy Issue Number: 12432
  • Status: closed  
  • Source: THALES ( Sebastien Madelenat)
  • Summary:

    page 50, the "nestedClassifier" association of Class is described like this: "References all the Classifiers that are defined (nested) within the Class. Subsets Element::ownedMember" page 148, the "packagedElement" association of Component is described like this: packagedElement: PackageableElement [*] "The set of PackageableElements that a Component owns. In the namespace of a component, all model elements that are involved in or related to its definition may be owned or imported explicitly. These may include e.g., Classes, Interfaces, Components, Packages, Use cases, Dependencies (e.g., mappings), and Artifacts. Subsets Namespace::ownedMember." This means a Class may own a Component and this Component may own a Package. I wonder what a Class owning (transitively) a Package could mean.

  • Reported: UML 2.1.2 — Fri, 9 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is one example of the unintended consequences of Component inheriting from Class. We may observe a related consequence, that it is possible for a Component to own another Component in two ways: as a nestedClassifier, and as a packagedElement. There is no distinction, notationally or otherwise, between these two modes of ownership.
    We can resolve these by adding two constraints to Component:
    · A Component's nestedClassifier collection is always empty.
    · If a Component is nested in a Class, then its packagedElement collection is empty.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Port

  • Key: UML22-401
  • Legacy Issue Number: 12492
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    for Port, there is a constraint that say :

    [1] The required interfaces of a port must be provided by elements to which the port is connected.

    I believe that ports are connected by delegation connector, this constraint may not be checked!

    Am I right?

  • Reported: UML 2.1.2 — Thu, 15 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    You are right, and this constraint is more correctly covered by a revised constraint [1] in chapter 8.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 14 Interaction

  • Key: UML22-400
  • Legacy Issue Number: 12455
  • Status: closed  
  • Source: Research Group Software Construction, RWTH Aachen ( Alexander Nyßen)
  • Summary:

    As it is intended by the current specification, an Interaction may be modeled independent of any BehavioredClassifier, which owns it. This would e.g. allow to use Interactions to model communication between analysis objects at a very early analysis stage, where no classes have been designed yet. The intention is manifested in the specification by allowing that a Lifeline or Messages does not have to specify a Property (Multiplicity of 0..1 of Lifelines->represents) or a Connector (Multiplicity of 0..1 of Message->connector) respectively (and that an Interaction does not have to be owned by a BehavioredClassifier). However, the restriction that every OccurrenceSpecification, and as such also every MessageOccurenceSpecification has to be associated with an event (compare Figure 14.5 on page 462) prevents that an Interaction may be used in above described manner. The reason for this is is as follows: 1) As the absense of a MessageEnd has another semantics (the MessageKind is inferred from it), in above described scenario, MessageEnds should indeed be specified (a complete message would be the only appropriate kind to model communication between objects as in above described scenario) 2) Because of above described multiplicity constraint, the MessageOccurenceSpecifications serving as sendEvent and receiveEvent of the message have to refer to some SendSignalEvent/ReceiveSignalEvent or SendOperationEvent/ReceiveOperationEvent respectively. 3) Those events in turn require to specify a Signal or Operation (see Figure 14.2 on page 459). 4) The Signal or Operation would have to be owned by some Classifier. There is however no Classifier in above described scenario, with exception of the Interaction itself (adding the Signals or Operations to the Interaction itself, would however require that all Signals and Operations are named unique, which is inappropriate). I would thus propose to change the specification, so that MessageOccurenceSpecifications (or OccurenceSpecifications) may, but do not have to specify an event (i.e. change multiplicity from 1 to 0..1).

  • Reported: UML 2.1.2 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Changing this cardinality in the metamodel is a breaking change, and is unnessary.
    It seems that, if you are modeling the sending of a message, then you are modeling that something is being sent. This
    .something. can be modeled as a signal, even if, at an early stage of analysis, this is just a placeholder for more detail
    to be added later.
    There are no constraints requiring that a message signature refer to an operation or signal reception defined for the
    type of the ConnectableElement associated with a Lifeline.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.11/Notation

  • Key: UML22-389
  • Legacy Issue Number: 12380
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    In chapter 15.3.12 (p. 568) the keyword "final" is informally introduced for states: "the states VerifyCard, OutOfService, and VerifyTransaction in the ATM state machine in Figure 15.42 have been specified as

    {final}" This should be mentioned in capter 15.3.11 (State (from BehaviorStateMachines, ProtocolStateMachines)) in section "Notation". Suggestion: "A state that is a leaf (i.e. isLeaf=TURE) can be shown using the keyword {final}

    after or below the name of the State."

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Agreed. The “final” keyword should be explained in the section describing the notation for state machines
    and not in the examples paragraph, it should also be added to the list of keywords in Table C.1 in the
    appendix

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 11.3.25 gives the definition of MultiplicityExpression::isConsisten

  • Key: UML22-388
  • Legacy Issue Number: 12379
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Section 11.3.25 gives the definition of MultiplicityElement::compatibleWith as: compatibleWith(other) = Integer.allInstances()-> forAll(i : Integer | self.includesCardinality implies other.includesCardinality) While technically correct, this may be a little impractical for any OCL interpreting tool. I think an alternative, that simply uses the upper and lower bounds, would be: compatibleWith(other) = other.includesMultiplicity(self)

  • Reported: UML 2.1.2 — Tue, 15 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

interpreting InstanceSpecification

  • Key: UML22-396
  • Legacy Issue Number: 12427
  • Status: closed  
  • Source: Dell Technologies ( Mr. George Ericson)
  • Summary:

    Various readers are interpreting InstanceSpecification differently. One interpretation is that a particular InstanceSpecification specifies a particular instance. A second interpretation is that a particular InstanceSpecification may be used to specify more than one instance. I prefer the second interpretation. This is supported by the Note at the bottom of page 83 that refers to "... such structures."

  • Reported: UML 2.1.2 — Fri, 2 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It is clear from this sentence: “As an InstanceSpecification may only partially determine the properties of an
    individual, there may actually be multiple individuals in the modeled system that satisfy the requirements
    of the InstanceSpecification.”
    But some of the earlier text seems to imply different - this text is changed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure showing an AssociationClass as a ternary association

  • Key: UML22-395
  • Legacy Issue Number: 12406
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Please insert a figure showing an AssociationClass that is a ternary association to make clear whether the dashed line is to be connected to a line or the diamond. (Use can re-use figure 7.21 on page 44).

  • Reported: UML 2.1.2 — Wed, 23 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 8974

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.10/Associations

  • Key: UML22-391
  • Legacy Issue Number: 12382
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    Please explain constrainedElement has to be an ordered set and not a set.

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The order of the constrainedElements may make a significant difference on the meaning of the constraint. For instance,
    a constraint on two numeric elementsmay require that one is less than the other, or a constraint on two sets may require
    one to be a subset of the other.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.3/ Changes from previous UML

  • Key: UML22-390
  • Legacy Issue Number: 12381
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    Chapter 13.3.3, section “Changes from previous UML“: “The metaattributes isLeaf and isRoot have been replaced by properties inherited from RedefinableElement.” RedefinableElement does not have the property isRoot.

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

Car dependency example

  • Key: UML22-394
  • Legacy Issue Number: 12405
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The car dependency example on page 63 of the UML Super Structure Specification appears wrong to me. The description indicates to me that the arrow should be going from the car to the carfactory not the other way around as depicted.

  • Reported: UML 2.1.2 — Wed, 23 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 11489

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.8/Generalizations

  • Key: UML22-393
  • Legacy Issue Number: 12385
  • Status: closed  
  • Source: Anonymous
  • Summary:

    ActivityNode need not specialize “NamedElement (from Kernel, Dependencies)” because is specializes ““RedefinableElement (from Kernel)” which in turn specializes “NamedElement (from Kernel, Dependencies)”.

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

qualifiers

  • Key: UML22-387
  • Legacy Issue Number: 12369
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Are qualifiers displayed at opposite end of association than role name (or multiplicity) or near the role name (or multiplicity)?

    E.g. composition diamond is displayed at opposite end, multiplicity value – at the same end. How about qualifiers?

    UML 2.1.2 page 124:

    qualifier : Property [*] An optional list of ordered qualifier attributes for the end.

    Notation (page 128):

    The qualifier is attached to the source end of the association.

    What is the “source of the association” ???

    Look at figure from UML spec (first sample):

    Are these qualifiers owned in association end typed by Bank or Person?

  • Reported: UML 2.1.2 — Thu, 20 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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 StateMachines: doActivity and internal transitions

  • Key: UML22-397
  • Legacy Issue Number: 12431
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    What happens with the do activity if a internal transition fires? It is not mentioned in the specification.

  • Reported: UML 2.1.2 — Wed, 7 May 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Since the state is not exited, the do activity is unaffected by the firing of the internal transition.
    Add a clarifying statement to make this point explicit

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.10/Associations - insert reference

  • Key: UML22-392
  • Legacy Issue Number: 12384
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    “Certain kinds of constraints (such as an association “xor” constraint) are predefined in UML” Please insert a reference to the document containing the predefined constraints

  • Reported: UML 2.1.2 — Wed, 16 Apr 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 9617 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unspecified constraint [1] on ActivityNode

  • Key: UML22-432
  • Legacy Issue Number: 12790
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on ActivityNode (12.3.8) is unspecified:

    [1] Activity nodes can only be owned by activities or groups.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] Activity nodes can only be owned by activities or groups.
    self.activity=self.owner xor self.inGroup->includes(self.owner.oclAsType(ActivityGroup))

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

constraint [4] on AcceptEventAction and unordered result:OutputPin property

  • Key: UML22-431
  • Legacy Issue Number: 12789
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on AcceptEventAction (11.3.2) is unspecified:

    [4] If isUnmarshalled is true, there must be exactly one trigger for events of type SignalEvent. The number of result output
    pins must be the same as the number of attributes of the signal. The type and ordering of each result output pin must be the
    same as the corresponding attribute of the signal. The multiplicity of each result output pin must be compatible with the
    multiplicity of the corresponding attribute.

    This constraint implicitly requires that the AcceptEventAction.result property should be ordered to enable order-sensitive comparison with corresponding properties in Signal.ownedAttribute.

    • result: OutputPin [0..*]
    Pins holding the received event objects or their attributes. Event objects may be copied in transmission, so identity
    might not be preserved.

    {Subsets Action::output}

    The
    [4a] If isUnmarshalled is true, there must be exactly one trigger for events of type SignalEvent.
    [4b] The number of result output pins must be the same as the number of attributes of the signal.
    [4c] The type and ordering of each result output pin must be the same as the corresponding attribute of the signal.
    [4d] The multiplicity of each result output pin must be compatible with the multiplicity of the corresponding attribute.
    self.isUnmarshall implies
    (self.trigger->size() = 1 and let e:Event = self.trigger.event->asSequence()->first() in
    e.oclIsKindOf(SignalEvent) and
    let s:Signal = e.oclAsType(SignalEvent).signal in
    Set

    {1..s.ownedAttribute->size()}->forAll(i|
    let ai:Property=s.ownedAttribute->at in
    let ri:OutputPin= self.result->asOrderedSet()->at in
    ai.type = ri.type and ri.lower <= ai.lower and ri.upper >= ri.upper))


    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the result property to the following:

    • result: OutputPin [0..*]
    Pins holding the received event objects or their attributes. Event objects may be copied in transmission, so identity
    might not be preserved. This association end is ordered. {Subsets Action::output}

    Change the specification of the constraint to the following:

    [4] If isUnmarshalled is true, there must be exactly one trigger for events of type SignalEvent. The number of result output
    pins must be the same as the number of attributes of the signal. The type and ordering of each result output pin must be the
    same as the corresponding attribute of the signal. The multiplicity of each result output pin must be compatible with the
    multiplicity of the corresponding attribute.

    (self.trigger->size() = 1 and let e:Event = self.trigger.event->asSequence()->first() in
    e.oclIsKindOf(SignalEvent) and
    let s:Signal = e.oclAsType(SignalEvent).signal in
    Set{1..s.ownedAttribute->size()}

    ->forAll(i|
    let ai:Property=s.ownedAttribute->at in
    let ri:OutputPin= self.result->at in
    ai.type = ri.type and ri.lower <= ai.lower and ri.upper >= ri.upper))

    Note: if the result property is not ordered, this constraint can be approximated in the following manner:

    (self.trigger->size() = 1 and let e:Event = self.trigger.event->asSequence()->first() in
    e.oclIsKindOf(SignalEvent) and
    let s:Signal = e.oclAsType(SignalEvent).signal in
    Set

    {1..s.ownedAttribute->size()}

    ->forAll(i|
    let ai:Property=s.ownedAttribute->at in
    let ri:OutputPin= self.result->asOrderedSet()->at in
    ai.type = ri.type and ri.lower <= ai.lower and ri.upper >= ri.upper))

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 8702

  • Updated: Fri, 6 Mar 2015 20:58 GMT

figure 13.12

  • Key: UML22-434
  • Legacy Issue Number: 12792
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    In the latest 2.2 version of the UML spec, there was a change for issue : 11409 - redirect TimeEvent::when to TimeExpression (from ValueSpecification).
    In the resolution to that issue, figure 13.13 (p427) was properly updated but it looks like figure 13.12 has a problem in that the association from TimeEvent should go to TimeExpression

  • Reported: UML 2.1.2 — Tue, 19 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    At first it seems like this would be any easy resolution - just update Figure 13.12. The problem is that the Event classes in Figure 13.12, including TimeEvent, are in the CommonBehaviors::Communications package, which is merged in at L1, while TimeExpression is in CommonBehaviors::SimpleTime, which is merged in at L2. Thus, having TimeEvent associated with TimeExpression - which is actually the case in the metamodel - causes a problem in the construction of L1 (which causes issues with the generation of XMI for L1).
    Now, one possibility would be to make the TimeEvent class in SimpleTime a merge increment. But the merging of typed elements has the constraint (see 7.3.40):
    "Matching typed elements (e.g., Properties, Parameters) must have conforming types. For types that are classes or data types, a conforming type is either the same type or a common supertype. For all other cases, conformance means that the types must be the same."
    While not entirely clear, the implication is that the resulting type is the common supertype. In this case, TimeEvent::when has type ValueSpecification in Communications and type TimeExpression, a subclass of ValueSpecification, in SimpleTime. The common superclass is thus ValueSpecification - but if you end up with TimeEvent::when having type ValueSpecification in the merged L2, then there isn't much point in typing it as TimeExpression in SimpleTime!
    Another possibility would be to leave the type of TimeEvent::when as ValueSpecification, which would allow a TimeExpression to be used when SimpleTime is included at L3. But this was explicitly changed in the UML 2.2 RTF, indicating a strong desire that the type of TimeEvent::when be TimeExpression (which does make some sense).
    It also doesn't seem to be a good idea to merge SimpleTime into L1 instead of L2, just to be able to have TimeExpression available for TimeEvent.
    So, the proposed resolution is that TimeEvent be moved into SimpleTime. This means that time events would only be allowed at L2, not L1. But since state machines aren't included until L2 and accept event actions not until L3, it seems unlikely that this would be a real problem.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unspecified constraint [1] on ActivityNode (StructuredActivities)

  • Key: UML22-433
  • Legacy Issue Number: 12791
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on Activity (12.3.8) is unspecified:

    [1] Activity nodes may be owned by at most one structured node.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] Activity nodes may be owned by at most one structured node.
    self.inStructuredNode->notEmpty() implies (self.inStructuredNode.oclAsType(ActivityGroup)->includesAll(self.inGroup)
    and self.inStructuredNode.oclAsType(Element)->includes(self.owner))

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification on use of Profiles.

  • Key: UML22-436
  • Legacy Issue Number: 12833
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    would like to get some clarification on the use of Profiles.

    Although it does not explicitly state this in the UML superstructure specification, there seems to be an implication that only Profiles should actually own Stereotype. The fact that Stereotype can be owned by any Package seems to be an unintended side effect of inheritance. Is it true that the only feature intended to own a Stereotype is Profile::ownedStereotype ?

    If it is true that only Profile can own a Stereotype, then it makes working with profiles with many stereotypes somewhat unruly (consider having 50 stereotypes). It would be nice to be able to group stereotypes within nested packages under a profile.

    Nesting profiles within profiles does not seem like an appropriate solution since: in order to satisfy constraint [2] in 18.3.6 the nested profile would also have to reference a metamodel; inconvenient. And, how would users use such a profile? Would they apply each nested profile separately? This seems to raise more problems than it solves.

    Either way, I would suggest that the spec. should provide some rules or guidelines in this area.

  • Reported: UML 2.1.2 — Thu, 4 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property – Additional Operations, page 127.

  • Key: UML22-435
  • Legacy Issue Number: 12794
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Property – Additional Operations, page 127.

    In the description of “isConsistentWith” –

    [1] The query isConsistentWith() specifies, for any two Properties in a context in which redefinition is possible, whether redefinition would be logically consistent. A redefining property is consistent with a redefined property if the type of the redefining property conforms to the type of the redefined property, the multiplicity of the redefining property (if specified) is contained in the multiplicity of the redefined property, and the redefining property is derived if the redefined attribute is property.”

    The last word, “property”, should be “derived”.

  • Reported: UML 2.1.2 — Thu, 21 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.3.44 Property P128

  • Key: UML22-443
  • Legacy Issue Number: 12841
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    [3] The query isNavigable() indicates whether it is possible to navigate across the property.
    Propery::isNavigable():Boolean
    isNavigable = not classifier->isEmpty() or
    association.owningAssociation.navigableOwnedEnd->includes(self)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    "association", and "owningAssociation" are also associationend on Property.
    Then, expression "association.owningAssociation" is not appropriate.
    It seems "association" in the expression should be suppressed.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

18.3.8 Stereotype

  • Key: UML22-442
  • Legacy Issue Number: 12840
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    For example in UML, States, Transitions, Activities,
    Use cases, Components, Attributes, Dependencies, etc.
    ~~~~~~~~~~
    In UML2.2, Attribute isn't model element.
    This seems incorrect.
    This explanation is example, then, it seems term "Attributes" should be suppressed.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Problem is now out of date.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unspecified constraint [3] on Activity

  • Key: UML22-430
  • Legacy Issue Number: 12788
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on Activity (12.3.4) is unspecified:

    [3] The groups of an activity have no supergroups.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [3] The groups of an activity have no supergroups.
    self.group->forAll(superGroup->isEmpty())

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo P205 10.3.4

  • Key: UML22-440
  • Legacy Issue Number: 12838
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:


    Attribute -> Attributes

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

On the table 2.3, page 8

  • Key: UML22-439
  • Legacy Issue Number: 12836
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    Sturcute CompositeStructure::InternalStructure.
    Is it correct?
    It seems typo. "CompositeStructures"

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

On the communication diagram in Fig 6.2 (second issue)

  • Key: UML22-438
  • Legacy Issue Number: 12835
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    The sequence expression is denoted as "A1", "B1", "A3".
    According to the specification, those messages means
    asynchronous messages.
    If so, the diagram doesn't show original intention.

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

On the communication diagram in Fig 6.2 (P12)

  • Key: UML22-437
  • Legacy Issue Number: 12834
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    There are underlined lifeline.
    According to UML 2.2 specfication (chapter 14),
    lifeline label refrains from underlined notation.
    It seems these are not appropriate

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

7.3.11 DataType, P61

  • Key: UML22-441
  • Legacy Issue Number: 12839
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    "The Attributes owned by the Data Type. This is an ordered collection.
    ~~~~~~~~~~
    Subsets Classifier::attribute and Element::ownedMember."

    Attributes->attributes

  • Reported: UML 2.1.2 — Mon, 8 Sep 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Well spotted.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.1.2:18.3.5 Package (from Profiles)

  • Key: UML22-383
  • Legacy Issue Number: 12278
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    18.3.5 Package (from Profiles)

    Description

    A package can have one or more ProfileApplications to indicate which profiles have been applied.

    Because a profile is a package, it is possible to apply a profile not only to packages, but also to profiles.”

    A Profile is a subclass of InfrastructureLibrary::Constructs::Package, which cannot own ProfileApplications and so you can’t apply a profile to a profile.

  • Reported: UML 2.1.2 — Fri, 14 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Profiles does subclass Constructs::Package, but when Profiles is merged with Kernel::Classes::Package in UML compliance level L3, Package gets the ability to have applied profiles, as does its subclass, Profile. So whether a profile can be applied to a profile depends on what Profiles is merged with.

    Note that Profiles cannot stand alone, with just an import of Constructs since it defines Class as a merge increment (in order to add extensions). Profiles::Class has no ownedAttributes, so without a merge, Stereotypes would not be able to have Properties.

    However, applying a profile to a profile would extend the extensibility mechanisms of UML in non-standard ways that would not be supported by most tools. This would limit interoperability and break model interchange. So it should not be possible to apply a profile to another profile.
    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Super 2.1.2:Feature

  • Key: UML22-382
  • Legacy Issue Number: 12275
  • Status: closed  
  • Source: Mathworks ( Alan Moore)
  • Summary:

    The Semantics section for Feature says:

    “A feature represents some characteristic for its featuring classifiers; this characteristic may be of the classifier’s instances considered individually (not static), or of the classifier itself (static).

    A Feature can be a feature of multiple classifiers. The same feature cannot be static in one context but not another.”

    It seems to me that the second sentence is simply a reiteration of the description of property “/ featuringClassifier: Classifier [0..*]

    The third sentence could be expressed more usefully as a constraint.

    I’m also puzzled by the 0..* multiplicity on featuringClassifier. It would be useful if the description of Feature explained when a feature can have more than one featuring classifier.

  • Reported: UML 2.1.2 — Wed, 12 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Much of this issue refers to obsolete text. This resolution addresses its final paragraph. We discussed
    this in our face-to-face meeting in Reston in March 2013 and decided to change the multiplicity of Feature::
    featuringClassifier to 0..1 (because this is a logical consequence of the remainder of the UML spec and
    does not affect serialization), and change the wording accordingly, pointing out the special case of Properties
    used as qualifiers which have no featuringClassifier.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A final node that returns to the caller but leaves alive any parallel flow

  • Key: UML22-384
  • Legacy Issue Number: 12284
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The regular ActivityFinalNode stops all possible parallel flows in the activity before
    returning to the caller.
    There are some cases where it would be interesting to have a variant of this behavior
    which would allow returning immediately but without affecting the execution of any
    parallel flow.

    A use case for this "soft return" construct: An application process a user "search" request.
    When it founds a first set of results it returns immediately the response to the user but it
    the meantime continues looking for another set of requests to anticipate possible additional
    request from the user, without loosing the context of the user request.

    For this use case we will use the "soft return" final node to return when finding the first
    set of responses and will use a FlowFinalNode at the end of a parallel branch looking for
    additional responses.
    For sure, it is always possible to encode this use case differently, but such new kind of
    final node would allow to model the intended behavior more directly.

    Rq: What would happen if a "soft return" is reached after a "soft return" already happened:
    I guess the semantics would be to behave as a FlowFinalNode (cannot return twice).
    And what if a "regular" ActivityFinalNode is reached after a "soft return": I guess all
    existing parallel are stopped but there is no return to the caller (since already returned).

  • Reported: UML 2.1.2 — Tue, 18 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    A behavior that is initially invoked via a synchronous call does not have its own thread of control, so it would be a fundamental semantics change to somehow allow it to continue executing after returning from the call. Fortunately, however, the functionality desired by the submitter can be easily achieved using existing UML mechanisms, by first starting the activity asynchronously, either as a classifier behavior or as a standalone behavior execution. Such an executing activity can then accept client requests using an accept event action and respond to them without terminating, as the submitter envisions. The activity can even accept a synchronous call via an accept call action and reply using a reply action, without terminating. In this case, the reply action acts, in effect, as the "soft return" suggested by the submitter.
    Revised Text:
    None
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

section '10.3.12 Property (from Nodes)'

  • Key: UML22-380
  • Legacy Issue Number: 12271
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    In section '10.3.12 Property (from Nodes)', the Description states "In the metamodel, Property is a specialization of DeploymentTarget", but a corresponding generalization is not defined under 'Generalization'. Proposed resolution: Add '"DeploymentTarget (From Nodes)" on page 205' to the Generalization section of 10.3.12.

  • Reported: UML 2.1.2 — Wed, 12 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

PackageableElement (from Kernel), subsection: "Attribute"

  • Key: UML22-379
  • Legacy Issue Number: 12266
  • Status: closed  
  • Source: System ( Mehran Touhidi)
  • Summary:

    section: PackageableElement (from Kernel), subsection: "Attribute" is writen "Default value is false." that it cannt has that value because its type is VibilityKind and can only has one of its enumerated value.

  • Reported: UML 2.1.2 — Sat, 8 Mar 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 10379 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CMOF file for UML2 does not have derived Associations marked as such

  • Key: UML22-386
  • Legacy Issue Number: 12357
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    For example A_ownedMember_namespace

    Has both its ends marked with isDerived=”true” but not the Association itself.

  • Reported: UML 2.1.2 — Thu, 27 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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.3

  • Key: UML22-385
  • Legacy Issue Number: 12356
  • Status: closed  
  • Source: University Karlsruhe ( Conny Kuehne)
  • Summary:

    On Page 23 of the UML Infrastructure Spec. it is stated, that "The multiplicity of an association end is suppressed if it is ‘*’ (default in UML).". This implies that omitting to define the multipl. of an association end A means that the multiplicity of A is * (between zero and infinity). However this contradicts most books I know and some examples in the specification itself.

  • Reported: UML 2.1.2 — Wed, 26 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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 MessageOccurenceSpecification

  • Key: UML22-378
  • Legacy Issue Number: 12263
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The description of MessageOccurenceSpecification defines a property called event. It is useless, because MessageOccurenceSpecification inherits from OccurenceSpecification that already owns this property, as denoted in the figure 14.5.

  • Reported: UML 2.1.2 — Wed, 5 Mar 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 14629 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The list of literal described for the ennumeration MessageSort is not compl

  • Key: UML22-377
  • Legacy Issue Number: 12259
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The list of literal described for the ennumeration MessageSort is not complete according to it sdescription as shown in figure 14.5.

  • Reported: UML 2.1.2 — Tue, 4 Mar 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

undefined term 'Element::redefinedElement' occurs three times in standard

  • Key: UML22-381
  • Legacy Issue Number: 12273
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    The undefined term 'Element::redefinedElement' occurs three times in the standard where 'RedefinableElement::redefinedElement' is expected.

  • Reported: UML 2.1.2 — Thu, 13 Mar 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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: 7.4 figure 7.1 missing dependency

  • Key: UML22-419
  • Legacy Issue Number: 12749
  • Status: closed  
  • Source: YTCA ( Trent Lillehaugen)
  • Summary:

    The first sentence of 7.4 states: As was depicted in Figure 7.1, the Profiles package depends on the Core package, .... Figure 7.1 does not shown any dependency between the Profiles package and the Core package

  • Reported: UML 2.1.2 — Tue, 5 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

UML2: Need a better mechanism for integrating UML2 Profiles

  • Key: UML22-418
  • Legacy Issue Number: 12587
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    UML2 Superstructure specifies how to define a Profile, how Profiles can reference other Profiles through PackageImport and ElementImport, and how one stereotype could extend another through generalization/specialization. However, this is insufficient for profile integration as it results in too much coupling between profiles. What is needed is a more flexible mechanism for integrating UML2 profiles.

    For example, both UPDM and SysML are UML2 profiles. UPDM would like to reuse certain stereotypes from SysML in order to provide effective integration in cases where consumers want to use both. However, UPDM would also like to be able to stand alone in cases where SysML isn't needed. The problem is how to model the overlapping stereotypes and classes without creating coupling that would require all applications of the UPDM profile to also require an application of SysML.

    Consider a concrete example of overlap between the profiles, the stereotype ViewPoint. Both UPDM and SysML have a similar concept of ViewPoint, for similar purposes. However, each has its own specializations of ViewPoint, and possibly associations between ViewPoint and other stereotypes. There are a number of approaches for handling this overlap, but none are adequate or practical.

    1. Profile refactoring: Each profile could factor its stereotypes into packages, and arrange the navigability of its associations to decouple its stereotypes in order to support anticipated reuse. This is what UML2 did, quite unsuccessfully, with the Abstractions packages. This isn't practical because 1) no existing profiles do it, 2) it is impossible to anticipate all the possible reuse opportunities and to design a profile to support them, and 3) it is sometimes impossible to define the associations between stereotypes to ensure the necessary decoupling.

    2. Use ElementImport to select only the stereotypes you need, then subclass to minimize the coupling: This can work, but it results in complex profiles with possibly a lot of subclasses simply to integrate with other profiles. For example, UPDM couldn't use ViewPoint directly, it would have to create a subclass, either coming up with a new name, or putting its ViewPoint in a different Package so that it wouldn't collide with SysML. This is confusing, and results in stereotypes with either the same meaning but different names, or two stereotypes with the same name in different packages. This also requires both profiles to exist, even though the both don't need to be applied. This is again an undesirable side-effect of too much coupling.

    Both of these approaches end up inhibiting profile integration and reuse resulting in limited integration between OMG submissions. UPMS had wanted to include integrations with many other submissions including RAS, BPDM, BPMN, ODM, QoS, and BMM. However we could not determine a practical way to do this with current technologies and did not include many of these integrations because of the resulting risk, complexity and coupling. This is a particular problem when we consider the OMG specifications, profiles, and metamodels in an enterprise architecture context where the relationships between the parts are critical to delivering value.

    UML2 provides a solution to this problem for extensions created using MOF metamodels to model capabilities. PackageMerge can be used to merge metaclasses with the same name from different capabilities in order to mixin their capabilities. What is needed is a similar capability for UML2 profiles.

    A proposed solution would be to extend UML2 Profiles to include similar merge semantics when multiple profiles containing the same classes or stereotypes are applied to the same model. When a Profile is applied to a Package, the Classes and Stereotypes in the Profile would be merged with Classes and Stereotypes of other Profiles that have already been applied. The rules for PackageMerge can be used to define how this merge is done as they already apply to Class, and can equally apply to Stereotype which is a specialization of Class. Conflicts resulting from the merge could be considered defects against the profiles that could be handled in an RTF.

    Consider the same example above; both UPDM and SysML define ViewPoint.

    3. Profile Merge: The UPDM submitters would be careful to use ViewPoint is a manner that is semantically consistent with SysML since SysML already existed. However UPDM conuld extend ViewPoint with additional properties and associations for its purposes. The UPDM submission could note to users that ViewPoint is a stereotype in UPDM that represents a "placeholder" to ViewPoint in SysML. Users could then apply UPDM to a model, and get UPDM's ViewPoint capabilities without any coupling or need for SysML. Later on, another user could decide to apply SysML to the same model in order to use its modeling capabilities. The SysML::ViewPoint would be merged with the UPDM::ViewPoint allowing the shared semantics to be supported without making any changes to the existing model. Similarly, users could have started with SysML and later applied UPDM to achieve the same effect.

    This is a significant change to UML2, but may be an urgent issue due to the number of other profiles and submissions looking for a solution to this problem.

  • Reported: UML 2.1.2 — Thu, 24 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Regression in XMI from UML 2.1.2 to UML 2.2

  • Key: UML22-421
  • Legacy Issue Number: 12774
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    At 03:12 PM 8/13/2008, Pete Rivett wrote:

    Well-spotted Nicolas: though from your example fragments you’re wrong to say that at 2.2 the ends are given a generic name – they are given a generic xmi:id and no name at all!
    Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs.
    The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable.

    In fact I’d say that we should probably treat this as an urgent issue and produce a new XMI file ASAP.

    >From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 – there is an incorrect owningAssociation attribute on the Property. This must not be serialized since it’s the opposite of the composite owner of the Property (Association.ownedEnd) and so redundant.

    Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this.

    Pete

    From: Nicolas Rouquette [ nicolas.rouquette@jpl.nasa.gov]
    Sent: 13 August 2008 19:15
    To: uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor
    Subject: unalabelled association-owned memberEnd property names affect the name of an association

    I noticed strange differences between the XMI serialization of the UML superstructure in:

    UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof
    UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    For example, in UML 2.1.2, we have:

    <ownedMember xmi:type="cmof:Association" xmi:id="Actions-CompleteActions-A_result_readExtentAction" name="A_result_readExtentAction" memberEnd="Actions-CompleteActions-ReadExtentAction-result Actions-CompleteActions-A_result_readExtentAction-readExtentAction">
    <ownedEnd xmi:type="cmof:Property" xmi:id="Actions-CompleteActions-A_result_readExtentAction-readExtentAction" name="readExtentAction" lower="0" type="Actions-CompleteActions-ReadExtentAction" association="Actions-CompleteActions-A_result_readExtentAction"/>
    </ownedMember>

    whereas in UML 2.2beta1, we have:

    <ownedMember xmi:type="cmof:Association" xmi:id="Actions-CompleteActions-A_result_readExtentAction" name="A_result_readExtentAction" memberEnd="Actions-CompleteActions-ReadExtentAction-result Actions-CompleteActions-A_result_readExtentAction-_ownedEnd.0">
    <ownedEnd xmi:type="cmof:Property" xmi:id="Actions-CompleteActions-A_result_readExtentAction-_ownedEnd.0" type="Actions-CompleteActions-ReadExtentAction" lower="0" owningAssociation="Actions-CompleteActions-A_result_readExtentAction" association="Actions-CompleteActions-A_result_readExtentAction"/>
    </ownedMember>

    In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec.

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/

    The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 – i.e., the name of the class with a lowercase initial.

    Is it OK for association names to change in this manner from one rev to another or is this a bug?

    Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes.

  • Reported: UML 2.1.2 — Wed, 13 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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: 2.2-2.4 compliance level clarifiction needed

  • Key: UML22-420
  • Legacy Issue Number: 12750
  • Status: closed  
  • Source: YTCA ( Trent Lillehaugen)
  • Summary:

    Section 2.2 introduces two compliance levels: L0 and LM. Section 2.3 states: "Compliance to a given level entails full realization of all language units that are defined for that compliance level. This also implies full realization of all language units in all the levels below that level. “Full realization” for a language unit at a given level means supporting the complete set of modeling concepts defined for that language unit at that level. Thus, it is not meaningful to claim compliance to, say, Level 2 without also being compliant with the Level 0 and Level 1." This is confusing as there is no such thing as Level 1 or Level 2 defined. This concept is repeated in section 2.4: "(as a rule, Level (N) includes all the packages supported by Level (N-1))" It may be worth mentioning that the superstructure document will introduce further levels on top of the infrastructure level L0. Also, if I understand it correctly: LM builds on L0, and so does L1. So we have two parallel paths of compliance: L0 <- LM and L0 <- L1 <- L2 <- L3 So how does LM fit in with the L(N) compliant is also L(N-1) compliant scheme? Do you need to specify L2 and LM compliance?

  • Reported: UML 2.1.2 — Tue, 5 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

Unspecified constraint [1] on AcceptEventAction

  • Key: UML22-424
  • Legacy Issue Number: 12782
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on AcceptEventAction (11.3.2) is unspecified:

    [1] AcceptEventActions may have no input pins.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] AcceptEventActions may have no input pins.
    self.input->isEmpty()

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 8702

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect OCL expression for constraint [1] on BehavioredClassifier

  • Key: UML22-423
  • Legacy Issue Number: 12781
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: incorrect OCL constraint

    Summary:

    The following constraint on BehavioredClassifier (13.3.4) is incorrectly specified:

    [1] If a behavior is classifier behavior, it does not have a specification.
    self.classifierBehavior->notEmpty() implies self.specification->isEmpty()

    Discussion:

    self.specification does not resolve to any attribute of BehavioredClassifier.
    self.classifierBehavior resolves to a Behavior which can have 0 or 1 BehavioralFeature specification.
    Hence, the correct OCL navigation expression should be self.classifierBehavior.specification instead of self.specification.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] If a behavior is classifier behavior, it does not have a specification.
    self.classifierBehavior->notEmpty() implies self.classifierBehavior.specification->isEmpty()

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OCL 2.0 8.2 Real

  • Key: UML22-415
  • Legacy Issue Number: 12583
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    OCL reuses Boolean, Integer, String, UnlimitedNatural from UML Infrastructure.

    OCL uses Real in a very similar fashion, but there is no corresponding
    definition of Real in either OCL or UML Infrastructure.

  • Reported: UML 2.1.2 — Sat, 19 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The primitive type “Real” needs to be added to the PrimitiveTypes package for consistency with the OCL Real type. “Real” has also been defined separately by SysML and MARTE specifications and the new Diagram Definition Submission, so adding it to the PrimitiveTypes package will encourage reuse.
    Another argument for adding a primitive type “Real” is that there is currently no normative way to notate real numerals in UML models. So, even if some model library adds a “Real” primitive type, there is technically still no normative way to write a literal for that type in a UML model. This suggests the need for a Real Literal definition as well.
    (Note that the revised text below presumes the resolution to Issue 13993.)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 issue regarding RedefinableTemplateSignature

  • Key: UML22-414
  • Legacy Issue Number: 12580
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    UML Superstructure V2.2, Section 17.5.9 RedefinableTemplateSignature.

    The paragraph in the "Semantics" section RedefinableTemplateSignature mentions the following:
    All the formal template parameters of the extended signatures are included as formal template parameters of the extending signature, along with any parameters locally specified for the extending signature.

    I beleive this would imply that the "parameter" feature would need to be derived which it is currently not.

  • Reported: UML 2.1.2 — Fri, 18 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    /inheritedParameter is indeed derived and is a subset of parameter, which corresponds to the semantics.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unspecified constraint [1] on ActivityEdge (CompleteStructuredActivities)

  • Key: UML22-427
  • Legacy Issue Number: 12785
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on ActivityEdge (12.3.5) is unspecified:

    Package CompleteStructuredActivities
    [1] Activity edges may be owned by at most one structured node.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    Package CompleteStructuredActivities
    [1] Activity edges may be owned by at most one structured node.
    self.inStructuredNode->notEmpty() implies
    (self.inStructuredNode.oclAsType(ActivityGroup)->includesAll(self.inGroup)
    and self.inStructuredNode.oclAsType(Element)->includes(self.owner))

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unspecified constraint [2] on ActivityEdge

  • Key: UML22-426
  • Legacy Issue Number: 12784
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on ActivityEdge (12.3.5) is unspecified:

    [2] Activity edges may be owned only by activities or groups.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [2] Activity edges may be owned only by activities or groups.
    self.source.activity = self.activity and self.target.activity = self.activity

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unspecified constraint [2] on Activity

  • Key: UML22-429
  • Legacy Issue Number: 12787
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on Activity (12.3.4) is unspecified:

    [2] An activity cannot be autonomous and have a classifier or behavioral feature context at the same time.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [2] An activity cannot be autonomous and have a classifier or behavioral feature context at the same time.
    self.isActive implies (self.getContext()>isEmpty() and self.classifierBehavior>isEmpty())

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unspecified constraint [1 on Activity

  • Key: UML22-428
  • Legacy Issue Number: 12786
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on Activity (12.3.4) is unspecified:

    [1] The nodes of the activity must include one ActivityParameterNode for each parameter.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] The nodes of the activity must include one ActivityParameterNode for each parameter.
    self.node->select(oclIsKindOf(ActivityParameterNode)).oclAsType(ActivityParameterNode).parameter->asSet()>symmetricDifference(self.ownedParameter>asSet())->isEmpty()

    Change the Superstructure XMI accordingly.

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is obsolete. All constraints have been specified in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.3.50 "substitution"

  • Key: UML22-417
  • Legacy Issue Number: 12586
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    As describe, a "Substitution" looks more like a derived property than like a relationship, except if it must be interpreted as an explicit inheritence restricted to the external contracts (with possible redefinition). The point is that is not clear with the current description

  • Reported: UML 2.1.2 — Thu, 24 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The revised text in UML 2.5 is clearer.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Keyword ambiguity for DataType Section

  • Key: UML22-416
  • Legacy Issue Number: 12584
  • Status: closed  
  • Source: ModelFoundry ( Sam Mancarella [X] (Inactive))
  • Summary:

    Keyword ambiguity for DataType Section 7.3.11 Describes the use of the 'dataType' keyword (along with Figure 7.36). Whereas, the example depicted in Figure 7.39 shows a DataType with the 'datatype' keyword.

  • Reported: UML 2.1.2 — Wed, 23 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

Unspecified constraint [1] on ActivityEdge

  • Key: UML22-425
  • Legacy Issue Number: 12783
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Source: UML 2.2 Superstructure document and XMI

    http://www.omg.org/cgi-bin/doc?ptc/08-05-05
    http://www.omg.org/cgi-bin/doc?ptc/08-05-12

    Nature: Unspecified OCL constraint

    Summary:

    The following constraint on ActivityEdge (12.3.5) is unspecified:

    [1] The source and target of an edge must be in the same activity as the edge.

    Discussion:

    OCL 101.

    Revised Text:

    Change the specification of the constraint to the following:

    [1] The source and target of an edge must be in the same activity as the edge.
    self.source.activity = self.activity and self.target.activity = self.activity

    Change the Superstructure XMI accordingly

  • Reported: UML 2.1.2 — Fri, 15 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Change the specification of the constraint to the following:

    [1] The source and target of an edge must be in the same activity as the edge.
    let edgeActivity:Set(Activity) = self.inGroup->closure(inGroup).inActivity->asSet()>union(self.activity>asSet()) in
    let sourceActivity:Set(Activity) = self.source.inGroup->closure(inGroup).inActivity->asSet() in
    let targetActivity:Set(Activity) = self.source.inGroup->closure(inGroup).inActivity->asSet() in
    edgeActivity->symmetricDifference(sourceActivity)->isEmpty() and
    edgeActivity->symmetricDifference(targetActivity)->isEmpty()

    Change the Superstructure XMI accordingly.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.8

  • Key: UML22-422
  • Legacy Issue Number: 12775
  • Status: closed  
  • Source: YTCA ( Trent Lillehaugen)
  • Summary:

    There is an association of EncapsulatedClassifier (9.3.8) ownedPort which is derived and subsets Class::ownedAttribute. The problem I have is that I don't see how ownedPort can subset Class::ownedAttribute. I don't see an inheritance path from EncapsulatedClassifier to Class. Also, which Class is it referring to? Class (from Kernel), Class (from StructuredClasses), etc. This problem exists for all "subsets" statements in the specification. Thank you.

  • Reported: UML 2.1.2 — Thu, 14 Aug 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It should in fact refer to StructuredClassifier::ownedAttribute

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 10.3.10

  • Key: UML22-406
  • Legacy Issue Number: 12545
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Shouldn't be a constraint or a redefinition in order to specify that the client of a manisfestation is its owning artefact?

  • Reported: UML 2.1.1 — Mon, 23 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The requested logic is already provided because artifact subsets owner. Since artifact also subset client, the artifact is
    clearly identified as the client. No additional constraints are required.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

definition of RedefinableElement::isLeaf

  • Key: UML22-405
  • Legacy Issue Number: 12532
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    Version of Spec: 2.1.1 2007--2-05, Section 7.3.46 p.130

    The definition of RedefinableElement::isLeaf indicates that "If the value is true, then it is not possible to further specialize the RedefinableElement". However there is no explicit constraint that actually enforces this (at least none that I could find). I believe that a constraint should be created to address this.

  • Reported: UML 2.1.2 — Tue, 17 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue is not a duplicate of issue 9831 which is closely related to issue 10515.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Behavior's parameter list

  • Key: UML22-404
  • Legacy Issue Number: 12530
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature.

    >From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint:
    [1] The parameters of the behavior must match the parameters of the implemented behavioral feature

    We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync.

    We would like to request that this constraint is removed from the specification.

  • Reported: UML 2.1.2 — Fri, 13 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 7626

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PackageMerge relationships

  • Key: UML22-403
  • Legacy Issue Number: 12528
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The way the PackageMerge relatrionships are used in the specification doesn't seem to be rigorous or, at least, are not clear. For instance: * §7.3.7 indicates that the "Class" from Kernel metaclass is a specialization of “Classifier (from Kernel, Dependencies, PowerTypes)”. That is not correct if you refere to the corresponding package diagram: "Class" from Kernel doesn't inherit from Dependencies and PowerType merge increment of "Classifier" * §7.3.6 "BehavioredClassifier" from Interfaces) is a merge increment of "BehavioredClassifier" from BasicBehavior) but not for "BehavioredClassifier" from Communications (it's the opposite). * etc... Then, i suggest to define PackageMerge relationships of the metamodele in a more formal way than simple diagrams and to validate that metaclass definition are consistent with these relationships.

  • Reported: UML 2.1.2 — Tue, 10 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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: 7.3.36

  • Key: UML22-413
  • Legacy Issue Number: 12569
  • Status: closed  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 6. 6.1 Operation is having very wide type (Type) as an exception instance (raisedException). Theoretically it is possible that Association may be thrown as an exception. ++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Agreed. I wish that this was the only place where the metamodel suffers from overgeneralization. Unfortunately, this is almost endemic in how things are done in UML.

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    If we were to constrain the type of exceptions, we might invalidate user models. There seems no reason to make a
    change here.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.30,12.3.23

  • Key: UML22-412
  • Legacy Issue Number: 12567
  • Status: closed  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 4 4.1. Exceptions raising is provided on L2 compliance level (RaiseExceptionAction from Actions/StructuredActions) while handling is provided on L3 (ExceptionHandler from Activities/ExtraStructerdActivities). That functionality is an integrated part and raising and handling exceptions should be provided on the same compliance level. ++++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Agreed. We did not focus too much on the modeling of exceptions – it was not a priority item at the time. It should probably be so now. Your work is definitely timely. Andrzej Zielinski: That is about my Ph.D thesis

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. There are no compliance levels in UML 2.5.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.3

  • Key: UML22-410
  • Legacy Issue Number: 12564
  • Status: closed  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 2 2.1 Relation raisedException of Operation and BehavioralFeature classes not consistently set (CommonBehaviors/Communications) (L2 compliance). Operation (Classes/Kernel) (L1 compliance level ) inherits from BehavioralFeature (Classes/Kernel) (L1) and redefines raisedException to Type. On that level there is no problem. But in CommonBehaviors/Communications BehavioralFeature redefines raisedExceptions to point to Classifier. As a result Operation points to Type, while BehavioralFeature to Classifier. Classifier is more specific than Type (Classifier inherits from Type) +++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Yes, that is a problem. I will relay it on to the OMG to be officially registered.

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    There does not seem to be any reason for Communications::BehavioralFeature to have a raisedException attribute. It is not used anywhere in Communications. Kernel::BehavioalrFeature already has a raisedException property that will be included when the BehavioralFeature merge increments are actually merged.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.2

  • Key: UML22-411
  • Legacy Issue Number: 12565
  • Status: closed  
  • Source: Motorola ( Andrzej Zielinski)
  • Summary:

    Problem 1 Some classes in certain packages are abstract, while they are not in packages that are on a higher (or the same) compliance level. 1.3. Pin in Activities/BasicActivities (L1 compliance level) (Fig. 12.4 p.299 ) and Activities/CompleteActivities (L3) (Fig.12.16 p. 305) are not abstract, while in they are in package ActionsBasicActions (L1) (Fig. 11.3 p. 221) ++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Yes, that is a problem. I will relay it on to the OMG to be officially registered.

  • Reported: UML 2.1.2 — Thu, 10 Jul 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The behavior of an OpaqueExpression should itself be opaque

  • Key: UML22-408
  • Legacy Issue Number: 12557
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The behavior of an OpaqueExpression should itself be opaque

  • Reported: UML 2.1.2 — Wed, 25 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Under Subclause 13.3.21, it says that the extension to OpaqueExpression "Provides a mechanism for precisely defining the behavior of an opaque expression." It is hard to see how one can precisely define behavior, if the behavior is itself opaque. Indeed, specifying the behavior of an OpaqueExpression with, say, an activity is the only way to model an expression in UML in terms of executable actions, so this should not be precluded.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.23

  • Key: UML22-409
  • Legacy Issue Number: 12558
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    The multiplicity of the "signal" property of a Reception is [0..1]. What's the semantic of a Reception that would be associated with no signal?

  • Reported: UML 2.1.2 — Wed, 25 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Areception should be required to specify a signal.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Classifiers

  • Key: UML22-402
  • Legacy Issue Number: 12516
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    Classifiers are specialized to hold useCase properties in the UseCases package but this package is not merged/imported by any other ones. Does it formally mean that - for instance - no version of the metaclass "Class" should be able to hold use cases?

  • Reported: UML 2.1.2 — Wed, 4 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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: 7.3.35

  • Key: UML22-407
  • Legacy Issue Number: 12556
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

    In order to be complinat with the semantics, "body" and "language" properties of an OpaqueExpression shall be ordered

  • Reported: UML 2.1.2 — Wed, 25 Jun 2008 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Packaging Issues with Stereotype Extension

  • Key: UML22-468
  • Legacy Issue Number: 13306
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Section: 18.3.2 (Extension)

    Extension::metaclass has the type Class. When the Profiles package is merged into L2, Profiles::Class is merged into L2::Class. This means that the metaclass for an extension has to be represented as a UML Class (at L2 or, after further merging, at L3).

    However, the UML abstract syntax metamodel is not actually a UML model, but a CMOF model. This means that UML metaclasses are instances of CMOF::Class, not UML::Class (at L2 or L3). This means that it is not possible to actually construct a stereotype extension that points to a metaclass representation of the correct type.

    UML tools currently get around this my referencing metaclasses from a version of the UML abstract syntax metamodel that is expressed in terms of UML L3, rather than CMOF. Or they just don't worry about the type checking. But that is not technically correct, and it means that stereotypes in each tool are referencing non-normative representations of the UML metamodel, rather than standard metaclass object IDs.

  • Reported: UML 2.1.2 — Tue, 20 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The problem is resolved by shipping a normative version of the UML metamodel expressed in terms of UML, and changing the text accordingly.
    A couple of decisions need making about this metamodel, which we?ve discussed extensively in email:
    1. Which compliance level of UML is used to create it? We?ll use the lowest compliance level that we can, which is L1. This means we cannot use Model, so the root of the metamodel will be a uml:Package.
    2. Do we apply any stereotypes such as «metamodel» or «metaclass» in the normative UML model? The answer is no and follows from (1): since we don?t use Model, we cannot use «metamodel». Also, using stereotypes in order to specify stereotypes (see 14092) might give circularity or fixed-point issues. We are justified in omitting these by the wording of PresentationOptions in 18.3.1: “A Class that is extended by a Stereotype may be extended by the optional stereotype «metaclass» …”

  • Updated: Fri, 6 Mar 2015 20:58 GMT

inconsistency with how constraints are specified in UML and OCL

  • Key: UML22-467
  • Legacy Issue Number: 13258
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    In OCL 2.0 specification, section Operation Body Expression, it specifies that
    expression must conform to the result type of the operation.

    However, in UML 2.1.2 specificaiton, it is specified that bodyCondition of an
    operation is a constratin which must evaluates to a boolean expression.

    The problem is that UML equates the term "constraint" with "boolean-valued
    expression that holds true at some time." The OCL usage of the term is not so
    narrow. A constraint is a model element that specifies more precise semantics
    for another model element than what its structure alone can achieve.

    So, for example, an attribute constrains its values to conform to some type,
    but a derivation expression (whose value conforms to the attribute type) more
    precisely constrains its values. Likewise the operation body expression
    constrains the value of an operation by computing it from the parameters and
    the context object. Note that OCL actually calls this constraint a "body
    expression," not a "body condition" as UML does. OCL's notion of "constraint"
    even extends to definition of helper operations and attributes.

    Consider what it means to require boolean values for operation body
    constraints. They must be formulated like postconditions, as boolean
    expressions on the "result" variable. In OCL, the body condition does not have
    a "result" variable; only post-conditions have it. Furthermore, consider an
    example: an operation phi() defined in the Real primitive type. According to
    UML's rules, it could be defined like this:

    context Real::phi() : Real
    body: result = (1.0 + 5.0.sqrt()) / 2.0

    or like this:

    context Real::phi() : Real
    body: (result - 1.0) = (1.0 / result)

    These are isomorphic constraints, but neither is friendly to OCL tool
    implementations (certainly not the second). According to OCL, the constraint
    would by formulated like this:

    context Real::phi() : Real
    body: (1.0 + 5.0.sqrt()) / 2.0

    and there really is no other kind of formulation. IMO, this is much more
    practical for all concerned.

    Consider an operation that has parameters, for which I write an ineffectual
    body constraint like this:

    context Foo::doSomething(bar1 : Bar, bar2 : Bar) : Baz
    body: bar1 <> bar2

    What does this mean?

    All in all, it is far mare useful to have an OCL expression that can readily be
    evaluated to compute the value of the operation. This leaves no room for
    ambiguity.

    The UML stipulation that Constraints in all contexts must be boolean
    expressions, as in operation precondition and classifier invariant context, is
    unnecessary. What is the benefit? It would be nice to see it removed in UML
    2.3.

  • Reported: UML 2.1.2 — Wed, 14 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    merged with 15259

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Allowing multiple Associations in a Package with the same name

  • Key: UML22-470
  • Legacy Issue Number: 13330
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I had a recent ‘argument’ with Steve Cook on his blog. There is a lot of confusion with regards to whether there can be multiple Associations with the same name in a Package. Steve made the valid point that Association does not redefine “isDistinguishableFrom”, which it gets from being a NamedElement. This is overridden for BehavioralFeature, but not for Association, thus based on that rule from NamedElement, I assume that there may not be multiple Associations with the same name (including empty) in a Package.

    However, I came across the following cases that seem to ignore this notion:

    1) In the rules for PackageMerge (7.3.40), they allow for the ability to have multiple Associations with the same name by taking into account their member ends: “Elements that are a kind of Association match by name (including if they have no name) and by their association ends where those match by name and type (i.e., the same rule as properties).”

    2) The MOF 2.0 XMI file almost never names its’ Associations, thus having many Associations with the same name.

    3) The UML 2.1.1 Superstructure XMI file also has multiple associations with the same name. As an example, see the package with id “AuxiliaryConstructs-Templates”. It owns 3 associations with the name “A_templateParameter_parameteredElement” (ids “A_templateParameter_parameteredElement”, “A_templateParameter_parameteredElement.1” and “A_templateParameter_parameteredElement.2”).

    Is it intended that multiple Associations with the same name be allowed in a Package or not? If not, then we need to fix Superstructure, MOF, and we can also relax the PackageMerge rule for Associations. If we do allow it, then we should add a new redefinition of “isDistinguishableFrom” for Association that specifies a similar rule to the one described in PackageMerge, that an Association type is distinguishable from another Association if the set of its name and the names of all its member ends is not equal to the corresponding set of the other Association.

  • Reported: UML 2.1.2 — Thu, 27 Nov 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    A redefine of isDistinguishableFrom for Association is not desired. As such, the PackageMerge rule for Association, which implies the possibility of multiple Associations in a Package with the same name, including if they have no name, provided their member ends differ in some way, is to be amended as it can result in ill-formed merged Packages. This is supported by the following 2 constraints:

    1. MOF 2.0 Specification, under section "12.4 EMOF Constraints" there is the following constraint (which would be violated if the Associations have no name):
    "[3] Names are required for all Types and Properties (though there is nothing to prevent these names being automatically generated by a tool)."

    2. In "9.14.2 Namespace" of the UML 2.1.2 Infrastructure Specification there is the following constraint (which would be violated if the Associations have the same name):
    "[1] All the members of a Namespace are distinguishable within it."

    As such, explicit rules are also to be added to PackageMerge requiring well-formedness of the merged Package.

    The XMI elements cited as examples of clashing Association names are to be renamed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

P479L.14 Section "Notation" in 14.3.10 ExecutionOccurences - Typo

  • Key: UML22-469
  • Legacy Issue Number: 13327
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    Regarding UML 2.2 Superstructure

    P479L.14 Section "Notation" in 14.3.10 ExecutionOccurences

    ExecutionOccurences
    ~~

  • Reported: UML 2.1.2 — Fri, 23 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 18.2 (which describes the contents of the Profiles package) is currently misleading

  • Key: UML22-472
  • Legacy Issue Number: 13844
  • Status: closed  
  • Source: PTC ( Phillip Astle)
  • Summary:

    Figure 18.2 (which describes the contents of the Profiles package) is currently misleading. On this diagram the majority of the elements have their specializations to infrastructure elements shown (either directly or indirectly). However, Class and Package (which are also infrastructure specializations) do not have their specializations shown. This makes them appear to be the superstructure Class and Package when they aren't (as the diagram is being shown in the context of the superstructure specification). I suggest that you add the missing specializations to make the diagram clearer. Due to the differences between infrastructure Class and superstructure Class, you wouldn't want to confuse them.

  • Reported: UML 2.1.2 — Mon, 30 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

ParameterableElement as a formal template parameter

  • Key: UML22-466
  • Legacy Issue Number: 13257
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    Say we want to expose a ParameterableElement as a formal template parameter.
    If we want to create the following List<E>, then the template parameter would refer to some parameterable element E whose type we would have to choose (say uml:Class).
    Now, say we wanted to create List< Interface >, or List < Class >, or List < DataType >. I don't think we would be able to then create TemplateParameterSubstitution for all these elements since the type of formal and actual parameters are inconsistent.

    The problem is that we must pick a concrete type for that ParameterableElement - we can't for example use Classifier as the template parameter because it's abstract.

  • Reported: UML 2.1.2 — Wed, 14 Jan 2009 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is a general issue with the way TemplateParameters are handled in the UML abstract syntax, and it would require
    a major change in the approach to templates to resolve it in general. However, the specific (and most common) case
    mentioned in the issue, that of a template for which it is desired to expose a Classifier as a parameter, is actually
    covered by a special case in the specification.
    In the UML 2.5 specification, subclause 9.3.3 describes the semantics of ClassifierTemplateParameters, which are
    TemplateParameters where the parameteredElement is a Classifier, optionally constrained by a set of constraining-
    Classifiers. Toward the end of this section, it says “if the constrainingClassifier property is empty, there are no constraints
    on the Classifier that can be used as an argument.” Thus, in defining a template List<E>, it is possible for the
    parameteredElement of the formal TemplateParameter E to be a Class, but to still, in a binding for List, substitute for
    E with an argument that is any kind of Classifer (including Interface, DataType, etc.).
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML. Clarify relationship of Substitution and InterfaceRealization

  • Key: UML22-465
  • Legacy Issue Number: 13164
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The specification of ClassifierTemplateParameter has a flag allowSubstitutable. The definition of ClassifierTemplateParameter::constrainingClassifier says “If the allowSubstitutable attribute is true, then any classifier that is compatible with this constraining classifier can be substituted”. What does “compatible” mean? If we look in Templates::Classifier we find this:

    Semantic Variation Points If template parameter constraints apply, then the actual classifier is constrained as follows. If the classifier template parameter:

    • has a generalization, then an actual classifier must have generalization with the same general classifier.

    • has a substitution, then an actual classifier must have a substitution with the same contract.

    • has neither a generalization nor a substitution, then an actual classifier can be any classifier.

    If template parameter constraints do not apply, then an actual classifier can be any classifier.

    Firstly, the spec for classifier template parameters needs to clarify what compatible means; and this clarification must surely include the possibility that the relationship between the constrainingClassifier and the template parameter can be an InterfaceRealization as well as a Substitution.

    Secondly, this text for Semantic Variation Points is weird. Presumably it means that the constraints on substitutability of ClassifierTemplateParameter are a SVP. If so it should say so, and the SVP text should be under ClassifierTemplateParameter.

    Finally, it appears that given the existence of Substitution, InterfaceRealization is completely redundant. A good simplification would be to eliminate InterfaceRealization altogether; failing that to make it a subclass of Substitution to clarify that it has contract compatibility semantics.

  • Reported: UML 2.1.2 — Wed, 17 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Most of this issue is obsolete: these semantic variation points have been clarified in the text. Changing the metamodel
    as suggested in the final point would be too disruptive.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 section 8.3.1 OCL derivations on Component.provided and Component.required are still invalid

  • Key: UML22-462
  • Legacy Issue Number: 13146
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The OCL definitions of how Component.provided and Component.required are still invalid, even though they were altered in 2.2. The subexpressions self.implementation and self.realizingClassifier, which appear in both derivations, are not valid: there are no such properties on Component.

  • Reported: UML 2.1.2 — Fri, 5 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It seems that the first "let" clause of each constraint is supposed to do what the second "let" actually does. So we'll delete the first one.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

transitionkind Constraints

  • Key: UML22-464
  • Legacy Issue Number: 13163
  • Status: closed  
  • Source: Individual ( Jerry Wang)
  • Summary:

    In transitionkind Constraints, the document said: [1] The source state of a transition with transition kind local must be a composite state. [2] The source state of a transition with transition kind external must be a composite state. Does these two constraint means that simple state can not have a outgoing transition?

  • Reported: UML 2.1.2 — Mon, 15 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The cited constraints are not present in the UML 2.5 version of the spec.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.2 figure 8.10 has arrows the wrong way around

  • Key: UML22-463
  • Legacy Issue Number: 13147
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The dependencies in 8.10 should surely point from the Component (the client) to the realizing Classifiers (the suppliers). Also there is a redundant sentence “Alternatively, they may be nested within the component shape” above that figure which is repeated below.

  • Reported: UML 2.1.2 — Fri, 5 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The first part of this issue is wrong (see resolution to 11008 for explanation). The notation for the diagram is wrong which will be fixed by 10651.
    The second part is correct.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2.2 Section 9.3.1 Presentation Options section

  • Key: UML22-461
  • Legacy Issue Number: 13142
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The Presentation Options section of 9.3.1 seems both inappropriately named and in entirely the wrong place. It is about usage dependencies, constructors and instance specifications and should appear somewhere in chapter 7.

  • Reported: UML 2.1.2 — Thu, 4 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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 Section 9.3.1 nested classes paragrpah in wrong chapter

  • Key: UML22-460
  • Legacy Issue Number: 13141
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In Section 9.3.1 the second paragraph starts “A class acts as the namespace ...”. This semantic about nested classes is part of normal classes and should be moved to 7.3.7.

  • Reported: UML 2.1.2 — Thu, 4 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

Figure 2.2 contains more than four packages, description referes to four packages

  • Key: UML22-471
  • Legacy Issue Number: 13665
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    In the paragraph describing Figure 2.2, the text refers to "four packages". Figure 2.2 contains more than four packages. The corresponding figure in Version 2.0 of the Superstructure displayed four packages; presumably the text wasn't updated along with the figure.

  • Reported: UML 2.1.2 — Mon, 9 Mar 2009 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

In normative XMI file for the metamodel, no Associations have a name.

  • Key: UML22-534
  • Legacy Issue Number: 7105
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In the normative XMI file for the metamodel, no Associations have a
    name.
    The name is needed for generating APIs and (in some cases) XMI elements;
    and their absence actually makes UML2 an invalid MOF2 metamodel: MOF2
    Core has the following constraint for CMOF:
    [6] Names are required for all classifiers and features (though there is
    nothing to prevent these names being automatically generated by a tool).

    (Association is a classifier)

    We could get by with not having a name in the MDL and auto-generating a
    name into the XMI. This is in fact what the Unisys XMI plug-in did when
    no Association name was provided - and this was hence reflected in the
    normative XMI for UML 1.x (the names were of the form A_<end1>_<end2>).

  • Reported: XMI 2.0 — Mon, 8 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/Constraints for create messages

  • Key: UML22-533
  • Legacy Issue Number: 6989
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    page 429 Constraints for message need to include "no EventOccurences before receiving the create message". In the graphic notation this is handled by defining the create graphic path as flowing into the Lifeline head symbol, but since we do not want to introduce the concept of a Lifeline head in the meta-model, we need an additional constraint.

    Constraints need to be updated as new sorts of messages are added.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Infra/11.5.1/Invalid reference to Attribute class

  • Key: UML22-536
  • Legacy Issue Number: 7274
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In section 11.5.1 (DataType) the first association is specified as:

    ownedAttribute: Attribute[*] The Attributes owned by the DataType.

    This is out of date: the class Attribute has been replaced by Property,
    though the association name is OK referring to 'Attribute'. This is
    reflected in the diagram above that text (Fig 86).

    Proposed resolution:
    Replace the above text with:
    ownedAttribute: Property[*] The Properties owned by the DataType.

  • Reported: XMI 2.0 — Wed, 28 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 78

  • Key: UML22-535
  • Legacy Issue Number: 7246
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Figure 78 - inconsistencies with Class Descriptions Figure 78 shows an enumeration ConnectorKind which is not defined in this chapter, however (see also Issue #7001). Suggestion: define ConnectorKind in section 8.3 - Class Descriptions. Figure 78 shows an association between Connector and Behavior with association end "+contract". This association is not defined in Section 8.3.2 - Connector, however.

  • Reported: UML 2.0 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed by the resolution to issue 8976 in UML 2.1. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Class InfrastructureLibrary::Core::Basic::Property

  • Key: UML22-532
  • Legacy Issue Number: 6923
  • Status: closed  
  • Source: Fraunhofer FOKUS, Germany ( Michael Soden)
  • Summary:

    Class InfrastructureLibrary::Core::Basic::Property contains an attribute named 'default' of type 'String'. If initial values should be provided for a Property instance, then there is no possibility to evaluate the string without a schema. I'm not sure about the intension of this default property, especially for MOF (it seems to be useable only for visualization in UML).

    Proposed resolution: If evaluation should be processable by tools (e.g. code generators), then the type of 'default' must be changed to class "Type" or a schema for evaluation should be provided.

  • Reported: UML 2.0 — Mon, 19 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In 2.13.3, the first sub-section about ActivityGraph is not numbered

  • Key: UML22-531
  • Legacy Issue Number: 6727
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In 2.13.3, the first sub-section about ActivityGraph is not numbered, it should be 2.13.3.1. Subsequent sub-sections should be renumbered

  • Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

missing closing parenthesis

  • Key: UML22-529
  • Legacy Issue Number: 6725
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In the second additional operation of the model element StateMachine, there is a missing closing parenthesis in the last else branch, i.e. the last else branch should read

  • Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Indeed so.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The Composition section does not follow the usual conventions

  • Key: UML22-528
  • Legacy Issue Number: 6724
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The Composition section does not follow the usual conventions of first presenting the attributes and then the associations of the model element.

  • Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In "2.9.3.5 Instance", numbering of different well-formedness rules wrong

  • Key: UML22-526
  • Legacy Issue Number: 6703
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In "2.9.3.5 Instance", the numbering of the different well-formedness rules is wrong. Below rule [2], there are two rule [3], one of which is not left-aligned properly.

  • Reported: UML 1.5 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The numbering of the sub-sections in 2.7.2 is wrong

  • Key: UML22-525
  • Legacy Issue Number: 6702
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The numbering of the sub-sections in 2.7.2 is wrong. In "2.7 Data Types", we have "2.7.1 Overview" and "2.7.2 Abstract Syntax". Below that, the numbering starts with "2.7.3.1 AggregationKind" instead of "2.7.2.1 AggregationKind".

  • Reported: UML 1.5 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Associations section of element JumpHandler

  • Key: UML22-523
  • Legacy Issue Number: 6697
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In the Associations section of element JumpHandler, the protectedAction association misses appropriate type information.

    The line should read:

    protectedAction: Action [0..*]

  • Reported: UML 1.5 — Mon, 15 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove one of the dots between protectedAction and availableOutput

  • Key: UML22-522
  • Legacy Issue Number: 6696
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In the Outputs listing, "self.jumpHandler.protectedAction..availableOutput.type" should read "self.jumpHandler.protectedAction.availableOutput.type"

    Remove one of the dots between protectedAction and availableOutput

  • Reported: UML 1.5 — Mon, 15 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 infra and super Constraints Diagram of the Kernel

  • Key: UML22-524
  • Legacy Issue Number: 6699
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    The Constraint:namespace to Namespace:ownedRule association depicted in the super structure spec on page (31) should be made navigable on both ends and the namespace property should be renamed to owningNamespace and this should subset context and subset namespace.

  • Reported: UML 1.5 — Tue, 16 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The section about Procedure does not contain any well-formedness rules

  • Key: UML22-527
  • Legacy Issue Number: 6704
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The section about Procedure does not contain any well-formedness rules. Instead, the section repeats the content (copy-paste!!) of section 2.9.2.11 about attributes and associations.

  • Reported: UML 1.5 — Wed, 17 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

At the bottom of the page, the characters "antics." should be removed

  • Key: UML22-530
  • Legacy Issue Number: 6726
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    At the bottom of the page, the characters "antics." should be removed

  • Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent use of 'Element' between MOF and UML

  • Key: UML22-549
  • Legacy Issue Number: 7889
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    UML uses Element to mean any Element in a Model, which is inherently something that has an identity separate from its value: this even includes elements such as ValueSpecification.
    MOF uses Object for such a thing, and uses Element to represent any value: specifically when used to declare parameters in Reflection then Element is used to represent both 'Objects' and plain data values (such as integers or strings) used as property or parameter values. Object inherits from Element.

    Proposed resolution:

    MOF should swap the names of Object and Element: this makes it consistent with UML and with languages such as Java where java.lang.object can represent data values.

  • Reported: UML 1.4.2 — Mon, 1 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing XMI tags in spec and XMI rendition of metamodel

  • Key: UML22-548
  • Legacy Issue Number: 7783
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This issue applies to Infrastructure, Superstructure and MOF

    In the XMI for Superstructure for example (in OMG document ad/03-04-02),
    while this does use the nsuri for MOF (using the correct form
    xmlns:cmof="http:///schema.omg.org/spec/mof/2.0/cmof.xmi) it does not
    contain any XMI tags to define for UML what its nsuri and prefix should
    be: which are needed in order to generate the UML xsd.
    Neither does the XMI for the MOF Core itself contain an XMI tag to
    define that the nsuri and prefix should be as just quoted.

    In any case these important values should be included in the
    specification documents as well as being buried in tags in the XMI
    files.

  • Reported: UML 1.4.2 — Fri, 24 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ptc-03-09-15/Constructs::Class superClass property

  • Key: UML22-504
  • Legacy Issue Number: 6493
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Constructs::Class has a superClass property that redefines general,
    which is from Constructs::Classifier (section 11.3, figure 73, p. 111); but
    Constructs::Class also inherits from Basic::Class, which has superClass as a
    property (section 10.2, 66, p. 97). What does this mean? Is this a bug?
    Is it something correct having to do with package merge?

    Recommendation: Determine whether this is intended or an oversight. If it
    is an oversight, correct it. If not, explain the meaning of having these
    both of these properties.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ptc-03-09-15/Non-navigable ends with no role names nor multiplicities

  • Key: UML22-503
  • Legacy Issue Number: 6492
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: It appears that associations with neither end names nor
    multiplicities on non-navigable ends are used in parts of the UML Core that
    are defined via CMOF. See, for example, section 9.9, figure 35, p. 62, for
    example. I understand that for elements defined via EMOF, this signifies a
    simple property. But is it appropriate for elements defined with CMOF.

    Recommendation: Either correct this by adding multiplicities and end names
    or explain in the specification why it is alright to omit them in these
    cases

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    The meaning of this convention should be explained in the document.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Issue: Message notation

  • Key: UML22-502
  • Legacy Issue Number: 6463
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    According to Superstructure, p. 430, the notation for messages in
    interaction diagrams is as follows (we put assumptions between parenthesis):

    asynchronous message - (solid line) open arrowhead
    synchronous message - (solid line) filled arrowhead
    reply message - dashed line (filled or open arrowhead?)
    object creation - dashed line open arrowhead

    However, the example given in Figure 333, p. 414, shows a different
    notation:

    asynchronous message - solid line open arrowhead (not shown in this diagram,
    but in others)
    synchronous message - solid line filled arrowhead
    reply message - dashed line OPEN arrowhead
    object creation - SOLID line open arrowhead

    Another confusing aspect of the notation is that in a reply message, which
    is not a true message, the message name is the name of the operation invoked
    on the callee (same as in the corresponding synchronous call), but it
    suggests instead that there is an operation with this name in the caller. In
    Figure 333, the reply labeled as "foo(_)" visually suggests that there is an
    operation named foo in class C1, which is wrong: foo is defined in C2, not
    in C1. It would make more sense to label a reply message with the name of
    the value returned.

    PROPOSED SOLUTION
    The simplest solution would be to fix Figure 333 using a dashed arrow to
    represent object creation, although this would yield the same notation for
    object creation and reply message. Therefore, beyond this simplest solution,
    we propose something more advanced: First, state explicitly the notation for
    all kinds of messages, leaving no place for assumptions. Second, use a
    filled arrowhead for reply messages, since this emphasizes the conceptual
    proximity to the synchronous message it is a reply from. Third, use the
    notation for object creation also for object deletion, which currently is
    not mentioned. That is:

    asynchronous message - SOLID LINE open arrowhead
    synchronous message - SOLID LINE filled arrowhead
    reply message - dashed line FILLED ARROWHEAD
    object creation OR DELETION - dashed line open arrowhead

    Or better, simply drop object creation as an special kind of message. Object
    creation (and deletion) was not considered a special kind of message in UML
    1, and it is not at all clear why it should be in UML 2. Probably, an object
    creation is either synchronous or asynchronous, but not "something else" in
    the same meta-specialization row. In fact, the constraints and semantics of
    Message (Superstructure, p. 429) do not consider object creation as
    messages: "The signature must either refer an Operation (...) or a Signal",
    "A Message reflects either an Operation call (...) or a sending and
    reception of a Signal". Neither does the meta-attribute Message.messageSort,
    which has the following permitted values: synchCall, synchSignal,
    asynchCall, asynchSignal. By the way, what do synchSignal and asynchCall
    mean? The "sorts" of message are not defined in the Spec. Although calls are
    considered in other places to be either synchronous or asynchronous, signals
    are explicitly defined to be asynchronous (Superstructure, pp. 15, 371, 394
    and 395), therefore at least synchSignal is banned.

    Finally, we also propose to label reply messages with the name of the value
    returned by the operation call, not the operation name itself. In Figure
    333, this would leave the replies foo() and doit() without label, and the
    last reply would be labeled simply as "x".

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Why not using the UML1 activity symbol for UML2 actions?

  • Key: UML22-508
  • Legacy Issue Number: 6503
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I didn't recognize it before, but now I am surprised that the action
    symbol
    is not the same as the UML1 activity symbol ("shape with straight top
    and bottom
    and with convex arcs on the two sides").
    Actions are no activities, but the semantic is similar for
    the "normal" UML user.
    In UML1 the user has to distinguish between the activity symbol and
    the state symbol ("round-cornered rectangle"), especially if states
    and activities
    are shown within the same diagram.
    Now you has to use the UML1 state symbol for actions. I think that
    this is confusing
    for the normal UML user.
    Another point is that the action symbol is the same as the state
    symbol. There will
    be no chance for a misunderstanding, because both symbols are not
    allowed within the same
    diagram. But it would be much clearer if the action symbol has a
    different notation and
    looks like the UML1 activity symbol.

    So, why not using the UML1 activity symbol for UML2 actions?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicity seems to be broken - UML2 Infra & Super

  • Key: UML22-507
  • Legacy Issue Number: 6502
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    The current Infastructure document defines it at page 54 as (line
    numbers have been added by me):
    (1) multiplicity ::= multiplicity_range
    (2) multiplicity_range ::= [lower '..'] upper
    (3) lower ::= integer
    (4) upper ::= unlimited_natural | '*'

    But at page 56 (also page 20 of the Superstructure document which
    copies
    the definition) it says:

    (5) multiplicity ::= multiplicty_range [

    {order_designator}

    ]
    (6) multiplicity_range ::= [lower '..'] upper
    (7) lower ::= integer | value_specification
    (8) upper ::= unlimited_natural | '*' | value_specification
    (9) order_designator ::= ordered | unordered
    (10) uniqueness_designator ::= unique | nonunique

    There are several problems arising from this definition:

    (P1) (9) and (10) are never used
    (P2) Defining the lower bound as "integer" (according to page 142 of
    the
    Infrastructure document) allows it to specify multiplicities with
    lower bounds below 0 (e.g. [-5..7], [-42..0])
    (P3) (4) and (8) include the asterisk symbol to denote an
    infinite
    upper bound. Though, this is redundant since the symbol is already
    there
    as part of the lexical representation of unlimited_natural (according
    to
    page 144 of the Infrastructure document)
    (P3) (4) and (8) define the upper bound using the datatype
    "unlimited_natural" which comprimises all integer numbers starting
    from
    zero. Thus multiplicities like [0..0] would be legal.
    (P4) It should be mentioned that the lower part is lower or equal to
    the
    value given for the upper part (where '*' is geater than any other
    element of the set named integer). Otherwise multiplicities like
    [8..2]
    would be considered legal.
    (P5) What is the role of the value_specification mentioned at (8) and
    (9) isn't it redundant there?

    Or am I just misreading the spec?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Dependency / ownership of dependencies

  • Key: UML22-499
  • Legacy Issue Number: 6451
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    At present, a dependency is not owned by any other element except a package. It seems to make sense for a dependency to be owned by its source. For example, the client of a usage should own it, since that would mean that the usage would be deleted along whenever its client is deleted – it makes no sense to have a dependency independently of the depending (source) element.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification of Information Flow semantics

  • Key: UML22-498
  • Legacy Issue Number: 6446
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Description: Consider the following recommendations to improve Information
    Flow semantics:
    b) Allow Information Flow to be specialized and decomposed using
    aggregation.
    c) Allow Information Flow between classifiers with ports and interfaces.
    Make provisions for relating the information flow to a port, such that an
    Information Flow can flow through a port.
    d) Allow Information Flows between classifiers with object flows across
    activity partitions.
    e) Change the name from Information Flow to Item Flow (or something similar)
    to allow for the flow of non-information, such as physical items specified
    in systems engineering applications.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity diagram problems

  • Key: UML22-497
  • Legacy Issue Number: 6444
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Description: The following are some recommendations to improve Activity
    diagrams for systems engineering applications:
    a) Generalize pins so that they can be applied to control as well as data.
    b) Clarify how activity diagrams can be used to represent continuous
    behavior (e.g., streaming input).
    c) Clarify how an object node to represent a role.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Infra/Metamodel::Constructs/invalid OCL constraint for "opposite"

  • Key: UML22-490
  • Legacy Issue Number: 6201
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Is OCL for InfrastructureLibrary::Core::Constructs::Property::opposite() incorrect? Should it be:
    opposite =
    if owningAssociation->empty() and association.memberEnd->size() = 2 then
    let otherEnd = (association.memberEnd - self)->any() in
    if otherEnd.owningAssociation->empty() then otherEnd else Set{} endif
    else Set {}
    endif

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8451 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Kernel/missing merges

  • Key: UML22-489
  • Legacy Issue Number: 6197
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Kernel does not merge Abstractions::Namespaces, Abstractions, Multiplicities, Ownerships, and Visibilities

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Package merge/redefinitions issue - lost association ends

  • Key: UML22-488
  • Legacy Issue Number: 6194
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There is a subtle problem with redefinitions resulting from package merge. Property names have to match by name or the merging property has to redefine the merged property, AND the property types have the same name. Otherwise association ends are lost. For example, consider package Communications which is merged into BehaivorStateMachines. Communications has association ownedBehavior:Behavior <--> context:BehavioredClassifier (ignoring multiplicities to keep the text simpler). BehaviorStateMachines has class StateMachine which specializes Behavior, and has association ownedStateMachine:StateMachine

    {redefines ownedBehavior}

    <--> context:BehavioredClassifier. After the merge, merging BehavioredClassifier must contain two properties for ownedBehavior:Behavior and ownedStatemachine:StateMachine. Otherwise the association to the superclass is lost. This is a case where a class ends up redefining one of its own properties, and where ! the redefined and redefining properties both appear in the merged result.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Super/missing merge

  • Key: UML22-487
  • Legacy Issue Number: 6187
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package Super isn't merged anywhere, so the constraints it adds to Classifier are never included in L3

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

raisedException

  • Key: UML22-493
  • Legacy Issue Number: 6275
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    Reviewing of the Rose MDL file the diagram Constructs::Operations (Class Diagram) displays raisedException as a reference from both BehavioralFeature as well as Operation. Operation inherits from BehavioralFeature as well.

    I believe this violates a well-formedness rule that all structural features must be distinguishable.

  • Reported: UML 1.5 — Thu, 18 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 8461 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Templates / TemplateParameter not named

  • Key: UML22-492
  • Legacy Issue Number: 6262
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    TemplateParameters do not appear to be namable. They inherit from Element and not NamedElement. In UML 1.5 they inherited from ModelElement (i.e. were namable). They need to be named to be referred to in the implementation of the template.

  • Reported: UML 1.5 — Tue, 23 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.75/kinds of changeability

  • Key: UML22-491
  • Legacy Issue Number: 6216
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 75: StructuralFeature::isReadOnly
    Limits severely limits previous capabilities to define various kinds of changeability. Even if some people think that the varieties of changeablity are not right, we should make this an enumerated value to provide extensibility for profiles. Call it "changeablity" as before. Should have enum values:

    Changeable (unrestricted)

    readOnly (no changes after initialization)

    [Note that the meaning and semantics of "initialization" are completely undefined, so this isn't all that useful.]

    The following additional choices were available in UML1:

    CreateOnly (add a set any time after initialization but no further changes)

    addOnly (may add members to the set but not change or remove any)

    Both of these occur in practice often enough.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 9.3.4 page 161, Presentation Option

  • Key: UML22-496
  • Legacy Issue Number: 6423
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    The statement "A dashed arrow with a stick arrowhead may be used to show that a collaboration is used in a classifier, optionally labelled with
    the keyword «represents»." and the accompanying example are confusing. Please clarify what this presentation option is trying to accomplish.

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Kernel features / cannot exclude superclass properties

  • Key: UML22-495
  • Legacy Issue Number: 6398
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In practice it is not always possible to refactor class hierarchies to ensure that all attributes are defined in the appropraite classes in that hierarchy. For example, a class hierarchy may be supplied by a third party or may be used by multiple products whereas the refactoring may only be required in a subset of them. In such cases, it is extremely useful to be able to exclude undesirable features inherited from a superclass. This einently practical technique should be supported in UML to allow those systems that use that feature to be properly modeled.

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Syntax of names

  • Key: UML22-494
  • Legacy Issue Number: 6389
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue: The UML infrastructure specification does not specify the syntax for names. This prevents model interchange.

    Proposal: Specify the syntax for the string in Name. At least, the characters that may be used in names, and any rules about where in the name certain characters may not (or may) appear.

    Include in the syntax specification a list of characters used in (or excluded from) names using (seven and) eight bit characters and a list of characters used in (or excluded from) names using sixteen bit characters.

    [After a quick glance, the rules sent to the UML 2 Superstructure FTF mail list looks like it will do the job. Or, in any event, get us started.]

  • Reported: UML 1.5 — Wed, 22 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Issue: definition of navigability

  • Key: UML22-501
  • Legacy Issue Number: 6460
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    There is no definition for navigability or navigation in the Spec. Other
    concepts of similar importance, such as visibility, multiplicity, etc., are
    defined in the Spec, so it is not clear why it should be assumed that this
    concept does not require a definition.

    PROPOSED SOLUTION
    Add definition in Section 4 (Terms and definitions): The navigability of a
    binary association specifies the ability of an instance of the source
    classifier to access the instances of the target classifier by means of the
    association instances (links) that connect them. Navigability is closely
    related to the possibility of sending messages through associations (a
    message cannot be sent through an association instance against its
    navigability, that is, navigability is required for sending messages through
    associations), but they remain nonetheless different concepts.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This issue was resolved in UML 2.1 where an explanation of navigability was provided (see page 41 top in formal/07-02/05) Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use 'represent' for the relationship of a model

  • Key: UML22-500
  • Legacy Issue Number: 6456
  • Status: closed  
  • Source: Anonymous
  • Summary:

    "An instance specification is a model element that represents an instance in a modeled system." [7.7.1] That is, the relationship of the instanceSpecification with a class to an object of that class is the representation relationship.

    At the same time, a lifeline represents a connectable element. [14.2]

    This is an example of a recurrent problem in the specification: model elements that represent other model elements.

    At the same time, "attributes of a class are represented by instances of Propert[ies]..."

    This is an example of an occassional and quite striking problem in the specification: items in the modeled system that represent model elements.

    The theory of representation needs to be settled. That done, the specification needs to be reviewed with this in mind and all improper uses of representation corrected.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rose Model of UML 2.0 spec

  • Key: UML22-506
  • Legacy Issue Number: 6501
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Class Diagram:Constructs/Packages in the Rose file shows the
    nestedPackage/package association the spec shows
    nestedPackage/nestingpackage

    I believe the spec to be in error...

    I am not sure where to report this and or who keeps this model up to
    date. Any recommendations would be appreciated

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ptc-03-09-15/Relationships among Core packages

  • Key: UML22-505
  • Legacy Issue Number: 6496
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: The superficial impression that Core::Abstractions is the lowest
    layer in the U2P Core does not stand up under close examination.
    Core::Basic is closer to being the fundamental layer because it uses none of
    the new association modeling constructs (such as derived unions and subsets)
    to define itself; but is not entirely so because it imports two packages
    from Abstractions.

    Recommendation: It would be worth considering whether the two packages that
    Basic imports from Abstractions can be placed in Basic, so that Basic is
    unambiguously the lowest layer in Core. This would also make EMOF
    unambiguously the lowest-—i.e. the most fundamental—-layer of MOF, since
    EMOF is based on Core::Basic while CMOF is based on Core::Constructs.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Move Comment into Basic and add Kind

  • Key: UML22-547
  • Legacy Issue Number: 7782
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Move Comment into Basic and add Kind
    The ability to annotate and describe elements and diagrams is pretty
    fundamental so should be included in Basic.
    There should also be the recognition that there are different kinds of
    comment: for example most tools have a dialog allowing people to enter a
    Description for an Element; and separately may allow the element to be
    annotated on diagrams in a particular context. At the moment there is no
    way to distinguish these.
    The UML Metamodel itself is an example of the need for different kinds
    of Comment: each Class has a number of distinct sections (e.g.
    Description, Semantics, Notation).
    Hence there should be a 'kind' attribute on Comment to reflect this.

  • Reported: UML 1.4.2 — Fri, 24 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unconsistent Profile extension description (02)

  • Key: UML22-546
  • Legacy Issue Number: 7757
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    18.3.5 says that "A profile by definition extends a reference metamodel or another profile."
    While in theory I could see how it might be modeled, I don't see how the latter could work in practice with real tools. Let's extend the current example and define a new Profile called ClockTechnology with Stereotype AtomicClock with baseClass Clock and property radioactiveElement:String..."

    Import between profiles is supported, and stereotype generalization is the usual way to achieve what has been called "extending a profile".

    The reference to profile extension should be simply discarded. A profile extends a reference metamodel.
    .

    Discussion

    In Profiles:Profile:semantics, change the first sentence

    A profile by definition extends a reference metamodel or another profile.

    Into

    A profile by definition extends a reference metamodel.

  • Reported: UML 1.4.2 — Fri, 3 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unconsistent association extension description

  • Key: UML22-545
  • Legacy Issue Number: 7756
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    b) More worryingly, 18.3.5 Semantics also says "As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel." I fail to see how a profile could in fact could cause an association between 2 stereotypes to subset an existing association in a reference metamodel since the stereotypes do not at all inherit from the baseClasses so do not inherit any of its properties or associations in order to be able to subset them: this is emphasized by the MOF representation shown in the new Figure 447.

    Indeed profiles do not support association subsetting. This should be made clear in the spec to avoid any confusion while using profiles.
    .

    Discussion

    In Profiles:Profile:semantics, change the paragraph

    As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass unless they are subsets of existing associations in the reference metamodel.

    Into

    As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass.

  • Reported: UML 1.4.2 — Fri, 3 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 11.7

  • Key: UML22-538
  • Legacy Issue Number: 7343
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    In the manner of representing the relationship between BehavioralFeature and Parameter the infrastructure imposes either a limit on the nature of parameters on modeling languages reusing the infrastructure or forces them to duplicate this mechanism. The infrastructure decided to represent as concrete associations the kinds of parameters, and distinguishes two: returnResult and formalParameter. The parameter association is then derived as a union of these. However, there may be a large number of parameter kinds. For example, the superstructure defines four, and one can easily imagine additional ones. To be more reusable and expandable, parameter should be characterized by its kind (does it return a result, is it a formal parameter). Note that this is, in reality, a property of the parameter, not of the relation between BehavioralFeature and Parameter and thus is modeled better this way anyway. Define an attribute "direction" on Parameter of type "ParameterDirectionKind". In infrastructure give it two values: in, and returnResult. This type can be extended in other languages, e.g., the UML uses also out, and inout). Make BehavioralFeature.parameter concrete. Make the formalParameter and returnResult associations derived from the direction attribute of each parameter. The result is the identical model, but much more reusable. Note that the superstructure was forced to introduce both mechanisms, thus running into the risk of inconsistencies, if the two mechanisms do not match up. There is no negative impact on the infrastructure of relying on the more reusable option proposed here. The number of model elements stored in the repository is identical for infrastructure, and lower for superstructure.

  • Reported: UML 2.0 — Sun, 16 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

simple time model" in CommonBehavior

  • Key: UML22-537
  • Legacy Issue Number: 7303
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    For the "simple time model" in CommonBehavior, it is unclear when the DurationObservationAction and TimeObservationAction would be executed. For one, it is not stated when these actions are executed. I assume that when the execution of the model reaches the point of the attached model elements, then these actions are executed. Several problems: It is unclear what determines when these actions are executed. If the actions are embedded in a sequence of actions, where control flow indicates when they execute, what is the meaning of the association to a named element? If that named element is reached later in the execution, does the execution wait? If it is reached earlier, does that element have to wait until the action sequence is enabled? (ii) There should be some constraint on the "NamedElements" associated with TimeExpression that limits those to elements that can be enountered during execution, as these elements appear to determine when these actions are evaluated. There is a tension between these actions being embedded in a sequence of actions where their execution is determined by the control and data flow, and the associated "NamedElements" that would determine the observation of time also. Normally, actions are used within a sequence of actions (an activity). These two actions are different in that they seem to make no sense within an activity due to that they have very special invocation points. They seem to only make sense as stand-alone elements. Maybe it should not be an action, but some other model element, that should dictate how time and duration are observed.

  • Reported: UML 2.0 — Wed, 5 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed as part of the resolution to issue 8894 in UML 2.1 Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problem with diagram references in Profiles section

  • Key: UML22-551
  • Legacy Issue Number: 7909
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    2nd paragraph in Stereotype Semantics does not have proper cross-references to the figures and hence they have not been updated as other figures have been inserted. The para currently reads:
    An instance "S" of Stereotype is a kind of (meta) class. Relating it to a metaclass "C" from the reference metamodel (typically UML) using an "Extension" (which is a specific kind of association), signifies that model elements of type C can be extended by an instance of "S" (see example Figure 454). At the model level (such as in Figure 457) instances of "S" are related to "C" model elements (instances of "C") by links (occurrences of the association/extension from "S’ to "C").

    But the 2 references should be to Figure 456 and Figure 461 respectively.

  • Reported: UML 1.4.2 — Sun, 14 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Design principles

  • Key: UML22-550
  • Legacy Issue Number: 7908
  • Status: closed  
  • Source: none ( Markus Flueckiger)
  • Summary:

    have a general problem with the UML 2.0 specification. A graphical modelling language is essential for succesful software development. However the more I read about UML 2.0 the more I had the impression that UML 2.0 has not been developed with actual real-world software development in mind. Just to give one highlight of UML 2.0 is the merge relation between packages: The relation leads to bad designs and incomprehensible software systems, e.g. like like badly designed inheritance hierarchies etc. Especially consider the following case: a trifle change in the diagram (change the merge relationship into e.g. an access relationship) causes a tremendous amount of changes on the code and the configuration level. The only way to handle this is to forbid the merge relationship and to hope that nobody is blind enough to actually use it. Reading the manual, I stumbled over numerous similar issues. I'm sorry to say but I'm very disappointed with UML 2.0 as it is

  • Reported: UML 1.4.2 — Wed, 10 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The specification is fond of using 'typically.'

  • Key: UML22-544
  • Legacy Issue Number: 7407
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    The specification is fond of using 'typically.' The term should be use with care in a specification. Typically, 'must' or 'may' are better choices. For example, at 7.4.1 p.42: The multiplicity bounds are typically shown in the format: lower-bound..upper-bound It will be better to write: The multiplicity bounds are shown in the format: lower-bound..upper-bound simply deleting 'typically.' (In this case, the syntax specification should show the case when the two bounds are equal.)

  • Reported: UML 2.0 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TimeObservationAction and DurationObservationAction

  • Key: UML22-543
  • Legacy Issue Number: 7406
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    TimeObservationAction and DurationObservationAction are described as actions, but are not really actions like the actions of the action chapter. They would never be used when defining a behavior, but are part of a metalanguage to define temporal constraints and to refer to measured times and durations in formulating such constraints. However, these two elements are the only aspects of this language, everything else is left to be defined later (see TimeExpression). Putting these two mechanisms into the specifications unduly constrains any profile that would want to define a notation for expressing temporal constraints. Such a language might not see a need to use the actions described in this chapter. My recommendation is to find a different way of expressing time observations and duration observations in the metamodel. The syntax examples clearly show that they are not meant to be used within an activity as actions. Note that the only way to use these observations is to create a "fake" activity attached to the interaction (e.g., as a nestedClassifier) which contains only this action. A rather convoluted and heavy-weight means of expressing the simple concept of "NOW" (as the point in time when some model element is executed). A simpler mechanism is clearly needed.

  • Reported: UML 2.0 — Sat, 29 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: Fixed as part of the resolution to issue 8894 in UML 2.1 Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

add an interaction fragment

  • Key: UML22-541
  • Legacy Issue Number: 7397
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Sequence diagrams are often used to describe abstract system behavior in the form of the interaction of the system with its environment. Experience has shown that systems have normal behavior and exceptional behavior (in response to unusual or unexpected events). UML2 has introduced a mechanism of representing exceptions. However, interactions do not give us a vehicle of showing exceptional behavior. Recommendation: add an interaction fragment indicating exceptional handling similar to the way this is done in the activity chapter.

  • Reported: UML 2.0 — Sun, 30 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interactions model sequences of events

  • Key: UML22-540
  • Legacy Issue Number: 7392
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Interactions model sequences of events. The metaclass EventOccurrence represents the occurrence of an event. Currently, there are the following kinds of events known: i. sending of a message ii. receiving of a message iii. start of the execution of a behavior iv. finish of the execution of a behavior v. stop First, clearly, there could be many more events that one might want to represent on a lifeline. In particular, the invocation of an action is a possible event, and should be allowed to be represented. Secondly, event occurrence is modeled poorly. It is shown as a kind of message end, which means that every event occurrence inherits the notion of being a message end point, even if the event has nothing to do with a message (such as a stop event). Clearly the inheritance hierarchy is inverted. A message end can represent an event occurrence (such as the sending or receiving of a message). But not every event occurrence is a message event.

  • Reported: UML 2.0 — Sat, 29 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This was fixed in UML 2.1 Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify example in figure 133

  • Key: UML22-539
  • Legacy Issue Number: 7362
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Could you describe in details the meaning of the example described in Figure 133, because it could very useful to understand the deployment specification concept. Moreover, is there anything lacking in figure 134? It contains no model element with the <<deployment specification>> stereotype.

  • Reported: UML 2.0 — Wed, 19 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XMI schema

  • Key: UML22-542
  • Legacy Issue Number: 7401
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "[C]omplying with a package requires complying with its abstract syntax, well-formedness rules, semantics, notation and XMI schema," [2] but there is no XMI schema. "It is expected that the normative XMI for this specification will be generated by a Finalization Task Force, which will architectually align and finalize the relevant specifications." [Appendix F] That is consistent with the OMG Document Archives, which show: ad/03-04-02: XMI for U2 Partners' UML 2.0: Superstructure, 3rd. revision (Contact: Mr. Cris Kobryn) No description of this document is available. Formats: Note: Not yet available. An XMI schema should be supplied, or the requirement to comply with an XMI schema should be removed.

  • Reported: RAS 2.0b1 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DataType attributes UML 2 Super (ptc/04-10-02)

  • Key: UML22-552
  • Legacy Issue Number: 7938
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    On Figure 13, DataType::ownedAttribute is specified as ordered but in the
    associations section on page 59, it is not specified as ordered.

  • Reported: UML 1.4.2 — Fri, 19 Nov 2004 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    See issue 7939 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Constructs/owningComment

  • Key: UML22-486
  • Legacy Issue Number: 6176
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Constructs association owningCommet:Element[0..1] c-> ownedCommet:Comment[0..*] should have been owningElement:Element[0..1] c-> ownedCommet:Comment[0..*] as defined in Kernel/Root.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Classes diagram of the Core::Constructs package

  • Key: UML22-485
  • Legacy Issue Number: 6006
  • Status: closed  
  • Source: Honeywell ( Steven Hickman)
  • Summary:

    In the Classes diagram of the Core::Constructs package, the references to StructuralFeature, Relationship, Type, and Classifier have no cross-reference to the package where they were originally defined, whereas other concepts in this diagram do. It is clear from the fact that some of these concepts are involved in derived roles or relationships, that they MUST have been defined somewhere else.

    The document needs to be fixed so that it is self consistent and so that proper cross-references are indicated.

  • Reported: UML 2.0 — Sat, 19 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

cross-reference missing

  • Key: UML22-484
  • Legacy Issue Number: 6005
  • Status: closed  
  • Source: Honeywell ( Steven Hickman)
  • Summary:

    The reference to TypedElement in the Expressions diagram for Core::Constructs makes no cross-reference to the definition of TypedElement in Core::Abstractions::TypedElements or Core::Basic.

    Is it a reference to either of these or is it yet another definition of a concept with the same name?

  • Reported: UML 2.0 — Sat, 19 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Relationship and DirectedRelationship in Core::Constructs

  • Key: UML22-483
  • Legacy Issue Number: 6004
  • Status: closed  
  • Source: Honeywell ( Steven Hickman)
  • Summary:

    There doesn't seem to be any value in the specialization of Relationship and DirectedRelationship in Core::Constructs from their definitions in Core::Abstractions::Relationships. The documentation clearly states that the specializations don't add anything to the either concept. In fact, it appears that this can be said for everything in the Core::Constructs Root Diagram.

    If this is the case, why do these specializations exist? The UML spec is big enough - there is no point in adding things that don't need to be there. If the goal is to merely create a single diagram that includes concepts and relationships that were previously spread across multiple diagrams, then why not simply create the diagram and have every contained concept refer to the package where it was originally defined?

    If there is a compelling reason for these specializations, then that reason needs to be spelled out in the spec - because it isn't obvious to me.

  • Reported: UML 2.0 — Sat, 19 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

document appears to be inconsistent in how it handles concepts

  • Key: UML22-482
  • Legacy Issue Number: 6003
  • Status: closed  
  • Source: Honeywell ( Steven Hickman)
  • Summary:

    This document appears to be inconsistent in how it handles concepts with the same name. In some cases, the class diagrams make it clear that a concept is being imported from one package to another by reference. However, there are a lot of cases where the same concept name is used in separate packages but it is not clear if it is the same concept, a parallel concept, or a refinement of the concept.

    In many cases the documentation of the concepts is the same (or nearly so) everywhere it appears. This tends to imply that it is, in fact, the same concept. However, if this were the case, then it should be defined in one package and imported by reference in other packages. On the other hand, since the import by reference is actually done in some cases, that tends to imply that, where the import by reference is not done, something else significant is going on. What that significant thing "is" is never made clear - at least not as far as I can tell.

    I suspect the same problem exists in the UML 2.0 Superstructure submission because they were both written by the same group.

    Proper understanding of the metamodel becomes impossible without this issue getting resolved. Someone needs to go through both of these documents and locate every place the same concept name is used in multiple packages and make sure it is clear how the concepts with the same name in different packages relate to each other.

  • Reported: UML 2.0 — Sat, 19 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Designates a Generalization

  • Key: UML22-477
  • Legacy Issue Number: 5794
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text:

    Designates a Generalization whose parent GeneralizableElement is the immediate ancestor of the current GeneralizableElement.

    disagrees in plurality with the * cardinality of the generalization association end between GeneralizableElement and Generalization in the Core Package - Relationships diagram (Figure 2-6) on page 2-14.

  • Reported: UML 1.4 — Sun, 15 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Namespace issue (UML 1.4 formal/2002-09-67, 2.5.3.26 Namespace )

  • Key: UML22-476
  • Legacy Issue Number: 5593
  • Status: closed  
  • Source: blomesystem ??????? ( Michael Zavyalov)
  • Summary:

    The Namespace has the following definition constraint (p. 2-64): [1] The operation contents results in a Set containing all ModelElements contained by the Namespace. contents : Set(ModelElement) contents = self.ownedElement -> union(self.namespace, contents)

    The errors: 1. Syntax error in the union operation. According to Object Constraint Language Specification set has operation (p. 6-38) set->union(set2 : Set(T)) : Set(T) with the single parameter !

    2. The functions contents and allContents are used to receive all composite and aggregate elements of namespace according to specification of these functions (Is that right ?). For example all overriden functions in the descedent elements (Package, DataType) release these functions in this manner. In this case function contents must be realized as: contents = self.ownedElement 3.The functions contents and allContents is sometimes used to receive list of «accessable» objects ! For example: definition constraint #2 for BehavioralFeature (p. 2-54): [2] The type of the Parameters should be included in the Namespace of the Classifier. self.parameter->forAll( p | self.owner.namespace.allContents->includes (p.type) ) Why parameter can't use imported DataType ? Why parameter can't use DataType located in the Namespace binded with the namespace of classifier by «friend» Permission ? Note that DataType may be included in the namespace of namespace of owner. It also may be included directly into owner ! I may send the collection of such errors («contents» instead of «acessable»).

  • Reported: UML 1.4 — Sun, 25 Aug 2002 04:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This is an issue raised against the UML 1 metamodel, which is no longer valid. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sending a signal after a delay

  • Key: UML22-475
  • Legacy Issue Number: 4937
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    Sending a signal after a delay

  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    The feature requested is already supported in UML 2.1: Precede an action by an AcceptEventAction, where the latter references a trigger that refers to a TimeEvent. Thus, for example, if you have a sequence of an AcceptEventAction with a TimeEvent specifyinig the desired delay and a SendSignalAction, then the signal will not be sent until the delay has passed. Note that this feature is extremely generic, probably giving the user even too much support (you can define a statemachine purely with actions, if there are not proper constraint placed on the events allowed in the AcceptEventAction).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Does visibility apply to creating an destroying links?

  • Key: UML22-474
  • Legacy Issue Number: 4448
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    It isn't clear whether visibility of association ends applies to
    creating and destroying links. If it does, then what if one end is
    private and the other public, can the private end create or destroy
    a link?

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

relationship should just be a cross-reference

  • Key: UML22-481
  • Legacy Issue Number: 6002
  • Status: closed  
  • Source: self ( Steve Hickman)
  • Summary:

    There is no clear relationship between NamedElement, TypedElement and Type as defined in Core::Basic and items by the same name in Core::Abstractions::Namespaces and Core::Abstractions::TypedElements. There is no reference between the two although the concepts seem identical.

    It seems like the relationship should just be a cross-reference. However, is it a type-instance relationship? Or is a refinement relationship (as can be seen in other parts of the spec)? Or is it something else? What is going on here?

  • Reported: UML 1.5 — Sat, 19 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

formal/03-03-01 : Omission of definition of Class "Action"

  • Key: UML22-480
  • Legacy Issue Number: 5907
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I believe I found an omission from the UML 1.5 Specification formal/03-03-01:

    p. 2-112, Fig. 2-18: Association between "Message" and "Action (from Common Behavior)"

    In Sec. 2.9 Common Behavior; none of the diagrams or text specify Class "Action".

    p. Index-1 cites "Action" p 2-103.

    p. 2-103 has no mention of "Action".

    The first item in Sec. 2.9.3 is "2.9.3.1 AttributeLink", not "2.9.3.1 Action" as would be alphabetized.

    My question is what is definition of the "Action" Class in Fig. 2-18?

  • Reported: UML 1.5 — Mon, 21 Apr 2003 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specify XMI parameters for the UML / XMI interchange format

  • Key: UML22-473
  • Legacy Issue Number: 3898
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    When the UML spec standardises an XMI-generated interchange format for
    UML
    models, it should include:

    • the "input" MOF meta-model for UML that was used to generate the
      interchange format, and
    • a formal statement of the other XMI "parameters" used to generate
      the interchange format.

    If possible, the UML spec should include a definitive meta-model for
    UML
    expressed as a MOF / XMI document. This is a MOF alignment issue.

  • Reported: UML 1.3 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

logic upperbound is the same as the lower bound.

  • Key: UML22-479
  • Legacy Issue Number: 5896
  • Status: closed  
  • Source: Anonymous
  • Summary:

    3] The operation lowerbound returns the lowest lower bound of the ranges in a multiplicity. lowerbound( ) : Integer; lowerbound = self.range->exists(r : MultiplicityRange |r.lower = result) and self.range->forall(r : MultiplicityRange |r.lower <= result) [4] The operation upperbound returns the highest upper bound of the ranges in a multiplicity. upperbound( ) : UnlimitedInteger; upperbound = self.range->exists(r : MultiplicityRange |r.upper = result) and self.range->forall(r : MultiplicityRange |r.upper <= result) =============================================

    according to the logic upperbound is the same as the lower bound.

    should the upperbound read as r.upper >= result instead of r.upper <= result on the last line?

  • Reported: UML 1.5 — Fri, 4 Apr 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2.27 ModelElement

  • Key: UML22-478
  • Legacy Issue Number: 5804
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text "deploymentLocation The set of locations may differ. Often it is more restrictive on the child." has no corresponding association in any diagram. The closest match is documented in 2.5.2.12 Component on pages 2-31 and 2-32. If this is the non-inherited feature discussed on page 2-44 is it not redundant and doesn't it cloud the meaning of the feature?

  • Reported: UML 1.4 — Thu, 19 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Classes / dependencies should be unidirectional

  • Key: UML22-511
  • Legacy Issue Number: 6630
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the metamodel, UML::Classes::Dependencies::NamedElement::supplierDependency should not be navigable, as it does not make sense for the supplier of a dependency to know about its dependencies

  • Reported: UML 1.5 — Wed, 26 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

two classes "NamedElement

  • Key: UML22-510
  • Legacy Issue Number: 6525
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Secondly, there are two classes "NamedElement" holding un-redefined
    attribute "name", one is in the
    package "InfrastructureLibrary.Core.Basic", and the other is in the
    package "InfrastructureLibrary.Core.Abstractions.Namespaces". The
    problem is that there are a lot of classes directly or indirectly
    inheriting both of them e.g. class "InstanceSpecification" in package
    uml.classes.kernel, and it causes problem of duplicated parameters in
    class creation in the generated JMI interfaces. e.g.
    "
    public InstanceSpecification createInstanceSpecification
    (java.lang.String name,
    infrastructurelibrary.core.abstractions.visibilities.VisibilityKind
    visibility, java.lang.String name, java.util.Collection classifier);
    "
    Similiar cases happen to attribute "type", "isAbstract" etc.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

well-formedness rules are not numbered correctly

  • Key: UML22-515
  • Legacy Issue Number: 6641
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The well-formedness rules are not numbered correctly. After the note in the middle of the page, the numbering scheme starts over at [1] instead of going on to [10].

  • Reported: UML 1.5 — Wed, 26 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

number of the figure is wrong

  • Key: UML22-514
  • Legacy Issue Number: 6640
  • Status: closed  
  • Source: Anonymous
  • Summary:

    At the bottom of page 2-216, the paragraph "This life cycle may be depicted informally using a statechart diagram, as shown in Figure 2-39." should actually read "This life cycle may be depicted informally using a statechart diagram, as shown in Figure 2-40." The number of the figure is wrong.

  • Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.5 table of contents

  • Key: UML22-520
  • Legacy Issue Number: 6665
  • Status: closed  
  • Source: EWSolutions ( Patrick Cross)
  • Summary:

    The example text <Company xmi:id="Company_1" name="Acme"> <HQAddress xmi:id="Address_1" Street="Side Street" </Company>City="Hometown"/> should be <Company xmi:id="Company_1" name="Acme"> <HQAddress xmi:id="Address_1" Street="Side Street" City="Hometown"/> </Company>

  • Reported: XMI 2.0 — Wed, 3 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In the last paragraph, the period after the word "collections" on the secon

  • Key: UML22-519
  • Legacy Issue Number: 6662
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In the last paragraph, the period after the word "collections" on the second line should be removed

  • Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11

  • Key: UML22-518
  • Legacy Issue Number: 6661
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    In paragraph 5, the addition of 2, 5, 7 and -3 does not yield 9 but 11. That's why "...subaction Addition is the scalar 9." should read "...subaction Addition is the scalar 11."

  • Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The multiplicity of association named subaction of type Action ill formed

  • Key: UML22-517
  • Legacy Issue Number: 6660
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The multiplicity of the association named subaction of type Action is ill formed. Instead of [1..] it should read [1..1].

  • Reported: UML 1.5 — Mon, 1 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operations and derived attributes

  • Key: UML22-521
  • Legacy Issue Number: 6692
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    I am looking at ValueSpecification which introduces Additional Operations, such as integerValue(). My question is : What is the reasoning behind making these Operations vs. Derived attributes?

    In MultiplicityElement we have a derived attribute lower which is equal to lowerBound(). What logic is used to determine whether an Operation has a corresponding Attribute?

    Also the spec seems to indicate that all derived values will be implemented via some operation. Is this a requirement or an assumption of implementation?

    Why can’t lower in MultiplicityElement simple be defined as if lowerValue->notEmpty() then 1 else lowerValue.integerValue()… what makes the lowerBound() operation required?

  • Reported: UML 1.5 — Wed, 10 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

class "InfrastructureLibrary.core.constructs.Association",

  • Key: UML22-509
  • Legacy Issue Number: 6524
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    found something strange in the specification of UML 2.0.
    First of all, in the
    class "InfrastructureLibrary.core.constructs.Association", there is
    an attribute "ownedEnd" with return type
    of "InfrastructureLibrary.Core.Constructs.Property" and 0...*; and it
    its direct subclass "infrastructurelibrary.profiles.Extension", there
    is an attribute "ownedEnd" which redefines ownedEnd in
    class "Association", but with return
    type "infrastructurelibrary.profiles.ExtensionEnd" and multiplicity
    of 1. It causes conflicts of generated JMI interface.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

remove paragraph

  • Key: UML22-513
  • Legacy Issue Number: 6639
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The paragraph starting at the bottom of page 2-200 with "A user model uses instances..." and finishing at the top of page 2-201 describes figure 2-37 which has been removed from the specification 1.4 when transiting to 1.5. Thus, the paragraph should be either adapted to reflect the change or removed.

  • Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Infra/Metamodel/missing derivation indicators

  • Key: UML22-512
  • Legacy Issue Number: 6637
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package::nestedPackage and Profile::ownedStereotype should be derived, just as Package::ownedType is (all three subset Package::ownedMember). In general, if the contents of a subset are determined soley by type (and the superset property is not derived), the subset property should be derived.

  • Reported: UML 1.5 — Fri, 21 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1.2
  • Disposition Summary:

    Discussion: This was fixed in release 2.1. Revised Text: N/A Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

multiplicity of the association named "type" of type DataType

  • Key: UML22-516
  • Legacy Issue Number: 6659
  • Status: closed  
  • Source: Condris Technologies ( Valentin Crettaz)
  • Summary:

    The multiplicity of the association named "type" of type DataType is given as [1..1}. It should be [1..1], i.e. with square brackets instead of curly braces

  • Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Behaviors Owned by State Machines

  • Key: UML22-327
  • Legacy Issue Number: 11076
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    State and Transition currently own the behaviors that they invoke. This is very restrictive because it makes it impossible to reuse Behaviors across state machines, or even across transitions and states.

    Consider allowing States and Transitions to merely reference behaviors rather than owning them.

  • Reported: UML 2.1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Interesting idea, but it's too large a change to be considered for the current RTF. 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

Section: 12.3.41 Streaming parameters for actions

  • Key: UML22-326
  • Legacy Issue Number: 11069
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Semantics, 2nd paragraph about streaming: "Streaming parameters give an action access to tokens passed from its invoker while the action is executing. Values for streaming parameters may arrive anytime during the execution of the action, not just at the beginning." Since an action represents a single step and is atomic. I think it is not possible that an atomic action comsumes further parameters during execution.

  • Reported: UML 2.1.1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The stated issue presumes that action execution is atomic, which is not necessarily the case, and is certainly not the case for a call action to a behavior with streaming parameters. The whole point of streaming parameters is the semantics given in the quoted sentence, and they would be useless if this was not possible.
    However, the quoted sentence is poorly worded, since it is behaviors that have parameters and are invoked, not actions. This may be causing the confusion and should be corrected.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.3.24

  • Key: UML22-316
  • Legacy Issue Number: 10960
  • Status: closed  
  • Source: International Business Machines ( Mr. Anders Ek)
  • Summary:

    There is an association defined for the Signal metaclass as follows: signal: Signal [1] The signal that is associated with this event. It is unclear what this associaiton is intended to represent. Should this association really be there?

  • Reported: UML 2.1.1 — Thu, 19 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disucssion: Duplicate of 9576. Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.14

  • Key: UML22-315
  • Legacy Issue Number: 10959
  • Status: closed  
  • Source: International Business Machines ( Mr. Adam Neal)
  • Summary:

    On page 569 in section 15.3.4 (Transitions), constaint # 5 identifies which outgoing transitions, given their source pseudostates, may not have triggers: [5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and ((source.kind <> #junction) and (source.kind <> #join) and (source.kind <> #initial)) implies trigger->isEmpty() This OCL is incorrect since transitions leaving either a Junction Point, Initial State or a Join should not have triggers. The given OCL specifies the inverse - that only those pseudostates may have triggers. One contradiction to the above OCL exists on page 537 in section 15.3.8 (Pseudostates), constraint #9: [9] The outgoing transition from an initial vertex may have a behavior, but not a trigger or guard. (self.kind = PseudostateKind::initial) implies (self.outgoing.guard->isEmpty() and self.outgoing.trigger->isEmpty()) Furthermore, transitions leaving a fork are also not allowed triggers (constraint #1), so this could also be contained in the transition's OCL constraint (#5). Therefore the OCL for constraint #5 should be written as: [5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and ((source.kind = #junction) or (source.kind = #join) or (source.kind = #initial) or (source.kind = #fork)) implies trigger->isEmpty()

  • Reported: UML 2.1.1 — Wed, 18 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Text has already been fixed in the UML 2.2 specification to be
    [5] Transitions outgoing pseudostates may not have a trigger (except for those coming out of the initial pseudostate).
    (source.oclIsKindOf(Pseudostate) and
    (source.kind <> #initial)) implies trigger->isEmpty()
    which resolves the above issue

    Revised Text:
    N/A

    Disposition: ClosedNoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong subsets

  • Key: UML22-321
  • Legacy Issue Number: 11008
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client).

    ComponentRealization incorrectly subsets supplier to define realizing Classifiers (implementation).

    Required changes:

    "abstraction" must subset "supplier" and "realizingClassifier" must subset "client".

  • Reported: UML 2.1 — Wed, 16 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Section 7.3.45 does indeed make it clear that the specification is the supplier and the implementation is the client. The implementation depends upon the specification; the specification does not depend upon the implementation.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.11

  • Key: UML22-320
  • Legacy Issue Number: 10976
  • Status: closed  
  • Source: Paranor AG ( Earl Waldin)
  • Summary:

    State.stateInvariant should subset ownedRule The stateInvariant property of State currently subsets Element.ownedElement. Given that a State is a Namespace and a stateInvariant is a Constraint, the stateInvariant property of State should subset ownedRule. Likewise, the opposite end of this association should subset Constraint.context instead of Element.owner. This change is needed so that a state invariant has a context and, thus, can be specified using OCL.

  • Reported: UML 2.1.1 — Mon, 30 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

information flow source and target

  • Key: UML22-328
  • Legacy Issue Number: 11090
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    UML 2.1.1 includes fix - "source" and "target" of InformationFlow are renamed to "informationSource" and "informationTarget".
    These changes are made in diagrams, but not in text under InformationFlow chapter (17.2.1).

  • Reported: UML 2.1 — Wed, 6 Jun 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

description of 14.3.24 MessageSort (from BasicInteractions) - typo

  • Key: UML22-318
  • Legacy Issue Number: 10967
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    On page 495, in the description of 14.3.24 MessageSort (from BasicInteractions) , the definition of createMessage seems not to start on a new line, instead following straight on from the definition of asynchSignal

  • Reported: UML 2.1 — Sun, 22 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

drawing a frame to represent Combined Fragment or an Interaction Occurrence

  • Key: UML22-317
  • Legacy Issue Number: 10966
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    I seem to remember that when drawing a frame to represent a Combined Fragment or an Interaction Occurrence there is a notation that indicates whether a given lifeline overlapped by the frame is actually covered by the fragment/occurrence or not. I believe that it hinged on whether the frame obscured the lifeline or not. However, I can't find reference to it in the spec. It would be good to have this notation described with an example, to avoid different vendors inventing their own notations.

  • Reported: UML 2.1 — Sun, 22 Apr 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion: It is correct that there is no such notation suggested in the standard. The ITU standard Z.120 has a specific notation for lifelines that are not covered by a combined fragment, but we have not included that in UML 2. The reason, I believe, is that it is basically a matter of taste whether you want to include as covered in a combined fragment a lifeline that has no internal fragments (such as occurrence specifications). Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14 Interactions: Lifeline representing an actor

  • Key: UML22-325
  • Legacy Issue Number: 11068
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It is common usage to model a lifeline in a interaction that represents an actor. I can't see how that could be done formally correct. A lifeline represents a connectable element, e.g. a property. It is not allowed to define a property that is typed by an actor.

  • Reported: UML 2.1.1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9 Composite Structures / Port notation

  • Key: UML22-324
  • Legacy Issue Number: 11067
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    It is unclear if it is allowed to show the provided and required interfaces of a port in a composite structure diagram (ball and socket notation). That notation is already used for example in SysML. However I can't find the definition of it.

  • Reported: UML 2.1.1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Ball and socket notation is only allowed for Components.

    Revised Text:

    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 16.3.2 Classifier (from UseCases)

  • Key: UML22-323
  • Legacy Issue Number: 11055
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The notation section of the classifier refers to the standard notation for nested classifiers. 1. I can't find that standard notation in the spec. 2. Nested classifiers are a feature of classes and not of classifiers. It seems that nesting and owning of classifiers is mixed up here

  • Reported: UML 2.1.1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 18.3.1

  • Key: UML22-322
  • Legacy Issue Number: 11054
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    18.3.1 – Class claims that it is a merge increment on InfrastructureLibrary::Constructs::Class, when in fig 18.1 it seems that Profile merely imports Constructs rather than merging it.

  • Reported: UML 2.1 — Thu, 24 May 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Duplicate of 9830

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Common Behavior - isReentrant should default to true

  • Key: UML22-247
  • Legacy Issue Number: 9873
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    isReentrant should default to true

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Having isReentrant default to false, as it currently does, means that, by default, there can be no concurrent invocations of a behavior, nor can a behavior be recursive. This does not seem to be the normal expectation of modelers when they model the invocation of behavior. Rather, the expected default it that behaviors are reentrant-with the ability to declare them not to be if that makes sense.
    On the other hand, it is often the case that, within an activity modeling, for example, a business or manufacturing process, an action invoking a behavior may be locally non-reentrant, in the sense that one invocation must complete before a new one can begin, because there is only a single performer to carry out the action. However, this case is more specifically addressed by Issue 6111. Once this is resolved at the local level, the default for the "global" isReentrant property on Behavior can be allowed to default to true, while "local" reentrancy for actions defaults to false.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Actions on non-unique properties with location specified

  • Key: UML22-246
  • Legacy Issue Number: 9870
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Actions on non-unique properties with location specified. Clarify what happens in the actions applying to non-unique features / association ends when they specify location and an existing value (eg, RemoveStructuralFeature and Destroy actions) if the value to be acted on is not at the position specified.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Currently, the WriteStructuralFeatureAction and WriteVariableAction superclasses specify a required value input pin, so all kinds of write structural feature actions must have such a pin in all cases. However, when a removeAt pin is required for a RemoveStructuralFeatureValueAction or RemoveVariableValueAction (that is, when the feature or variable is ordered and non-unique and isRemoveDuplicates is false), the expectation is that whatever value is at the given position is removed. Having to provide any value at all is counterintuitive. If the value is ignored, then it is pointless. If the value has to be the same as the value at the given position, then it is extremely inconvenient and redundant to have to read the value at that position just to remove it!
    Therefore, the remove value actions should not have a value input pin in the case they are required to have a removeAt pin. This means that the value input pin should be optional in the write action superclasses, but should then be constrained to be required for the add value actions.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions - Output of read actions for no values

  • Key: UML22-243
  • Legacy Issue Number: 9863
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Output of read actions for no values. In the various read actions (links, structural features, variables), what is the output when there are no values read? Is it a null token or no tokens at all?

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Suppose the result output pin of a read action is connected by an object flow to an action with an input pin with a multiplicity lower bound of zero. Assuming the second action has no other inputs or incoming control flows, it still will not fire unless it receives some token on its input pin (note that this semantic interpretation of enabled actions is explicit in the Foundational UML specification). Thus, if the read action produces no token in the case that no values are read, then the second action will not fire, even though its input is optional. In order to ensure that the second action can actually fire with no input values, it would be necessary to also model an explicit control flow from the read action to the second action, which is inconvenient and can lead to ordering and sequencing issues between control and object tokens in the case when the read action does produce values.
    On the other hand, if the read action produces a null token when no values are read, then this will be offered to the second action, which can accept it, since its input multiplicity allows the case of no values. The second action will thus fire with an empty input, as would be intuitively expected. Note that if the second action's input pin had a multiplicity lower bound greater than zero, the semantics would not be effected by the offering of a null token, since this still would not provide the minimum number of values required for the action to fire.
    Therefore, in the framework of the token offer semantics of activities, it makes the most sense for a read action to produce a null token when there are no values to read. Note that this is also consistent with the semantics for call actions implied by the statement in Subclause 12.3.41 that if, at the time an activity finishes execution, "some output parameter nodes are empty…they are assigned null tokens", in which case one would expect the null tokens to be offered by the corresponding output pins of a call action for the activity. That is, call actions should also offer null tokens in the case that an output has no values.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Actions - InputPin semantics wording

  • Key: UML22-242
  • Legacy Issue Number: 9862
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    InputPin semantics wording. In Actions, InputPin, Semantic, second sentence, replace "how many values" with "the maximum number of values that can be".

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Output pin semantics clarification

  • Key: UML22-245
  • Legacy Issue Number: 9869
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Output pin semantics clarification. The current semantics for Action says it won't complete without the output pins having the minimum number of tokens, as specified by the minimum multiplicity. It should be clarified that the output values are not put in the output pins until it the action completes, so the tokens already in the output pins are not included in meeting the minimum multiplicity.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - ForkNode semantics wording

  • Key: UML22-244
  • Legacy Issue Number: 9868
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    ForkNode semantics wording. In semantics of ForkNode, the phrase "keep their copy in an implicit FIFO queue until it can be accepted by the target" should not be different from other situations of ordered offers to refusing targets. In particular, it should be refined to clarify that the acceptance of offers by a fork is the same as acceptance by object nodes in the sense that they can't be revoked once accepted, and that for the edges leading to refusing targets, the offers are standing along those edges in the order they were received.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    In general, the ForkNode semantics needs to be more carefully worded in terms of offers of tokens, rather than just the tokens themselves "arriving" at a fork node.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Preserving order of multiple tokens offered.

  • Key: UML22-241
  • Legacy Issue Number: 9861
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Preserving order of multiple tokens offered. In Activities, ActivityEdge, when tokens are offered in groups, for example for weight greater than 1, if the source and target are pins, the multiplicity ordering of the source node, if any, should be preserved in the target node.

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The real issue is preserving the ordering of offers as made by the source, whether the source is a pin or not. The relationship of multiplicity ordering on pins to the ordering of offers is handled by the resolution to Issue 9860.

  • 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

definition of 'isCompatibleWith' for ValueSpecification

  • Key: UML22-375
  • Legacy Issue Number: 12251
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    The definition of 'isCompatibleWith' for ValueSpecification starts with 'Property::isCompatibleWith[...]', instead it has to start with 'ValueSpecification::isCompatibleWith[...]'.

  • Reported: UML 2.1.2 — Thu, 28 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

formal definitions of 'isCompatibleWith' (pages 622, 647, 649)

  • Key: UML22-374
  • Legacy Issue Number: 12250
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    The three formal definitions of 'isCompatibleWith' start with: 'isCompatibleWith = p->oclIsKindOf(self.oclType) and [...]'. This is wrong, p and self have to be swapped, that is: 'isCompatibleWith = self.oclIsKindOf(p.oclType) and [...]'. Rationale: As defined in the OCL-specification formal/06-05-01, the function 'oclIsKindOf(t)' determines if t is either the direct type or one of the supertypes of the object, on which this function is called. That is, if the function returns true, the type t is a generalization or equal to the type of the current object. The corresponding has to be valid for 'isCompatibleWith(p)': If the function returns true, the type of p has to be the same or a generalization of the type of the object, on which this function is called (otherwise, the constraints [1] of 17.5.4 and 17.5.5 would make no sense).

  • Reported: UML 2.1.2 — Thu, 28 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Agreed. (The operations in question are ParameterableElement::isCompatibleWith, ValueSpecification::
    isCompatibleWith and Property::isCompatibleWith.)
    This also resolves Issue 17870.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

association 'ownedTemplateSignature' of a Classifier

  • Key: UML22-373
  • Legacy Issue Number: 12244
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    For the association 'ownedTemplateSignature' of a Classifier, 'Subsets Element::ownedElement' is specified. This should be replaced by 'Redefines TemplateableElement::ownedTemplateSignature' (because a Classifier inherits 'ownedTemplateSignature' from its superclass TemplateableElement). Correspondingly, in figure 17.18 '

    {subsets ownedElement}

    ' should be replaced by '

    {redefines ownedTemplateSignature}

    '.

  • Reported: UML 2.1.2 — Wed, 27 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

term 'templatedElement' not defined

  • Key: UML22-376
  • Legacy Issue Number: 12252
  • Status: closed  
  • Source: OFFIS e.V. ( Christian Mrugalla)
  • Summary:

    There are two occurrences of the term 'templatedElement' in the Standard (both in an OCL-expression), but this term is nowhere defined. I propose to replace 'templatedElement' by 'template' on page 629 respectively 'Template::templatedElement' by 'TemplateSignature::template' on page 636.

  • Reported: UML 2.1.2 — Fri, 29 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

Usage of "Element::ownedMember"

  • Key: UML22-309
  • Legacy Issue Number: 10829
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    In the Superstructure spec 2.1.1, there are a few occurences where an
    association end "ownedMember" in metaclass "Element" is referenced.
    This should be changed to reference the end "ownedElement" instead.

    The places I found, are:
    "Class::nestedClassifier"
    "Enumeration::ownedLiteral"
    "DataType::ownedAttribute"
    "DataType::ownedOperation"

  • Reported: UML 2.1 — Sat, 17 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    According to the metamodel diagrams,

    {subsets ownedMember}

    would refer to the closest inherited ownedMember attribute which would be Namespace, not Element. For example, see figure 7.12.
    Change all references of Element::ownedMember to Namespace::ownedMember.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consistency in description of ends owned by associations

  • Key: UML22-308
  • Legacy Issue Number: 10827
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    In the Superstructure spec 2.1.1, association ends owned by
    associations between UML metaclasses are not currently described in
    the descriptions of the metaclasses. Only ends owned by the
    associated classes are. In the abstract syntax diagrams, in a few
    cases, ends owned by the associations have labels and/or other
    specifications.

    It is quite confusing to not mention those association ends in some
    places, but to mention them in others. If the end is important enough
    to be described, this should be done consistently. If the end is
    irrelevant enough not to be described, it should consistently not be
    described (and thus be subject to the default naming rules).

    I suggest to establish consistency by determining for each such end,
    whether it is relevant or not to describe it. If it is relevant to
    describe it, then the end should be labeled in the diagrams, and it
    should be described in the metaclass descriptions. Otherwise, the end
    should be unlabeled and have no specifications in the diagrams and
    should not be described in the metaclass descriptions.

    Here is the set of ends owned by associations that is labeled in
    diagrams:
    Figure 7.5: "ValueSpecification::owningUpper"
    Figure 7.5: "ValueSpecification::owningLower"
    Figure 7.6: "ValueSpecification::expression"
    Figure 7.7: "ValueSpecification::owningConstraint"
    Figure 7.8: "ValueSpecification::owningSlot"
    Figure 7.8: "ValueSpecification::owningInstanceSpec"
    Figure 7.10: "ValueSpecification::owningParameter"
    Figure 7.10: "Parameter::ownerFormalParam"
    Figure 7.11: "Constraint::preContext"
    Figure 7.11: "Constraint::postContext"
    Figure 7.11: "Constraint::bodyContext"
    Figure 7.12: "ValueSpecification::owningProperty"
    Figure 7.12: "Classifier::class"
    Figure 7.14: "PackageableElement::owningPackage"
    Figure 7.15: "NamedElement::supplierDependency"

    Here is the set of ends owned by associations that is unlabeled but
    has specifications in diagrams:
    Figure 7.16: The right end of the aggregation between "Property"
    and "Interface" has a "

    {subsets ...}

    " specification.

  • Reported: UML 2.1 — Sat, 17 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.30

  • Key: UML22-306
  • Legacy Issue Number: 10818
  • Status: closed  
  • Source: ELIOP ( Ignacio Gonzalez)
  • Summary:

    Figur 12.95 - Fork node example has an error. Instead of: |-> Fill Order Fill Order -->| |> Send Invoice It should be: |> Ship Order Fill Order -->| |-> Send Invoice

  • Reported: UML 2.1.1 — Tue, 13 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.12

  • Key: UML22-312
  • Legacy Issue Number: 10832
  • Status: closed  
  • Source: Delphi ( Kirk Bailey)
  • Summary:

    The problem is with the definition of the ancestor query on page 559. I believe that the algorithm, as stated, determines whether s1 is an ancestor of s2, not whether s2 is an ancestor of s1.

  • Reported: UML 2.1 — Fri, 16 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This method is testing that s2 is nested within s1, and such s1 would be the ancestor. The method description is therefore wrong and needs to be fixed as suggested.
    Furthermore, the check that s1 has a container has no bearing on whether s2 is contained within it. And the parameters of the function accept states but we are passing the container which will be a region.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"PackageableElement::visibility" uses "false" as default value

  • Key: UML22-311
  • Legacy Issue Number: 10831
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    In the Superstructure spec 2.1.1, the description of
    "PackageableElement::visibility" says: "Default value is false."
    However, "false" is not a valid value for the type "VisibilityKind".

    I suggest that the default visibility be defined as "public". While
    it may make sense for properties in a class to be private by default,
    this is not the case for packageable elements, here it makes way more
    sense to have a public default. The description should be changed
    accordingly.

    Second, the UML Metamodel CMOF files define metaclass
    "PackageableElement" to be a specialization of metaclass
    "NamedElement" without redefining "visibility". However, the
    metaclass description in the superstructure spec does redefine
    "visibility". The CMOF files should be adjusted to make the same
    redefinitions the description makes.

  • Reported: UML 2.1 — Sat, 17 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Regarding the first point,.PackageableElement::visibility already has „public? as a default value in the normative CMOF models, so the description in the spec text needs to be corrected as suggested in the issue.
    Regarding the second point, PackageableElement::visibility in the CMOF models already redefines NamedElement::visibility, matching the spec doc, so no change is needed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mismatch between Superstructure ptc/06-04-02 and XML Schema ptc/06-04-05

  • Key: UML22-302
  • Legacy Issue Number: 10778
  • Status: closed  
  • Source: MID GmbH ( Mr. Detlef Peters)
  • Summary:

    Possible Mismatch between Superstructure ptc/06-04-02 and XML Schema ptc/06-04-05

    Please clarify the effects of the merge increments of 'Class' on its descendants, esp. on the 'Behavior' subtypes. IMHO the fact that 'behavior' inherits from 'Class (from Kernel)' implies that in turn it does NOT inherit features from 'BehavioredClassifier' or 'EncapsulatedClassifier' even on Compliance level L1. This would mean that e.g. an interaction may not have ownedPorts or ownedBehaviors, but nestedClassifier.

    If this is not the case, please clarify the precedence between the merge and inheritance constructs.
    Example:
    L1 (as seen in Fig. 2.2) merges Kernel, BasicBehaviors and InternalStructures and thus provides the 'Class', 'BehavioredClassifier' and 'EncapsulatedClassifier' constructs simultanously.

    • If inheritance comes before merging (which is what the diagrams suggest), 'Behavior' will have neither ownedPorts nor ownedBehaviors.
    • If merging comes before inheritance (which is what the XSD suggests), 'Behavior' will both have ownedPorts and ownedBehaviors.

    In the second case, the question arises that if even in L1 the three constructs mentioned above are provided, why does 'Behavior' not simply inherit from 'Class (from StructuredClasses)', directly being an EncapsulatedClassifier?

  • Reported: UML 2.1 — Fri, 16 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 155, 162

  • Key: UML22-301
  • Legacy Issue Number: 10651
  • Status: closed  
  • Source: DMR Consulting ( Jasmin Bouchard)
  • Summary:

    In the notation for ComponentRealization on section 8.3.4 (page 162), it is stated that a ComponentRealization is notated in the same way as a realization dependency, "i.e., as a general dashed line with an open arrow-head". This contradicts the notation presented for Realization in section 7.3.45 (page 133), where it is stated that "A Realization dependency is shown as a dashed line with a triangular arrowhead at the end". If the notation of section 8.3.4 is indeed in error, Figure 8.10 (page 155) should be corrected to use triangular arrowheads, since it is a representation of the realization of a complex component.

  • Reported: UML 2.1 — Tue, 6 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This is a duplicate of 11007 (incorrect arrowhead in text) and 8705 (incorrect fig 8.10).

    Revised Text:
    None.
    Disposition: Duplicate of 8705 and 11007

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 17/17.5.7

  • Key: UML22-305
  • Legacy Issue Number: 10802
  • Status: closed  
  • Source: CNAM ( Jean-Frederic Etienne)
  • Summary:

    Missing constraint for template binding in classifier context There seems to be an omitted constraint for template binding in the context of the classifier metaclass on page 667. Indeed, there is no restriction to the kind of template element to which a classifier can be bound. For example, nothing forbids a class to be bound to a data type or association or even an operation defined as template. There is a need for a constraint similar to the one defined on page 57, where it is stated that a classifier can only specialize classifiers of a valid type. Something like, self.templateBinding -> forAll(tb | self.oclIsKindOf(tb.signature.template.oclType)) Note that the variable oclType is not a valid OCL expression, even though it is referenced more than once in the UML Superstructure document (e.g definition of maySpecializeType on page 58). We therefore here assume that the oclType expression returns the associated metatype of the uml element to which it is applied. Thanks in advance for any feedback Jean-Frédéric Etienne

  • Reported: UML 2.1.1 — Mon, 5 Mar 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is covered in constraint [1] of TemplateParameterSubstitution, section 17.5.5.
    Revised Text:
    Disposition: Closed, no Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Port.provided:Interface

  • Key: UML22-304
  • Legacy Issue Number: 10789
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    ptc/2006-04-02/p187.

    The spec for Port.provided:Interface says: “References the interfaces specifying the set of operations and receptions that the classifier offers to its environment, and which it will handle either directly or by forwarding it to a part of its internal structure. This association is derived from the interfaces realized by the type of the port or by the type of the port, if the port was typed by an interface.”

    This would seem to indicate that a Port typed by an Interface cannot have more than one provided interface. Clarify that this was the intention, or fix if not.

  • Reported: UML 2.1 — Tue, 27 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    I cannot see how it can mean anything else. This specification was modified in the resolution to 13080 and the meaning is clear there.

    Revised Text:

    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.28 ReceiveSignalEvent (from BasicInteractions)

  • Key: UML22-300
  • Legacy Issue Number: 10650
  • Status: closed  
  • Source: Softeam ( Cédric MARIN)
  • Summary:

    About "8784 - add ReceiveOperationEvent and ReceiveSignalEvent metaclasses" issue, the "ReceiveSignalEvent" (14.3.28 p522) metaclass seems to have the same meaning as "SignalEvent" (13.3.25 p468) and is then redundant. This issue should be resolved by either: - detailing the differences between ReceiveSignalEvent and SignalEvent - removing the ReceiveSignalEvent metaclass

  • Reported: UML 2.1 — Tue, 6 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 14629 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.38

  • Key: UML22-299
  • Legacy Issue Number: 10637
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Is "Set of <name>" a keyword? Or is it allowed to write for example "<name>List" or "<name>Container"?

  • Reported: UML 2.1.1 — Fri, 2 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue applies to Figure 15.49 in Subclause 15.4.4 of the UML 2.5 beta specification. Since ObjectNodes
    are not MultiplicityElements, the only way that an ObjectNode can contain a set or other collection is if its
    type is a collection type. Since UML does not provide any standard such types, the notation cannot be fully
    standardized

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2: Actor cannot have ownedAttributes

  • Key: UML22-303
  • Legacy Issue Number: 10780
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Constraint [1] in section 16.3.1 is incorrect.
    [1] An actor can only have associations to use cases, components, and classes. Furthermore these associations must be binary.
    self.ownedAttribute->forAll ( a |
    (a.association->notEmpty()) implies
    ((a.association.memberEnd.size() = 2) and
    (a.opposite.class.oclIsKindOf(UseCase) or
    (a.opposite.class.oclIsKindOf(Class) and not a.opposite.class.oclIsKindOf(Behavior))))

    An Actor is a BehavioredClassifier and therefore cannot have ownedAttributes. The constraint above would have to iterate over all the associations in the model and insure that if one ownedEnd is an Actor or UseCase, the other ownedEnd must be a UseCase or Actor respectively.

  • Reported: UML 2.1 — Tue, 20 Feb 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Agreed. This also resolves issues 13948 and 14875

  • Updated: Fri, 6 Mar 2015 20:58 GMT

State Machines

  • Key: UML22-314
  • Legacy Issue Number: 10931
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Execution semantics of deferrable triggers. The execution semantics of deferrable triggers in the notation section of Transition, under Figure 15.44, conflicts with the semantics given in State. The description of deferrable trigger in the State attribute and semantics sections say a deferred event remains deferred until the machine reaches a state where it is consumed. The notation section of Trigger says the deferred event is lost when the machine reaches a state where the event is not consumed and not deferred

  • Reported: UML 2.1.1 — Sun, 25 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.3.8

  • Key: UML22-313
  • Legacy Issue Number: 10930
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The description how values of a stereotyped element can be shown offers three ways. But all of them requires a graphical node. There is no description how to show the values of a stereotyped element that has no graphical notation, e.g. an attribute

  • Reported: UML 2.1.1 — Tue, 20 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution: Duplicate of 9877

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"Constraint::context" is marked as derived in the metaclass description

  • Key: UML22-310
  • Legacy Issue Number: 10830
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    In the Superstructure spec 2.1.1, the description of the "context"
    association end in metaclass "Constraint" has the leading slash,
    marking it as derived. This is probably wrong. Besides not making
    much sense for this end to be derived, the following places support
    the view that "context" is meant to be non-derived:

    • The text in the description of the "context" end does not state
      from what or how the end would be derived.
    • In the UML Metamodel CMOF files, the end is not defined to be
      derived.
    • In figure 7.7, the "context" end is shown as non-derived.

    The description of the "context" end in the Superstructure spec
    should be changed to remove the derived-mark (leading slash) from it.

  • Reported: UML 2.1 — Sat, 17 Mar 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Constraint::context is not derived in the metamodel. See figure 7.7. This is already correct in InfrastructureLibrary.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

discrepancies between package dependencies and XMI file for Superstructure

  • Key: UML22-222
  • Legacy Issue Number: 9818
  • Status: closed  
  • Source: Technolution ( Mick Baggen)
  • Summary:

    I verified the alignment between the package dependencies (packageImport and packageMerge) in the XMI file Superstructure.cmof (contained in ptc-06-01-04) and the package dependency diagrams in the convenience document, and noticed some discrepancies. Assuming the XMI file is correct, these discrepancies are: - Part I, Figure 1 (p.19): the packageImports from Classes to CommonBehaviors and AuxiliaryConstructs are missing. - Figure 7.2 (p.22): the packageImport from Dependencies to Kernel is missing. - Figure 9.1 (p.168): the packageImports from Ports to Kernel and Interfaces are missing. - Figure 10.1 (p.202): the packageImport from Nodes to Kernel is missing. - Part II, Figure 1 (p.225): the packageImports from StatesMachines, Activities and Interactions to CompositeStructures are missing. - Part II, Figure 1 (p.225): the packageImport from Activities to StateMachines is missing. - Part II, Figure 1 (p.225): the packageImport from CommonBehaviors to Actions is missing. - Part II, Figure 1 (p.225): the packageImport from UseCases to CommonBehaviors is not correct: it is not present in the XMI file. There only exists a packageMerge relation from UseCases to BasicBehaviors. - Figure 11.1 (p.230): the packageImports from CompleteActions to Kernel and BasicBehaviors are missing. - Figure 11.1 (p.230): the packageImport from IntermediateActions to Kernel is missing. - Figure 11.1 (p.230): the packageMerge from IntermediateActions to BasicBehaviors is missing. - Figure 12.1 (p.309): the packageImports from CompleteActivities to Kernel and BasicBehaviors are missing. - Figure 12.1 (p.309): the packageImports from IntermediateActivities to Kernel and BasicBehaviors are missing. - Figure 12.1 (p.309): the packageMerge from BasicActivities to BasicBehaviors is missing. - Figure 15.1 (p.546): the packageMerge from BehaviorStateMachines to Communications is missing. - Part III, Figure 1 (p.631): the packageImport from AuxiliaryConstructs to Classes is missing.

  • Reported: UML 2.1 — Sat, 10 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Figure 14.5

  • Key: UML22-224
  • Legacy Issue Number: 9820
  • Status: closed  
  • Source: Technolution ( Mick Baggen)
  • Summary:

    The editorial fix in Figures 14.5 is not carried out: OccurenceSpecification is still abstract, not concrete. Please note that there is no editorial fix planned for, or applied to Figures 14.3 and 14.4. However, in these figures OccurenceSpecification is also shown as abstract. All of the figures pertaining to the package BasicInteractions should at least show the same view of OccurenceSpecification

  • Reported: UML 2.1 — Sat, 10 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Appendix F

  • Key: UML22-223
  • Legacy Issue Number: 9819
  • Status: closed  
  • Source: Technolution ( Mick Baggen)
  • Summary:

    The Classifier taxonomy in Appendix F shows a Generalization from Collaborations::Collaboration (child) to Collaborations::Classifier (parent). This Generalization is not present in the metamodel in Figure 9.6 (p. 172), and I therefore believe it to be in error.

  • Reported: UML 2.1 — Sat, 10 Jun 2006 04: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-218
  • Legacy Issue Number: 9807
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Fig. 8.12 shows delegate connectors that are directly connected with an interface. According to the metamodell that's not possible. A connector end can only be connected with connectable elements.

  • Reported: UML 2.1.1 — Wed, 7 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    Resolved by the changes specified in 8168.

    Revised Text:
    None.
    Disposition: Duplicate of 8168.

  • 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

Section: 7.3.44

  • Key: UML22-225
  • Legacy Issue Number: 9822
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    In the defintion of the Property concept, the type of the default attribute is a String. I believe it would be more powerful to type default with ValueSpecification

  • Reported: UML 2.1.1 — Mon, 12 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Actually, Property::defaultValue is a ValueSpecification, which gives what is required. Property::/default is
    a derived string, although its current documentation—“A String that is evaluated to give a default value for
    the Property when an instance of the owning Classifier is instantiated” — is misleading. Property::/default
    only exists at all because of earlier efforts to align superstructure and infrastructure through package merge.
    Its derivation makes no sense for default values that are not strings. Since it is derived, removing it would
    not affect model serialization. Delete it.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.2

  • Key: UML22-221
  • Legacy Issue Number: 9817
  • Status: closed  
  • Source: Technolution ( Mick Baggen)
  • Summary:

    In paragraph 7.2 it says: "Figure 7.2 shows the package dependencies of the Kernel packages". However, this should read "...dependencies of the Classes packages." The caption of figure 7.2 is correct.

  • Reported: UML 2.1 — Sat, 10 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page: 64 & 112

  • Key: UML22-220
  • Legacy Issue Number: 9812
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The section 7 contains two concepts, ElementImport and PackageImport, that seems to quite redundant. I believe that the semantics of ElementImport covers the semantics of PackageImport. SO, either clarify the difference (if there are?), or delete the PackageImport or make PackageImport a specialization of ElementImport.

  • Reported: UML 2.1.1 — Fri, 9 Jun 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

UML 2.2 scope statement

  • Key: UML22-334
  • Legacy Issue Number: 11152
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Current Scope section in UML 2.1.1 Infrastructure
    =================================================

    This UML 2.1.1: Infrastructure is the first of two complementary
    specifications that represent a major revision to the Object Management
    Group's Unified Modeling Language (UML), for which the previous current
    version was UML v1.5. The second specification, which uses the
    architectural foundation provided by this specification, is the UML 2.1.1:
    Superstructure. The UML 2.1.1: Infrastructure defines the foundational
    language constructs required for UML 2.1.1. It is complemented by UML
    2.1.1: Superstructure, which defines the user level constructs required for
    UML 2.1.1.

    Current Scope section in UML 2.1.1 Superstructure
    =================================================

    This Unified Modeling Language: Superstructure is the second of two
    complementary specifications that represent a major revision to the Object
    Management Group's Unified Modeling Language (UML), for which the most
    current version is UML v2.0. The first specification, which serves as the
    architectural foundation for this specification, is the Unified Modeling
    Language: Infrastructure.

    This Unified Modeling Language: Superstructure defines the user level
    constructs required for UML 2. It is complemented by Unified Modeling
    Language: Infrastructure which defines the foundational language constructs
    required for UML 2. The two complementary specifications constitute a
    complete specification for the UML 2 modeling language.

    Proposed Scope section
    ======================

    This specification defines the Unified Modeling Language (UML), revision 2.
    The objective of UML is to provide system architects, software engineers,
    and software developers with tools for analysis, design, and implementation
    of software-based systems as well as for modelling business and similar
    processes.

    The initial versions of UML (UML 1) originated with three leading
    object-oriented methods (Booch, OMT, and OOSE), and incorporated a number
    of best practices from modelling language design, object-oriented
    programming and architectural description languages. Relative to UML 1,
    this revision of UML has been enhanced with significantly more precise
    definitions of its abstract syntax rules and semantics, a more modular
    language structure, and a greatly improved capability for modelling
    large-scale systems.

    One of the primary goals of UML is to advance the state of the industry by
    enabling object visual modeling tool interoperability. However, to enable
    meaningful exchange of model information between tools, agreement on
    semantics and notation is required. UML meets the following requirements:

    • A formal definition of a common MOF-based metamodel that specifies the
      abstract syntax of the UML. The abstract syntax defines the set of UML
      modelling concepts, their attributes and their relationships, as well as
      the rules for combining these concepts to construct partial or complete UML
      models.
    • A detailed explanation of the semantics of each UML modelling concept.
      The semantics define, in a technology-independent manner, how the UML
      concepts are to be realised by computers.
    • A specification of the human-readable notation elements for representing
      the individual UML modelling concepts as well as rules for combining them
      into a variety of different diagram types corresponding to different
      aspects of modelled systems.
    • A detailed definition of ways in which UML tools can be made compliant
      with this specification. This is supported (in a separate specification)
      with an XML-based specification of corresponding model interchange formats
      (XMI) that must be realised by compliant tools.
  • Reported: UML 2.1 — Thu, 12 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property::isAttribute() query needs no argument

  • Key: UML22-333
  • Legacy Issue Number: 11120
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The Property::isAttribute() OCL query (see p. 133 of 07-02-03) is currently defined to take an argument:

    [4] The query isAttribute() is true if the Property is defined as an
    attribute of some classifier
    context Property::isAttribute(p : Property) : Boolean
    post: result = Classifier.allInstances->exists(c|
    c.attribute->includes(p))

    This argument (p) is not necessary, as the query should be based on the context property. Note that the OCL body for this query does not appear to be correct either.

  • Reported: UML 2.1 — Wed, 4 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Yes, this is wrong. Fix it. This also resolves issue 12842.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.4

  • Key: UML22-330
  • Legacy Issue Number: 11114
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    The derivation of Classifier.inheritedMember is incorrect: self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self))) The "collect" in that should be "select". I'd also appreciate it if someone could tell me why the spec does not match the l3-merged.cmof here, and particularly, whether the transformation of the above into a query/derivation (by removal of the includesAll) was intentional in the l3-merged.cmof, or just some accident which suggests that the l3-merged.cmof is not up-to-date with the specification .pdf.

  • Reported: UML 2.1 — Fri, 29 Jun 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 15267 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.4 Classifiers Diagram

  • Key: UML22-329
  • Legacy Issue Number: 11109
  • Status: closed  
  • Source: Department of Computer Science and Technology, Nanjing University ( Zhang, Tian)
  • Summary:

    In "Figure 11.16 - The Classifiers diagram of the Constructs package", the end of the association between Classifier and Feature are named as "/featuringClassifier" and "/feature". But in "11.4.1 Classifier" the Assciations part illustrates the feature without slash. Also, in "11.4.2 Feature" the featuringClassifier is demonstrated without slash neither. According to UML series specifications, "/featuringClassifier" and "/feature" are different from "featuringClassifier" and "feature".

  • Reported: UML 2.1 — Fri, 22 Jun 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Figure 7.10 indicates that Classifier::/feature and Feature::/featuringClassifier are both derived unions. Classifier:: /feature is shown as derived in section 7.3.8 where it is described. Feature::/featuringClassifier is shown as derived in section 7.3.19 where it is described. So there are no issues for Superstructure

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Actor concept was indeed changed

  • Key: UML22-340
  • Legacy Issue Number: 11200
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The constraints on associations include a condition that an Actor not be associated with a Behavior, which blocks the owned behavior and classifier behavior, but in that case, it is a mystery to me why Actors were made to be BehavioredClassifiers.

    This is not an issue with the consistency or clarity of the spec.
    It is an issue with understanding the use of UML 2 as contrasted with UML 1.n

    The 2.1.1 spec, section 16.3.1, says:

    Changes from previous UML There are no changes to the Actor concept except for the addition of a constraint that requires that all actors must have names.

    But a very important change was introducing BehavioredClassifier (there was no BehavioredClassifier in UML 1) , and then making it the generalization of Actor, which gives Actors

    1. ability to own behaviors
    2. ability to have a unique classifier behavior
    3. and own triggers.

    some remarks on the intended pragmatics of this change would make UML spec better.

    Merely citing the change in the "Changes.." section provide accuracy without value, but explaining what use is foreseen for this change, would provide value.

  • Reported: UML 2.1 — Tue, 24 Jul 2007 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: 13.3.3

  • Key: UML22-339
  • Legacy Issue Number: 11162
  • Status: closed  
  • Source: Patterndigm ( Ben Bovee)
  • Summary:

    In, "Table 12.1 - Graphic nodes included in activity diagrams," the 'Notation' entry for 'ActivityNode' should exclude "ExecutableNode" (unless such an entry is added--or found elsewhere).

  • Reported: UML 2.1 — Wed, 18 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

composite subsets

  • Key: UML22-343
  • Legacy Issue Number: 11238
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    There are several places in metamodel where non-derived composite property is subset of other non-derived composite property.
    In this case element is owned in two collections, so how it should be reflected in XMI where element could appear just once?
    We can leave element just in subset, and merge collections after load, but is this correct?

    Below are these occurrences:

    classes::mdKernel::Operation::bodyCondition subsets ownedRule

    statemachines::mdBehaviorStateMachines::Transition::guard subsets ownedRule

    classes::mdKernel::Operation::postcondition subsets ownedRule

    statemachines::mdProtocolStateMachines::ProtocolTransition::postCondition
    subsets ownedRule

    classes::mdKernel::Operation::precondition subsets ownedRule

    statemachines::mdProtocolStateMachines::ProtocolTransition::preCondition
    subsets ownedRule

    Profile::metaclassReference subsets elementImport

    uml2.1.1::mdProfiles::Profile::metaclassReference subsets packageImport

  • Reported: UML 2.1 — Wed, 1 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.1.2: Path names for CMOF files

  • Key: UML22-342
  • Legacy Issue Number: 11234
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The (new) path names for the CMOF files, based on the naming proposal that was presented in Brussels, need to be listed next to the bullet points in Appendix H of the UML specification. This change should be made as part of the urgent ballot for UML 2.1.2.

  • Reported: UML 2.1 — Wed, 25 Jul 2007 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: 7.3.21 figure 7.47

  • Key: UML22-332
  • Legacy Issue Number: 11116
  • Status: closed  
  • Source: myself ( jonathan tanner)
  • Summary:

    Figure 7.47 - Power type notation Specific classifier-2 has powertype 'classifier-1' but inherits from PowerType Classifier-2. Should the inheritance lines not point to the 'General Classifier'?

  • Reported: UML 2.1.1 — Tue, 3 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.21

  • Key: UML22-331
  • Legacy Issue Number: 11115
  • Status: closed  
  • Source: myself ( jonathan tanner)
  • Summary:

    Inconsistancy between background fill colouring. Default colour preferences are normally white background, black text, and this issue is then not visible. Changing to a custom colouring to green backgrond, black text, one sees that that some boxes are filled white, whereas others are the same as the selected background colour. Is this intentional? Does this have any semantic meaning? Example in Figure 7.47 (b) Power type notation. The PowerType classifiers use the page background

  • Reported: UML 2.1.1 — Tue, 3 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Abstractions (02)

  • Key: UML22-337
  • Legacy Issue Number: 11156
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    Generalization of Parameter to NamedElement in redundant in Abstractions. Would be easier on serialization to remove the multiple inheritance.

  • Reported: UML 2.1 — Mon, 16 Jul 2007 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: Constructs

  • Key: UML22-336
  • Legacy Issue Number: 11155
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    Package import is defined in the context of Namespace. This has two consequences: 1. Namespaces such as Classe, Node, and UseCase can import Packages. This does not seem to be a good design goal. 2. There is a circular definition between Package and Namespace: Package is a sub-type of Namespace and Namespace requires the definition of Package and PackagedElement.

  • Reported: UML 2.1 — Mon, 16 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Namespace URI for Standard Profile(s)

  • Key: UML22-338
  • Legacy Issue Number: 11160
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The UML (Superstructure) specification does not define the namespace URI for the standard profile(s) - it should. Note that the currently recommended convention (from p. 703, section 18.3.6 of 07-02-03) for such URIs is

    nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi

  • Reported: UML 2.1 — Wed, 18 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Abstractions

  • Key: UML22-335
  • Legacy Issue Number: 11154
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    Abstractions should support serialization by itself and interoperably with serialization of Constructs. In particular: - Package and Property should be available in Abstractions, to enable Abstractions to be used for serialization of typical models by itself. - There should be no circular dependencies between packages in Abstractions. - Constructs should only use imports from Abstractions, to enable models using Constructs to interoperate with models using only Abstractions. Package merge produces noninteroperable XSDs

  • Reported: UML 2.1 — Mon, 16 Jul 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.3.3

  • Key: UML22-341
  • Legacy Issue Number: 11201
  • Status: closed  
  • Source: mit.bme.hu ( Zoltan Micskei)
  • Summary:

    In the Notation part of CombinedFragment, in the part 'Presentation Options for “coregion area"' the text refers to Figure 14.12 for an example of a coregion. However, on Figure 14.12 there is no coregion. The reference should be changed to Figure 14.22

  • Reported: UML 2.1.1 — Thu, 26 Jul 2007 04: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

Invalid redefinitions introduced into metamodel

  • Key: UML22-265
  • Legacy Issue Number: 10079
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There seem to be cases where redefinitions have appeared in the metamodel that were not in the spec. I think something is needed but overall I think subsetting is probably more appropriate for these cases.

    It appears that these redefinitions between non-navigable properties (owned by associations) may have been inadvertently introduced by the tool processing the metamodel before the ends were assigned names. In the first example I suspect that the opposites of DirectedRelationship::target and Generalization::general were detected as being involved in an implicit redefinition because their names were empty (the same). The tool can probably be tweaked to produce a complete list of such redefinitions which we can then itemize and remove to resolve this issue..

    The cause of the second example is the same, but was likely introduced before Package::ownedMember was renamed to Package::packagedElement and never cleaned up.

    For example, in Fig 7.9, the Classifiers diagram, the end opposite to Generalization::general is completely unlabeled. But in the metamodel we have
    <ownedEnd xmi:type="cmof:Property" xmi:id="A_general_generalization-generalization" name="generalization" type="Generalization" association="A_general_generalization" redefinedProperty="A_target_directedRelationship-directedRelationship"/>

    I'm not sure I see the need for a redefinition here - especially when its sibling (Classifier-generalization) is as follows and has no such redefinition:

    <ownedAttribute xmi:type="cmof:Property" xmi:id="Classifier-generalization" name="generalization" lower="0" upper="*" type="Generalization" association="A_generalization_specific" subsettedProperty="Element-ownedElement" isComposite="true">

    This has no reference at all to the general Association A_source_directedRelationship - to be consistent I would have expected redefinedProperty="A_source_directedRelationship-directedRelationship. As I mentioned at the start though a subsets seems more appropriate - since the other ends use

    {subsets source}

    etc.

    One that has an additional problem is the following:

    <ownedMember xmi:type="cmof:Association" xmi:id="A_ownedStereotype_profile" name="A_ownedStereotype_profile" general="A_packagedElement_owningPackage" memberEnd="Profile-ownedStereotype A_ownedStereotype_profile-profile">
    <ownedEnd xmi:type="cmof:Property" xmi:id="A_ownedStereotype_profile-profile" name="profile" type="Profile" association="A_ownedStereotype_profile" redefinedProperty="A_member_namespace-namespace"/>

    Here the Association inherits from A_packagedElement_owningPackage but the End redefines A_member_namespace-namespace which is not even a direct member of the specialized Association - and furthermore is a derivedUnion - so we have no real Slot to base the end on. If anything I would have expected a redefine of A_packagedElement_owningPackage-owningPackage

  • Reported: UML 2.1 — Wed, 2 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.2

  • Key: UML22-267
  • Legacy Issue Number: 10081
  • Status: closed  
  • Source: International Business Machines ( Mr. Adam Neal)
  • Summary:

    The body property of OpaqueBehavior (as well as OpaqueExpression and OpaqueAction) should be declared not unique. The OpaqueBehavior can be used to store user code and the given language that it was written in. The specifiction identifies the lists of languages and bodies to be ordered (and by default unique). It makes sense for the list of languages to be uniuqe, but not the bodies. For example, consider the user has written the same code but in 2 different languages (say c and c+, or written an identical comment in c and c+ and java). Currently the UML specification disallows one to have the same body even though it may semantically make sense in both languages

  • Reported: UML 2.1.1 — Wed, 2 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Agreed. In addition, the body and language attributes should be ordered

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.5

  • Key: UML22-266
  • Legacy Issue Number: 10080
  • Status: closed  
  • Source: ISP ( Leonid)
  • Summary:

    The grammar below is wrong, because there is no rule for the non-terminal <prop-property>. <prop-modifier> should be used instead. <property> ::= [<visibility>] [‘/’] <name> [‘:’ <prop-type>] [‘[‘ <multiplicity> ‘]’] [‘=’ <default>] [‘

    {‘ <prop-property > [‘,’ <prop-property >]* ’}

    ’]

  • Reported: UML 2.1 — Wed, 2 Aug 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: 7.3.3

  • Key: UML22-270
  • Legacy Issue Number: 10140
  • Status: closed  
  • Source: Thought, Systems Consulting & Engineering, Inc. ( Marc W George)
  • Summary:

    Use of only the link name as the default for the association name limits the use of both namespace::membersAreDistinguishable() and nameElement::isDistinguishableFrom() operations. The full association name for creating the signature of the element should be at least the concatenation of "memberEndA name - link name - memberEndB name".

  • Reported: UML 2.1.1 — Thu, 24 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 7.31

  • Key: UML22-269
  • Legacy Issue Number: 10087
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure 7.31 shows the association-like notation for attributes. However this still sues the navigability arrow in the 'old' way. It would be consistent to use the new 'dot' notation to show the class owning the property representing the attribute.

  • Reported: UML 2.1 — Mon, 7 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex C.1

  • Key: UML22-268
  • Legacy Issue Number: 10086
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Language unit for stereotype create should be named Classes::Dependencies instead of just Dependencies

  • Reported: UML 2.1.1 — Fri, 4 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

StructuredActivityNode [UML 2.1.1]

  • Key: UML22-355
  • Legacy Issue Number: 11646
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    StructuredActivityNode, based on both common sense and its semantics, requires input and output pins. However StructuredActivityNode::input and StructuredActivityNode::output, both inherited from Action are derived unions and so cannot be used directly. StructuredActivityNode::result is a concrete property but has a special meaning.

    What is needed is some solution that subsets StructuredActivityNode::input and StructuredActivityNode::output but can be used to describe input and output pins of StructuredActivityNode.

  • Reported: UML 2.1.2 — Thu, 8 Nov 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The semantics of StructuredActivityNode does, indeed, talk specifically about pins on such nodes. Further, having pins on StructuredActivityNodes is assumed as being allowed in and is required by the Java to UML activity model mapping in the Foundational UML specification. The submitter is correct, however, that the abstract syntax model itself does not seem to explicitly support this.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Issue - 'abstract' not listed in keyword Annex

  • Key: UML22-357
  • Legacy Issue Number: 11683
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    I just noticed that in formal/07-02-05 section 7.3.8, Classifier, includes:

    An abstract Classifier can be shown using the keyword

    {abstract}

    after or below the name of the Classifier.

    However this is not listed in Annex B of keywords.

  • Reported: UML 2.1.2 — Wed, 21 Nov 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18454

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 issue: ProfileApplication treated as Import

  • Key: UML22-356
  • Legacy Issue Number: 11657
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 13.1.6, figure 13.11 (of Infra) and 18.2.7, figure 18.11 (of Super) show an example of a profile containing Types which are available for use when the profile is applied. This rests on the statement “(since profile application is a kind of import)”. However this is not the case: ProfileApplication only inherits from DirectedRelationship.

    To achieve the end effect of the example there seem to be two alternatives:

    a) Alter the metamodel to make ProfileApplication inherit from PackageImport, with appropriate redefinitions.

    b) Explicitly state that ProfileApplication has exactly the same semantics as PackageImport without inheriting from it. More awkward but lower impact. And will mean that generic processing that works off Imports will not pick up ProfileApplications.

    This area is causing significant consternation for groups such as UPDM trying to define sophisticated profiles that make use of common elements or other profiles.

  • Reported: UML 2.1.2 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    ProfileApplication makes stereotype names visible to the referenced metamodel, not the model the profile is applied to. ProfileApplication is not a kind of PackageImport because of this crossing of metamodel levels. As with package import, profile application does not expose the names of nested profiles. Therefore alternative b) is the appropriate choice.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

context of Constraint

  • Key: UML22-348
  • Legacy Issue Number: 11407
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Context of the Constraint is described as derived property

    • / context: Namespace [0..1] Specifies the Namespace that is the context for evaluating this constraint. Subsets NamedElement::namespace.

    However it is not derived in Figure 7.7 - Constraints diagram of the Kernel package.

    So should it be derived or not? One of these places shall be fixed.

  • Reported: UML 2.1.1 — Fri, 14 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 10830 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.3.6 Profile (from Profiles)

  • Key: UML22-347
  • Legacy Issue Number: 11343
  • Status: closed  
  • Source: Mid GmbH ( Joachim Back)
  • Summary:

    In the first serialization example, the memberEnd refers to property 'id4' and 'id5'. This would lead to 2 inconsistencies: 1. the 'id7' is in ownedEnd, but not in memberEnd. This contradicts the subset defined in chapter 7.3.3. 2. there are two candidates for the derived 'metaclass' attribute of 'Extension': id4.type and id5.type. This contradicts the definition in chapter 18.3.2. Instead it should refer to id7 and id5. The correct XMI file excerpt looks like that: <ownedMember xmi:type="uml:Extension" xmi:id="id6" name="A_Interface_Home" memberEnd="id7 id5"> <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="id7" name="extension_Home" type="id3" isComposite="true" lower="0" upper="1"> </ownedEnd> </ownedMember>

  • Reported: UML 2.1.1 — Wed, 12 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.33

  • Key: UML22-354
  • Legacy Issue Number: 11630
  • Status: closed  
  • Source: Volvo Technology Corporation ( Hans Blom)
  • Summary:

    Figure 7.15 - Contents of Dependencies package There is a rolename supplierDependency that it not defined in §7.3.33 for NamedElement.

  • Reported: UML 2.1.1 — Tue, 23 Oct 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    supplierDependency is a non-navigable end and, therefore, cannot be owned by NamedElement. Per the usual style in the UML specification document, non-owned ends are not listed in the documentation for a class.
    Revised Text:
    None.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In section 7.3.12 Figure 7.38

  • Key: UML22-353
  • Legacy Issue Number: 11489
  • Status: closed  
  • Source: Anonymous
  • Summary:

    As described above the Figure 7.38 I think the arrow should point from Car to CarFactory.

  • Reported: UML 2.1.1 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    In the UML 2.5 specification, the corresponding figure is 7.19 in subclause 7.7.5. The direction of the
    dependency in the diagram is correct: the CarFactory instantiates Cars and so depends on the Car class, but
    the Car class does not need to depend on CarFactory specifically instantiating it.
    However, the text above the diagram says “the Car Class has a Dependency on the CarFactory Class”, which
    is incorrect.
    This also resolves duplicate issues 12405, 13136, 13947 and 17804.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect word renders sentence meaningless: Chap. 12.3.41

  • Key: UML22-351
  • Legacy Issue Number: 11414
  • Status: closed  
  • Source: Kratzer Automation AG ( Tom Riedl)
  • Summary:

    Incorrect word renders sentence meaningless: Chap. 12.3.41, "Parameter (from CompleteActivities)" Section "Semantics", 1st paragraph, Beginning of last sentence: Suggestion: Replace: "Arrange for separate executions of the activity to use separate executions of the activity..." by: "Arrange for separate invocations of the activity to use separate executions of the activity..."

  • Reported: UML 2.1.1 — Mon, 17 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The section titled "Changes from previous UML" is not complete

  • Key: UML22-350
  • Legacy Issue Number: 11413
  • Status: closed  
  • Source: n/a ( Brian Arbuckle)
  • Summary:

    The section titled "Changes from previous UML" is not complete "The following changes from UML 1.x have been made: to be written."

  • Reported: UML 2.1.1 — Mon, 17 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

first constraint for CombinedFragment

  • Key: UML22-346
  • Legacy Issue Number: 11286
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The first constraint for CombinedFragment:

    [1] If the interactionOperator is opt, loop, break, or neg, there must be exactly one operand.” ..

    should also include the assert operator.

  • Reported: UML 2.1.1 — Tue, 21 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.1 AcceptEventAction

  • Key: UML22-345
  • Legacy Issue Number: 11268
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Figures 12.25-27 show examples of the AcceptEventAction. The actions have an outpin pin which can be omitted in the diagram. But the target actions should show the input pins, e.g. action "Cancel order" needs an input pin "Cancel order request".

  • Reported: UML 2.1.1 — Fri, 10 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The referenced diagrams are correct as drawn when the edges are interpreted as control flows rather than data flows.
    Revised Text:
    None
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RedefinableTemplateSignature

  • Key: UML22-344
  • Legacy Issue Number: 11244
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    RedefinableTemplateSignature::classifier owns this template signature, so it shall redefine inherited TemplateSignature::template, because it is used for the same purpose and subsets Element::owner.

  • Reported: UML 2.1.1 — Tue, 7 Aug 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ElementImport

  • Key: UML22-352
  • Legacy Issue Number: 11488
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Element is restricted to be imported only once (not possible to import the same element into different namespaces).
    I think this is clear bug in Figure 7.4 - Namespaces diagram of the Kernel package
    ElementImport multiplicity (on association between ElementImport and PackageableElement) shall be changed from [1] to [*] (as multiplicity of PackageImport).

  • Reported: UML 2.1.1 — Wed, 19 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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.1.1 - fig 7.14

  • Key: UML22-349
  • Legacy Issue Number: 11408
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    This seems odd to me. The ‘owningPackage’ role of PackageableElement is non-navigable, whereas I would expect it to be navigable so that it is possible from a Packageable Element to find its owner. Interestingly Type, which is a PackageableElement does have a navigable role to its parent, but InstanceSpecification, for example doesn’t.

  • Reported: UML 2.1.1 — Fri, 14 Sep 2007 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7

  • Key: UML22-287
  • Legacy Issue Number: 10515
  • Status: closed  
  • Source: Paranor AG ( Earl Waldin)
  • Summary:

    The property isLeaf as inherited by Class from RedefinableElement deals with the concept of redefinition in the context of a classifier. The concept of "this class cannot be subclassed" is missing from UML 2.0 and the current version of UML 2.1. In UML 1.4, the isLeaf property is present in two contexts: Operation and GeneralizableElement. The former refers to the concept of redefinition while the later refers to the concept of subclassing. In UML 2.1, isLeaf from RedefinableElement corresponds to the former. There is nothing corressponding to the later. It is clear from the UML 2.1 specification that redefinition of Classes is related to nesting. In the association class->nestedClassifier between Class and Classifier in Figure 7.12, the source end subsets redefinitionContext. The current constraints for RedefinableElement, Classifier and Class give the following interpretation. Let A be a class with nested class A1, B a class with nested class B1, and B be a subclass of A. Then B1 can redefine A1 as long as A1 has isLeaf = false and A1's visibility is not private. B1 can subclass A1 regardless of the the value of isLeaf on A1. In short, subclassing and redefinition are two separate, orthogonal concepts. The concept of isLeaf for subclassing is not present in UML 2.1.

  • Reported: UML 2.1.1 — Tue, 19 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    In UML 1.5, isLeaf is used in 3 contexts, not two:
    UML 1.5's Operation::isLeaf and Reception::isLeaf in UML 2 correspond to the concept of a redefinable element that cannot be further redefined.
    UML 1.5's GeneralizableElement::isLeaf in UML 2 corresponds to the concept of a classifier that cannot be further specialized in a generalization hierarchy. There are several options to add this capability in UML 2 and the two that are least disruptive to the UML 2 specification are:
    a) Rename RedefinableElement::isLeaf to RedefinableElement::isFinal
    Add Classifier::isLeaf
    b) Keep RedefinableElement::isLeaf
    Add Classifier::isFinal
    c) Keep RedefinableElement::isLeaf
    Add Classifier::isFinalSpecialization
    Option (a) would break compatibility with UML 2.2 in a really bad way because the original meaning of "isLeaf" is now "isFinal" and there is a completely different meaning assigned to "isLeaf".
    Option (b) preserves the UML 2 meaning of "isLeaf" but adds support for the UML 1.x notion of a classifier that cannot be specialized in a generalization hierarchy. However, option (b) creates possible confusion for end users in distinguishing the purpose of isLeaf vs. isFinal.
    Option (c) provides the same advantages as option (b) in addition to providing end users a clue about the role of isLeaf vs. isFinalSpecialization.
    Since option (b,c) represent an upwardly compatible change w.r.t. UML2.2, it is preferred to option (a) which would not only break compatibility with UML 2.2 but also create a lot of confusion in comparing UML 2.2 vs. UML 2.3 models. The rest of this resolution follows option (c).
    Add a property 'isFinalSpecialization' to a Classifier which is the basis for expressing taxonomic relationships among general and specific classifiers.
    Specify a package merge transformation for merging Classifier::isFinalSpecialization according to the principle that a resulting classifier is final if either matching classifier is final.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15

  • Key: UML22-286
  • Legacy Issue Number: 10512
  • Status: closed  
  • Source: fht-esslingen.de ( Dirk)
  • Summary:

    state machines: --------------- I can find a BNF for an behavioral transition but not for a protocol transition. Theres is no explanation why a protocol transition needs the "/" following the trigger. What for is the "/" ? The figure 15.15 on page 521 just shows a protocol trigger but there is no explanation. Wouldn't it be sufficient to write: [pre condition] trigger [post condition] Because of this everyone uses different notations...

  • Reported: UML 2.1 — Fri, 15 Dec 2006 05: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

UML 2.1 Spec, Interactions: 14.3.18

  • Key: UML22-295
  • Legacy Issue Number: 10591
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    I don’t understand why the type of the property ‘InteractionUse.argument’ is Action; I think that there at least needs to be some explanation.

    Also, looking at the syntax for ‘InteractionUse’ in the Notation section:

    “<name> ::=[<attribute-name> ‘=’ ] [<collaboration-use> ‘.’] <interaction-name> [‘(‘ <io-argument> [‘,’ <io-oargument>]* ‘)’] [‘:’ <return-value> <io-argument> ::= <in-argument> | ‘out’ <out-argument>]

    The <attribute-name> refers to an attribute of one of the lifelines in the Interaction.”

    How does the reference to the attribute get stored in the model?

    Finally in Fig 14.18, I don’t see how the notation for the described InteractionUse can be produced from the syntax above, particularly the first part: “:xx.xc=”

  • Reported: UML 2.1 — Fri, 12 Jan 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Arguments of InteractionUse shall be ValueSpecifications, as arguments of Message.
    Furthermore introduce a couple of extra attributes/associations to cover the information not easily found today.
    Finally fix the BNF of the concrete textual syntax by a concluding „]?

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.1 Spec, Interactions: 14.3.18 - InteractionUse

  • Key: UML22-294
  • Legacy Issue Number: 10590
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    One of the constraints for this element is:

    [2] The InteractionUse must cover all Lifelines of the enclosing Interaction that appear within the referred Interaction.”

    This needs to be rephrased I think – I don’t see how Lifelines can “appear” in more than one Interaction.

  • Reported: UML 2.1 — Fri, 12 Jan 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A_outgoing_source and A_incoming_target should not be bidirectional

  • Key: UML22-293
  • Legacy Issue Number: 10537
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The A_outgoing_source and A_incoming_target associations between Vertex and Transition should not be bidirectional - it's unreasonable to expect that a vertex be changed in order to create a transition to another vertex, considering that the vertices could be in a different model from the transition (especially in the context of state machine refinement). Note that since pseudostates are not redefinable, there is currently no way to redefine a transition that has a pseudostate as its source/target. There should perhaps be separate, derived Vertex::outgoing and Vertex::incoming properties instead.

  • Reported: UML 2.1 — Thu, 21 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Superstructure/Components/overly stringent constraints

  • Key: UML22-289
  • Legacy Issue Number: 10526
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The constraints defined for Connectors in the components chapter should be removed: they refer to "provided" and "required" ports (categories no longer supported in UML) but also force very stringent connection rules that get in the way of informal sketching type usage, since they require the explicit declartion of interfaces when doing structure modeling. These types of constraints should only be enforced through a profile.

  • Reported: UML 2.1 — Wed, 13 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    Resolved by 7248-7251.

    Revised Text:
    None
    Disposition: Duplicate of 7248 - 7251

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AcceptCallAction has not operation

  • Key: UML22-288
  • Legacy Issue Number: 10521
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    In UML2, AcceptCallAction isA AcceptEventAction --> trigger: Trigger --> event: CallEvent --> operation: Operation. In the notation, there's the accept call action in an activity which has a name, and an operation provided by the performer. In the metamodel, this would mean that a Trigger and Event would have to be created to connect an operation to an AcceptCallAction. This is overkill resulting in a complex metamodel and extra work for modelers to create Trigger and Event model elements that are not needed.

    AcceptCallAction should have an operation: Operation property directly. Then a <<trigger>> keyword should be used to indicate the operation is implemented with an AcceptCallAction rather than a method Behavior

  • Reported: UML 2.1 — Mon, 11 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The proposed change would, indeed, simplify the model, but it would be inconsistent with AcceptCallAction being, syntactically and semantically, a subclass of AcceptEventAction. AcceptCallAction is just a special case of triggering based on a call event, with some syntactic conveniences. Any complexity of the metamodel should be hidden by proper tool support.
    Revised Text:
    None.
    Disposition: Closed, no change.

  • 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

UML2: notation issue

  • Key: UML22-297
  • Legacy Issue Number: 10634
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    In the spec, some elements have a notation which contain a keyword put in quote like for Abstraction or for Interface. But this keywork does not match the stereotype notation.

    So if I applied a stereotype on such elemen, what is the right notation (see both following examples):

    EX1:

    Ex2:

  • Reported: UML 2.1 — Mon, 29 Jan 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • 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

A_end_role should not be bidirectional

  • Key: UML22-292
  • Legacy Issue Number: 10536
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The A_end_role association between ConnectableElement and ConnectorEnd should not be bidirectional - it's unreasonable to expect that a connectable element be changed in order to connect it to another connectable element, considering that the connectable element(s) could be in a different model from the connector. There should perhaps be a separate, derived ConnectableElement::end property instead

  • Reported: UML 2.1 — Thu, 21 Dec 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ReplyAction::replyValue type is incorrct

  • Key: UML22-298
  • Legacy Issue Number: 10636
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Section 11.3.43 shows the replyValue attribute of ReplyAction is of type OutputPin. It is shown as InputPin in figure 11.12. The type should be InputPin in section 11.3.43

  • Reported: UML 2.1 — Tue, 30 Jan 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This was editorially corrected in UML 2.1.
    Revised Text:
    None.
    Disposition: Closed, no change.

  • 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

Section: 7.3.10

  • Key: UML22-205
  • Legacy Issue Number: 9617
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The description of Constraint mentions the xor-association that is predefined in UML. There's no place in the superstructure (and infrastructure) where that constraint is defined.

  • Reported: UML 2.1.1 — Tue, 2 May 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Figure 7.34 shows an

    {xor}

    constraint attached to two associations, indicating an Account can be a property of Person or Corporation, but not at the same time. Section 7.3.10 Constraint references “xor” constraint as an example of a UML predefined constraint.
    The xor constraint is not explicitly defined in UML. Rather it is used as an example of a constraint between associations as in figure 7.34, and as an example of an expression in section 7.3.18. So the parenthetical remark about xor being an example of a UML predefined constraint in section 7.3.10 should be removed.

  • 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

Table 8.2 must be named "Graphic paths..." instead of "Graphic nodes..."

  • Key: UML22-370
  • Legacy Issue Number: 12235
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Table 8.2 must be named "Graphic paths..." instead of "Graphic nodes..."

  • Reported: UML 2.1.1 — Tue, 19 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

Datatypes in UML profiles

  • Key: UML22-369
  • Legacy Issue Number: 12224
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    The UML Superstructure section on profiling (18, 18.3) is vague about the datatype usage in profiles.
    In particular, it is not clear what (if any) datatypes can the user define and use in his profile as types of the tags.

    --------------------------------------------------------------------------------
    Datatypes used in profiles (e.g. as types of the tags) are not ordinary UML datatypes, but MOF datatypes (if I am not mistaken).
    Hence it is not obvious if all of the various datatype possibilities, defined in CMOF, can be used by a profile creator.

    It would be nice to have some clarifying statement in the Semantics section of the 18.3.6 Profile paragraph
    In the same manner as the possible associations between stereotypes is clarified there (page 663, at the bottom):

    Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is
    owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by
    the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than
    the other class/metaclass
    (a little side note - I am not sure if this passage is correct - ?metalevel mixing? but this is irrelevant for the issue I am describing)

    --------------------------------------------------------------------------------
    I can think of the 4 distinct cases of datatypes that the modeler might use in his profile:

    #1 Enumerations
    #2 New primitive types, narrowing the existing primitive types - String, Integer, Boolean, UnlimitedNatural.
    e.g.

    #3 Completely new primitive types, e.g. Double
    #4 Complex datatypes, defined by the user, composed of fields of primitive types and other complex types.
    e.g.

    #1 and #2 are the least problematic. #1 is widely supported even in the current crop of modeling tools and
    #2 is conceptually simple (handling is the same as existing primitive types + additional constraints)

    What I am worried about is #3 and #4.
    #3 is problematic; the question arises about how the values of this type are then handled in the model and how they are
    serialized into the XMI.
    Maybe we could state here that if the tool allows the user to define his own primitive types, then the user is responsible for
    extending the tool (through some kind of plugin mechanism) - providing at least the rules of how to serialize such datatypes into the string,
    to be written into the XMI.

    #4 Is theoretically non problematic (supposedly, it is described how to serialize such complex datatype values - XMI 2.1.2 spec, 07-12-01.pdf, 4.8.7 paragraph).
    However I haven't seen live implementations of this. Is the usage of such datatypes in the profile legal?

    --------------------------------------------------------------------------------
    So, to summarize, we should clarify here, if all of these cases must be supported by the UML tool. Are there any
    semantic variation points or compliance levels here?

  • Reported: UML 2.1.2 — Thu, 14 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TemplateSignature / TemplateParameter / StructuredClassifier

  • Key: UML22-364
  • Legacy Issue Number: 12168
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    Version 2.1.1 2007-02-05 of the spec.

    TemplateSignature p. 625
    parameter : TemplateParameter[] Should mention that it is a derived union of TemplateSignature::ownedParameter ( or show ‘/’ )

    ownedParameter: TemplateParameter[] Should mention that it subsets TemplateSignature::parameter.

    TemplateParameter p. 623

    default : ParameterableElement should mention that it is a derived union of TemplateParameter::ownedDefault ( or show ‘/’ )

    parameteredElement::ParameterableElement[] should mention it is a derived union of TemplateParameter::ownedParameteredElement

    StructuredClassifier p. 186

    There seems to be some discrepency in the spec in regards to Role : ConnectableElement[]. The spec mentions that it is a derived union (it uses the term Abstract union which is inconsistent ) that subsets Classifier::feature. I believe we should have StructuredClassifier::ownedAttribute subsetting StructuredClassifier::role.

  • Reported: UML 2.1.2 — Tue, 8 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

inability to specify ordering of messages connected to gates is problematic

  • Key: UML22-363
  • Legacy Issue Number: 12167
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    In the 2.1.1 specification (070205):

    Gates are simply MessageEnds and not some form of OccurrenceSpecification. This makes relative ordering of messages between gates on different InteractionUse within an interaction impossible.
    In addition to gates on InteractionUse, gates on Interaction that have outgoing messages cannot specify any relative ordering.

    The inability to specify ordering of messages connected to gates is problematic.
    __________________________________

  • Reported: UML 2.1.2 — Tue, 8 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Add clarification that Gates are messageEnds which are ordered by the occurrences at the opposite ends of
    the two messages linked by the gate. UML 2.5 already added several clarification on semantics of Gates.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The semantics of an assembly connector remains unspecified

  • Key: UML22-372
  • Legacy Issue Number: 12241
  • Status: closed  
  • Source: AdaCore ( Matteo Bordin)
  • Summary:

    The semantics of an assembly connector remains unspecified: it is not possible to understand which port is the source and which port is the target of the data that are meant to "flow" at run-time on the assembly. The specification indeed refer to "required port" to express the semantics of a connector, but the concept of "required port" doesn't exist in UML. The real problem is the following: it is not possible to specify which interfaces provided/required by a port are involved in an assembly. A possible solution could be: - Have a port typed to an interface - Specify if the interface is provided or required using a tag (in a way similar for the direction of SysML FlowPort)

  • Reported: UML 2.1.2 — Wed, 20 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    I am not sure that this is really a semantics question. If the semantics are in doubt, that is an issue about connectors in general. I believe this is actually the issue about the ball and socket notation, which is resolved by the changes specified in 8168 and 8900, by restricting the notation to parts with simple ports.

    Revised Text:
    None.

    Disposition: Duplicate of 8168 and 8900.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 8.2

  • Key: UML22-371
  • Legacy Issue Number: 12236
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Table 8.2 should contain graphic paths for - delegate connector - component realization

  • Reported: UML 2.1.1 — Tue, 19 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Table 8.2 shows the assembly connector which is an element of a composite structure diagram. But table 8.2 denotes elements of a structure diagram. A table for composite structure diagram elements that are specific for components is missing.
    The heading of table 8.2 is incorrect. The table doesn't show nodes, but paths.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2: Missing ActionOutputPin

  • Key: UML22-362
  • Legacy Issue Number: 12161
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    UML2 Activities support two different approaches for exchanging data between actions: "push semantics" of token passing over ObjectFlows and "pull semantics" of typical programming languages using ActionInputPins or ValuePin. The fromAction of an ActionInputPin could be a ValueExpression that references a Variable of the Activity or StructuralFeature of the context Classifier. However, support for pull semantics is incomplete. The first issues is 9247 where there is no ReadParameterAction or WriteParameterAction to support pull semantics for Activity Parameters. These Actions should be provided so that ActivityParameterNodes are only needed for ObjectFlows allowing the Activity Parameters to be directly referenced for pull semantics. This would also allow Parameters, Variables and StructuralFeatures to be all handled the same way.

  • Reported: UML 2.1.2 — Mon, 7 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Despite the misleading title, this issue appears to be essentially a duplicate of issues 9247 and 8470. It looks like the text in this issue was just introductory to that of issue 12162, and was incorrectly made an issue of its own.
    Revised Text:
    None.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The spec needs to clarify the isConsistentWith() method for transitions

  • Key: UML22-361
  • Legacy Issue Number: 12158
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    In the 2.1.1 specification (070203) states on page 583/732 (or pg.569), it states:
    [1] The query isConsistentWith() specifies that a redefining transition is consistent with a redefined transition provided that
    the redefining transition has the following relation to the redefined transition: A redefining transition redefines all
    properties of the corresponding redefined transition, except the source state and the trigger.

    This restriction seems a little harsh. Consider the use case:
    1) a user has a state machine, in a top level abstract class, and there exists a transition between two states with no triggers.
    2) the users expect to add triggers to the transition in the concrete sub class state machines. (i.e. redefine in the sub class context and add a trigger)

    The way the above constraint is written does not allow new triggers to be added to redefined transitions. I am requesting a clarification point that will state that new triggers can be added to the redefined transition.

  • Reported: UML 2.1.2 — Fri, 4 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 6395

  • Updated: Fri, 6 Mar 2015 20:58 GMT

paragraph on "deferred events" on page 552

  • Key: UML22-367
  • Legacy Issue Number: 12204
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Towards the bottom of the page there is a paragraph on "deferred events". This appears to be a holdover from UML 1.x, as the current specification speaks of "deferred triggers" (see p.550). Adjust this paragraph to match the current abstract syntax. Similar changes must be made to the corresponding paragraph on p.554.

  • Reported: UML 2.1.2 — Wed, 31 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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 14.3.19

  • Key: UML22-366
  • Legacy Issue Number: 12195
  • Status: closed  
  • Source: mit.bme.hu ( Zoltan Micskei)
  • Summary:

    In the description of Lifeline the coveredBy association has a multiplicity of [0..1]. However, in Figure 14.4 the multiplicity is *, in the XMI it has also * as upper bound, and the text talks also about multiple InteractionFragments ("References the InteractionFragments in which this Lifeline takes part").

  • Reported: UML 2.1.2 — Thu, 24 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

Figure 7.6

  • Key: UML22-360
  • Legacy Issue Number: 11828
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure 7.6 should show properties body and language of OpaqueExpression as multivalued i.e. [0..*].

  • Reported: UML 2.1.2 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12

  • Key: UML22-359
  • Legacy Issue Number: 11763
  • Status: closed  
  • Source: Student at Technische Universität Braunschweig ( Stefan Schulze)
  • Summary:

    The constraint [2] in section 12.3.5 on page 325 ("Activity edges may be owned only by activities or groups") of class ActivityEdge seems to be contrary to the fact that inGroup - the only reference between edge and group - is a simple association but no composition or aggregation. According to figures 12.5 and 12.6 I would think, that edges are always owned by activities (composition) and referenced by groups. There is no composition or aggregation that specifies, that edges can be owned by groups. (http://groups.google.de/group/UMLforum/browse_thread/thread/bdd07d113676a41f/20b33a18f90db3d9?#20b33a18f90db3d9

  • Reported: UML 2.1.1 — Thu, 6 Dec 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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

15.3.14: This paragraph refers to signal and change events

  • Key: UML22-368
  • Legacy Issue Number: 12218
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    This paragraph refers to signal and change events, but should refer to signal and call events: >>However, relative to its use for signal events (see “SignalEvent (from Communications)” on page 449) and change events (see “ChangeEvent (from Communications)” on page 435), the <assignment-specification> ... Instead it should read: >>However, relative to its use for signal events (see “SignalEvent (from Communications)” on page 449) and call events (see “CallEvent (from Communications)” on page 434), the <assignment-specification> ... ChangeEvents don't even have an assignment specification, but signal an call events do.

  • Reported: UML 2.1.2 — Fri, 8 Feb 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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 Connector

  • Key: UML22-358
  • Legacy Issue Number: 11762
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In fig. 8.12 on page 153 the delegate connector points directly to an interface or from an interface on the right side. According to the connector definition in 9.3.6 and 8.3.2 it is not allowed to do that. In addition such a notational variant is nowhere described.

  • Reported: UML 2.1.1 — Thu, 6 Dec 2007 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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.1.1 Issue: Invalid association end in Figure 7.20

  • Key: UML22-365
  • Legacy Issue Number: 12193
  • Status: closed  
  • Source: Eclipse Foundation ( Mr. Kenneth Hussey)
  • Summary:

    The non-navigable (as indicated by the X) association end typed by classifier ‘B’ in figure 7.20 of 07-02-05 is invalid, since the classifier – not the association – owns that end (as indicated by the dot notation as described on page 42)… recall that an association end owned by a classifier (and not the association) is implicitly navigable.

  • Reported: UML 2.1.2 — Tue, 22 Jan 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    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: 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

UML 2 state machines / entry point outgoing transitions

  • Key: UML22-274
  • Legacy Issue Number: 10147
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In section 15.3.8 of the of the UML spec 06-04-02.pdf on page 563 it says:

    An entry point pseudostate is an entry point of a state machine or composite state. In each region of the state machine or composite state it has a single transition to a vertex within the same region.

    I believe that the intent was to say "at most a single transition", since it is possible that no transition exists as well as having multiple outgoing transitions (with guards) in each region.

  • Reported: UML 2.1 — Wed, 30 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It is correct that entry points do not 'have' to have an outgoing transition. Updating the text is appropriate.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 60 of the pdf

  • Key: UML22-278
  • Legacy Issue Number: 10356
  • Status: closed  
  • Source: Queen's Unioversity ( Juergen Dingel)
  • Summary:

    Page 60 of the pdf (41 in the doc), right above Figure 7.19:

    • replace "also shows umambiguously that end B is owned by BinaryAssociationAB"
      by "also shows umambiguously that endB is owned by BinaryAssociationAB"
  • Reported: UML 2.1 — Wed, 20 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The is a space between end and B. end B should be endB.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2: Parameter::isException overlaps with Operation::raisedException

  • Key: UML22-277
  • Legacy Issue Number: 10353
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Section 12.3.41 in CompleteActivites extends Parameter with an isException property. Operation also has property raisedException. The relationship between parameters with isException true and the operation's raisedExceptions is unclear. Is it the intention that Parameter::isException is a notation for indicating the exceptions raised by an operation. If so, then it should be in Basic where raisedException is introduced and constraints need to be added to ensure these parameters are not included in the operation's ownedParameters, and are include in the operation's raisedException. See also Issue 9406: UML2: No notation for indicating Operation::raisedException. Hopefully this is not the case because it mixes parameter and exceptions together and results in redundancy in the metamodel.

    It is possible isException was added so Activities could have an ActivityParameterNode to output exceptions. But this did not get completely integrated with the rest of UML2. I will raise an issue for this too. Perhaps there should be ActivityExceptionNodes that correspond to an operation's raisedExceptions instead of mixing parameters with exceptions.

  • Reported: UML 2.1 — Tue, 19 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

uml.xsd schema file in ptc/2006-04-05 is not correctly generated

  • Key: UML22-279
  • Legacy Issue Number: 10376
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    New ISSUE on UML 2.1 Schema File

    Source: Tom Rutt (Fujitsu)

    Criticality: URGENT

    Problem Description:

    The UML 2.1 RTF Final report cites the following supporting
    documents:

    ptc/2006-04-02 Unified Modeling Language: Superstructure
    ptc/2006-04-03 Unified Modeling Language: Infrastructure
    ptc/2006-04-04 Unified Modeling Language: XMI specifications
    ptc/2006-04-05 Unified Modeling Language: XSD specifications

    The uml.xsd schema file in ptc/2006-04-05 (which is an
    informative document) is not correctly generated.

    In particular, several of the enum values specified in this
    schema have prefixes attached, which are not specified in the
    Meta Model. For example, the visibilityKind enumeration has its
    values improperly prefixed by the string “vis_” ( vis_public, vis_private …).

    This has caused interoperability problems with existing tools,
    since some of them have used the incorrectly generated xsd file for
    uml There is a need to post a corrected uml 2.1 schema on the document server.

    Also, the OMG document references for the supporting xmi and
    schema files are not up to date in the superstructure specification.

    Proposed Solution:

    Post properly generated schemas in a new UML 2.1 XSD Specification
    file on the server.

    Post an updated version of the UML 2.1 RTF report which refers to
    the correctly generated UML XSD specification file.

    The Document references cited in Annex G of the UML 2.1
    superstructure spec should be corrected to point at the most up
    to date and correct specifications.

  • Reported: UML 2.1 — Thu, 28 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2: ReadSelfAction with a context cannot access behavior owned attributes

  • Key: UML22-284
  • Legacy Issue Number: 10441
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Section 11.3.36 ReadSelfAction, Semantics indicates ReadSelfAction returns the context classifier for a behavior if the behavior has a context, otherwise it returns the behavior itself. This special case should be removed. ReadSelfAction should always result in the behavior. Otherwise if a behavior has a context classifier, there is no action available to access the structural features of the behavior. Having ReadSelfAction always result in the Behavior provides access to both the Behavior's ownedAttributes as well as those of the context classifier. If ReadSelfAction is the context classifier, then only its properties can be accessed.

  • Reported: UML 2.1 — Sun, 5 Nov 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    Duplicate of issue 8016.
    Revised Text:
    None.
    Disposition: Duplicate

  • 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

12.3.27 ExpansionRegion

  • Key: UML22-273
  • Legacy Issue Number: 10146
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Typo in paragraph Presentation options on page 385: insert blank between "12.85" and "maps".

  • Reported: UML 2.1.1 — Mon, 28 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This seems to have already been corrected in UML 2.2 as an editorial change.
    Revised Text:
    None
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

12.3.26 ExpansionNode

  • Key: UML22-272
  • Legacy Issue Number: 10145
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Specify constraint that a expansion node can have a regionAsInput and a regionAsOutput, but not both at the same time.

  • Reported: UML 2.1.1 — Tue, 1 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Meaning of Constraint visibility

  • Key: UML22-281
  • Legacy Issue Number: 10382
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Constraint inherits visibility from PackageableElement but there is no
    description of what it might mean for a Constraint to be more or less
    visible.
    One option would be to constrain Constraint::visibility to be a specific
    value

  • Reported: UML 2.1 — Thu, 5 Oct 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.38

  • Key: UML22-280
  • Legacy Issue Number: 10379
  • Status: closed  
  • Source: St. Petersburg State University ( Iskander Absalyamov)
  • Summary:

    visibility default value cannot be false

  • Reported: UML 2.1.1 — Mon, 30 Oct 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 10831 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 12.3.2 Action

  • Key: UML22-276
  • Legacy Issue Number: 10351
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Semantics, rule [2] "If multiple control tokens are available on a single edge, they are all consumed." How does this rule fit to the rule that the default weight of an edge is 1. If multiple control tokens are available only one of them can traverse the edge to the target node

  • Reported: UML 2.1.1 — Tue, 19 Sep 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

redefined properties

  • Key: UML22-271
  • Legacy Issue Number: 10144
  • Status: closed  
  • Source: International Business Machines ( James Bruck)
  • Summary:

    I believe that Port should subset Property::redefinedProperty to include Ports since Ports are Properties

  • Reported: UML 2.1 — Mon, 28 Aug 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change references in Infra- and Superstructure to UML 2.1.1- URGENT ISSUE-

  • Key: UML22-282
  • Legacy Issue Number: 10386
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Change all references to UML 2.1 in the Infrastructure and Superstructure documents to UML 2.1.1

  • Reported: UML 2.1 — Thu, 12 Oct 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Activities - Pin ordering semantics

  • Key: UML22-240
  • Legacy Issue Number: 9860
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Pin ordering semantics. In Activities, InputPin, OutputPin, the semantics of ordering inherited from ObjectNode should be related to multiplicity ordering inherited from MultiplicityElement. For example, if an output pin of ReadStructuralFeatureAction has an object node ordering of FIFO, and the structural feature is ordered (which means the multiplicity ordering of the pin is also), then perhaps the multiple values posted by a single execution of the action should be drawn from the pin in the same order as in the structural feature. Since the action will post the values to the output pin at the same time, currently FIFO ordering on the pin will be indeterminant

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Add text below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section Activities: Default weight

  • Key: UML22-239
  • Legacy Issue Number: 9858
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Default weight. In Activities, ActivityEdge, Assocations, the default weight should be unlimited . For example, a ReadStructuralFeatureAction of a mult-valued attribute might produce multiple tokens, which flow to the input of an AddStructuralFeatureAction. Do not want the values to be input to separate executions of AddStructuralFeatureAction

  • Reported: UML 2.1.1 — Tue, 27 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The spec says weight determines the minimum number of tokens that must traverse the edge (offers accepted by target) at the same time. And it requires any tokens offered above the minimum to be taken at the same time:
    When the minimum number of tokens are offered, all the tokens at the source are offered to the target all at once.
    So the default can remain 1 for the example.
    Revised Text:
    None.
    Disposition: Closed No Change

  • 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

Section: 7

  • Key: UML22-226
  • Legacy Issue Number: 9823
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    In UML2, it is possible to describe user defined datatypes and propertis may typed by this typed. But, nothing has been defined in the UML2 specifcation to be abble to describe values (of slots for example) which has to be conform to a datatype. One could add a new metaclass (for example, DataTypeValueSpecification inheriting from ValueSpecification) in the Expression package to be abble to denote datatype values. And to define the underlying notation.

  • Reported: UML 2.1.1 — Mon, 12 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 15248

  • 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: 12.3.8

  • Key: UML22-232
  • Legacy Issue Number: 9829
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Section Associations of ActivityNode: /inGroup:Group[0..*] Groups containing the node. should be /inGroup:ActivityGroup[0..*] Activity groups containing the node.

  • Reported: UML 2.1.1 — Mon, 19 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • 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: 15.3.12

  • Key: UML22-236
  • Legacy Issue Number: 9839
  • Status: closed  
  • Source: Engenuity Technologies, Inc. ( Mikon Dosogne)
  • Summary:

    If there are multiple enabled internal transitions within the active state, should they all be fired? The standard suggests that they should all be fired, but is this done in practice? For example, consider the case of two internal transitions within the same state, triggered by the same event, with no guard condition. If that event occurs, will both transitions fire?

  • Reported: UML 2.1.1 — Mon, 26 Jun 2006 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 9840

  • 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

Page: 338, 339

  • Key: UML22-185
  • Legacy Issue Number: 9330
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The fork node does not provide tokens to outgoing edges with a guard that evaluates to false. Actions with more than one outgoing edge have a implicit fork semantic. It is unclear if a token is provided to edges with false-guards. The specification defines on page 339: "The guard must evaluate to true for every token that is offered to pass along the edge." Does the token exist if the guard evaluates to false? Does the token wait until it evaluates to true? The evaluation is done at runtime. At which time exactly? While offering tokens or all the time during activity runtime?

  • Reported: UML 2.1 — Mon, 30 Jan 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    In the UML 2.5 beta specification, in Subclause 15.2.3, under “Activity Edges”, it states: “An ActivityEdge may have
    a guard, which is a ValueSpecification that is evaluated for each token offered to the edge.” In 15.3.3, under “Fork
    Nodes”, it further states: “Tokens offered to a ForkNode are offered to all outgoing ActivityEdges of the node.” Thus,
    the guards on outgoing edges are evaluated when the tokens offered to the ForkNode are offered to them. Finally, the
    specification notes: “Any outgoing ActivityEdges that fail to accept an offer due to the failure of their guard, rather
    than their target, shall not receive copies of those tokens.” So, outgoing edgeswith guards that evaluate to false do not
    receive tokens and therefore do not offer them downstream.
    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

Page: 625

  • Key: UML22-189
  • Legacy Issue Number: 9362
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Extend (with condition) entry in diagram table: The comment anchor line has a small circle at the end. That's not UML notation, but Pavel Hruby notation

  • Reported: UML 2.1 — Wed, 15 Feb 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18084

  • 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

Section: 12.3.48

  • Key: UML22-196
  • Legacy Issue Number: 9416
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I've found a implicit constraint: Imagine - for example - a LoopNode. It's part of an activity partition called component1. Within the body of the loop node an action should be called that's part of another activity partition called component2 (It's a common scenario: a component calls another component from within a loop). However that's not allowed: the loop node is in partition component1 while a contained action is in partition component2. Is that right? If yes, I believe it should be allowed.

  • Reported: UML 2.1 — Tue, 14 Mar 2006 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It is not clear what the submitter means by a loop node "calling" an action. As a structured activity node, a loop node owns the actions within it. However, an activity partition references contained nodes and edges, but it does not own them. Therefore, it is allowable for the actions contained in a loop node to be in different partitions, if this is what is desired.
    Revised Text:
    None
    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

Meaning of navigability

  • Key: UML22-140
  • Legacy Issue Number: 8921
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The resolution to issue 6460 in the InfrastructureLibrary specification indicates "Implementation can support traversal across non-navigable ends, but it is not required. Once an object is found by traversal, messages can be sent to it like any other object." This statement may lead to interoperability problems between implementations, is not included in the adopted Superstructure specification, and contradicts constraint [4] for ReadLinkAction which states the end must be navigable. Infrastructure also does not define what it means to send messages to an object so it is not clear what these statements actually mean.

    It is possible that the resolution to issue 6243 traded coupling between navigability and property ownership for coupling between navigability and tool implementations. Navigability no longer has any well-defined semantics and becomes simply a hint to tool implementors that the traversal should be efficient.

    I believe this is quite unfortunate and can be avoided by decoupling tool implementations that manipulate models from the meaning of the models themselves. Navigability should continue to mean semantically traversable as specified by ReadLinkAction. This will establish an interoperable meaning across all tools and preserve an important and commonly used semantic. If tools wish to support efficient traversal to non-navigable ends for their purposes, they should feel free to do so. This can be done by maintaining additional information in associations for the non-navigable ends for the tools purpose, or by using crawlers that examine the model and cache information for specific tool purposes. This is manipulating the model for very different purposes than the meaning of the model itself. If it is desired to have some standard means of indicating to tool vendors where non-navigable association ends should be efficiently traversable, this should be done by a separate property perhaps available through the standard profile. It should not be coupled with the semantic meaning of navigability.

  • Reported: UML 1.4.2 — Fri, 1 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

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 134, Chapter 11.4.1

  • Key: UML22-138
  • Legacy Issue Number: 8904
  • Status: closed  
  • Source: Anonymous
  • Summary:

    on page 134, Chapter 11.4.1, you write:

    "Constructs::Classifier merges the definitions of Classifier from Basic and
    Abstractions. It adds specializations from Constructs::Namespace and
    Constructs::Type."

    In Basic there is no definition for "Classifier".

  • Reported: UML 1.4.2 — Thu, 30 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 97, Chapter 10.2.2. MultiplicityElement

  • Key: UML22-137
  • Legacy Issue Number: 8903
  • Status: closed  
  • Source: Anonymous
  • Summary:

    On page 97, Chapter 10.2.2. MultiplicityElement, you write

    "Constructs::Relationship reuses the definition of Relationship from
    Abstractions::Relationships. It adds a specialization to
    Constructs::Element."

    which seems to be a little mislead copy-paste-action.

  • Reported: UML 1.4.2 — Thu, 30 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: 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

ObjectNode

  • Key: UML22-135
  • Legacy Issue Number: 8895
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    ObjectNode is abstract, so CentralBuffer or DataStore should be always used in Activity diagram. It is normal?
    CentralBuffer and DataStore are described as "special cases of ObjectNodes", but simple ObjectNode can't exist.

  • Reported: UML 1.4.2 — Mon, 20 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Yes, this is correct. ObjectNode is a general abstraction. Only its subclasses (which include ActivityParameterNode, InputPin and OutputPin, in addition to CentralBufferNode and DataStore) have concrete syntax and semantics.
    Revised Text:
    None
    Disposition: Close, no change

  • 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

UseCase and Actors

  • Key: UML22-134
  • Legacy Issue Number: 8893
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    UseCase can be connected with Actors using Association, but neither UseCase nor Actor can't own Properties (there are no subsets), so Association is always non-navigable, properties are owned by Association.

  • Reported: UML 1.4.2 — Mon, 20 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: 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: 10.1 Types Diagram

  • Key: UML22-128
  • Legacy Issue Number: 8882
  • Status: closed  
  • Source: University of Kassel, Germany ( Thomas Weise)
  • Summary:

    The Elements Type, NamedElement and TypedElement of the package Core::Basic are (ambiguous and redundant) redefinitions of the types Type, TypedElement (Core::Abstractions::TypedElements), and NamedElement (Core::Abstractions::Namespaces). Why is that?

  • Reported: UML 1.4.2 — Tue, 28 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

Figure 179 (Control nodes)

  • Key: UML22-93
  • Legacy Issue Number: 8673
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    Figure 179 (Control nodes) is not a complete partition of ControlNode: ForkNode, JoinNode, etc. are missing.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This was resolved by the resolution to issue 7319 (during the UML 2.0 FTF), which added the FundamentalActivities package and resulted in changes to related diagrams.
    Revised Text:
    None
    Disposition: Duplicate

  • 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: Actions

  • Key: UML22-101
  • Legacy Issue Number: 8702
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add OCL to constraints in Actions chapter

  • Reported: UML 1.4.2 — Tue, 26 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. All constraints that can be specified in OCL have been in UML 2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CombinedFragment Loop notation

  • Key: UML22-100
  • Legacy Issue Number: 8698
  • Status: closed  
  • Source: TMNA Services ( Jim Schardt)
  • Summary:

    There seems to be some confusion about how to show the notation for the loop combinedFragment. Some tools show only the minint and maxint for the loop InteractionOperator but do not allow you to show the full specification in the InteractionOperand. This is a limitation that allows for the modeling of simple for loops without an additional guard to model do while and do until types of loop constructs. I would suggest the UML Superstructure 2.0 be updated with the following:

    In Section 14.3.3 in Notation with header Loop:
    Place a simple example of a loop combined fragment with a InteractionOperand guard as well as a minint and maxint
    Add a paragraph that says something like, "In those cases where more control over the number of passes through the CombinedFragment is necessary use a separate InteractionConstraint. This InteractionConstraint is shown in square brackets covering the lifeline where the first event occurrence will occur, positioned above that event, in the containing Loop InteractionOperand. If this separate InteractionConstraint is true, the loop continues, otherwise the loop terminates."

  • Reported: UML 1.4.2 — Thu, 21 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • 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

editorial in section 12

  • Key: UML22-98
  • Legacy Issue Number: 8689
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    "... is eligible for execution when it receives control tokens from each of its predecessor clauses. " Should read ``a control token''

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Different constraints for Property in Super and Infra

  • Key: UML22-97
  • Legacy Issue Number: 8688
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The Infrastructure has an additional constraint on Constructs::Property (pg. 128):

    [2] A specialization of a composite aggregation is also a composite aggregation.

    that does not exist in the Superstructure. These two should be made consistent; either the constraint appears in both places or in neither.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    It appears a sentence was removed from superstructure but not InfrastructureLibarary.
    Revised Text:
    In section 11.3.5, subsection Constraints, change:
    [2] A specialization of a composite aggregation is also a composite aggregation.A multiplicity of a composite aggregation must not have an upper bound greater than 1.
    To:
    [2] A multiplicity of a composite aggregation must not have an upper bound greater than 1.

  • 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

rewording isuse?

  • Key: UML22-96
  • Legacy Issue Number: 8687
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    "When an execution of an activity makes a token available to the input of an expansion region, the expansion region consumes the token and begins execution." ``the input'' is ill-defined, since an expansion region has several inputs, see Examples in the same subsection. It should read: "When an execution of an activity makes a token available to each of the inputs of an expansion region (implicit join), the expansion region consumes these tokens and begins execution."

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Resolution:
    This should be merged with Issue 8725.
    Revised Text:
    None
    Disposition: Duplicate/merged

  • Updated: Fri, 6 Mar 2015 20:58 GMT

reword sentence

  • Key: UML22-95
  • Legacy Issue Number: 8686
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    " Any test section with a predecessorClause " Should be: " Any test section whose parent clause has a predecessorClause "

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A test cannot be empty

  • Key: UML22-94
  • Legacy Issue Number: 8682
  • Status: closed  
  • Source: FUNDP ( Pierre Yves Schobbens)
  • Summary:

    A test cannot be empty since it has at least a decider: 0..* should be changed to 1..*.

  • Reported: UML 1.4.2 — Tue, 5 Apr 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    agreed

  • 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

Starting state machine

  • Key: UML22-2
  • Legacy Issue Number: 4932
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    [Steve Mellor] The action semantics has an action that starts a state
    machine. The state machine starts in some known initial (pseudo-)state.

    There are many cases where one wants to initialize a state
    machine so that starts in a specified (non-initial) state.

    Therefore the StartStateMachineAction needs to accept a state
    (possibly multi-leveled) as an input. The state machine will
    not execute any procedures or actions until after the state
    machine is in the target state and then detects an event.

  • Reported: UML 1.4 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disposition: Deferred to UML 2.4 RTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Starting a state machine

  • Key: UML22-3
  • Legacy Issue Number: 5107
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Description:
    The State Machines chapter (Section 2.12) does not provide a clear description of what it means to "start" a state machine.

    Syntactically, we have the following:

    o Well-formedness rule [1] for Pseudostate (p. 2-157) says "An initial vertex [i.e., a initial pseudostate] can have at most one outgoing transition and no incoming transitions". Presumably, it is the single transition from the initial pseudostate at the top level that is taken when the state machine starts.

    o Well-formedness rule [6] for Transition (p. 2-160) says "An initial transition at the topmost level either has no trigger [i.e., event] or it has a trigger with the stereotype 'create'." Thus, the ONLY kind of event allowed on an initial transition is a "creation event".

    o The definition of the stereotype <<create>> is (p. 2-149):

    "Create is a stereotyped call event denoting that the instance receiving
    that event has just been created. For state machines, it triggers the
    initial transition at the topmost level of the state machine (and is the
    only kind of trigger that may be applied to an initial transition)."

    Thus, a "creation event" MUST be a call event.

    o However, well-formedness rule [5] for Transition (p. 2-160) states without qualification, that "Transitions outgoing pseudostates may not have a trigger"! This prohibits all together the "creation events" allowed by rule [6].

    Semantically, there is no specific discussion of how a state machine "starts". Section 2.12.4.3 describes "Entering a non-concurrent composite state" on p. 2-162 and "Entering a concurrent composite state" on p. 2-163. Since the top state of a state machine must be a composite state, one could assume that "starting" a state machine has the semantics of entering the composite top state. However, this does not provide an explanation of the "creation events" allowed (or at least seem intended to be allowed) in the special case of the initial transition at the top level.

    Now, well-formedness rule [5] of StateMachine says "If a StateMachine describes a behavioral feature, it contains no triggers of type CallEvent, apart from the trigger on the initial transition (see OCL for Transition [8])" (this is probably intended to refer to Transition rule [6]). Presumably, then, the call event on the initial transition is suppose to be the call event for the behavioral feature described by the state machine, at least in this case, but this is not described in the semantics (and it doesn't make sense for this event to be a "creation" event, anyway).

    This issue came out during the finalization of the Action Semantics. In the Action Semantics, when an object is created, any state machine associated with the object (via its classifiers) are NOT started automatically. Instead, there is an explicit "StartStateMachineAction" which is supposed to "start the execution of the state machines." However, it is not clear from the current state machine semantics what it really means to do this.

    Recommendation:

    1. Describe the "start" of the execution of a state machine as an RTC step from an implicit "not started" state (that is, not explicitly modeled in the state machine) to the target of the initial transition of the state machine (that is, the single transition with the top-level initial pseudo-state as its source). This RTC step includes the execution of any relevant transition actions and entry actions, per the usual state machine semantics.

    2. Define that, if no other explicit specification is given in a model, a state machine associated with a classifier is assumed to start when an instance of the classifier is created and a state machine associated with a behavioral feature is assumed to start when that feature is invoked. (When the action semantics is included, a formal specification of the start of a state machine can be given with the StartStateMachineAction.)

    3. Change well-formedness rule [5] to exclude the top initial pseudo-state.

    4. Change well-formedness rule [6] to allow, if the state machine describes a behavioral feature, a trigger (call event or signal event) on the initial transition that corresponds to that behavioral feature.

    5. If the state machine describes a classifier, then, in the absence of the action semantics, it is unclear whether a "creation event" is really useful at all (particularly since it would only allow for a single creation operation). With the action semantics, such an event is probably unnecessary, since the procedure for a creation operation will then be able to explicitly create an instance (using CreateObjectAction), start the state machine of that instance (using a StartStateMachineAction), which will get the state machine into a "real" state, and then send the instance a message (using an ExplicitInvocationAction), which can be handled by an event on the state machine, with any additional data required for initialization.

  • Reported: UML 1.4 — Thu, 4 Apr 2002 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disposition: Deferred to UML 2.4 RTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

saying {nonunique} on one end of a binary association is meaningless

  • Key: UML22-5
  • Legacy Issue Number: 5977
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    Also, saying

    {nonunique}

    on one end of a binary association is
    meaningless by the current rules, because the other end remains

    {unique}

    by
    default, so no duplicate links would be allowed

  • Reported: UML 1.5 — Thu, 19 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Also, saying

    {nonunique}

    on one end of a binary association is meaningless by the current rules, because the other
    end remains

    {unique}

    by default, so no duplicate links would be allowed
    Disposition: Merged with 6464

  • Updated: Fri, 6 Mar 2015 20:58 GMT

behaviour of the shallow history state and deep history state

  • Key: UML22-4
  • Legacy Issue Number: 5886
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the UML specification the behaviour of the shallow history state and deep history state are described (added below). The final state is seen as a real state in UML which can have entry actions and in which can be stayed. When a child composite state is in its final state and at a higher level a transition is taken to an other state and then to the deep history state we expect that the final state is set active again, instead that then default history state is made active. For example we have a composite state that does the setup of a piece of hardware and it is in the final state, but it doesn't leave the composite state because another condition is not true yet. When now the composite state is left at a higher level (for example emergency), then we go back according to the spec to the default history state, so we do the complete setup again, but we expect to return in the final state.

    Shallow history entry: If the transition terminates on a shallow history pseudostate, the active substate becomes the most recently active substate prior to this entry, unless the most recently active substate is the final state or if this is the first entry into this state. In the latter two cases, the default history state is entered. This is the substate that is target of the transition originating from the history pseudostate. (If no such transition is specified, the situation is illegal and its handling is not defined.) If the active substate determined by history is a composite state, then it proceeds with its default entry. • Deep history entry: The rule here is the same as for shallow history except that the rule is applied recursively to all levels in the active state configuration below this one.

  • Reported: UML 1.5 — Fri, 21 Mar 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disposition: Deferred to UML 2.4 RTF

  • 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

UML 2 Issue: Qualified pathnames

  • Key: UML22-22
  • Legacy Issue Number: 6466
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    The notation for qualified names is double-colon ('::'). However, the Spec
    always and everywhere uses a different notation: instead of
    "Kernel::Comment", "Comment (from Kernel)".

    PROPOSED SOLUTION
    Use the standard notation for qualified names.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 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

show object flow or interactions

  • Key: UML22-35
  • Legacy Issue Number: 7166
  • Status: closed  
  • Source: Boeing ( David Hickerson)
  • Summary:

    There needs to be a way to show object flow or interactions between multiply concurrent threads or processes in Activity Diagrams. Example: In TCP sockets, the interaction between a client and server should be able to be shown with two separate start points, one for the client and one for the server. The connection sequence and packet flow should be able to be shown. With a single start point, the diagrams imply that one action starts both processes. I would like to illustrate multiple concurrent threads or processes and their interactions in an Activity Diagram and be able to distinguish between the flowing threads. I would also like to show access to objects shared by the threads or processes.

  • Reported: UML 1.5 — Fri, 19 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This issue has already been discussed in previous F/RTFs and considered out of scope:
    FTF: Activity diagrams only show task dependency, which can be achieved by multiple implemented processes. An activity can have more than one initial node. These are all started when the activity is. The initial nodes can be used in separate partitions to indicate which actions are taken on the client and server. If the two processes are completely independent, then this is a request is for a hybrid diagram, especially when trying to show shared objects. This is too much for an FTF to address.
    RTF: Hybrid diagrams are too complicated a topic for an RTF to address. There are many combinations and not enough experience to choose among them.
    Revised Text:
    None
    Disposition: Closed Out of Scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/Need constraints that cover multiple Lifelines

  • Key: UML22-34
  • Legacy Issue Number: 7161
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Consider an Interaction that describes collaboration of several parts of a classifier that owns some attributes.
    None of the parts own this attribute. I need to be able to describe a constraint, involving these attributes.

    Or when the overall classifier has a State Machine describing its overall behavior, and we want to refer to these states in an Interaction.

    In order to achieve this, it would be desirable to use:
    1. A guard that covers more than one lifeline (represents a guard involving the attributes, "global" to the set of Lifelines)
    2. A state symbol that covers more than one lifeline (represents a state invariant refering to the state of some state machine "global" to the set of Lifelines)
    3. A state invariant covering more than one lifeline (represents an invariant involving the attributes, "global" to the set of Lifelines)

  • Reported: UML 1.5 — Mon, 15 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion:
    Although this is a reasonable feature to request, it is an enhancement that exceeds the scope of the RTF. One of the main issues with it is that the semantics of defining such constraints in a distributed environment are not simple and require some serious consideration. The issue here is that Interactions consider all lifelines as potentially concurrent, and the restrictions on guards reflect this to prevent specifying distributed decisions that would imply implicit synchronization. The fact is, however, that many systems are such that it is known that the lifelines are not concurrent and checking remotely or on enclosing objects is not really hazardous. The problem is that we do not have a good way to define this in the specification. This is of course not dependent upon Interactions, but is a feature of all of UML. There seems to be a need to define object groups that share the same "thread" and are only pseudo-concurrent. If we had had such a construct, the guard could cover any subset of such a "same-thread-set-of-objects".
    Disposition: Closed Out Of Scope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ptc-03-09-15/Separate classification and generalization in Core::Basic

  • Key: UML22-24
  • Legacy Issue Number: 6495
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: One of the main requirements for a core that can be reused by CWM
    hinges on whether it is possible to reuse the abstract syntax that supports
    classification and supports having properties (or features), without pulling
    in generalization constructs. U2P’s Core::Basic package, upon which EMOF is
    based, does not appear to adequately separate these concerns.

    The most abstract level of Core::Basic's inheritance hierarchy at which the
    ability to have properties appears is in the Class metaclass. But Class
    also carries the “baggage” of a definition of superclass.

    The Core::Abstractions package does appear to adequately separate these
    concerns. It does so by defining a simple Classifier in the
    Core::Abstractions::Classifiers package that supports features but not
    generalization. The Core::Abstractions::Super package defines another
    Classifier metaclass that subclasses
    Core::Abstractions::Classifiers::Classifier and adds support for
    generalization.

    Presumably, then, the intent is that CWM metamodels that support
    classification and properties but not generalization can reuse
    Core::Abstractions::Classifiers::Classifier. However, Core::Basic does not
    reuse either of these basic definitions of Classifier from
    Core::Abstractions, and EMOF is based on Core::Basic. Thus, if a CWM
    metamodel reuses Core::Abstractions::Classifiers::Classifier, it will not
    share a common definition of Classifier with EMOF. That could mean that a
    metamodel expressed solely via EMOF will not be able to be the source or
    target in a unified approach to transformations. This is not a problem for
    CMOF, though, because CMOF is based on Core::Constructs, whose Classifiers
    are based on Core::Abstractions.

    Recommendation: Solving the problem for EMOF would require some refactoring
    of Core::Basic to separate concerns between classification and
    generalization.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 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

Ports in Protocol State Machines

  • Key: UML22-23
  • Legacy Issue Number: 6489
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Protocol machines should not have ports in them. It should be an
    extension in the ports package. Otherwise there is a backwards
    dependency onto composite structure.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    Statemachines already depend on ports via triggers, so the proposed change will not remove the dependency.
    Furthermore, creating a dependency from composite structures to statemachines would create a more serious
    layering problem. Therefore, resolving this dependency requires a non-trivial restructuring that shall be done
    by an RTF at this point.
    UML 2.5 has a different modular structure than UML 2.4 and earlier versions, with a single-level “flat”
    structure in which inter-module dependency concerns, which are at the core of this issue, are no longer
    relevant.
    Disposition: Closed - No Change

  • 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

UML2 Super/Kernel Classes

  • Key: UML22-27
  • Legacy Issue Number: 6681
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    section 7.11 Does Property.aggregation have meaning for properties typed by
    value types, (Data Type and subtypes)?

  • Reported: UML 1.5 — Mon, 8 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The spec now says under the semantics of Property “The semantics of composite aggregation when the
    container or part is typed by a DataType are intentionally not specified.”
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Superstructure FTF : isRoot property disappeared

  • Key: UML22-26
  • Legacy Issue Number: 6616
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The property isRoot has disappeared from Classifier. INtention was to move it to RedefinableElement but it seems to have dropped through the cracks.

    On page 399 FAS: section 13.3.4

    The metaattributes isLeaf and isRoot have been replaced by properties inherited from RedefinableElement.

    On page 86 FAS section 7.8.3 RedefinableElement:

    isLeaf: Boolean Indicates whether it is possible to further specialize a RedefinableElement. If the value is
    true, then it is not possible to further specialize the RedefinableElement. Default value is
    false.

    But no mention of isRoot....

  • Reported: UML 1.5 — Fri, 14 Nov 2003 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

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

Part subtype

  • Key: UML22-29
  • Legacy Issue Number: 6866
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Would be useful to be able to assign a subtype for objects that fill a
    part, to add additional characteristics. For example, a person fills
    the Employee part of a company, and is reclassified under a subtype of
    person that has an office. It is not sufficient to use the subtype as
    the type of the part, because the model wouldn't record what objects are
    allowed to fill the parts. The object is reclassified under the subtype
    after filling the part.

  • Reported: UML 1.5 — Wed, 5 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The issue suggests a new feature of UML. This is strategic and outside the scope of the RTF.

    Revised Text:
    None.

    Disposition: Closed, out of scope

  • 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

Federated models - UML2 issue

  • Key: UML22-25
  • Legacy Issue Number: 6500
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    When creating a complete environment for agreements and BCF we need
    to
    work with ModelElements, classes, package, models etc created and
    managed by many unrelated person and organisations. This means that
    we
    need to support loosely coupled models (federated models) where an
    association starts in one model (stored in doc A) and ends in another
    model (stored in document B).

    This may mean that we need to add references to an external
    modelelement
    so the assoication that references "out" to external ME need to be
    annotated with for example UUID of remote modelelement, name of model
    where the remote/external model , physicial location of remote model
    (URL) etc.
    We may also want to attach constraints to the remote modelement that
    restricts "incomming" associations.

    The question is how are loosely coupled model handled in UML 2 ?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    closed no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 Kernel Operations Diagram and Features Diagram and mdl

  • Key: UML22-28
  • Legacy Issue Number: 6700
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    The operations diagram redefines the formalParameter Property and removes the

    {ordered subsets parameter subsets ownedMember}

    .

    The mdl file has an added associtation between Operation: ownedparameter and Parameter:operation that isn’t defined in the spec.

    I believe the intent was to specialize the property Parameter:operation but I do not find the Operation:formalParameter Parameter:operation association required at all and would recommend its removal.

    This would require the ownerformalParam be made navigable. But I feel that this change is already required to sync the OCL and Superstructure specs.

    An alternative would be to add a unidirectional derived Property to the Parameter Class named operation and the derivation simply being operation=ownerFormalParam

  • Reported: UML 1.5 — Tue, 16 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No longer applicable closed no chnage

  • 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

Events in Sequence diagram

  • Key: UML22-114
  • Legacy Issue Number: 8760
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    MessageEnd are MessageOccurrenceSpecification that redefines "event"
    > as MessageEvent.
    > DestructionEvent and CreationEvent are not subclasses of
    > MessageEvent, so can't be on message end, so how to map "create
    > message" and "destroy message"?

    This is an open item. The one thing that was highly contested in the FTF was that there be explicit create and destroy messages. So, they are no longer in MessageKind.

    > Also unclear how to map Reply
    > message, what kind of events should be in reply message ends?

    You should check with Oystein.

    > Events are owned by package, it's very uncomfortable (at least two
    > nesting levels from Interaction), it think they should be owned by
    > Interaction.

    No, because the whole idea of events is that they have to be shared by the sender's and reciever's behaviors. It makes little sense to define them in an Interaction.

  • Reported: UML 1.4.2 — Tue, 3 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    See issue 14629 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

1. Deployment

  • Key: UML22-113
  • Legacy Issue Number: 8757
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    1. Deployment
    > What is client and what is supplier for this relationship?
    > Why DeploymentTARGET has word "target" in name but subsets "source"
    > for Dependency?

    The meaning of "client" and "supplier" in Dependency is pretty arbitrary and depends on one's point of view. I don't recall the reasoning behind this particular choice, but it may have to do with the direction of the arrow more than anything else. Guus probably wanted the arrow to go from the artifact to the node because it looked more natural to him. Perhaps Guus can explain – I've copied him on this reply.

    However, there is definitely a bug here since "client" and "supplier" are not derived unions, hence, they cannot be subset as shown in figure 126. This may have already been raised as an issue. I'll have to check. I suggest that you raise a formal issue in any case.

    > And why notation examples are from Artifact to Node (arrow near
    > Node, but Node is "client" in model).

    Ostensibly, this is explained by what I wrote above. However, there seems to be a deeper problem here: note that Dependency::supplier and Dependency::client are not specializations of DirectedRelationship::target and DirectedRelationship::source respectively, as I would have expected (otherwise it does not seem to make sense to subclass DirectedRelationship at all). I do not understand why this is so, it does not seem to make sense. It may have to do with the constraints that Dependency did not want to impose on supplier and client, but I am not sure. This needs further study and, likely, an issue to be raised.

    > "Location" attribute of Deployment should be DeploymentTarget, not Node.

    You are correct. Please raise an official issue on this through issues@omg.org

  • Reported: UML 1.4.2 — Tue, 3 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Questions about the appropriateness of the use of Dependency and the directionality of theway its ends are connected
    are covered by other issues, such as 10781. In any case, such changes require modifications to the metamodel and are
    thereby out of scope for the UML 2.5 FTF.
    There no requirement that client and supplier must be, or must subset, derived unions. In Clause 19.5, the location
    attribute of Deployment is clearly identified as type DeploymentTarget.
    Disposition: Merged with 10781

  • 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

Nested Nodes

  • Key: UML22-115
  • Legacy Issue Number: 8763
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Node has nestedNodes collection that redefines "nestedClassifier",
    > but Node have Generalizations to Class from StructuredClasses that
    > has no Generalization to Class from Core package, so Nodes don't
    > inherits "nestedClassifier".

  • Reported: UML 1.4.2 — Tue, 3 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

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

Return message

  • Key: UML22-120
  • Legacy Issue Number: 8785
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    How return message should be mapped into model? What kind of events are on message ends, how return values should be mapped? Should return values be arguments of message? How return message can be recognized in the model?
    How variable assignment should be mapped and related with message?

  • Reported: UML 1.4.2 — Wed, 18 May 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    There has never been anything called a "return message", but the issue is probably about "reply message" which we had forgotten to give a messageSort, but that has been fixed. The other issues are related, but are also asking for clarification of metamodel encoding. This should eventually be picked up again if necessary during a major revision.
    Disposition: ClosedOutOfScope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

multiplicity should not be used/shown in an communicates association

  • Key: UML22-121
  • Legacy Issue Number: 8854
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Figure 404 - Example of the use cases and actors for an ATM system
    (The ATM example is repeated in Figure 410.)

    If you think multiplicity gives value to this diagram, please add additional text and explain the usage of multiplicity (1, 0..1, 0..*) in this diagram.

  • Reported: UML 1.4.2 — Fri, 3 Jun 2005 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Merged with 18072

  • 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

inconsistent description

  • Key: UML22-73
  • Legacy Issue Number: 8332
  • Status: closed  
  • Source: none ( Rui Xu)
  • Summary:

    There is an inconsistent description about determining conflicting transitions of a internal transition. According to sector Conflicting transitions, p.492: "Two transitions are said to conflict if they both exit the same state", two internal transitions in the same configration won't be conflict, However, P.492 says "Each orthogonal region in the active state configuration that is not decomposed into orthogonal regions can fire at most one transition as a result of the current event" There are two possible explanation: 1.Internal transition is treated orthogonal to the container region: thus, any two internal transitions in different state won't be confilict. 2.Internal transition is treated as self-transition without entry/exit action: thus, internal transition will be conflict with transitions which are conflict with corresponding self-transition. And a orthogonal region fires at most one transition(either internal or non-internal) an example: A and B are two states of top state. A is superState of AA AA is superState of AAA and AAB t1 is an internal transition of A t2 is an internal transition of AA t3 is an external transition from AAA to AAB t4 is an external transition from AA to B does t1 and t2 conflict? t2 and t3? which should be chosen for firing?

  • Reported: UML 1.4.2 — Thu, 24 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    An internal transition IS a self-transition. It does not exit or enter the state to which it is attached. Internal transitions
    belong to states and not to regions, as seemed to be implied by the issue summary. This is explicitly stated in the
    specification. From the point of view of firing rules, they are no different than for any other transition. If there are
    conflicts (and, there CAN be conflicts between two internal transitions), they are resolved the same way as all other
    conflicts based on the firing rules for such cases. Hence, the ambiguity discussed in the summary of the issue does not
    exist.
    (However, after reading the text, it seems that there is no explicit statement on how the issue of conflicting transitions
    of the same priority is resolved. Presumably, this is one of those “intentionally left unspecified” cases; i.e., it is an
    implementation choice. But, this is a different and more general issue that needs to be dealt with separately.)
    Disposition: Closed - No Change

  • 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

UML 2 Super / Kernel / invalid restriction in isConsistentWith()

  • Key: UML22-80
  • Legacy Issue Number: 8460
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    A derived union association end represents a union of all of its subsets. The leaf subsets clearly have to be non-derived. However, in operation Property::isConsistentWith(), defined on page 127 of ptc/-04-10-02, it is stated that a derived property cannot be redefined by a non-derived property. This means that all such subsets of derived unions will be incorrect. Clearly, this restriction should be removed.

    Recommendation:

    Remove the constraint:

    (prop.isDerived implies isDerived)

    from the operation Property::isConsistentWith() (on pg. 127)

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

namespace

  • Key: UML22-67
  • Legacy Issue Number: 8246
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The namespace is xmlns:Model="omg.org.mof.Model" Surely it should be xmlns:Model="org.omg.mof.Model" " The official/latest version of this file: omg.org/models/MOF1.4/XMI1.1/Model1.4/Model.xml" does not exist on the OMG web site.

  • Reported: UML 1.4.2 — Sat, 5 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

Figure 89 on page 158 is incorrect

  • Key: UML22-66
  • Legacy Issue Number: 8168
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ptc/04-10-02: Figure 89 on page 158 is incorrect: the delegation connector on the left seems to be pointing the wrong way.

    More generally, it is not clear why an arrow is required on delegation connectors, since they are automatically implied when a port is connected to a part or a port on a part. The arrow can be misleading since some may interpret incorrectly it as a restriction on the direction of data flow. Note that the table 5 on page 166 does not show the arrow notation nor does table 7.

    Finally, the title of table 5 should say: "graphic paths" instead of "graphic nodes"

  • Reported: UML 1.4.2 — Fri, 28 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The first part refers to figure 8.12. The "more generally" part applies to figure 8.16 and the associated text.
    Delegation connectors do not need any special notation other than that defined for connectors in general in table 9.2.
    The third aspect of this issue is a duplicate of 12236, already resolved.

  • 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

UML2/Infra section 11.6.2/ Enumerations should not have attributes

  • Key: UML22-70
  • Legacy Issue Number: 8274
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    11.6.2 of Infra and 7.3.16 of Super refer to the possibility of Enumerations having attributes: "A compartment listing the attributes for the enumeration is placed
    below the name compartment." This concept does not make sense to me: an enumeration inherently represents a single value-set modeled through owned EnumerationLiterals.
    The only type of attribute that might ever make sense is a derived attribute (e.g. Color.isPrimary).

    Proposed resolution:
    Add constraint to above sections on Enumeration to state that only attributes permitted are derived ones. Also that any Operation must have isQuery=true.

  • Reported: UML 1.4.2 — Mon, 14 Feb 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Enumeration literals are immutable, so writeable attributes do not make sense. But read-only attributes do
    make sense: they don’t need to be derived. The current description of equality of EnumerationLiterals needs
    improvement. Operations on enumerations are allowed.
    This also resolves 17933

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Default values for ValueSpecification are not specified properly

  • Key: UML22-79
  • Legacy Issue Number: 8450
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There are a few cases when the default is documented as a ValueExpression, as follows:

    • JoinNode.joinSpec = {default value is" and"}
    • ActivityEdge.guard= {default value is "true"}

    These defaults are currently just plain text in the Rose Model displayed under the ValueSpecification as shown in figure 185 in the superstructure specification.

    They should be included formally in the model. However it is not clear that the UML2 notation text allows defaults for association ends, and that those defaults can include expressions that construct instances of classes such as ValueSpecification. For example, the notation for ActivityEdge::guard in figure 185 could be:

    +guard = LiteralBoolean(true)

    The default value for guard is set to a newly constructed LiteralBoolean (a ValueSpecification) with value true.

    Recommendation:

    Ensure the text notation for default values includes the ability to construct InstanceSpecifications, and that the notation supports defaults for properties on association ends.

  • Reported: UML 1.4.2 — Fri, 4 Mar 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • 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

isComposite inconsistency in UML 2.0 and MOF 2.0

  • Key: UML22-46
  • Legacy Issue Number: 7910
  • Status: closed  
  • Source: N/A ( Rob Grainger)
  • Summary:

    The usage of isComposite varies in these two specs as detailed below. Hope this proves useful. Rob ------- UML 2.0 ------- The UML 2.0 Infrastructure spec (03-09-15) section 10.2.4 defines Basic::Property::isComposite as follows: – isComposite : Boolean If isComposite is true, the object containing the attribute is a container for the object or value contained in the attribute. The default value is false. i.e. an attribute marked "isComposite" is the container for the value. – However, Constructs::Property (which inherits Basic::Property) has the following constraint: [3] A multiplicity of a composite aggregation must not have an upper bound greater than 1. isComposite implies (upperBound()>isEmpty() or upperBound() <= 1) This is surely intended to mean that an object can have [0..1] containers, rather than (as defined by the two definitions above) that a container can store [0..1] instances in each composite property. The difficulty seems to be one of terminology - from the perspective of a property, being composite implies the property is composite, ie. contains zero or more objects, while from the perspective of an object, the composite of an object could be viewed as a container. The problem can be fixed by redefining the constraint something like: [3] If a property has isComposite==true, than if the property has an opposite, that opposite property must have an upper bound greater than 1. isComposite implies (opposite == null) or (opposite.upperBound()>isEmpty() or opposite.upperBound() <= 1). In 11.3.1 - Association, "Composition is represented by the isComposite attribute on the part end of the association being set to true." - again this is the opposite sense. This is also indicates that there is a degree of complexity implementing MOF::Reflection::Object::container() - there is actually no property for which this is a simple test. Instead, it is necessary to find a property of the object such that the opposite property is marked isComposite, there is no guarantee such a property is accessible, hence an implementation must, in some cases, store a separate (hidden) reference to the object's container. This is an implementation property however. The other alternative I can see would be to replace isComposite on the container object with isContainer on the contained object, or even to have both (with an appropriate constraint to guarantee that the two properties are consistent). --------- MOF 2.0 --------- The same problem manifests in the definition of CMOF abstract semantics. In section 15.2, ClassInstance includes the following definition: 2. At most one Slot for an isComposite property may have a value. (this needs more work if the owner reference is not navigable) Using the current definition of isComposite, this needs to be restated to the effect that at most one slot for a property that is the opposite of an isComposite property may have a value. And again, in the specification of DataType... For all properties, isReadOnly is true, isComposite is false, isDerivedUnion is false Surely this is not correct - a data type may contain other datatypes, which by definition are stored by value, implying strong ownership, and hence a composition relationship. Indeed, any classifier containing a property whose value is a data type should always have isComposite set to true. In 15.4, Object::delete() seems to use isComposite correctly given the definition. Later, however, Object::owningProperty() uses the other approach - using isComposite() to identify the container of the current object.

  • Reported: UML 1.4.2 — Mon, 15 Nov 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.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

should retain Comment and its associations to Element

  • Key: UML22-47
  • Legacy Issue Number: 7958
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    The resolution to Issue 7782 (Move Comment from Constructs to Basic) removed Comment from Constructs. For consistency with the rest of Constructs (which included everything else reused from Basic), the resolution should not have removed Comment from Constructs, it should have just copied Comment into Basic.

  • Reported: UML 1.4.2 — Wed, 1 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is resolved in the UML 2.2 specification.
    Revised Text:
    None.
    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

completion transitions

  • Key: UML22-41
  • Legacy Issue Number: 7254
  • Status: closed  
  • Source: ISTI-CNR ( Franco Mazzanti)
  • Summary:

    Suppose that we have two composite states, nested within to two concurrent regions, which both become "complete" as part of the same "run-to-completion" step, and each of the composite states is the source for a completion transition. I.e. within this "run-to-completion" step two completion events are generated. How should these two completion events be dispatched? - Sequentially, in the same sequential order in which they have been generated. - Sequentially, but any ordering is allowed, - Concurrently. I.e. both completion transitions are considered enabled. - other ??? or any of the above Notice that completion transition may have guards, and activity, hence the firing of one of them may cause the other to become no more "enabled". Hence the above three cases may really cause different system behaviors.

  • Reported: UML 1.5 — Wed, 21 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Add a clarification for this case based on the above discussion

  • 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

Use case extension inconsistencies

  • Key: UML22-49
  • Legacy Issue Number: 7993
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    According to Figure 401, an Extend object references at least one ExtensionPoint which itself must be owned by exactly one UseCase.
    Therefore it seems that the Extend.extendedCase property is redundant and should be derived.

    Also the section for ExtensionPoint does not include the useCase property shown in Figure 401, which itself does not show the

    {subset}

    .

    Proposed resolution
    -----------------------------

    1) Update Figure 401 to replace +extendedCase by +/extendedCase

    2) Update Figure 401 to replace +useCase by +useCase

    {subsets owner}

    .

    3) Section 16.3.3 Extend: update the Associations section to replace:
    extendedCase : UseCase [1] References the use case that is being extended. (Specializes DirectedRelationship.target.)

    by

    /extendedCase : UseCase [1] References the use case that is being extended: this is derived as the Use case that owns the ExtensionPoint(s). (Specializes DirectedRelationship.target.) in OCL: extendedCase = self.extensionLocation->useCase

    4) Section 16.3.4 ExtensionPoint update the Associations section to replace:
    No additional associations

    by

    useCase: UseCase [1] References the use case that owns the ExtensionPoint. (subsets owner.)

  • Reported: UML 1.4.2 — Mon, 20 Dec 2004 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AssociationClass

  • Key: UML22-45
  • Legacy Issue Number: 7400
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    The text says that a non-navigable end of an association class is an attribute of that association class. "When a property is owned by a class it represents an attribute." [7.11.4] "AssociationClass is both an Association and a Class." [7.16.1] "When a property is owned by an association it represents a non-navigable end of the association." [7.11.2] This is good, is as expected, and is consistent with both the object and the relational theories of modelling. It is said that the drawings tell a different story. If so, they should be corrected. There is no practical advantage to requiring that the non-navigable ends of an association class are not attributes of that class. On the contrary, such a requirement is unexpected and will be confusing.

  • Reported: UML 1.5 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The issue is obsolete. The text in 11.5.3 clearly states that the ownedEnds of an AssociationClass are not
    attributes.
    Disposition: Closed - No Change

  • 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

ClassifierInState not supported in UML2.0 ?

  • Key: UML22-54
  • Legacy Issue Number: 8071
  • Status: closed  
  • Source: GOO Tech ( Birol Berkem)
  • Summary:

    In the UML 1.x, we have the notion of ClassifierInState. We used them for representing associations and methods of classes that are valid when instances of these classes are in the corresponding states.

    Could you let me know how to do that using UML 2 ? If class-in-states are not supported in UML 2.0, I am afraid, we cannot represent these valuable information particularly for reifying business processes. For example Order[Delivery] , Order[Billing], etc.. with their operations and session attributes !

  • Reported: UML 1.4.2 — Tue, 4 Jan 2005 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    This is really a question of clarification of a misunderstanding of the submitter. The equivalent of ClassifierInState for activity modeling is supported in UML 2 by the ObjectNode inState association. UML 1 also allowed ClassifierInState to be used in instance and collaboration modeling. While there is no direct equivalent for this in UML 2, the same effect can be achieved by using an OCL constraint on an instance.

  • 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

Association specialization semantics

  • Key: UML22-53
  • Legacy Issue Number: 8023
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Association specialization semantics The semantics of Association addresses specialization. Some of this paragraph is applicable to Generalization and should be moved there. The discussion specific to association could be clearer, for example, what does "correlates positively" mean?

  • Reported: UML 1.4.2 — 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

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

Reentrancy 1

  • Key: UML22-7
  • Legacy Issue Number: 6111
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    How is the effect if isReentrant achieved for actions other than call
    actions? isReentrant is only on behaviors. Perhaps it should also be
    available on actions and operations

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    The current semantics of isReentrant on behaviors leads to unexpected global mutual exclusion of invocation of a behavior if isReentrant=false, the default (see Issue 9873). However, at the level of the invocation of a behavior in an activity, it is often the case that one execution of such an invocation action should complete before a second can begin (for example, if the activity is modeling a business process with the invoked behavior assigned to a single person, or a manufacturing process with the behavior carried out by a single piece of equipment). Thus, it is reasonable to have "local" non-reentrancy as the default.
    In this case, however, it makes as much sense to allow the specification of reentrancy or non-reentrancy on any action, not just on the invocation of a behavior, as requested by the issue submitter. This also allows locally non-reentrant semantics, without the unexpected consequences of global non-reentrancy.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Suspension Region

  • Key: UML22-6
  • Legacy Issue Number: 6082
  • Status: closed  
  • Source: Ostfold University College ( Dr. Oystein Haugen)
  • Summary:

    “Supspension region” is a concept from MSC-2000 that occurred in earlier drafts of UML 2.0. It was removed since the metamodel had not been properly updated. A suspension region is an area of a lifeline where no events should occur since the lifeline is waiting for reply from an operation call.

    This has been flagged as a potential FTF issue before.

  • Reported: UML 1.5 — Fri, 29 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion:
    This is a concept that highlights a syntactic requirement. Often users think that suspension is always the case between call and reply, but since lifelines may be decomposed into independent sub-parts, this is not necessarily the case. That is why it is useful to clarify a synchronization situation. Still it is a new concept, and cannot be considered critical for the use of Interactions. Let us bring this up again at a larger revision.
    Disposition: ClosedOutOfScope

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Missing OCL constraints

  • Key: UML22-18
  • Legacy Issue Number: 6452
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the final adopted spec, there are numerous constraints associated with the various metaclasses that do not have corresponding OCL written. This should be fixed.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 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

03-04-01 Chap 2 p. 112/Components: Different ways to wire components

  • Key: UML22-17
  • Legacy Issue Number: 6433
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re Chapter 2, Components, Figure 2-15, p. 112: The text of the fifth
    paragraph says: “A component has a number of provided and required
    Interfaces, that form the basis for wiring components together, either using
    Dependencies, or by using Connectors.” Is this really an either or choice?
    What is the real semantic distinction? And what is the semantic distinction
    between wiring via connectors without ports vs. wiring via connectors with
    ports?

    Recommendation: Clearly specify the semantic distinctions among the three
    ways of wiring components together:

    1) Via Dependencies
    2) Via Connectors without Ports
    3) Via Connectors with Ports.

    If there are no semantic distinctions--that is, if the distinctions are
    purely mechanical--then the specification should probably changed such that
    there is one way to wire components together.

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Dependencies are used for wiring components at the type level, and indicate some policies about how components might be wired. Connectors are used for wiring component internals and show how parts and ports are actually wired.
    We will not resolve the issue about distinguishing between the presence and absence of ports: this is fundamental to composite structures and too big a change for the RTF.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Issue: AssociationEnd

  • Key: UML22-20
  • Legacy Issue Number: 6462
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    In UML 1 the navigability of an association end was specified by the
    meta-attribute AssociationEnd.isNavigable. In UML 2 apparently this
    meta-attribute dissapears, and AssociationEnd is substituted by Property. We
    know whether an association end is navigable by the following rule: if the
    property is owned by a class, it represents a navigable end; if the property
    is owned by an association, it represents a non-navigable end (see
    Superstructure, p. 89). However, references to old metaclass AssociationEnd
    and old meta-attribute isNavigable still appear in the Spec in several
    places and OCL expressions (AssociationEnd appears in: Infrastructure, p.
    33; Superstructure, pp. 119, 245; isNavigable appears in: Superstructure, p.
    245).

    PROPOSED SOLUTION
    Add derived meta-attribute /isNavigable to metaclass Property.
    Eliminate references to AssociationEnd.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 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

instantiations of Classifiers

  • Key: UML22-19
  • Legacy Issue Number: 6455
  • Status: closed  
  • Source: Anonymous
  • Summary:

    7 and 14: "An instance specification is a model element that represents an instance in a modeled system." [7.7.1] There are no objects in a UML 2 model, but only models of objects, that is, instance specifications. The instantiation of a UML class is not in the model, but in the modeled system. At the same time, "an ExecutionOccurrence is an instantiation of a unit of behavior ..." [14.3.4] Suggested resolution: Abandon the idea that there are no objects in a model. Specify that an instanceSpecification with a class is an object in the model, the instiantiation of a class is an object in the model. Likewise for an association and its links, and so on.

    This brings the theory of classifiers and their instances and instantiations into alignment with the theory of behaviors and their occurrences.

    It is consistent with the existence of power types in the language.

    It is consistent with the MOF specification of meta-layers.

    It removes the conflation of the type conformance and instatiation relationships with the representation relationship. It reduces the meanings conflated into 'instance of' by one.

    Thus, the UML places instantiations of Classifiers in the modeled system (not in the UML model) and, at the same time, places instantiations of Behaviors in the UML model (not in the modeled system).

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The change proposed in the issue is fundamentally different than the basic interpretation of models in UML.
    Further, the assertion that UML “places instantiations of Behaviors in the UML model (not in the modeled
    system)” is not correct. An instance of a Behavior is an execution (in the modeled system), while an
    ExecutionOccurrence is a model of such an instance. This is quite similar to the difference between an
    instance and an InstanceSpecification. The UML 2.5 specification is now clearer on this.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 9.3.3

  • Key: UML22-15
  • Legacy Issue Number: 6422
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    The Collaboration example on page 159 appears to be a CollaborationOccurrence rather than a Collaboration. I recommend that the Collaboration example be revised to a description of the Observer pattern (or some other collaboration) and the example be continued in the CollaborationOccurrence section. In addition to fixing the example, I believe it is important to make the Collaboration and CollaborationOccurrence examples cohesive

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Original discussion:
    The submitter is incorrect in believing that the example (Figures 104 and 105) represent a collaboration occurrence. They are indeed collaborations. However, the submitter makes a good point on having a single example between the collaboration and the collaboration occurrence section. To this effect, it would be possible to update this example by replacing Figures 104 and 105 by an updated version of the example in Figure 107 (albeit one would have to add types to the parts in that example) and make it a little more interesting. The current example in Figures 104 and 105 was adapted from UML 1.4.
    New comments (March 2009):
    This issue dates back to 2003. I propose we close it on the grounds of cost/benefit.

    Revised Text:
    None.

    Disposition: Closed, no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/missing OCL constraints

  • Key: UML22-14
  • Legacy Issue Number: 6409
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Not all the constraints in the Interactions section (14.3). They should be added

  • Reported: UML 1.5 — Mon, 3 Nov 2003 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 Super/Metamodel/redefinition and substitutability

  • Key: UML22-10
  • Legacy Issue Number: 6200
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Redefinition, as used in UML2, sometimes violates superclass substituitability rules. For example, redefining multiplicity from many to 1 breaks some OCL constraints. For example, Statemachines changed a multiplicity from many to 1. Statemachines redefines association to OwnedBehaviors to OwnedStateMachines which does not allow other types of owned behaviors.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    The specific issue with state machines no longer applies, having been resolved in an earlier RTF. The general
    issue about redefinition is a complaint about a fundamental characteristic of UML semantics which are by
    now quite well understood. Changing these semantics would be very fundamental and disruptive.
    This also resolves issue 14929.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Target pin notation

  • Key: UML22-9
  • Legacy Issue Number: 6126
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    On CallOperationAction, etc, how do you tell graphically which pin is
    the target?

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disposition: Deferred to UML 2.4 RTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notes versus curly braces

  • Key: UML22-12
  • Legacy Issue Number: 6372
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Why do decision input behaviors use the note notation and join
    specification use curly braces?

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    A decision input behavior is a behavior, and it could potentially involve a lengthy computation. A join specification is a value specification and will typically be very short, perhaps even just a single operator (the default is "and").
    Revised Text:
    None
    Disposition: Closed, no Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity OCL

  • Key: UML22-11
  • Legacy Issue Number: 6346
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Not all the constraints in the Activities section have corresponding OCL
    specifications. These should be added

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Discussion
    This issue is obsolete. All constraints related to Activities that can be given OCL now have OCL in UML
    2.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 super/ad-03-04-01/Derived attributes and associations

  • Key: UML22-16
  • Legacy Issue Number: 6430
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: There are many places where the specification indicates that an
    attribute or association is derived, but does not state how it is derived;
    that is, the specification does not state, in English or in OCL, how to
    compute the derivation.

    Recommendation: Specify, in English and OCL, how to compute the derivations
    of all derived attributes and associations.

  • Reported: UML 1.5 — Tue, 4 Nov 2003 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 super / Dependencies / improper subsetting?

  • Key: UML22-13
  • Legacy Issue Number: 6405
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Should Dependency::supplier subset DirectedRelationship::target and Dependency::client subset DirectedRelationship::source? Otherwise, the source and target properties of specializations that add no additional properties (e.g. Usage) will be empty...

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

State extension

  • Key: UML22-8
  • Legacy Issue Number: 6114
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    State should be an extension of type rather than object node.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Disposition: Deferred to UML 2.4 RTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 issue, Common Behaviors

  • Key: UML14-559
  • Legacy Issue Number: 7380
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Behaviors: objects that don't exist?

    At 13.1 we read:

    "Behaviors, as such, do not exist on their own, and they do not communicate. ... (Note that an executing behavior may itself be an object, however.)"

    It is not clear what this is intended to mean. To the untutored reader it seems to be a contradiction.

    What a behavior is and what a behavior execution is is fundamental to this half of UML. Whatever is intended should be spelled out clearly for the reader, very clearly.

  • Reported: RAS 2.0b1 — Wed, 26 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Components / provided and required interfaces -- derived or subsets

  • Key: UML14-558
  • Legacy Issue Number: 6875
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Should Component::provided and Component::required really be derived? It seems that these sets of interfaces should be subsets of the sets of interfaces implemented/used by the component and/or its realizing classifiers, not derived from them

  • Reported: XMI 2.0 — Fri, 2 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Feature;ModelElement

  • Key: UML14-557
  • Legacy Issue Number: 5922
  • Status: closed  
  • Source: HTL Villach ( Lassnig Gernot)
  • Summary:

    Why there are two different Backbone Diagrams in the UML 1.5 Specification. The one on Page 71 shows that a Feature has a visibility and a ModelElement has just a name, nothing more. On Page 596 an Feature has the visibility not anymore, but ModelElement has one, how this should be interpreted, which one is the right visibility

  • Reported: UML 1.5 — Tue, 29 Apr 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"Physical" Metamodel Package Structure (uml-rtf)

  • Key: UML14-554
  • Legacy Issue Number: 3123
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The package structure of UML 1.3 makes it difficult to deploy small parts of
    the "physical" metamodel separately. For example, a MOF-based facility that
    supports classes from Behavioral_Elements.Common_Behavior must support all
    of Behavioral_Elements. A facility that supports Exceptions must also
    support Use Cases and State Machines. This has been a problem in the
    formation of the CWM metamodel which extends UML. Its interfaces and DTDs
    are made to be much too large.

    The result of UML currently having three metamodels (two of which are large)
    rather than many smaller metamodels is that the IDL modules are very large
    and so are the DTDs. Breaking the metamodels into several smaller ones will
    allow smaller interface sets and DTDs that can be mixed and matched to
    provide necessary functionality without a huge overhead.

  • Reported: XMI 1.1 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TaggedValue in TaggedValue

  • Key: UML14-556
  • Legacy Issue Number: 4726
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 metamodel, a ModelElement can contain any number of
    taggedValues, of type TaggedValue [UML 1-4, pp. 2-76].

    However, because a TaggedValue itself is a ModelElement [UML 1-4, pp. 2-76],
    it can itself contain taggedValues.

    The question is: is this really intended? And if so: please explain the
    semantics of such a construction.

    If not, at simple well-formedness rule

    self.taggedValue = { }

    attached to TaggedValue would do the trick.

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguous semantics of classifier ownerscope

  • Key: UML14-555
  • Legacy Issue Number: 4446
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of classifier ownerscope is ambiguous for structural
    features declared on classifiers that have children. It is not
    defined whether this gives value for the classifier and all its
    descendents, or values for the classifier and each descendant
    separately.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 super/notation/Keywords

  • Key: UML14-471
  • Legacy Issue Number: 6877
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This is a general issue that is quite pervasive. I think it is important
    enough to be considered by the FTF.

    The specification is littered with keywords which are used on diagrams
    to indicate various things.

    What the specification sorely needs is an Appendix that gathers them all
    together. And cross-references each with where it is defined and the
    compliance level it is associated with.
    Also what it needs is a general description of the semantics of
    keywords, how they differ from 'Standard Stereotypes' and associated
    constraints - e.g. it should not be allowed to declare a Stereotype with
    a name which, when decapitalized, is the same as a keyword (since they'd
    be indistinguishable).

    Arguably keywords would be depicted with a distinct notation from
    stereotypes (based on language design principles and to help users
    interpret diagrams where they see words in guillemets and don't know
    whether to look it up in the list of keywords or stereotypes) but that
    is probably too major a change to make at this stage. However the
    notation should be clarified to cover the following cases:
    A) if the same element requires a keyword and has a stereotype applied
    are they shown in 2 separate <<xxx>> expressions or in one, separated by
    a comma?
    B) if a stereotype is applied to a class normally indicated by a
    keyword, does that keyword still need to be provided?

  • Reported: XMI 2.0 — Thu, 8 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Appendix B/Standard Stereotypes too heavyweight and incompletely defined

  • Key: UML14-470
  • Legacy Issue Number: 6876
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This is in my opinion important enough to be considered by the FTF since
    it affects implementability.

    Appendix B contains a list of Standard Stereotypes.
    Ironically, due to the nature of the UML2 Profile mechanism this
    mechanism is more heavyweight than a subclass since it requires a
    separate instance - so for the <<call>> stereotype of Usage one ends up
    with not only a instance of Usage but an attached instance of Call -
    this is far more heavyweight than having a distinct subclass of Usage
    which would result in only one object. And it's also harder to process
    via XMI or APIs.

    The Appendix is not adequate as a definition and does not use the
    official Stereotype notation? In particular it does not make clear the
    name of the instance of Stereotype (which I can only guess would be the
    capitalized form of the stereotype keyword e.g. "Call"), nor does it
    specify the name of the association used to attach an instance of the
    stereotype with the instance of the metaclass. And, of course, is there
    actually a Profile object (or objects) that contains these stereotypes?
    Can users consider this Profile already applied to any UML model or does
    it have to be explicitly done or is this a variation point?

    Finally, Appendix B is not properly referenced: 7.14.1 refers to the
    "Standard Profiles chapter" and 8.3.3 and 10.3.1 refer to "The UML
    Standard Profile".

  • Reported: XMI 2.0 — Thu, 8 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Interactions / incorrect multiplicity for PartDecomposition

  • Key: UML14-480
  • Legacy Issue Number: 6925
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The description of Lifeline on p. 427 (and Figure 331 on p. 409) indicates that the Lifeline::decomposedAs property is mandatory. This property refers, indirectly through a PartDecomposition, to an interaction the describes the internal workings of the ConnectableElement that the Lifeline represents.

    Unfortunately, there are common situations in which the decomposedAs property cannot be specified because the ConnectableElement is not decomposable (i.e., is not structured). In fact, the first constraint on p. 431 in the description of the PartDecomposition metaclass makes this very clear: "PartDecompositions apply only to Parts that are Parts of Internal Structures not to Parts of Collaborations."

    Therefore, we would request that the specification be amended to make the Lifeline::decomposedAs property optional (multiplicity [0..1]). If you can amend the generated multiplicity in your API in advance of any changes to the spec, that would be greatly appreciated!

  • Reported: XMI 2.0 — Sun, 18 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The contents of the Interfaces package is shown in Figure 51

  • Key: UML14-479
  • Legacy Issue Number: 6913
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    "The contents of the Interfaces package is shown in Figure 51. The Interfaces package is one of the packages of the Classes package. "

    Should be "Figure 58"

  • Reported: XMI 2.0 — Fri, 16 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Interactions / navigability of enclosingOperation

  • Key: UML14-482
  • Legacy Issue Number: 6928
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Should InteractionFragment::enclosingOperation be navigable? The association end is named and even has a subset constraint, but the association isn't navigable in that direction for some reason (see Figure 329).

  • Reported: XMI 2.0 — Sun, 25 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Dependencies / Abstraction should have an optional mapping

  • Key: UML14-481
  • Legacy Issue Number: 6926
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In section 7.14.1 (Abstraction) it is stated explicitly that the mapping associated with an abstraction is optional (as it should be, since we do not necessarily want to have a mapping attached to every kind of abstraction). However, the diagram in figure 51 has a multiplicty of 1 for the "mapping" role (at the Expression end). This should be changed to 0..1.

  • Reported: XMI 2.0 — Wed, 21 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Templates / subsetting templateParameter

  • Key: UML14-478
  • Legacy Issue Number: 6911
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ParameterableElement::owningParameter should subset ParameterableElement::templateParameter

  • Reported: XMI 2.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / Idenitfy sections specifying run-time semantics

  • Key: UML14-477
  • Legacy Issue Number: 6902
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The sections of the spec that describe the run-time semantics of UML are scattered throughout the document and not clearly identified. There should be at least some convenient guide in the document that would help locate those sections.

  • Reported: XMI 2.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Classes /

  • Key: UML14-476
  • Legacy Issue Number: 6901
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    on page 115 (section 7.15.3) when talking about the Notation of an
    interface, the third paragraph (between figure 59 and 60) says:
    "
    The usage dependency from a classifer to an interface is shown by
    representing the interface by a half-circle or socket, labeled
    with the name of the interface, attached by a solid line to the
    classifier that *implements* this interface (see Figure 60).
    "

    And I think it should say:
    "
    The usage dependency from a classifer to an interface is shown by
    representing the interface by a half-circle or socket, labeled
    with the name of the interface, attached by a solid line to the
    classifier that *requires* this interface (see Figure 60).
    "

  • Reported: XMI 2.0 — Wed, 14 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

importedMember property

  • Key: UML14-473
  • Legacy Issue Number: 6897
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    The importedMember property is derived from the ElementImports and the PackageImports.

    self.importedMember->includesAll(self.importedMembers(self.elementImport.importedElement.asSet()>union(self.packageImport.importedPackage>collect(p | >p.visibleMembers()))))

    The query importedMembers(...) should be importMembers(...). A fixed version is:

    self.importedMember->includesAll(self.importMembers(self.elementImport.importedElement.asSet()>union(self.packageImport.importedPackage>collect(p | >p.visibleMembers()))))

  • Reported: XMI 2.0 — Sat, 10 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Interactions / Two typos

  • Key: UML14-475
  • Legacy Issue Number: 6900
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    On page 408 there is text that says:

    Gates are just points on the frame, the ends of the messages. They may have an explicit name. See Figure 335.

    I think it should say:

    Gates are just points on the frame, the ends of the messages. They may have an explicit name. See Figure 336.

    On page 414 there is text that says

    See example of the usage of collaboration occurrences in Figure 345.

    I think it should say:

    See example of the usage of collaboration occurrences in Figure 339.

  • Reported: XMI 2.0 — Wed, 14 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

missing closing bracket

  • Key: UML14-474
  • Legacy Issue Number: 6898
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    There is a missing closing bracket in slot->forAll(s | classifier->exists(c | c.allFeatures()->includes(s.definingFeature) )

    The correct version is: slot->forAll(s | classifier->exists(c | c.allFeatures()->includes(s.definingFeature)) )

  • Reported: XMI 2.0 — Sat, 10 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"• value : InstanceSpecification

  • Key: UML14-472
  • Legacy Issue Number: 6896
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    "• value : InstanceSpecification [*] ~~~~~~~~~~~~~~~~~~~~~ <<<< should be ValueSpecification The value or values corresponding to the defining feature for the owning instance specification. This is an ordered association. Subsets Element::ownedElement

  • Reported: XMI 2.0 — Sat, 10 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Corrections and improvements to glossary definitions

  • Key: UML14-377
  • Legacy Issue Number: 6447
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Description: Consider the following corrections and improvements to Terms
    and Definitions:

    Activation ­ Consider changing from “the execution of an action” to
    “initiating the execution of an action”.

    Analysis ­ Delete the term “software”.

    Artifact ­ Delete the term “software”.

    Comment ­ Replace term “note” with “comment”.
    Runtime. run-time for a physical system, to imply execution of the
    operational system. (S-pg 252)

    Deployment diagram ­ Replace “software artifacts as nodes” with “artifacts
    on nodes”. Delete the term software and change as to on.

    Design ­ Delete the term “software”. Delete “required functional and
    quality”. This is too restrictive, and doesn't include physical
    requirements, etc.

    Design time - Delete the term “software”.

    Development process - Delete the term “software”.

    Diagram ­ Update the types of diagrams to be consistent with the proposal
    (i.e. timing diagrams, structure diagrams, information flow, etc)

    Generalization ­ Insert “indirect” prior to “instance of the general
    classifier”.

    Inheritance ­ Delete last fragment “related by behavior”.

    Interaction diagram ­ Include reference to timing diagram.

    Interaction overview diagram ­ delete “s” on nodes

    Layer ­ Don’t restrict the use of the term partition to reflect a vertical
    slice of the architecture. This is too limiting. Add a qualifier such as
    may.

    Modeling time - Delete the term “software”.

    Module - Delete the term “software”.

    Object diagram ­ should this be replaced with Instance diagram.

    Part ­ Add the following after classifier instance “or roles of a
    classifier”. Reference the definition for “Role”, which provides
    clarification.

    Partition - Don’t restrict the use of the term partition too much. Partition
    can reflect the grouping of any set of model elements based on a set of
    criteria.

    Run time ­ Insert after “computer program” “or a system”.

    Specification ­ Consider changing the definition to “a set of requirements
    for a system or other classifier.

    Subsystem ­ Replace “See package” with “See system”

    System ­ Replace system definition with the following: A component which
    contains parts, and has observable properties and behaviors.

    Trace ­ Add the following ­ A dependency between a derived requirement and a
    source requirement

    Use case diagram ­ Change from “A diagram that shows the relationships among
    actors and use cases within a system” to “A diagram that shows the
    relationships among actors, the subject (system), and use cases

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The name "required interface" is misleading

  • Key: UML14-376
  • Legacy Issue Number: 6443
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    The name "required interface" is misleading
    Description: The name "required interface" is misleading, since a required
    interface is not really an interface; it is a usage of an interface.
    Recommendation: Rename "required interface" to something more descriptive

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 significant typo - collaboration diagram

  • Key: UML14-373
  • Legacy Issue Number: 6439
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    In the UML 2.0 Superstructure final adopted specification
    document 03-08-02 (and all previous versions), the phrase
    "collaboration diagram" appears in the last row of Figure 464 on
    page 590, and in no other place in the entire document. This
    occurrence probably missed the global change from "collaboration
    diagram" to "communication diagram". This is a key figure that is
    likely to be reproduced in many articles and slide sets, and
    should be fixed.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is the same as issue 6066.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

targetScope on StructuralFeature and AssociationEnd

  • Key: UML14-372
  • Legacy Issue Number: 6437
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    UMl 1.x supported targetScope on StructuralFeature and AssociationEnd. This does not seem to be present in UML 2.0 when looking at Property or elsewhere. For backward compatibility this should be reinstated or alternatively at least be a standard tag in Appndix B.

  • Reported: UML 1.5 — Wed, 5 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specification of parametric models

  • Key: UML14-375
  • Legacy Issue Number: 6442
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Description: It is unclear how to specify parametric models as they are used
    in systems engineering. In particular, it is unclear how to specify
    mathematical or logical equations (e.g., Force = mass * acceleration) that
    constrain the values of classifier attributes/properties. Systems engineers
    must be able to:
    a) Specify the dependencies between parameters and expressions or
    constraints. This must support arbitrarily complex and continuous time
    equations.
    b) Allow parameters to be passed into expressions.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Excessive syntactic and semantic overlap between structured Classifiers

  • Key: UML14-374
  • Legacy Issue Number: 6440
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    There is excessive syntactic and semantic overlap between two
    kinds of structured Classifiers: StructuredClasses::Classes and Components.
    It is confusing to users how to choose between these constructs, and how to
    apply them correctly. The confusion extends to how Ports and Interfaces are
    used with these constructs, since it is unclear how to use both of these in
    a complementary manner.
    Recommendation: Remove one of these structured Classifiers, or clarify how
    to choose between and apply them. Also explain how to apply Ports and
    Interfaces in a complementary manner for both black-box and white-box views
    of structured Classifiers.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Superstructure: 03-08-02 / <>

  • Key: UML14-371
  • Legacy Issue Number: 6434
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Definition mismatch:

    p. 108/109:
    "...dependency is an instantiate dependency, where the Car class is an instance of the Vehicle Type class."

    p. 595:
    "A usage dependency among classifiers indicating that
    operations on the client create instances of the supplier."

    Either use a <<create>> dependency on p. 108/109 or change definition on p. 595.

    I think the instantiate dependency is a relationshp between an instance and its specification.

  • Reported: UML 1.5 — Wed, 5 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of issue 6159

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ad-03-04-01 Chap 3 p. 151 Table 3/Composite structures: ComplexPort

  • Key: UML14-370
  • Legacy Issue Number: 6432
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re Chapter 3, Composite Structures, Table 3, p. 151: The "Reference"
    column for Port refers to ComplexPorts. ComplexPorts are not defined in the
    specification.

    Recommendation: Delete the reference to ComplexPorts and clarify the
    language in the Reference column for Port accordingly

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ad-03-04-01 Chap3 p.146/Composite structures: Connected elements constraint

  • Key: UML14-369
  • Legacy Issue Number: 6431
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re the definition of Port in Chapter 3, Composite Structures,
    constraint [1], p. 146, which says: "The multiplicities on connected
    elements must be consistent." This seems too vague. Consistency needs to be
    defined more precisely.

    Recommendation: The English statement of the constraint should be expressed
    directly in terms of the properties of the metamodel. (The constraint
    should be expressed in OCL too, of course.)

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chap 3 p. 142-143 Figure 3-35 /Composite structures: Port multiplicity

  • Key: UML14-368
  • Legacy Issue Number: 6429
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re the definition of Port in Chapter 3, Composite Structures, third
    paragraph of the Notation section, which starts on page 142: This paragraph
    discusses how to notate the multiplicity of a Port (last line of p. 142),
    referring to Figure 3-35 on page 143. However, the semantics of Port
    multiplicity do not appear to be spelled out.

    Recommendation: Define the semantics of the multiplicity of a Port.

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of firing compound transitions still appears to be circular

  • Key: UML22-1
  • Legacy Issue Number: 4110
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In UML 1.4 beta R1, the semantics of firing compound transitions still appears to be circular and therefore incorrect. At any rate I am confused by the text so it may be confusing to others.

    As far as I can see the "Least Common Ancestor" is needed to determine the "main source", but actions following exit from the "main source" must be performed before the targets following a choice point are known, so without known targets there is no known LCA and therefore no specified "main source".

    On page 2-173 of 2.12:

        • The least common ancestor (LCA) state of a transition is the lowest composite state that contains all the explicit source states and explicit target states of the compound transition. In case of junction segments, only the states related to the dynamically selected path are considered explicit targets (bypassed branches are not considered).

    If the LCA is not a concurrent state, the main source is a direct substate of the least common ancestor that contains the explicit source states, and the main target is a substate of the least common ancestor that contains the explicit target states. In case where the LCA is a concurrent state, the main source and main target are the concurrent state itself. The reason is that if a concurrent region is exited, it forces exit of the entire concurrent state.

    [...]

    Once a transition is enabled and is selected to fire, the following steps are carried out in order:

    • The main source state is properly exited.

    • Actions are executed in sequence following their linear order along the segments of the transition: The closer the action to the source state, the earlier it is executed.

    • If a choice point is encountered, the guards following that choice point are evaluated dynamically and a path whose guards are true is selected.

    • The main target state is properly entered. ***

    This is certainly much better than 1.3. But I still find it difficult to follow:

    Since guards following a choice point are evaluated dynamically, the targets are still unknown when the "main source" is exited. Therefore the LCA is still unknown. How then does one determine the "main source" as a "direct substate" of the (unknown) LCA?

    The (target) "states related to the dynamically selected path" referred to above for determining the LCA cannot be determined in the case of choice points, without having first determined which branches will be taken from the choice points. That requires performing exit actions for the "main source", then additional actions along the path to the choice point, in order to determine which branch will be taken. So the "main source" must be already known in order to determine the targets.

    If one defined the "initial source" as the LCA of the source states then the "main source" might be any superstate of that "initial source".

    With different targets, there might be additional actions to "properly exit" from enclosing superstates of the "initial source" before actions along the transition to a choice point. These could affect which branch is taken and therefore which enclosing superstate of the "initial source" must be "properly exited", which would affect which actions are performed before reaching the choice, and therefore affect the branch taken from the choice.

  • Reported: UML 1.3 — Thu, 7 Dec 2000 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Remove the paragraph explaining the LCA from the “Transition execution sequence” section and add an
    explanation of LCA to the “Transition ownership” section

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue 6090 correction

  • Key: UML14-553
  • Legacy Issue Number: 7561
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Issue 6090 correction. The following sentence should have been added to the last paragraph of the resolution to issue 6090: "An action may not put more values on an output pin in a single execution than the upper multiplicity of the pin."

  • Reported: RAS 2.0b1 — Mon, 21 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super / Classes / Operation constraints

  • Key: UML14-543
  • Legacy Issue Number: 7366
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Currently, the UML 2 specification defines Operation properties precondition, postcondition, and bodyCondition that are owned constraints. However, these properties do not subset the Namespace::ownedRule property, but rather the Namespace::ownedMember property.

    The opposites of these properties are preConstraint, postConstraint, and bodyConstraint, all of which are non-navigable and subset Constraint::context and Constraint::namespace.

    Also, the Constraint::namespace property, which is non-navigable, subsets Constraint::context, which is navigable. This is inconsistent, and in fact violates the UML's own constraint on property subsetting which stipulates that a navigable property can only be subsetted by a navigable property (constraint [4] of metaclass Property).

    The consequence of all this is that a Constraint that is the precondition (for example) of an Operation does not have a context . This means that a constraint such as an OCL expressions in pre-conditions cannot be parsed against the context namespace.

    There are (at least) two ways to solve this problem:
    let Operation::precondition and its cohorts subset Namespace::ownedRule instead of Namespace::ownedMember (which would leverage the eContainer() "cheat" that EMF offers to get the owner of an element that doesn't have a navigable owner property)
    let Constraint::namespace redefine NamedElement::namespace and make it navigable, thus making the subset relationship with Constraint::context valid

    The first option seems preferred, for two reasons:
    It makes sense that all constraints that a namespace owns should be included in the ownedRule property
    This would be consistent with the Behavior metaclass, whose precondition and postcondition properties do subset ownedRule

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super / ordering of association ends

  • Key: UML14-542
  • Legacy Issue Number: 7365
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It seems to me the the following properties should perhaps be ordered (currently they are not):

    ApplyFunctionAction::argument
    Association::endType
    CombinedFragment::operand
    ConnectableElement::end
    InteractionOccurrence::argument
    Message::argument
    StringExpression::subExpression
    StructuredClassifier::ownedAttribute
    TemplateSignature::parameter

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Q re Parameter

  • Key: UML14-541
  • Legacy Issue Number: 7355
  • 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.

  • Reported: XMI 2.0 — Sun, 16 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of issue 7344

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 super/interactions

  • Key: UML14-537
  • Legacy Issue Number: 7301
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf: page 412: consider/ignore - I can find no explanation of how
    the message types to be considered/ignored are modeled. The spec should be
    clear on this issue, probably in the description of combined fragment.

  • Reported: XMI 2.0 — Wed, 5 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Templates / invalid multiplicity

  • Key: UML14-536
  • Legacy Issue Number: 7277
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Figure 428 says that TemplateParameterSubstitution::ownedActual has a multiplicity of (0..1). However, the association description on page 549 states that the multiplicity is (1..). However, it seems to me that the multiplicity was intended to be 0.. despite what the diagram (and Rose model) seem to suggest.
    This is because a template substitution may not necessarily own any of its actual parameter values.

  • Reported: XMI 2.0 — Thu, 29 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Profiles / problem with name collisions

  • Key: UML14-535
  • Legacy Issue Number: 7276
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The new rule for extension end role names as adopted in ballot 10 (specifically for metaclass extension role names) is likely to lead to name collisions. For example, a stereotype that extends the Package metaclass with a property named 'basePackage' would conflict with the recommended role name of the metaclass extension end ('basePackage'). The recommended role names should be less likely to collide with names that might be chosen for stereotype properties, for example, base$"ExtendedMetaClassName" (i.e. base$Package).

  • Reported: XMI 2.0 — Thu, 29 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XMI schema (02)

  • Key: UML14-548
  • Legacy Issue Number: 7402
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    "[C]omplying with a package requires complying with its abstract syntax, well-formedness rules, semantics, notation and XMI schema." [2] The requirement to comply with an XMI schema may be ambiguous. If this is intended to require that a compliant implementation correctly create a model from an XMI file written according the the XMI scheam and write an XMI file from a model according to that schema, this ought to be spelled out.

  • Reported: RAS 2.0b1 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This aspect has been clarified as part of the resolution to issue 6248

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Question about Enumeration and EnumerationLiteral

  • Key: UML14-547
  • Legacy Issue Number: 7379
  • Status: closed  
  • Source: Red Hat ( Randall Hauch)
  • Summary:

    Enumeration is a subtype of DataType, and DataType allows both Properties and Operations. And since Enumeration has no additional constraints, this means that Enumeration also allows owned Property and Operation instances. Is there a reason why this is so? I would have expected an OCL constraint that limited the owned members of Enumeration to be only EnumerationLiteral instances.

    EnumerationLiteral is a subtype of InstanceSpecification, which itself is a subtype of PackageableElement. Because Package and own any number of PackageableElements, Package can actually own EnumerationLiteral. Is there a reason why this is so? The sematics talk about EnumerationLiteral being in the scope of an Enumeration, but it is somewhat vague about whether that is a constraint (there are no additional constraints). I would have expected an OCL constraint stating that EnumerationLiteral is only valid in the context of an Enumeration.

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / missing owners of concepts

  • Key: UML14-540
  • Legacy Issue Number: 7336
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The owners of the metaclasses InformationFlow, ParameterSet, and PrimitiveFunction are not defined

  • Reported: XMI 2.0 — Fri, 14 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / state machines / state should be a namespace

  • Key: UML14-539
  • Legacy Issue Number: 7323
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Currently, a State is not a namespace, even though it contians things such as entry and exit pseudostates, substates, etc. all of which are in the context of a State. Therefore, State should be made a kind of Namespace as well as being a kind of Vertex. (Note that Vertices in general do not need to be Namespaces.

  • Reported: XMI 2.0 — Sat, 8 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the resolution to issue 6207.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Connector

  • Key: UML14-538
  • Legacy Issue Number: 7321
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf, page 163:
    Specifies a link that enables communication between two or more instances.
    This link may be an instance of an association, or it may represent the
    possibility of the instances being able to communicate because their
    identities are known by virtue of being passed in as parameters, held in
    variables, created during the execution of a behavior, or because the
    communicating instances are the same instance.

    Doesn't this imply a semantic variation point?

  • Reported: XMI 2.0 — Fri, 7 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super / Common Behavior / Trigger should be a named element

  • Key: UML14-546
  • Legacy Issue Number: 7369
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In figure 317, Trigger is defined as a specialization of Element. However, it seems reasonable for triggers to have names, so it really should be a subclass of NamedElement

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super / Use cases / navigation from subject to use case

  • Key: UML14-545
  • Legacy Issue Number: 7368
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The current model of use cases does not allow navigation from a subject classifier of a use case to its use case. It should be possible to do this, so that a classifier can easily identify which use cases apply to it. The proposed resolution is to make Classifier::useCase navigable.

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / superclass pointers

  • Key: UML14-544
  • Legacy Issue Number: 7367
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It would greatly improve readability if every metaclass had a section that listed all the immediate superclasses of that class. This would also make the document consistent with the resolution to issue 7156, which indicates that such a subsection should exist.

  • Reported: XMI 2.0 — Thu, 20 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue 6094 correction.

  • Key: UML14-552
  • Legacy Issue Number: 7560
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Issue 6094 correction. The resolution to Issue 6094 made action concrete, but left the assocations input and output as unions, which are derived and cannot be used in a a direct instance of Action (the input and output associations were changed to nonderived, but this is inconsistent). Restore original model and introduce OpaqueAction instead

  • Reported: RAS 2.0b1 — Mon, 21 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/Need unattached lifelines

  • Key: UML14-551
  • Legacy Issue Number: 7553
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    At present, a lifeline always requires a corresponding ConnectableElement. For informal users of UML this requires that have to declare a specific structure for every interaction diagram that they want to draw. However, there are many uses of UML who want a less formal approach. For example, people may want to attach scenarios to use cases informally, that is, without having to talk about any specific connectable elements.

    Therefore, the multiplicity of the Lifeline::represents association end should be changed from 1 to 0..1.

  • Reported: RAS 2.0b1 — Wed, 30 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

transition is simply never enabled

  • Key: UML14-534
  • Legacy Issue Number: 7256
  • Status: closed  
  • Source: ISTI-CNR ( Franco Mazzanti)
  • Summary:

    Maybe this is a stupid question. But I could not find an answer ... A transition is not required to have a trigger. If the source of the transition is a composite state, its triggering is described by the rules about "completion transitions". But what happens if the source is just a simple state: It would seem that the transition cannot be considered as a "completion transition", but at the same time, the transition never satisfies the rules about "enabled transitions". Hence it woulds seem that the transition is simply never enabled. Is this interpretation correct? If so, it this behaviour really intended?

  • Reported: XMI 2.0 — Wed, 21 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Sequence diagram

  • Key: UML14-533
  • Legacy Issue Number: 7253
  • Status: closed  
  • Source: Independence Blue Cross ( Janardhanam Venkat)
  • Summary:

    In the UML Sequence diagram there are asynchronous message that is very useful in designing application. I am trying to create an activity diagram between 4 asynchronous system. Why cant we have asynchronous arrow in activity diagram between swim lanes? That is the true representation of a flow in a distributed system.

  • Reported: XMI 2.0 — Fri, 16 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

property strings on association ends

  • Key: UML14-550
  • Legacy Issue Number: 7404
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    The drawings show property strings on association ends, which consist of a comma separated list of property strings. This is not authorized by the Notation section of 7.11.2.

  • Reported: RAS 2.0b1 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

change trigger

  • Key: UML14-549
  • Legacy Issue Number: 7403
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    A change trigger specifies an event that occurs when a Boolean-valued expression becomes true as a result of a change in value of one or more attributes or associations." [13.3.8] Does this intend to mean a change in value not of of one or more attributes, but of one or more slots? If so, then does it also intend to mean a change in value not of of one or more associations, but of one or more links? But, can the value of a link change? "A link is a tuple with one value for each end of the assocaition, where each value is an instance of the type of the end." [7.11.2] With a different value, we have a different tuple. Perhaps the text intends: A change trigger specifies an event that occurs when a Boolean-valued expression becomes true as a result of a change in value in one or more slots or the creation of destruction of one or more links.

  • Reported: RAS 2.0b1 — Mon, 31 May 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify termination of asynchronous invocations

  • Key: UML14-405
  • Legacy Issue Number: 6486
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that asychronously invoked behaviors/operations aren't
    terminated by activity final

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Appendix A Diagrams

  • Key: UML14-404
  • Legacy Issue Number: 6485
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Figure 464 includes a Collaboration Diagram. Is this a carryover error from UML 1.x or a reference to a diagram that contains Collaborations and CollaborationOccurrences

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is the same issue as issue 6066

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 17

  • Key: UML14-403
  • Legacy Issue Number: 6484
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Page 534 states, "When it is attached to an information channel, a black triangle on the information channel indicates the direction." What is an information channel? This is the only sentence in the document in which this phrase is used.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.3.3 Realization

  • Key: UML14-396
  • Legacy Issue Number: 6477
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    The text states, "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." What is an open arrowhead. Compare and contrast that with the "stick arrowhead" described in the Presentation Options section of Class in Composite Structures (page 156). Stick arrowhead can be found 6 times in the spec, while open arrowhead can be found 4 times. They all appear to refer to the same notation. I recommend that you chose one term.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.3.1 Component

  • Key: UML14-395
  • Legacy Issue Number: 6476
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Figure 89 and 90. The text states "A component is shown as a Classifier rectangle with the keyword «component». Optionally, in the right hand corner a component icon can be displayed." Some of the example components do not have the <<component>> included, just the icon is present. My reading of the text is that this is incorrect. The icon is optional but the <<component>> designation is required

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 14.4 Diagrams

  • Key: UML14-401
  • Legacy Issue Number: 6482
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    In the text describing Figure 345 it states, "Thus the appearance of a w message after the v is an invalid trace." There is no w message in the diagram.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 14.4 Diagrams

  • Key: UML14-400
  • Legacy Issue Number: 6481
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Table 15. The text describing message states, "asynchronous message, a call and a reply" but the graphic shows them in the order of call, asynchronous, reply. The text should match the graphic.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.3.1 Component

  • Key: UML14-394
  • Legacy Issue Number: 6475
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Figure 81 should have identifiers for the provided interfaces. Figure 83 is not consistent with section 7.15.3 in that it uses a realization instead of a dependency as described in the text related to Figure 62. The examples in this section are not cohesive. It is not clear how Figure 85 relates to the rest of the examples.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 14.3.14 Message

  • Key: UML14-399
  • Legacy Issue Number: 6480
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    The semantics section states, "There will normally be a return message from the called lifeline..." while the Notation section refers to "The reply message from a method has a dashed line." If the return message and the reply message are the same ting then only use one name. If they are differnt, then explain the difference

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 10 Deployments

  • Key: UML14-398
  • Legacy Issue Number: 6479
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Figure 130 and 131. If these are meant to be two representations of the same node, then make the contents the same or explain the differences. Figure 136 should be <<ExecutionEnvironment>> vice <<container>>. Either that or the text is incorrect and needs to be changed

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.1 Overview

  • Key: UML14-393
  • Legacy Issue Number: 6474
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    This section states "It has one or more provided and required interfaces" but other sections indicate that a component may have EITHER provided or required interfaces, or both. They are not required to have both types.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 14.4 Diagrams (02)

  • Key: UML14-402
  • Legacy Issue Number: 6483
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Table 19 the Message entry- it is unclear which message is which and I don't think any of them are reply messages

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 9.4 Diagrams

  • Key: UML14-397
  • Legacy Issue Number: 6478
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Table 6. The Collaboration and CollaborationOccurrence notation is incorrect

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Ports

  • Key: UML14-450
  • Legacy Issue Number: 6669
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    page 168 - isBehavior: Boolean Specifies whether requests arriving at this
    port are sent to the classifier behavior of this
    classifier (see "BehavioredClassifier (from BasicBehaviors)" on page 383).
    Such ports are
    referred to as behavior port. Any invocation of a behavioral feature
    targeted at a behavior
    port will be handled by the instance of the owning classifier itself, rather
    than by any
    instances that this classifier may contain. The default value is false.

    This needs to be backed up by a constraint that ensures that no
    ownedConnectors may connect to such a Port.

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Connector

  • Key: UML14-449
  • Legacy Issue Number: 6668
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    If as has been suggested structured classes completely encapsulate their
    parts, then I would expect to see a constraint against Connector, which
    states that the parts associated to its ends via "role" or "partWithPort"
    should be owned by the same StructuredClassifier as owns the Connector.

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Activities / association end naming

  • Key: UML14-457
  • Legacy Issue Number: 6679
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ActivityNode::interruptibleRegion should probably be renamed to ActivityNode::inInterruptibleRegion so as to be consistent with ActivityNode::inGroup, ActivityNode::inPartition, and ActivityNode::inStructuredNode.

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    See changes for 6678.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Activities / inconsistency in representing subsetting

  • Key: UML14-456
  • Legacy Issue Number: 6678
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Instead of subsetting ActivityEdge::inGroup with an ActivityEdge::interruptibleRegion property (as is done with ActivityNode), a completely new association (ActivityEdge::interruptibleRegion<->InterruptibleActivityRegion::interruptingEdge) is introduced. Why the inconsistency?

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Activities/assocition end specialization consistency

  • Key: UML14-454
  • Legacy Issue Number: 6676
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ActivityGroup::edgeContents and ActivityGroup::nodeContents are redefined by subclasses ActivityPartition (Figure 183), InterruptibleActivityRegion (Figure 191), and StructuredActivityNode (Figure 192), but the opposites of these properties are subsetted instead. Would make more sense to apply either redefinition or subset constraints to both ends of the associations rather than a mixture of both?

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

subsettedProperty->forAll(sp | isDerivedUnion) ?

  • Key: UML14-452
  • Legacy Issue Number: 6674
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    As used in UML 2 Infra and Super is it intended that all properties that are subset by some other properties be derived unions?

    So that the following constraint would be true for the Class Property…

    subsettedProperty->forAll(sp | isDerivedUnion) ?

    I understand this may not be a requirement but am just trying to understand if this is how it is used in the Spec.

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of issue 6430

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Connector End

  • Key: UML14-451
  • Legacy Issue Number: 6670
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    p 165, partWithPort: Property [ 0..1 ] Indicates the role of the internal
    structure of a classifier with the port to which the connector
    end is attached.

    Is there any significance to the fact that the term role is used, or is part
    meant here? There seems to be no constraint that makes it explicit that
    partWithPort must associate to a part (i.e. a property with
    isComposite=true.)

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Activities/invalid multiplicity 0

  • Key: UML14-455
  • Legacy Issue Number: 6677
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    InterruptibleActivityRegion::edgeContents redefines the multiplicity of ActivityGroup::edgeContents to be 0, which violates the constraint that an upper bound must be greater than 0

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Structured Classes

  • Key: UML14-447
  • Legacy Issue Number: 6666
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf

    Figure 95 - the term

    {subsets redefinit ionContext}

    appears in an odd place - I assume it belongs as a complement to
    redefinedConnector, rather than ownedConnector

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Activities/end naming consistency

  • Key: UML14-453
  • Legacy Issue Number: 6675
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ActivityGroup::edgeContents and ActivityGroup::nodeContents should probably be renamed to ActivityGroup::edgeContent and ActivityGroup::nodeContent so as so be consistent with the rest of the specification.

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 164 - there are two constraints sections for Connector

  • Key: UML14-448
  • Legacy Issue Number: 6667
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Page 164 - there are two constraints sections for Connector

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Delete the section “Constraints” at the top of p. 164 of adtf/03-08-02.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 Superstructure Derived Union vs. derivationExpression?

  • Key: UML14-444
  • Legacy Issue Number: 6646
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    The use of the latter would eliminate the isDerivedUnion Property from the Class Property and would eliminate the subsets and union property strings from all the associations. Also would allow for the definition of more complex derivations other than simple unions. A Property could be overridden/redefined for each child class to update the derivation for that class.

    Most importantly the information would be stored in a more appropriate location. When attempting to determine a value for a property one simply need look at the derivationExpression and not look at all other properties to determine which properties subset this derived union. Given the number of mistakes using derived union in the UML 2.0 Spec it seems apparent that this is error prone.

    Implementation would also be easier. Most modeling tools could simply add a couple of tagged values to allow for the definition of derivationExpression. Also languages would be able to generate a standard function call to calculate the derivationExpression.

    Example:

    The Property ownedMember of the Class Package is redefined to specialize the EndType from NamedElement to PackageableElement. In order to determine how to actually derive the value of ownedMember one has to currently iterate all the properties to determine which ones subset the derived union property and then perform the union. Also, one would have to ensure the property strings are on each subsetting member.

    Using the derivationExpression one would only need the following in one location:

    ownedType->union(nestedPackage)->union(ownedRule)

    If desired, but not required, the derivation expression could be displayed on a diagram via a comment.

  • Reported: UML 1.5 — Mon, 1 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is really a continuation of issue 6644, not a separate issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 Superstructure reccomendation (derived unions)

  • Key: UML14-443
  • Legacy Issue Number: 6644
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    For all Properties that are derived unions it would be nice to see the derivation expressed as an OCL expression for each inherited property that is a derived Union in all child classes.

  • Reported: UML 1.3 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of issue 6430

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / use cases / incorrect comments in notation section

  • Key: UML14-442
  • Legacy Issue Number: 6643
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML 2.0 Superstructure ptc/03-08-02

    In table 22, in the Notation cell associated to the "Include" Note Type,
    the comments associated to the two Use Case shoud be exchanged :
    the Whidraw UC should be the including UC; the Card Identification should
    be the included UC.

  • Reported: UML 1.5 — Sat, 29 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Error in definition of PackageMergeKind

  • Key: UML14-441
  • Legacy Issue Number: 6642
  • Status: closed  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    Figure 9-11 specifies that the two values for PackageMergeKind are 'extent' and 'define'. This is probably an editorial error. I suppose the same error exists in the OMG Standard petal file(s).

    Under PackageMerge, Properties, the sentence, 'mergeType: PackageMergeKind Specifies the kind of package merge to perform, define, or extend.', has an extra comma, the last, which should be removed. This sentence might better be written with a colon in place of the first comma:

    mergeType: PackageMergeKind Specifies the kind of package merge to perform: define or extend.

  • Reported: UML 1.5 — Thu, 27 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/parts

  • Key: UML14-446
  • Legacy Issue Number: 6648
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf, page 174:part: Property References the properties specifying
    instances that the classifier owns by composition.
    This association is derived, selecting those owned properties where
    isComposite is true.

    This seems to imply that /parts can only reference Properties whose types
    are Class, Interface, Templateable Class., i.e. only those subtypes of
    Classifier that denote instances. Is this correct - if so then it should be
    more explicit in the constraints (I couldn't see any other reference to this
    constraint).

  • Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Composite Classes

  • Key: UML14-445
  • Legacy Issue Number: 6647
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    pg 168: The provided and required interfaces completely characterize any
    interaction that may occur between a classifier and its
    environment at a port.

    If the type of a port is a class, perhaps with superclasses, then I don't
    see how the above statement can be true.

  • Reported: UML 1.5 — Tue, 2 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

section 9 (State Machines) of 3rd revision

  • Key: UML14-437
  • Legacy Issue Number: 6626
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    In section 9 (State Machines) of 3rd revision

    Page 454 - The Description of the class “Transition” associations fails to list the association “container” depicted on the drawing on page 415.
    Drawing on page 415 displays

    {redefines owner}

    for both container of Vertex and for Transition. I believe these should be

    {subsets owner}

    (also in mdl file)

  • Reported: UML 1.5 — Sun, 23 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Actions/PrimitiveFunction missing properties

  • Key: UML14-436
  • Legacy Issue Number: 6625
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    PrimitiveFunction is missing formalParameter and returnedResult properties, as referenced by ApplyFunctionAction on page 222. Should it be a specialization of Behavior?

  • Reported: UML 1.5 — Fri, 21 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    See resolution of 7405.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Time trigger notation in state machines

  • Key: UML14-434
  • Legacy Issue Number: 6607
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In activity diagrams a time expiration event can be notated using a special "time consumation" icon.
    For state machines it is not clear whether the same icon can be used.

  • Reported: UML 1.5 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No way to represent "uninterpreted" actions

  • Key: UML14-433
  • Legacy Issue Number: 6606
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Within a state machine we would like refer to an action defined rather "informally" using natural language.
    Among the list of actions metaclasses, we did not see any one that could be used to map our "informal"
    action.
    Suggestion for resolution: Add a UninterpretedAction metaclass in the metamodel.

  • Reported: UML 1.5 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Actions/non-existent feature "multiplicity"

  • Key: UML14-438
  • Legacy Issue Number: 6627
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The third constraint on StructuralFeatureAction (page 258) uses the very non-existent feature "multiplicity" of the InputPin metaclass. Not only that, but because this "multiplicity" feature doesn't exist, who is to tell what kind of element it is that defines the "is(lower, upper)" operation! Recall that the InputPin is a specialization of ObjectNode, which is not a MultiplicityElement, but defines a single attribute "upper : ValueSpecification." Where is the corresponding "lower"?

  • Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This duplicates 6090.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation when guards are used in conjunction with triggers in transitions

  • Key: UML14-435
  • Legacy Issue Number: 6608
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    According to the metamodel, a transition may have a guard and a trigger. However the specification
    does not say how to draw a transition that has both. Should we put the guard, (1) near the arrow
    which is before the "input" symbol representing the trigger signal, or (2) near the arrow which is after
    the "input" symbol or (3) inside the symbol representing the trigger?

  • Reported: UML 1.5 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 Superstructure 3rd revision - Owner of triggers?

  • Key: UML14-440
  • Legacy Issue Number: 6629
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    Trigger specializes Element which has the constraint self.mustBeOwned() implies owner->notEmpty()

    And defines mustBeOwned = true

    Trigger and all of its specializations

    1. never define any relationship that

    {subsets owner}

    2. Do not override mustBeOwned

    Therefore Trigger and all specializations will violate the constraint.

  • Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of 6206

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Action/featuringClassifier misinterpreted

  • Key: UML14-439
  • Legacy Issue Number: 6628
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The fourth constraint on StructuralFeatureAction (page 258) appears to assume that the "featuringClassifier" of a structural feature is singular, and the description of StructuralFeature in the Classifiers package likewise suggests that it is singular. However, the spec does not redefine Feature::featuringClassifier (which is explicitly 1..* cardinality) as 1..1 cardinality in StructuralFeature!

  • Reported: UML 1.5 — Tue, 25 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UseCase - Constraint for non-circular include relation

  • Key: UML14-493
  • Legacy Issue Number: 6965
  • Status: closed  
  • Source: Anonymous
  • Summary:

    UseCase - Constraint for non-circular include relation

    I suggest to add the following fragments to the sections "Additional Operations" and "Constraints":

    Additional Operations [1] The query allIncludedCases() gives a set of all of the uses cases which are either included directly by this use case or indirectly by other included use cases.

    UseCase::allIncludedCases(): Set(UseCase); allIncludedCases = self.include->union( self.include->collect(uc | uc.allIncludedCases()) )

    Constraints [4] A Use Case may not directly or indirectly include itself not self.allIncludedCases()->includes(self)

  • Reported: XMI 2.0 — Sat, 31 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What level of MOF 2.0 is the metamodel for UML 2.0?

  • Key: UML14-492
  • Legacy Issue Number: 6959
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    UML 2.0 does not state which level of MOF (EMOF, CMOF, or
    whatever else) provides its meta-meta-model. Therefore, there is
    no formal statement defining which Class definition (Basic or
    Constructs package level) and so forth is the basis for the
    definitions in the UML 2.0 specification. UML tools implement
    this class, so it's probably a good idea to know which one it's
    supposed to be. (Proof, in case you're wondering: The names
    EMOF and CMOF do not occur anywhere in the Superstructure
    final adopted specification 03-08-02. The name MOF does, but
    not in the context of which version of MOF defines the
    UML metametamodel.)

    If there is an ambiguity in which it is, the FTF needs to resolve
    it. Once it's resolved ("The metamodel for UML 2.0 is CMOF"), it
    should be stated clearly in the specification.

  • Reported: XMI 2.0 — Wed, 4 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Realize keyword-stereotype

  • Key: UML14-484
  • Legacy Issue Number: 6930
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Table 28 in the appendix identifying standard stereotypes identifies that the "realizes" stereotype of Abstraction has been retired. However, on page 110 it is stated that the notation for a Realization dependency is a dependency with the "realize" keyword attached to this. Although this could be explained by saying that the keyword has not been retired whereas the stereotype has, this is very confusing and appears contradictory. I suggest we eliminate the table entry in Table to 28 that specifies that the "realize" stereotype has been retired.

    The bigger problem, perhaps is that the difference between keywords and stereotypes is not properly explained anywhere (at least not where I could find it). Perhaps the Notation appendix should discuss this.

  • Reported: XMI 2.0 — Mon, 26 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Classes / Properties owned by properties

  • Key: UML14-483
  • Legacy Issue Number: 6929
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It seems that the lower bound of Feature::featuringClassifier should perhaps be 0 (not 1) to allow for the situation in which a Property is owned not by a class, association, or data type, but another property (as one of its qualifiers)

  • Reported: XMI 2.0 — Mon, 26 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 367

  • Key: UML14-489
  • Legacy Issue Number: 6949
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    Top of page 367, text says:
    Activity diagrams have graphical elements for containment. These
    are included in Table 13.

    In the next line, the table caption says:
    Table 13 - Graphic nodes included in activity diagrams

    Proposed resolution:
    These are inconsistent, although not necessarily wrong. They should be
    made consistent.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent labeling of tables in Section 12.4, Activities.Diagrams: p 366

  • Key: UML14-488
  • Legacy Issue Number: 6948
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    Middle of page 366, text says:
    The graphic paths that can be included in structural diagrams are
    shown in Table 12.

    In the next line, the table caption says:
    Table 12 - Graphic nodes included in activity diagrams

    Proposed resolution:
    The table caption is correct, and the text above it needs to be changed
    to conform.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent labeling of tables in Section 12.4, Activities.Diagrams p365

  • Key: UML14-487
  • Legacy Issue Number: 6947
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    Inconsistent labeling of tables in Section 12.4, Activities.Diagrams:

    Issue 1:
    Top of page 365, text says:
    The graphic nodes that can be included in structural diagrams are
    shown in Table 11.

    In the next line, the table caption says:
    Table 11 - Graphic nodes included in activity diagrams

    Proposed resolution:
    The table caption is correct, and the text above it needs to be changed
    to conform.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Deployments / Invalid cross-references

  • Key: UML14-486
  • Legacy Issue Number: 6946
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Table 9 on page 199 references pages such as 10-50, 26-201. These are not valid page number in the spec.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / use cases / incorrect table title

  • Key: UML14-495
  • Legacy Issue Number: 6969
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Table 22 on pages 523-524 is titled "Graphic nodes used in sequence diagrams" but should be titled "Graphic nodes used in use case diagrams"

  • Reported: XMI 2.0 — Mon, 2 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UseCase - Include - Constraint for irreflexivity

  • Key: UML14-494
  • Legacy Issue Number: 6967
  • Status: closed  
  • Source: Anonymous
  • Summary:

    UseCase - Include - Constraint for irreflexivity

    I suggest to add the following constraint for Include:

    Constraints [1] An include relation is irreflexive, i.e. source and target are not equal. self.addition <> self.includingCase

  • Reported: XMI 2.0 — Sat, 31 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the resolution to issue 6965.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Classes / Dependency should not be abstract

  • Key: UML14-485
  • Legacy Issue Number: 6945
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    A quick survey of the superstructure spec reveals the following places where Dependency is defined (and I probably missed some):

    Fig 51, P.106, shown as NOT abstract - this is where the Dependency package is shown
    Table 4, P.130, defines a visual symbol for it
    Fig. 101, P.155, shown as abstract
    Fig. 126, P.183, shown as abstract
    Fig 130, P.188, shows a pure dependency in an example
    Table 9, P.199, defines a visual symbol for it

    Most of the text also refers to the section containing figure 51 for the definition of dependency. If I were reading the spec, I would tend to consider the section where it is defined as the authority and dismiss the others as errors made by those writing the other chapters.

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 superstructur: actor

  • Key: UML14-496
  • Legacy Issue Number: 6970
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    UML2 superstructure 03-08-02
    p. 513
    "[1] An actor can only have associations to use cases, subsystems, components and classes, and these associations must be binary."

    A subsystem is a component stereotype, so it doesn't make sense to mention it here.

    I would propose the following constraint instead of the above one:
    "[1] An actor can only have associations to classifiers, and these associations must be binary."

    It makes sense that an actor can have binary associations to the subject they are interacting with.
    The subject of an use case is a classifier.

  • Reported: XMI 2.0 — Mon, 2 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / specialization labeling convention

  • Key: UML14-491
  • Legacy Issue Number: 6958
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In most cases, when a metaclass is refined in a package, the phrase used in the title of the class description is "as specialized". In a few places, however, it is flagged as just "specialized". This needs to be made consistent.

  • Reported: XMI 2.0 — Wed, 4 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in Collaboration Diagram figure

  • Key: UML14-490
  • Legacy Issue Number: 6950
  • Status: closed  
  • Source: Object Management Group ( Nancy Siegel)
  • Summary:

    In UML Superstructure, ad/03-08-02, Section 14.4 "Diagrams", page 443,
    figure 346, bottom right box labeled "sd Q", the label "ysuperB" needs
    a colon, and should be "y:superB" (as it is in the top right box).

  • Reported: XMI 2.0 — Thu, 29 Jan 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Issue: Connector types

  • Key: UML14-386
  • Legacy Issue Number: 6461
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    This is the definition of Connector (Superstructure, p. 163): "Specifies a
    link that enables communication between two or more instances. This link may
    be an instance of an association, or it may represent the possibility of the
    instances being able to communicate because their identities are known by
    virtue of being passed in as parameters, held in variables, created during
    the execution of a behavior, or because the communicating instances are the
    same instance. (...)"

    This paragraph is clearly a reinterpretation of the five old association and
    link stereotypes, now obsolete. Let's rewrite the second sentence as
    follows, inserting those old stereotypes for clarity:

    This link may be an instance of an association, <<association>>
    or it may represent the possibility of the instances being able to
    communicate because their identities are known
    by virtue of being passed in as parameters, <<parameter>>
    (by virtue of being) held in variables, <<???>>
    (by virtue of being) created during the execution of a behavior, <<local>>
    or because the communicating instances are the same instance. <<self>>

    It seems that the concept conveyed by the old <<global>> stereotype has
    completely disappeared (probably an improvement). But the comma between the
    words "variables" and "created" suggests that a new kind of connector, or
    link, has been introduced. But maybe the true intention of the writer was:

    (by virtue of being) held in variables created during the execution of a
    behavior, <<local>>

    That is, the comma between the words "variables" and "created" would be
    superfluous. It is not very important whether the kinds of Connector
    correspond to the old stereotypes, but it is important to know how many
    kinds of Connector there are.

    PROPOSED SOLUTION
    Suppress the comma between the words "variables" and "created".

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

glossary

  • Key: UML14-385
  • Legacy Issue Number: 6459
  • Status: closed  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    The glossary included with the appendices of the text that was adopted by the voters has been removed and that text inserted as normative text. There is no authority for the editors preparing the final adopted specification to make this major change. To make matters worse, the change introduces contradictions into the normative part of the specification.
    ...

    Suggested resolution: Move this text back where it came from.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Abandon the OMGS4LMMA

  • Key: UML14-383
  • Legacy Issue Number: 6457
  • Status: closed  
  • Source: Anonymous
  • Summary:

    If the so-called OMGS4LMMA is accepted, it is not possible that an InformationFlow could connect both Classes and Instance Specifications.
    ...

    Suggested resolution: Abandon the OMGS4LMMA. Apply InstanceSpecification uniformly (for example, an informationFlow is used to connect classes and an instanceSpecification of an informationFlow is used to connect instanceSpecifications of classes, that is, to connect objects.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

14.3: StateInvariant and ExecutionOccurrence

  • Key: UML14-382
  • Legacy Issue Number: 6454
  • Status: closed  
  • Source: Anonymous
  • Summary:

    14.3: StateInvariant and ExecutionOccurrence are both subclasses of InteractionFragment. "Each interaction fragment is conceptually like an interaction by itself." [14.3.9] And, indeed, "An ExecutionOccurrence is an instantiation of a unit of behavior..." [14.3.4] But, "A StateInvariant is a constraint on ... state..." [14.3.17] That's not like an interaction by itself, nor like any interaction at all. We've mixed models of behavior with specifications of constraints on state.

    This is an example of a recurrent problem in the specification: subclasses that are not like their superclasses.
    ...

    Suggested resolution: Review the specification with this in mind and correct all improper subtyping

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 Superstructure FTF issue - Profiles

  • Key: UML14-381
  • Legacy Issue Number: 6453
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    In the Profile chapter, there is no section for "Changes from UML 1.4" for
    stereotypes

    However, one feature of UML1.4 : attaching tagged values independently of
    any stereotype, has disappeared in UML2.0

    The evolution tagged values --> attribute should be discussed and that
    particular case enlighted. a specific pattern for converting UML1.4
    stereotype independant tags into UML2.0 should be provided.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Removal of gratuitous restrictions to software applications

  • Key: UML14-380
  • Legacy Issue Number: 6450
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Removal of gratuitous restrictions to software applications
    Description: UML is being used extensively for systems modeling as well as
    software modeling. Consequently, gratuitous restrictions to software
    applications should be removed from the specification.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.3.1 ElementImport

  • Key: UML14-388
  • Legacy Issue Number: 6468
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    The Semantics discussion includes the statement
    An imported element can be further imported by other namespaces using either element or member imports.

    The phrase "member import" is not defined and does not appear anywhere else in the spec. What does it mean? Provide an example of member import.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Issue: Include(s) and Extend(s)

  • Key: UML14-387
  • Legacy Issue Number: 6465
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    PROBLEM STATEMENT
    The notation for the Extend and Include relationships is a dashed arrow with
    open arrow and the keyword <<extend>> or <<include>> (Superstructure, pp.
    516, 518). Nevertheless, the notation examples given in pages 521, 523 and
    524 write "extends" and "includes", with an final "s". The other examples
    are allright.

    PROPOSED SOLUTION
    Fix the notation examples.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Diagram Taxonomy corrections

  • Key: UML14-379
  • Legacy Issue Number: 6449
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Description: The diagram taxonomy should be corrected as follows:
    a) "Collaboration Diagram" as a subtype of "Interaction Diagram" should be
    renamed "Communication Diagram";
    b) "Collaboration Diagram" should be added as a subtype of "Composite
    Structure Diagram";
    c) "Interaction Diagram" should be classified as a subtype of "Sequence
    Diagram" and "Activity Diagram"

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent use of terms "implement" and "realize"

  • Key: UML14-378
  • Legacy Issue Number: 6448
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    Description: The terms “implement” and “realize” are used inconsistently
    throughout the specification. These terms should be defined in the glossary
    (Preface, Terms and Definitions) and applied consistently throughout the
    specification.

  • Reported: UML 1.5 — Thu, 6 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.18 Diagrams

  • Key: UML14-392
  • Legacy Issue Number: 6473
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Table 4 - the Package Import dependency should be <<access>> not <<uses>>.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.15.3 Interfaces

  • Key: UML14-391
  • Legacy Issue Number: 6472
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    The text states "Alternatively, if an interface is shown using the rectangle symbol, their implementation and usage dependencies to provided and required interfaces, respectively, may be shown using dependency arrows (see Figure 62)." Figure 62 has an association and a generalization relationship, not dependencies.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue was resolved by the resolution to issue 6069.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change 'Part' to 'Role.

  • Key: UML14-384
  • Legacy Issue Number: 6458
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the UML 1 specification, "every time a word coinciding with the name of some construct in UML is used, that construct is referenced." [UML 1 2.3.4]

    In the UML 2 specification, the word, 'part,' is used both to mean a Part and with its ordinary meaning.

    This is an example of a recurrent problem in the specification: words that name UML 2 concepts are used both to refer to that concept, or an instance of that concept, and with their ordinary meaning. The rule of the UML 1 specification needs to be both stated and carefully followed.
    ...

    Suggested resolution: Change 'Part' to 'Role.' This permits the use of 'part' to mean part. Add the rule of the UML 1 specification. Carefully follow that rule.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.13.2 Package Merge

  • Key: UML14-390
  • Legacy Issue Number: 6471
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    Figure 47. Some of the relationships appear to be generalization and some appear to be realization. It is not clear when Package Merge is useful or necessary. A more concrete example would help

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.3.5 PackageImport

  • Key: UML14-389
  • Legacy Issue Number: 6469
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    This section is unique because it does not have a Notation section like all of the others

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

concurrent vs. parallel ExpansionRegions

  • Key: UML14-412
  • Legacy Issue Number: 6506
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    The 3rd rev. draft of UML 2's superstructure document introduces the
    keywords "parallel", "iterative", and "stream" for ExpansionRegions
    (p.
    292).

    But the example figures given at page 296 uses "concurrent" instead of
    "parallel" without any introduction.

    Finally, the metamodel type ExpansionKind (p. 248) solely defines
    "parallel" and the other two keywords mentioned above. "concurrent" is
    completely missing.

    Sure, there is a distinction between concurrency (pseudo-parallel
    execution of processes or threads on one single CPU) and parallelity
    (parallel execution of processes or threads on multiple CPUs) but I'm
    not convinced if we should introduce this distinction at the
    specification level.

    Any ideas?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate with 6099.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use Case Metamodel - UML2 Superstructure issue

  • Key: UML14-411
  • Legacy Issue Number: 6505
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    I tried to understand some parts of the Use Case metamodel but get
    stucked ...

    Looking at figure 10-49 (p. 468) of the current (i.d. 3rd rev)
    Superstructure document it is not clear or at least not that obvious
    to
    me how the Actor is related to the Use Case.

    The only possibility seems to be the relationship where the UseCase
    participates taking the role useCase connected to the Classifier. But
    I
    don't think that the Actor should play the role subject ...

    Further, the relationship connecting Actors with UseCases allows the
    placement of Multiplicities but users are not encouraged to use roles.
    Why is this asymmetry introduced? I could imagine situations
    (especially
    for business models) where roles would perfectly make sense even for
    Actors. This would be the case always when a actor acts on behalf of
    another entity or an actor is to be specialized w.r.t. a specific
    context.

    Any ideas?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operation without - UML2 Superstructure

  • Key: UML14-420
  • Legacy Issue Number: 6514
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    Page 55 of the current superstructure document lists the operation's
    syntax as "visbility name (parameter-list) : property-string" and
    states
    that "property-string optionally shows other properties of the
    operation
    enclosed in braces".

    I wondering where the good old return type or the property enclosed in
    curly brackets might have gone.

    If the "property-string" mentioned in the operation's syntax quoted
    above is the return type the possibility to add operation wide
    properties (like "query") is gone.

    If the "property-string" is the way to add properties it should be
    enclosed in curly brackets and the separation by the colon from the
    parameter list containing also the return type could be misleading.
    Hence the colon should be dropped or exchanged by another symbol.

    Or am I just misreading the spec?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Components and artifacts: Dependency problem - UML2 Superstructure

  • Key: UML14-419
  • Legacy Issue Number: 6513
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Reading the component section of the specification I come across a
    dependency
    problem. Figure 2-9 shows a white-bix representation of a component.
    The bottom
    compartment lists the related artifacts. But the direction of
    manifest dependency
    is from the artifact as source to the component as target. So the
    component
    does not know anything about its implementing artifacts.

    In my opinion the artifacts compartment is wrong.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AcitivityEdge: weight=all vs weight=null - UML2 Superstructure

  • Key: UML14-416
  • Legacy Issue Number: 6510
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    there is a mismatch in the specification.

    On p. 262 about the weight attribute on activity edges:
    "A null weight means that all the tokens at the source are
    offerd to the target."

    But Fig. 6-39 on p. 265 specifies

    {weight=all} for the same purpose.


    Which one is the correct one?


    I think {weight=all}

    is the better alternative to express the
    semantic.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate with 6096.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Large diamond for binary associations legal? - UML2 Superstructure issue

  • Key: UML14-415
  • Legacy Issue Number: 6509
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    Reviewing the current Superstructure spec I noticed that it allows the
    usage of the large diamond in the middle of an association also for
    binary associations which significantly changes to notation compared
    to
    UML 1.x

    By doing so UML class diagrams become Entity-Relationship flavoured
    but
    do not have the semantics of those notation (identity, multiplicities,
    etc.) and also the notation is still different (multiplicity,
    association name, etc.).

    Is it really intended to allow the usage of the large diamond also for
    binary associations?

    Personally, I'm quite reluctant accepting these change ...

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Guard conditions at fork nodes - UML2 Superstructure issue

  • Key: UML14-418
  • Legacy Issue Number: 6512
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I have a question about the token flow traffic rules within activity
    models:

    It is allowed to have guards at outgoing edges from fork nodes.
    The specification says about fork nodes:

    "When an offered token is accepted on all the outgoing edges,
    duplicates of the token
    are made and one copy traverses each edges."

    This means that the fork node offers tokens to its outgoing edges, if
    all guard
    conditions evaluates to true. So there is a dependency between the
    parallel flows
    after a fork node.

    Is that true?

    I think the fork node should offer tokens on all outgoing edges that
    accept the token.
    If there is a guard condition at an outgoing edge, it is possible
    that the flow continues
    only on two of three outgoing edges.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Token flow semantics: Implicit fork and join - UML2 Superstructure

  • Key: UML14-417
  • Legacy Issue Number: 6511
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    As mentioned on p. 250 an action execution is created when all its
    object flow and control flow prerequisites have been satisfied
    (implicit
    join). Same for outgoing egdes (implicit fork).

    Is it the same semantic for object nodes?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiobject in UML2

  • Key: UML14-409
  • Legacy Issue Number: 6499
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I am looking for the multiobject in the UML2 spec.

    It is defined in the UML1.5 spec. as part of the collaboration
    diagram. The multiobject is shown as two rectangles in which
    the top rectangle is shifted slightly vertically and horizontally.

    Is this still valid for UML2? Where can I find the definition in the
    spec?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Outputting constants

  • Key: UML14-408
  • Legacy Issue Number: 6491
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    How are constants introduced in a flow, eg, to output a constant to an
    activity parameter node? UML 1.5 had GetLiteralAction to output a
    constant. Reintroduce it or some construct that has the same effect.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Diagrams, Diagrams, Diagrams ... UML 2 Superstructure issue

  • Key: UML14-414
  • Legacy Issue Number: 6508
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    While trying understand the jungle of diagrams offered by UML I
    probably
    discovered an inconsistency within the most recent Superstructure
    document.

    Page A-546 shows a class digram giving a taxonomy of structure and
    behavior diagrams. The figure (numbered A-5) is accompanied with some
    descriptive text at the same page.
    The diagrams includes a box (class) for a diagram called the
    "collaboration diagram" which is not mentioned in the document set
    elsewhere. But the text mentiones a "communication diagram" which is
    completely missing in the figure.

    Additionally, shouldn't the "protocol state machine" be shown as a
    specialization of the "state machine diagram"?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Binary associations decorated with large diamonds legal?

  • Key: UML14-413
  • Legacy Issue Number: 6507
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    The current Superstructure document states that "Any association may
    be
    drawn as a diamond ...". This changes the behavior present in UML 1.x
    significantly which only allowed the diamond for n-ary (n>2)
    associations.

    As a consequence of this change a UML diagram may look more like an
    Entity-Relationship model with some changes (placement of the
    association's name, multiplicity notation, and all the semantics)
    than a
    upward compatible UML digram.

    Is this intended?

    I tend to retain UML's former behavor to allow the large diamond only
    for n-ary associations.

    Any ideas or am I just misreading the spec?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Protocol machines do not subset state invariant

  • Key: UML14-407
  • Legacy Issue Number: 6490
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Protocol machines subset guards, but not state invariant. What's the
    difference?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Conditions for parameter sets (02)

  • Key: UML14-406
  • Legacy Issue Number: 6488
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Parameter sets need conditions for pre/postconditions

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ActivityFinalNode and running actions - UML2 Superstructure issue

  • Key: UML14-410
  • Legacy Issue Number: 6504
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Reaching an ActivityFinalNode terminates the activity.
    What happens to running actions within the activity?

    Is there an interruption? Or do they run to completion?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

adopt a single notation to specify text strings used in the notation

  • Key: UML14-518
  • Legacy Issue Number: 7135
  • Status: closed  
  • Source: X-Change Technologies ( Joaquin Miller)
  • Summary:

    There are three different ways to specify text strings used in the notation and two variations.

    The three ways:

    1. a sort of Bakus-Naur form as in: multiplicity ::= <multiplicity_range> [ ‘

    {‘ <order_designator> ‘}

    ’ ] see Super 7.4.1

    2. a second way as in: [visibility] [/] name [: type] [multiplicity] [= default] [

    { property-string }] see Super 7.8.1 The characters that are a part of the notation (virgule, colon, equals and braces) are simply shown.

    3. a third way, combining features of both as in: visibility name ‘<‘ template-parameter-list ‘>’ ‘<<‘binding-expression-list ‘>>’‘( ‘ parameter-list ‘)’ ‘:’ property-string see Super 17.5.12 The characters that are a part of the notation (angle bracket, parens, colon) are enclosed in single quotes. (The inverted comma and apostrophe are not consistently used as opening and closing single quotes.)

    Both the second and the third ways are sometimes used at the same place as in: [visibility] [/] name [: type] [multiplicity] [= default] [{ property-string }

    ] {{ [ name ] ‘:’ classname } | name } [ ‘[‘ multiplicity ‘]’ ] see Super 17.5.7

    The two variations:

    a. Sometimes a single bracket does double duty as in: direction name : type-expression [multiplicity] = default-value [

    { property-string }

    ] see Super 7.10.1 Here, the brackets around multiplicity indicate both that multiplicity is optional, and that the multiplicity is to be shown inside brackets. see Super 7.10.1

    b. Sometimes the brackets are not used when an item is optional as in: visibility name ( parameter-list ) : property-string see Super 7.10.1

  • Reported: XMI 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Appendix A of the superstructure spec

  • Key: UML14-517
  • Legacy Issue Number: 7125
  • Status: closed  
  • Source: International Business Machines ( Eran Gery [X] (Inactive))
  • Summary:

    Appendix A of the superstructure spec specify the usage of frames
    in diagrams. The text says:
    "Each diagram has a frame, a contents area, and a heading, see Figure 460."

    This statement implies that frames are normative. The text later says
    that "In cases where not needed, the frame may be omitted and implied by the border of the diagram area provided by a tool."

    This entire explanation distorts the common intent and practice of UML
    diagramming. Text should present the frames as an optional presentation
    option in the first place. Also, in all cases mentioned (ports, entry points)
    it is possible to notate the context using class boxes or states, so in none of these cases frames are "needed". It is a mere presentation option that might be

    used as an alternative to using prime container symbols.

  • Reported: XMI 2.0 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Activities / Fig.192 constraint duplicated

  • Key: UML14-516
  • Legacy Issue Number: 7099
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In Fig. 192 on pg. 277, the association end StructuredActivityNode::activity, the constraint

    {redefines activity}

    is duplicated

  • Reported: XMI 2.0 — Fri, 5 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguous semantics of isStatic - resubmission of issue 4446

  • Key: UML14-515
  • Legacy Issue Number: 7098
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of isStatic = true is ambiguous for structural features
    declared on classifiers that have children. It is not defined whether
    this gives a single value for the classifier and all its descendents,
    or values for the classifier and each descendant separately.

  • Reported: XMI 2.0 — Mon, 9 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is the same issue as issue 6974

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Interactions / Invalid subsetting for enclosingOperand

  • Key: UML14-514
  • Legacy Issue Number: 7069
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There is a serious model consistency issue with InteractionFragment::enclosingOperand because it is currently constrained to be a subset of NamedElement::namespace, but its type (InteractionOperand) is not a specialization of Namespace. Also, InteractionOperand::enclosingInteraction does not subset NamedElement::namespace (it probably should; Interaction is already an indirect specialization of Namespace).

    The simplest solution is to make InteractionOperand a specialization of Namespace

  • Reported: XMI 2.0 — Thu, 4 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Classes / makesVisible () operation incorrect

  • Key: UML14-513
  • Legacy Issue Number: 7068
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    there appears to be a bug in the specification with respect to the definition of the makesVisible() OCL query on packages. Here is the OCL expression from the specification (page 100):

    Package::makesVisible(el: Namespaces::NamedElement) : Boolean;
    pre: self.member->includes(el)
    makesVisible = el.visibility->isEmpty() or el.visibility = #public

    As you can see, this definition makes even imported elements visible based on their own visbility rather than the visibility of the import
    relationship. The same applies to elements made visible indirectly via a package import.

  • Reported: XMI 2.0 — Thu, 26 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Super and Infra / Kernel-Classifiers / incorrect hasVisibilityOf definition

  • Key: UML14-512
  • Legacy Issue Number: 7056
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It seems that there is an issue with the hasVisibilityOf(NamedElement) operation on Classifier. In particular, it doesn't consider visibilities when determining if a member is visible:

    Classifier::hasVisibilityOf(n: NamedElement) : Boolean;
    pre: self.allParents()>collect(c | c.member)>includes
    hasVisibilityOf =true

    One might logically expect the operation to exclude, for example, members with private visibility.

  • Reported: XMI 2.0 — Sun, 29 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operations and derived attributes

  • Key: UML14-526
  • Legacy Issue Number: 7219
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    I am looking at ValueSpecification which introduces Additional Operations, such as integerValue(). My question is : What is the reasoning behind making these Operations vs. Derived attributes?

    In MultiplicityElement we have a derived attribute lower which is equal to lowerBound(). What logic is used to determine whether an Operation has a corresponding Attribute?

    Also the spec seems to indicate that all derived values will be implemented via some operation. Is this a requirement or an assumption of implementation?

    Why can’t lower in MultiplicityElement simple be defined as if lowerValue->notEmpty() then 1 else lowerValue.integerValue()… what makes the lowerBound() operation required?

  • Reported: XMI 2.0 — Mon, 12 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

use of stereotypes

  • Key: UML14-525
  • Legacy Issue Number: 7213
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Today, the reason for this mail is that in my UML certification I was asked a question regarding the include and extend relationship between use cases.
    I was (and am still a bit) confused, because one question was dealing with the extend and include notation between use cases. I think the 640 pages UML 2 documnet 03-08-02.pdf is inconsistent here. (I now ask because I think I lost two correct answers in my fundamental UML 2 certification caused by include/includes and extend/extends...): UML 1 used the stereotype notations "extends" and "includes". Im UML 2, the classifiers are now called "include" and "extend". But confusingly enough, some association arrows inside the OMG document 03-08-02.pdf
    "UML Superstructure 2.0 Draft Adopted Specification" use the stereotypes (see <<extends>> and <<includes>> in Fig 406 p. 521 and twice <<extends>> and one time <<includes>> in Table 22 on page 523/524.)

    Who to report these inconsistencies to? Or are the stererotypes still allowed to be labeled <<extends>> and one time <<includes>> ?

  • Reported: XMI 2.0 — Fri, 26 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of issue 6465.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Appendix A / Typos

  • Key: UML14-524
  • Legacy Issue Number: 7162
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    p587 para 2 line 2 "UML diagrams contains graphical elements" (should be "contain")
    p587 para 5 line 1 "symbols defines the type" (should be "define")
    p587 last para "C1 and C1" (should be "C1 and C2")
    p588 para 1 line 2 "a graphical symbols" (should remove "a")
    p588 para 1 line 4 "assocition"

  • Reported: XMI 2.0 — Tue, 16 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/Alternative with all false guards

  • Key: UML14-523
  • Legacy Issue Number: 7160
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Semantics of the alternative CombinedFragment (page 410) does not describe what happens if all branches are guarded, and
    all guards are false.
    Does this means: a) empty trace, or b) (dynamically) invalid trace ?
    I suggest to add a sentence, defining such traces as dynamically invalid.
    This will be consistent with the behavior of a ConditionalNode in Activities (page 313): "if no test section yields a true value, then no body section is executed; this may be a semantic error if output values are expected from the conditional node".

  • Reported: XMI 2.0 — Mon, 15 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / Classes chapter organization

  • Key: UML14-522
  • Legacy Issue Number: 7159
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The Classes chapter is organized differently from all other chapters in the document – it should be made consistent with the organization of all the other chapters

  • Reported: XMI 2.0 — Tue, 16 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / State machines / incorrect navigation specifications

  • Key: UML14-521
  • Legacy Issue Number: 7158
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In figure 354 on page 457, it is shown that it is not possible to navigate back from Region towards either the state machine that owns it or the state that owns it. However, it is often necessary to know who the owner of a region is, therefore these associations need to be made navigable in both directions.

  • Reported: XMI 2.0 — Mon, 15 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / consistent formatting conventions

  • Key: UML14-520
  • Legacy Issue Number: 7157
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Different chapters in different parts of the spec use different conventions for naming, headings, layout etc. These should all be made consistent based on one shared convention.

  • Reported: XMI 2.0 — Sun, 14 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is resolved by the resolutions to issue 6958 and 7190.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / General / Dcoument conventions

  • Key: UML14-519
  • Legacy Issue Number: 7156
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The document needs an explanation of how it is laid out and how the format and meaning of the various sections in the individual class descriptions

  • Reported: XMI 2.0 — Sun, 14 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity Diagrams: Relax Traverse-to-Completion semantics

  • Key: UML14-528
  • Legacy Issue Number: 7221
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In my interpretation of the current semantics description of UML
    activity diagrams (Superstructure, Final Adopted Spec, ptc/03-08-02) I
    have identified some rather unpleasant properties of the current
    traverse-to-completion semantics. The full discussion together with
    examples can be found in the attached .pdf, the short of it is:

    *) the current semantics does not prevent deadlocks (as it is
    supposed to do)

    *) it rather induces deadlocks even in simple examples (e.g. examples
    in the UML spec are wrong)

    *) it makes for a very complex evaluation and introduces unnecessary
    synchronization in the (basically asynchronous) notation of Activiy
    Diagrams.

    I therefore propose to relax the semantics of token flow by dropping
    the constraint that every Action has to accept all tokens for all its
    input pins at once. MergeNodes should als be able to buffer tokens
    until their conditions are satisfied. This is a more natural way of
    interpreting ADs.

  • Reported: XMI 2.0 — Mon, 5 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 super/Deployments/CommunicationPath

  • Key: UML14-530
  • Legacy Issue Number: 7228
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In section 10.3.2 and Figure 125 the constraint is given that a
    CommunicationPath can only associate Nodes.
    This seems too restrictive and does not, for example, allow
    CommunicationPaths between actual servers (Instance Specifications).

    Proposed resolution:
    Relax constraint such that a CommunicationPath can link
    DeploymentTargets.

  • Reported: XMI 2.0 — Sun, 11 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

State machines / name of transitions association end

  • Key: UML14-529
  • Legacy Issue Number: 7226
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML::StateMachines::BehaviorStateMachines::Region::transitions should be renamed to transition (i.e. made singular) to be consistent with the naming convention for other association ends.

  • Reported: XMI 2.0 — Sun, 11 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Composite Structure

  • Key: UML14-532
  • Legacy Issue Number: 7231
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    page 178, table 6 - the entry for port shows the only option for a port as
    being on the boundary of an enclosing box whereas the notation section for
    ports (169) states that port boxes may be shown inside the boundary of the
    enclosing box. The port entry on table 6 should amended so that it includes
    all cases.

    page 179, the table is headed table 6 but should be table 7.

  • Reported: XMI 2.0 — Mon, 12 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1 activities

  • Key: UML14-531
  • Legacy Issue Number: 7230
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    figure 274 - should the arrow between Award Quote and Quote Responses be the
    other way round

  • Reported: XMI 2.0 — Fri, 9 Apr 2004 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Composite Structures, 03-08-02.pdf

  • Key: UML14-527
  • Legacy Issue Number: 7220
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Can a connector be typed by an association one of whose ends are composite
    or shared? I can't see anything in the spec that prohibits this but I'm not
    sure that it makes a lot of sense to do so.

  • Reported: XMI 2.0 — Mon, 22 Mar 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect usage/definition of "emergence" in Common Behavior Chapter

  • Key: UML14-431
  • Legacy Issue Number: 6527
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    PROBLEM STATEMENT

    In section 13.1 of the Common Behaviors chapter, the following paragraph is
    contains an incorrect definition of "emergent behavior":
    "Emergent behavior results from the interaction of one or more participant
    objects. If the participating objects are parts of a larger composite
    object, an emerging behavior can be seen as indirectly describing the
    behavior of the container object also. Nevertheless, an emergent behavior is
    simply the sum of the executing behaviors of the participant objects."

    The current area of scientific study know as Complex Adaptive Systems, or
    Complexity Science", describes emergent behavior as "the appearance of a
    coherent pattern that arises out of interactions among simpler objects, that
    is MORE than just their summed behavior." (emphasis mine) Furthermore,
    Complexity Science expressly states that a behavior that is limited to the
    sum of its behavior is NOT emergent. (See references, below.)

    Emergence is a primary area of study at the Santa Fe Institute and has Nobel
    Laureates and MacArthur geniuses studying the effect. Therefore, I think
    that the use of the terms "emergence" (used once) and "emergent behavior"
    (used 9 times) are not correct for Common Behavior chapter. If left in,
    they will cause confusion, because the terminology is already
    well-established in both science and industry.

    PROPOSED SOLUTION
    1) Common Behavior Domain Model (Fig. 306) to contain the classed called
    BehaviorEmergence. Therefore, the class should wither be removed or another
    tem substituted.
    2) Remove, or rename, all 9 usages of "emergent behavior" if the chapter and
    appendix.

    References (to name a few) :

    Holland, J.H., Emergence: From Chaos to Order. 1998, Reading, MA:
    Addison-Wesley. (MacArthur Fellowship Genius Award)

    Gell-Mann, M., The Quark and the Jaguar: Adventures in the Simple and the
    Complex. 1994, New York: W. H. Freeman. (Nobel Laureate in Physics)

    Kauffman, S., At Home in the Universe: The Search for the Laws of
    Self-Organization and Complexity. 1995, New York: Oxford University Press.
    (Professor, Santa Fe Institute)

    Coveney, P. and R. Highfield, Frontiers of Complexity: The Search for Order
    in a Chaotic World. 1995, New York: Fawcett Columbine.

    Waldrop, M.M., Complexity: The Emerging Science at the Edge of Order and
    Chaos. 1992, New York: Simon and Schuster. (PhD in elementary particle
    physics)

    The Emergence of Everything: How the World Became Complex
    by Harold J. Morowitz

    Emergence: The Connected Lives of Ants, Brains, Cities, and Software – by
    Steven Johnson

    A New Kind of Science by Steve Wolfram

  • Reported: UML 1.5 — Sun, 9 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The node "Order cancel request" that appears in figure 6-86

  • Key: UML14-427
  • Legacy Issue Number: 6521
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    I would really appreciate an answer to the following questions
    regarding the
    3rd revised submission of UML 2.0 superstructure from April 10, which
    I hope
    is the most recent one:

    1. The node "Order cancel request" that appears in figure 6-86 (page
    304),
    and the node "Ready to award bid" and "Bid arrives that appear in
    figure
    6-39 (page 265) are of the type "Object nodes for tokens with signal
    as
    type", presented in page 316?
    If they are then there is a discrepancy between the respective
    graphical
    notation in page 316 and page 331 (table 1), and pages 304 and 265.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GeneralizationSet Description clarification - UML2 Superstructure

  • Key: UML14-426
  • Legacy Issue Number: 6520
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    On page 121 of 03-08-02 the GeneralizationSet description reads:
    7.17.3 GeneralizationSet (from PowerTypes)

    A GeneralizationSet is an AutonomousElement (from Foundation ::
    Kernel ::
    PackagingNamespaces) whose instances define

    partitioned sets of Generalization relationships.

    Description

    Each Generalization is a binary relationship that relates a specific
    Classifier to a more general Classifier (i.e., a subclass).

    For clarification, should the parenthetical read "(i.e., a subclass
    to a
    superclass). As written, it may convey to some that the subclass is
    the
    more general Classifier.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos

  • Key: UML14-429
  • Legacy Issue Number: 6523
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    page 261, on the Description of complete activities:
    "Edges support controlling token flow and be contained in
    interruptible
    regions."

    page 269, second line says "It covers invocation nodes, control nodes
    (...)". I believe it should read "It covers executable nodes, control
    nodes
    (...)"

    page 282, second line:
    "A control flow is an edge starts an activity node after the previous
    one is
    finished."

    page 286, in constraints [2]:
    "The input parameter must be the same as or a supertype the type of
    object
    token coming along the incoming edge."

    page 301, in Semantics:
    "This is equivalent interposing a CentralBufferNode between the
    initial node
    and its outgoing edges."
    page 307, second line:
    "A loop node is a costructured activity node that represents a loop
    with
    setup, test, and body sections."
    page 331, Table 2 caption should be "Graphic paths (...)" instead of
    "Graphic nodes (...)". Table 3 caption should also be made more
    specific.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Order cancel request

  • Key: UML14-428
  • Legacy Issue Number: 6522
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    2. Assuming that, for example, "Order cancel request" that appears in
    figure
    6-86 (page 304), is an object nodes with signal as type, from where
    or how
    does it get the respective token which is then subtracted by the arc
    ending
    in Cancel order?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Package Extensibility <> - UML2 Superstructure issue

  • Key: UML14-423
  • Legacy Issue Number: 6517
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    When merging packages... How are associated state machines handled?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Dependency notation for interfaces - UML2 Superstructure

  • Key: UML14-422
  • Legacy Issue Number: 6516
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    Comparing figure 1-63 (Superstructure document page 92) with the text
    placed above describing it and the presentation guidelines for
    interface
    relationships (i.e. the relationships connecting an interface with its
    requiring and/or providing classes) it seems that the dashed lines
    announced in the text are gone in the figure.

    Reading the text the arrow pointing from TheftAlarm to ISensor should
    be
    realized as a dependency relationship and also the arrow pointing from
    ProximitySensor to ISensor. The latter is currently realized as a
    generalization arrow which is solely a valid presentation option for
    relationships connecting a Component and their Interface. According to
    the spec the arrow should be a dependency relationship that is
    stereotyped with realizes having ProximitySensor as client and Isensor
    as supplier.

    Or am I just misreading the spec?
    Any help and clarification appreciated

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Resolved by the resolution to issue 6069

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency concerning VisibilityKind - UML2 Superstructure

  • Key: UML14-421
  • Legacy Issue Number: 6515
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    Just a minor point, but still annoying to the reader ...

    The superstructure lists at page 16 all four possible types (i.e.
    "public", "private", "protected", and "package") but within the
    Infrastructure document (page 73) solely "public" and "private" are
    mentioned. The same for the enumeration example at page 116.

    Also it would be helpful to shift the visual presentation options
    ("+",
    "-", "#", and "~") for VisibilityKind from the chapter describing
    attributes (Superstructure p. 41) to more general description at page
    16
    which is multiple referenced from other parts of the spec.

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see abov e

  • Updated: Fri, 6 Mar 2015 20:58 GMT

does "is not instantiable" imply "isAbstract"? - UML2 Superstructure

  • Key: UML14-424
  • Legacy Issue Number: 6518
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    Just a minor graphical typo: Page 487 of the superstructure document
    specifies an InformationItem as not instanciable. But the classifiers
    taxonomy provided at page E-565 of the same document depicts it as
    instanciable class.

    I guess it should be italicized.

    Or am I just misinterpreting the sentence "is not instanciable"? I
    guessed it implies "isAbstract == true".

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity nodes and Stereotypes - UML2 Superstructure issue

  • Key: UML14-425
  • Legacy Issue Number: 6519
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    The new Profiles package and the respective Stereotypes still seem
    very
    "class-oriented" when it comes to notation (maybee my fault?).
    Specifically,
    I have the following doubt:

    If I want to define a Stereotype for an activity node, e.g. a
    ForkNode, is
    the notation in the attached file correct?

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing actual arguments in submachines states

  • Key: UML14-432
  • Legacy Issue Number: 6605
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    A state machine, as a behavior, has formal parameters. When referencing it in a submachine state, we
    may need to pass actual arguments. However, nothing seems to be specified for that purpose in the
    UML2 metamodel. Is this a bug? If not, how can we send/retrieve data to/from a referenced submachine?

  • Reported: UML 1.5 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

/pages 485,487,495/mixed names for state machine diagram

  • Key: UML14-430
  • Legacy Issue Number: 6526
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The UML 1 terminology "StateChart" and another term "state diagram" also occurs.

    Appendix A of the Superstructure spec makes it clear that the UML 2 name is "state machine diagram"

    Recommendation: All occurrences of "statechart" and "state diagram" must be replaced with "state machine diagram"

  • Reported: UML 1.5 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguous example of a local action on a Lifeline in Figures 334, 335

  • Key: UML14-511
  • Legacy Issue Number: 6988
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 415-6 Figures 334,335 use a rectangular box with the text "DoSth" in it. The meaning of this symbols is not explained in the corresponding section, nor in Table 14 graphical nodes in Sequence Diagrams.
    In ITU Message Sequence Charts this would mean an informal action, local to the Lifeline.

    The syntax and semantics of local actions is the key issue in "executable sequence diagrams", and in proper alignment of semantics between Interactions, Activities and State Machines (and Actions).

    As a minimum, Figures 334, 335 need to be explained, and table 14 updated.
    It would be better to illustrate formal use of Actions.
    Ideally, Interactions will benefit from a data sublanguage based on Actions, in order to have a capability to fully specify flows of data between Lifelines:

    • message parameters (including composite values)
    • local attributes (storing data in Lifeliens; in data structures like lists, sets, tables, etc.)
    • identities of objects (input and output pins for actions)
    • actions (manipulations on data, access to data structures and composite values)
    • proper usage of data in guards and state invariants
    • proper usage of data in loop expressions
  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ambiguous definition of the scope of a break CombinedFragment

  • Key: UML14-510
  • Legacy Issue Number: 6987
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    page 410 mentions that "Break CombinedFragments must be global relative o the enclosing InteractionFragment".

    This is ambiguous and needs to be explained in more precise way, involving InteractionOccurences and Interaction Overview Diagrams. There were debates on the scope of a similar construct in the ITU language.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/inconsistent spelling for InteractionOperator

  • Key: UML14-509
  • Legacy Issue Number: 6986
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    The enum type name InteractionOperator is often misspelt (e.g. interactionOperator or interaction operator). It is also used inconsistently when referring to a particular operator, e.g. InteractionOperator alt.
    I suggest using a single typigraphic convention:
    InteractionOperator <italic> alt </italic>

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguous sentence and typo in description of EventOccurence

  • Key: UML14-502
  • Legacy Issue Number: 6979
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 416:

    The sequences of Eventoccurences are the meanings of Interactions. >>Messages are sent through either asynchronous signal sending or operation calls.<<
    Likewise they are >>>recieved<<< by >>Receptions or actions of consuption.<<

    typo needs to be corrected.
    highlighted parts need to be re-phrased and terminology aligned with the rest of the spec.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

graphic nodes for state invariant and continuation are not always distingui

  • Key: UML14-501
  • Legacy Issue Number: 6978
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    It is not possible to visually distinguish between a continuation (oval with a name) and a simple state invariant (also oval with a state name). Compare Figure 345 and 334.

    One possibility is to use guard syntax for state invariants.
    Another possibility is to use a different graphic for continuations

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguous semantics of isStatic

  • Key: UML14-498
  • Legacy Issue Number: 6974
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of isStatic = true is ambiguous for structural features
    declared on classifiers that have children. It is not defined whether
    this gives a single value for the classifier and all its descendents,
    or values for the classifier and each descendant separately.

  • Reported: XMI 2.0 — Mon, 9 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

self-activation notation in Sequence diagrams missing

  • Key: UML14-497
  • Legacy Issue Number: 6972
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    UMl 1.x sequence diagrams had a notation for self-activation, where the activation boxes (now called "execution occurrences" in UML 2) can be nested.

    E.g. UML 1.4, Notation, Sequence Diagrams, section 3.60.4, figure 3-56

    This notation is missing from UMl 2.0 Interactions chapter. No alternative notation is provided.

  • Reported: XMI 2.0 — Fri, 6 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/rationale subsections not informative

  • Key: UML14-505
  • Legacy Issue Number: 6982
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Most sections in chapter 14 on Interactions do not have a Rationale subsection, while the remaining few only contain the text "not applicable". This is not informative.
    I suggest to remove the Rationale subsections altogether.

    Pages 414 421 423 425 428 430 433

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Remove the empty “Rationale” sub-sections on pages 414, 421, 423, 425, 428, 430, 433.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/incorrect grammar for

  • Key: UML14-504
  • Legacy Issue Number: 6981
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Grammar for <state-info> at page 434 has a typo:
    <state-info>::=<region}

    {, <region> }*


    must be:
    <state-info>::=<region> {, <region> }

    *

    It is not clear, how to define <region-name> in Sequence Diagrams.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

word "execute" in definition of alternative CombinedFragment is ambiguous

  • Key: UML14-507
  • Legacy Issue Number: 6984
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 410 The word "execute" is used to describe the Alternative CombinedFragment i nthe context "operand will execute", etc. This word is ambiguous. I suggest changing it to "operand is chosen", etc.
    Or even the full description, like "the meaning of the InteractionOperator alt is a trace corresponding to only one of its operands".

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/Ambiguous description of state invariants

  • Key: UML14-506
  • Legacy Issue Number: 6983
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    page 433 has the following text: "A StateInvariant is a constraint on the state of a Lifeline. In this case we mean by "state" also the values of >>eventual attributes<< of the Lifeline".

    The term >>eventual attribute<< may be ambiguous.

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/incorrect text and table title for Table 19

  • Key: UML14-500
  • Legacy Issue Number: 6977
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 450 has the following text:
    "The graphic nodes that can be included into >>structural diagrams<< are shown in Table 19". Table 19 has the following title "Graphic nodes and paths included in >>sequence diagrams<<"

    The text needs to be changed into "The graphic nodes >>and paths<< that can be included into >>timing diagrams<< are shown in Table 19"

    Title of Table 19 should read "timing diagrams" instead of "sequence diagrams".

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/incorrect text before Table 14

  • Key: UML14-499
  • Legacy Issue Number: 6976
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    Page 436 has the following text:
    "The graphic nodel that can be included in >>structural diagrams<< are shown in Table 14."

    Table 14 is called "Graphic nodes included in sequence diagrams".

    Text needs to be changed into "sequence diagrams"

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of 6934, already resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Interactions/incorrect spelling of EventOccurence

  • Key: UML14-503
  • Legacy Issue Number: 6980
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    There are multiple places in the Interaction section, where class name EventOccurence is spelt incorrectly (usually as Eventoccurence).

    pages 403 410 411 416 417 419 420 422 427 429 431

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

text differs from metamodel for critical region InteractionOperator

  • Key: UML14-508
  • Legacy Issue Number: 6985
  • Status: closed  
  • Source: KDM Analytics ( Dr. Nikolai Mansourov)
  • Summary:

    On page 411 subsection for Critical Region mentions the InteractionOperator "critical", while the metamodel uses the enum "region".

  • Reported: XMI 2.0 — Mon, 16 Feb 2004 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / state machines / incorrect property redefinition

  • Key: UML14-466
  • Legacy Issue Number: 6871
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Constraints 9 and 10 in section 15.3.8 (page 470) refer to the owner property, but the owner property is redefined by Vertex::container, as shown in Figure 354 on page 457. Vertex::container should probably subset owner instead

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a subset of issue 6626 and is resolved by the same resolution.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / state machines / non-existent property reference

  • Key: UML14-465
  • Legacy Issue Number: 6870
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Constraints 4 and 6 in section 15.3.8 (page 470) refer to the non-existent stateMachine property on PseudoState (i.e. self.stateMachine).

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambuiguity in value pin evaluation

  • Key: UML14-462
  • Legacy Issue Number: 6865
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    When the value specification of a ValuePin is an expression, when is the
    expression evaluated?

  • Reported: UML 1.5 — Wed, 5 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 136, "BasicComponents",

  • Key: UML14-461
  • Legacy Issue Number: 6728
  • Status: closed  
  • Source: Object Management Group ( Nancy Siegel)
  • Summary:

    Superstructure, final adopted spec 03-08-02, page 136, "BasicComponents",
    contains this inscrutable phrase in the first paragraph:

    In addition, because a itself Class is a subtype of an
    EncapsulatedClassifier,...

    This should be fixed up in the final version, if you can
    figure out what you meant to say

  • Reported: UML 1.5 — Thu, 18 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / state machines / non-existent return type

  • Key: UML14-468
  • Legacy Issue Number: 6873
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The LCA operation, defined in section 15.3.12 (page 194) has a non-existent return type, CompositeState

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / state machines / misplaced operation definition

  • Key: UML14-467
  • Legacy Issue Number: 6872
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The containingStateMachine() operation is defined in the "Additional Operations" for StateMachine (see section 15.3.12, page 491) rather than in the corrsponding section(s) for the type(s) to which it applies.

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Activities / subsetting two properties

  • Key: UML14-458
  • Legacy Issue Number: 6680
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Activity::structuredNode subsets two properties, Activity::node and Actvity::group. This is among the few, if not the only, cases in the metamodel where a containment property subsets two superset containment properties. What is the semantic intent of this constraint? Should Activity::structuredNode be derived from the set of structured activity nodes in Activity::node and Actvity::group (StructuredActivityNode is both a group and a node)?

  • Reported: UML 1.5 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consistent Naming

  • Key: UML14-460
  • Legacy Issue Number: 6691
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    Associations with and end on the class Value Specification that subset owner have inconsistent names:

    ownerUpper

    ownerLower

    owningConstraint

    owningInstanceSpec

    owningParameter

    owningProperty

    owningSlot

    I would recommend renaming ownerUpper and ownerLower to owningUpper and owningLower to be consistent.

    All other properties that subset owner on other classes should be renamed consistently:

  • Reported: UML 1.5 — Thu, 11 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / state machines / oclIsKindOf arguments error

  • Key: UML14-464
  • Legacy Issue Number: 6869
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The syntax of the oclIsKindOf() is not correct in all occurrences. For example, constraints 4 and 6 in section 15.3.8 (page 470) use the syntax oclIsKindOf(self.stateMachine, ActivityGraph) whereas constraints 9 and 10 use the syntax owner.oclIsKindOf(Region).

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Signal

  • Key: UML14-459
  • Legacy Issue Number: 6690
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    13.3.21 suggests that Signal has no additional associations, and yet in
    Figure 316 it has ownedAttribute.

    I also note that in the mdl file Signal inherits from BehaviouredClassifier
    but I can't see that on Figure 316

    If it is a BehaviouredClassifier it seems odd that it has no concrete
    BehaviouralFeatures.

  • Reported: UML 1.5 — Wed, 10 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/State machines/pseudostate name consistency

  • Key: UML14-463
  • Legacy Issue Number: 6868
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The specification refers to a PseudoState type (page 469), but in the Rose model, it is named "Pseudostate".

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / use cases / invalid subsetting

  • Key: UML14-469
  • Legacy Issue Number: 6874
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UseCase::extensionPoint subsets Classifier::feature, but ExtensionPoint is not a specialization of Feature.

  • Reported: UML 1.5 — Wed, 31 Dec 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ad-03-04-01 Chap 3 p. 137/Composite structures: Connector multiplicity >2

  • Key: UML14-366
  • Legacy Issue Number: 6427
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: In the definition of Connector in Chapter 3, Composite Structures, p.
    137, the "end" Association's multiplicity is 2..*. It is not clear what the
    notation should be when the multiplicity is greater than 2.

    Recommendation: Define a notation for Connectors when multiplicity is
    greater than 2, or constrain the multiplicity to be 2..2.

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ad-03-04-01 Chap 2 p. 118 Figure 2-15/Components: Wiring notation

  • Key: UML14-365
  • Legacy Issue Number: 6426
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re Chapter 2, Components, Figure 2-15, p. 118: The figure caption
    says that the figure is an example of connector wiring, but the text
    directly below the caption says that the figure "may be used as a notation
    option for dependency based wiring." These two statements appear to be
    contradictory.

    Recommendation: To avoid having an ambiguous notation, specify that
    dependency notation should be used for dependency based wiring. (This
    recommendation may be affected by the resolution of the issue submitted
    about semantic distinctions between different ways to wire components
    together).

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ad-03-04-01 Chap 3 p. 137-138/Composite structures: Connector semantics

  • Key: UML14-367
  • Legacy Issue Number: 6428
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Re the definition of Connector in Chapter 3, Composite Structures,
    third paragraph of the Semantics section, which starts on p. 137 with "If
    the type of the connector is ommitted...": This paragraph is inpenetrable.

    Recommendation: Re-write the section around concrete examples for each
    point.

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Infras./Interactions/ execution occurrence should not be abstract

  • Key: UML14-364
  • Legacy Issue Number: 6425
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    ExecutionOccurrence should not be abstract, as it has no specializations

  • Reported: UML 1.5 — Tue, 4 Nov 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos

  • Key: UML14-219
  • Legacy Issue Number: 6162
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    On the Description of complete activities: :Edges support controlling
    token flow and be contained in interruptible regions."

    "It covers invocation nodes, control nodes (...)". I believe it should
    read "It covers executable nodes, control nodes (...)"

    "A control flow is an edge starts an activity node after the previous
    one is finished."

    "The input parameter must be the same as or a supertype the type of
    object token coming along the incoming edge."

    "This is equivalent interposing a CentralBufferNode between the initial
    node and its outgoing edges."

    "A loop node is a costructured activity node that represents a loop with
    setup, test, and body sections." page 331, Table 2 caption should be
    "Graphic paths (...)" instead of "Graphic nodes (...)". Table 3 caption
    should also be made more specific.

    Add constraint numbers to ExceptionHandler.

    In ActivityNode, the entry for interuptibleRegion should be under a
    heading Associations (CompleteActivities).

    In semantics of ActivityEdge move sentence about guards from
    (IntermediateActivities) to basic.

    "in invoked" => "is invoked"

    Constraint 5 for ActivityParameterNode should read: "Activity parameter
    object nodes with no outgoing edges and one or more incoming edges must
    have a parameter with out, inout, or return direction."

    Text should list mustIsoloate under StructuredActivityNode, not
    ActivtyNode.

    Local pre/postcondition semantics: "must" => should.

    Local pre/postcondition semantics: "locaprecondition" =>
    "localPrecondition".

    Semantics of streaming parameter, third bullet/execution rule: replace
    "activity" with "behavior". Also in second bullet, remove "for" from
    "that is, for all". Also add analogous sentence after "not just at the
    beginning" for outputs.

    Search on "wil exist", replace with "will exist".

    Search on "(str-adv)" and remove.

    In ConditionalNode: "the modeler asserts that at least one true section
    will yield a true value." Should be "test section".

    IsReadOnly is in basic activities in the metamodel diagrams, but should
    be in complete, according to the attribute list on Activities.

    In ReclassifyObjectAction and elsewhere, replace "error" with "undefined
    semantics".

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.4.1 Multiplicity

  • Key: UML14-225
  • Legacy Issue Number: 6169
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Presentation Options

    The BNF for the syntax for the multiplicity string seems to have a couple of things wrong. First, the 'lower' is specified as an 'integer' whereas it is specified to be unlimited natural from Notation part. Second, it does not allow for multiplicities to include a uniqueness designation. The first sentence defining the 'multiplicity' non-terminal only contains <order_designator> and does not include <uniqueness-designator>. Also, if both a uniqueness designation and order designation are specified the BNF should probably specify a delimiter (as in Figure 11). Perhaps the following:

    multiplicity ::= <multiplicity_range> [ '{' <order_designator> | <uniqueness_designator> |

    {<order_designator> ',' <uniqueness_designator>}

    '}' ]

    In addition, the multiplicity specification for Purchase is different between Figure 11 and 12, the former uses a comma to separate ordered and unique and the latter seems to be missing the comma.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.3.1 ElementImport

  • Key: UML14-224
  • Legacy Issue Number: 6168
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    The next to last sentence states: "A member may be further imported by other namespaces using element or member imports." What are member imports? Should this be package imports?

    Notation

    The difference between public import using <<import>> and private import using <<access>> is not explicitly stated, nor is an example of <<access>> given in the Examples part. My understanding is that <<import>> adds an element to importing namespace using public visibility, i.e., the imported element can be accessed without qualification within the importing namespace and any namespace the importing namespace encloses. My understanding of <<access>> is that it adds an element to the importing namespace using private visibility which does not allow the imported element to be further imported. Does the last sentence of the Description, "It is also possible to control whether the imported element can be further imported", refer to <<access>> element import?

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify that profiles can contain model libraries

  • Key: UML14-218
  • Legacy Issue Number: 6161
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The definition of <<modelLibrary>> says it is:

    A package that contains model elements which are intended
    to be reused by other packages. A model library differs from
    a profile in that a model library does not extend the
    metamodel using stereotypes and tagged definitions. A
    model library is analogous to a class library in some
    programming languages.

    However, profiles can contain model libraries. UML 1.x has an explicit
    dependency to model this (called <<modelLibrary>> also). It should be
    clarified that in 2.0 this is done by including model library pacakages
    in profile packages. The above text should be clarified. Suggestion:

    A package that contains model elements which are intended to be
    reused by other packages. A model library can be contained in a
    profile package, but the classes in a model library are not
    stereotypes stereotypes and tagged definitions extending the
    metamodel. A model library is analogous to a class library in some
    programming languages.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for anonymous instance

  • Key: UML14-217
  • Legacy Issue Number: 6160
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify the notation for anonymous instance

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Superstructure 03-08-02: Loop node notation missing

  • Key: UML14-221
  • Legacy Issue Number: 6165
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The notation for the loop node on page 341 is missing.
    I saw the notation in an older version of the specification

  • Reported: UML 1.5 — Tue, 2 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Same as Issue 6071

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Superstructure: 03-08-02 -- typos

  • Key: UML14-220
  • Legacy Issue Number: 6164
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    p. 32, 2nd/3rd semantics paragraph
    "element" instead of "ele-ment" (twice)
    "qualified" instead of "qual-ified"

    p.38, presentation options:
    "identifies" instead of "identi-fies"

    p. 108, fig. 53:
    "<<dependencyName>>" instead of "<<dependecyName>>"

    p. 109, fig. 54:
    "An example of a instantiate dependency" instead of "An example of a instantiatedependency"

    p. 110, Description:
    First and second paragraph are the same.

    p. 114, 3rd line:
    "...mapping to a property of..." instead of "...mapping to a propertyof..."

    p. 117, fig. 65:
    Class name is "DoorBell" instead of "oorBell"

    p. 137, last paragraph, first line:
    "...by a component that offers equivalent..." instead of "...by a component that offers that offers equivalent..."

    p. 170, first line:
    "...while the figure on the right..." instead of "...while the figure onj the right..."

    p. 172, semantics paragraph:
    Reference to ""StructuredClassifier" on page 171" seems to be wrong (twice)

    p. 325, stream description:
    "..., in order of..." instead of "..., in oprder of..."

    p. 403, last but one paragraph:
    "...UML language..." instead of "...UML languatge..."

    p. 537, PrimitiveTypes, first paragraph:
    "These include primitive types..." instead of "These includes prmitive types..."

    p. 587, paragraph below fig. 460, last line:
    "..., the heading is..." instead of "..., the headning is..."

  • Reported: UML 1.5 — Tue, 2 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for attributes

  • Key: UML14-215
  • Legacy Issue Number: 6158
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The notation for attributes is given in Kernel::Classifier, but the
    abstract syntax for classifiers have no features

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property string undefined

  • Key: UML14-214
  • Legacy Issue Number: 6157
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The BNF for property-string is missing in Property and Operation. Eg,
    how are the properties delimited (a comma?)? How are property values
    shown (property-name property-value)?

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InstanceSpecification

  • Key: UML14-226
  • Legacy Issue Number: 6170
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Notation

    The first paragraph indicates that both the instance name and the classifier can be omitted from an instance specification. This informal description leads open the possibility of specifying just the colon with neither the instance name nor the classifier. Is this what is intended? BNF should be used to clarify.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a more detailed version of Issue 6160.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Instantiates stereotype

  • Key: UML14-216
  • Legacy Issue Number: 6159
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 54 (An example of a instantiatedependency) shows the instantiates
    stereotype/keyword being used as an instance-of relation, whereas the
    entry for the instantiates stereotype in the standard stereotypes table
    says "A usage dependency among classifiers indicating that the
    operations on the client create instances of the supplier".

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No notation defined for suppressing attributes or operations

  • Key: UML14-223
  • Legacy Issue Number: 6167
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    There is a mention that attributes and operations may be supressed for clarity, but no mention as to how. In UML 1.4 this was shown by including '...' in the compartment, to indicate that there was more information. Is this still viable?

  • Reported: UML 1.5 — Tue, 2 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation mismatch for the realization dependency

  • Key: UML14-222
  • Legacy Issue Number: 6166
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The notation for the realization dependency is described on p. 110:
    "A Realization dependency is shown as a dependency with the keyword <<realize>>
    attached to it."

    On p. 130 the Realization dependency is shown as a dashed line with
    a hollow triangle as an arrowhead.

  • Reported: UML 1.5 — Tue, 2 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter set corrections 3

  • Key: UML14-177
  • Legacy Issue Number: 6117
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Examples are incorrect in implying that parameter sets can replace
    merges. They are separate parameters, not a single input as would come
    from a merge.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Streaming

  • Key: UML14-181
  • Legacy Issue Number: 6121
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Separate streaming from optionality and multiple tokens being input or
    output during action execution.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter set corrections 6

  • Key: UML14-180
  • Legacy Issue Number: 6120
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that semantics for paramater sets on operations is the same as
    for behaviors.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter set corrections 5

  • Key: UML14-179
  • Legacy Issue Number: 6119
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Rule 2 for parameter sets conflicts with nonoptional inputs: "If a
    behavior has input parameters that are in a parameter set, then any
    inputs that are not in a parameter set must be streaming. Same for
    output parameters." Just disallow parameters not in parameter sets in
    the presence of parameter sets. Since parameters be in more than one
    set, there is no need for parameters out of a set in this case

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter set corrections 4

  • Key: UML14-178
  • Legacy Issue Number: 6118
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    How are parameter sets notated in classes? Parameter sets can be
    referred to by their names.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Outgoing edges of initial nodes

  • Key: UML14-332
  • Legacy Issue Number: 6358
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint on initial nodes that its outgoing edges can only be
    control.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Port is a Property in XMI

  • Key: UML14-331
  • Legacy Issue Number: 6357
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Port is a Property in the XMI, but not in the spec. This is because in
    MDL file Port is a Property, but it is only visible in the object
    browser. It was only hidden from the diagrams instead of being deleted.
    U2P internal history live on. Search on name="Port"

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of 6281.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InformationFlow realization

  • Key: UML14-326
  • Legacy Issue Number: 6351
  • Status: closed  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    InformationFlow realization should be to more than relationships. It
    could be to any set of elements

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Dependency multiplicity to CollaborationOccurrence

  • Key: UML14-325
  • Legacy Issue Number: 6350
  • Status: closed  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    Figure 100 says Dependency must be in exactly one
    CollaborationOccurrence. Presumably there are dependencies that are not
    in collaboration occurrences

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    The multiplicity of the end at CollaborationOccurrence should be changed to “0..1”.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ports as properties

  • Key: UML14-330
  • Legacy Issue Number: 6356
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Roger Burkhart)
  • Summary:

    Ports should be properties (better yet parts), to participate in
    composite association when desired.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

partWithPort without ports

  • Key: UML14-329
  • Legacy Issue Number: 6355
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Seems like partWithPort should be able to connect parts of parts without
    needing to use ports. Just use partWithPort to part, connectorEnd to
    part of part. Loosen constraint 2 of ConnectorEnd to allow all parts

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of 6251.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Control pins

  • Key: UML14-323
  • Legacy Issue Number: 6348
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    There should be a special kind of pin for control tokens. This will
    allow parameter sets to be used with control, for example. Also
    resolves issue of where control is bufferred when it is direceted at a
    join. Can be implemented as a pin that has no parameter, by making them
    the last in the ordering of pins, so no parameter corresponds to them.
    This is also a request of the SysML team.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profiles in fixed repositories

  • Key: UML14-322
  • Legacy Issue Number: 6347
  • Status: closed  
  • Source: INCOSE ( Mr. Sanford A. Friedenthal)
  • Summary:

    Do profiles working for fixed repositories in UML 2? My understanding
    is that they are at M3 now, so they wouldn't. If that's the case, then
    what is their purpose? The other feature of dynamically changing
    metaclasses is something a repository could provide if it was useful,
    instead of using stereotypes.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association end names and part types

  • Key: UML14-328
  • Legacy Issue Number: 6354
  • Status: closed  
  • Source: MITRE ( Dr. Bruce Powel Douglass)
  • Summary:

    In the notation of composite structure, are association end names
    allowed to be presented on connectors? If so, how are they
    distinguished from port type?

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Deployment location

  • Key: UML14-327
  • Legacy Issue Number: 6352
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In Deployments, the spec uses "location" as an association end name, but
    "node" in MDL file.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Guards on initial nodes

  • Key: UML14-333
  • Legacy Issue Number: 6359
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Carify whether guards can be used at initial nodes.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Control at joins

  • Key: UML14-324
  • Legacy Issue Number: 6349
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Where are control nodes buffered when directing control to a join?

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.11.2 Association

  • Key: UML14-228
  • Legacy Issue Number: 6172
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Notation

    I cannot find where the hollow diamond notation for aggregation is specified. It is shown in Table 5 but specified in the body. Is this now called 'shared' aggregation?

    The second to last sentence states;" The notation for an attribute can be applied to a navigable association end name." By full notation is it meant the full attribute syntax specified in section 7.81. Classifier under Notation part can be used? This would allow redundant specification of multiplicity. Should it be stated that if attribute notation is used, then other types of association end adornments cannot be used?

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.10.1 Operation

  • Key: UML14-227
  • Legacy Issue Number: 6171
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Semantics

    The following is stated: "An operation may be redefined in a specialization of the featured classifier. This redefinition may specialize the types of formal parameters or return results, add new preconditions or postconditions, and new raised exceptions, or otherwise refine the specification of the operation." This statement is not correct if the 'isSubstitutable' attribute of the Generalization is true. To achieve substitutability the parameter types must either be invariant or contra-variant (generalized) rather than specialized. Clearly this statement reflects the type safety restrictions of programming languages, but overriding in actual programming languages does not guarantee substitutability. Similarly, the preconditions of the redefined operation in the specialized class can only be weakened (i.e., removed) not strengthened (i.e., added).

    Notation

    BNF should be used for specifying the syntax of an operation string.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::IntermediateActivities/redundant merge error

  • Key: UML14-234
  • Legacy Issue Number: 6179
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Redundant merge error: Nodes merges Kernel directly, and indirectly through Artifacts, Dependencies, Kernel

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

BehaviorStateMachines/missing owningState end name

  • Key: UML14-233
  • Legacy Issue Number: 6178
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package BehaviorStateMachines has association :State[0..1] c-> stateInvariant: Kernel::Constraint[0..1] is missing the owningState end name as defined in ProtocolStateMachines owningState:State[0..1] c-> stateInvariant: Kernel::Constraint[0..1]

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Kernel::DataTypes/missing renames

  • Key: UML14-238
  • Legacy Issue Number: 6183
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Kernel/DataTypes has association enumeration:Enumeration <--> literal:EnumerationLiteral with no renames redefinition while its ownedLiteral:EnumerationLiteral every where else.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AuxiliaryConstructs::Templates::Operation/extra space

  • Key: UML14-237
  • Legacy Issue Number: 6182
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML::AuxiliaryConstructs::Templates::Operation had a space at the end of the class name. This causes some matching algorithms to fail

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::BasicBehaviors/package merge issue

  • Key: UML14-232
  • Legacy Issue Number: 6177
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package BasicBehaviors merges Kernel, but has associations like :Behavior[0..1] -->parameter:Kernel::Parameter[0..*] instead of :Behavior[0..1] -->parameter:Parameter[0..*] implying the parameter property type after the merge is to the Kernel::Parameter superclass, not the Parameter that was merged into BasicBehaviors. Is this the intention? Or should BasicBehaviors have redefined Parameter too? Looks like there are a number of these in the model where the type in the merging package was dragged into the class diagram from the merged package instead of creating a new merging type. If these types should be the merging type, then the model should be corrected. Or there needs to be clarification in package merge that the merging type is always used, regardless of what is specified in the model

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.15.3 Interface

  • Key: UML14-231
  • Legacy Issue Number: 6175
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Presentation Option

    In Figure 62 the relationship between TheftAlarm and ISensor should be a dependency relationship (dashed arrow) with the <<use>> stereotype rather than a unidirectional association. The relationship between ProximitySensor and ISensor should be an implementation relationship (probably same as realization consisting of dashed arrow with open arrowhead) rather than a generalization relationship (Table 5).

    Figure 63 shows attribute visibility notation for non-navigable association ends. The second from last sentence in section 7.11.2 Association under the Notation part indicates that attribute notation can only be applied to a navigable association end name.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Communications/redundant merge error

  • Key: UML14-235
  • Legacy Issue Number: 6180
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Redundant merge error: IntermediateActivities should not merge both StructuredActivities and BasicActivities as StructuredActivities already merges BasicActivities. IntermediateActivities both merges BasicActivities and explicitly references types in it (:Clause[0..1] -> decider:BasicActivities::OutputPin[0..1]). This makes resolving the type reference for association end named decider ambiguous

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of 7436

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.14.1 Abstraction

  • Key: UML14-229
  • Legacy Issue Number: 6173
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    Examples

    The dependency arrow should be reversed in Figure 52. The client should be the element that is more developed (i.e., Employee Record) and supplier should be the element that is the base for refinement (i.e., Employee). This is analogous to realization where the supplier is the specification and the client the implementation.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Nodes/redundant merge error

  • Key: UML14-236
  • Legacy Issue Number: 6181
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Redundant merge error: Nodes merges Kernel directly, and indirectly through Artifacts, Dependencies, Kernel

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.14.6 Realization

  • Key: UML14-230
  • Legacy Issue Number: 6174
  • Status: closed  
  • Source: SSA ( Art Culbertson)
  • Summary:

    The notation of a dashed arrow with hollow arrow head at the supplier is not mentioned. However, Table 5 shows this notation.

  • Reported: UML 1.5 — Wed, 3 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pins on structured nodes 2

  • Key: UML14-195
  • Legacy Issue Number: 6136
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Is it really intended that all StructuredActivityNode's have pins, such
    as ExpansionRegions?

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pins on structured nodes 1

  • Key: UML14-194
  • Legacy Issue Number: 6135
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 193 - Structured nodes (CompleteStructuredActivities) shows
    StructuredActivityNode, LoopNode, and ConditionalNode inheriting from
    Action, but LoopNode and ConditionalNode already inherit from
    StructuredActivityNode (Figure 192 - Structured nodes).

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Action packaging

  • Key: UML14-203
  • Legacy Issue Number: 6145
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Structured actions should depend on structured activities for
    variables. In general, actions should be in smaller packages to

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

BroadcastSignalAction

  • Key: UML14-202
  • Legacy Issue Number: 6144
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify whether BroadcastSignalAction returns after the signals are sent
    or after they are received.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Time spec text

  • Key: UML14-196
  • Legacy Issue Number: 6138
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The overview of Activity says: "The UML does not provide for the
    specification of a time metric, but only describes sequences of
    executions.", but UML does have a time model that can be applied to
    activities. Remove sentence.

    It also says: "Execution is not instantaneous, but takes place over a
    period of time." Seems like activities should be agnostic on this.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update actions for isUnique

  • Key: UML14-200
  • Legacy Issue Number: 6142
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Update structural feature and associations actions for isUnique. For
    example, the semantics description of the class
    AddStructuralFeatureValueAction says: "Reinserting an existing value at
    a new position moves the value to that position (this works because
    structural feature values are sets)".

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExpansionRegion

  • Key: UML14-193
  • Legacy Issue Number: 6134
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Why does ExpansionRegion have its own input/output metaassociations,
    rather than the ones on actions? (BTW, these associations are
    misnomers, they are not just elements). ExpansionRegion inherites pins
    from StructuredActivityNode in complete activities

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Partition semantics

  • Key: UML14-197
  • Legacy Issue Number: 6139
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that behaviors outside of actions, such as on decision nodes,
    guards, etc, that are contained in a partition, have the same semantics
    as behaviors invoked by actions.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity frame and parameter nodes 1

  • Key: UML14-198
  • Legacy Issue Number: 6140
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    An object node with no input or no output notation should map to an
    ActivityParameterNode, so that frame isn't required.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

actions on properties that are association ends

  • Key: UML14-201
  • Legacy Issue Number: 6143
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    Clarify semantics for (or lack thereof) for modifying properties that
    are association ends

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity frame and parameter nodes 2

  • Key: UML14-199
  • Legacy Issue Number: 6141
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that parameter nodes can overlap frame as defined in the
    diagram appendix.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Flows across SAN boundaries

  • Key: UML14-347
  • Legacy Issue Number: 6375
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    Clarify that control and object flows can cross SructuredActivityNode
    boundaries (we need this).

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Initial nodes in structured actions

  • Key: UML14-346
  • Legacy Issue Number: 6374
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    Clarify whether structured actions can have initial nodes

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameters in Features and Common Behavior

  • Key: UML14-345
  • Legacy Issue Number: 6373
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The Features model (Figure 28) shows BehavioralFeature with the
    parameter association presumably derived from formalParameter and
    returnResult, whereas the Common Behavior model (Figure 312) shows
    Behavior formalParameter and returnResult derived, derived from the
    parameter association. These parameter models for operations and
    behavior should be the same.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify join specs referencing control flow edges

  • Key: UML14-342
  • Legacy Issue Number: 6369
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that join specs reference to control flow edge names as being
    boolean.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Combining joined tokens

  • Key: UML14-341
  • Legacy Issue Number: 6367
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Join nodes should have an option to combine tokens with identical
    values. For example, when joining flows created by a fork duplicating
    tokens.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AcceptCallAction in SAN

  • Key: UML14-349
  • Legacy Issue Number: 6377
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    What is the behavior when a SAN contains an AcceptCallAction with no
    incoming control links. Is the accept only enabled once when the SAN
    receives a control token, or it it enabled for the lifetime of the SAN?
    Either way, how do you model the other behavior.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Terminating a SAN

  • Key: UML14-348
  • Legacy Issue Number: 6376
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    How do you end a SructuredActivityNode in the way that an
    ActivityFinalNode ends an Activity?

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Join example

  • Key: UML14-344
  • Legacy Issue Number: 6371
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The example for join, Figure 263, doesn't make sense from a domain point
    of view. Orders aren't accepted and shipped concurrently.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify join rules

  • Key: UML14-343
  • Legacy Issue Number: 6370
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that a successful non-and join spec still combines the incoming
    tokens by the same rules as "and".

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Side effects of value specifications

  • Key: UML14-336
  • Legacy Issue Number: 6362
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify whether guards and other value specification can have side
    effects

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity final clarification

  • Key: UML14-335
  • Legacy Issue Number: 6361
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify the effect of an activity final node when only some of the
    non-streaming output parameters have tokens.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ReadSelfAction with no host

  • Key: UML14-339
  • Legacy Issue Number: 6365
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Extend ReadSelfAction to return behavior object if there is no host.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Decision behaviors on control tokens

  • Key: UML14-338
  • Legacy Issue Number: 6364
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that decision behaviors work on control tokens. Suggest that
    control tokens invoke behaviors with no input parameters. Behavior can
    use ReadSelfAction to access host if necessary

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify ReadSelfAction in activity behaviors

  • Key: UML14-340
  • Legacy Issue Number: 6366
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify the semantics of ReadSelfAction for behaviors used in activities
    (decision input, etc).

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Guard evaluation

  • Key: UML14-337
  • Legacy Issue Number: 6363
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that not all the guards are required to be evaluated, only that
    one succeed (expand on race condition sentence).

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Caption typo

  • Key: UML14-334
  • Legacy Issue Number: 6360
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Caption to Figure 251 (Final node example) should be flow final
    example

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Confusion regarding XMI for use of stereotypes

  • Key: UML14-291
  • Legacy Issue Number: 6242
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    I've been looking at Figure 458 and can't quite get it, but don't know if
    it's an issue -the problem I have is that the instance model seems to mix
    meta-levels; we have an instance of the UML (meta) class, Class and an
    instance of the user stereotype(class) Clock - yet on the diagram this jump
    in metalevels is not mentioned. I can't see how this can be the true
    Instance model. Could someone provide me with the XMI fragment that this
    figure is intended to produce - I think that this would give me more of a
    clue about what's going on.

  • Reported: UML 1.5 — Fri, 12 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Actors that are outside and inside the system

  • Key: UML14-290
  • Legacy Issue Number: 6241
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    There is a fundamental problem with the Actor element.
    It is defined as
    "An Actor models a type of role played by an entity that interacts with the subject
    (e.g., by exchanging signals and data), but which is external to the subject."

    Now put your modeling focus on a subsystem. Use cases of that subsystem can have
    external subsystems as actors. Let A be an actor of a use case. A is an external subsystem.

    But now put your modeling focus on the whole system. Now A isn't an actor anymore, but
    a subsystem. The same "real world" entity is defined twice in my model: as an actor and
    as a subsystem. It depends on my modeling focus, but that's more a topic of the view and
    not of the model.

    The problem is common in business process modeling. In the BPM view a employee is a
    stereotyped class, e.g. business worker. In the system analysis view (for a system
    that should support parts of my business processes) the employee is an actor of the system.

    We solved that problem by not using actors, but stereotyped classes. But I'm not feel
    happy with that solution, because it just a workaround.

    Any ideas?

  • Reported: UML 1.5 — Tue, 9 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 super/pgs.17 + 598/"topLevel"

  • Key: UML14-289
  • Legacy Issue Number: 6240
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    Subject: topLevel standard stereotype is referred to on pg 17 and retired on pg 598.

  • Reported: UML 1.5 — Tue, 16 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Remove the complete entry for “top level” in the Glossary.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Actor

  • Key: UML14-288
  • Legacy Issue Number: 6239
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    Three sentences define actor differently. One of these (or a fourth) shold be chosen.

  • Reported: UML 1.5 — Tue, 16 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicity of Regions owning Transitions

  • Key: UML14-287
  • Legacy Issue Number: 6238
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    The multiplicity of Regions owning Transitions shall be changed from 0..1 to 1, as Transitions can only be owned by Regions

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

State list

  • Key: UML14-286
  • Legacy Issue Number: 6237
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    Statelist has to be done differently, as transitions outgoing from a junction point cannot have triggers

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 serious layout problems with activity diagrams

  • Key: UML14-285
  • Legacy Issue Number: 6236
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    In UML 1.x you can draw several outgoing transitions from an action state
    with guard conditions. That's semantically equivalent to a decision.
    The semantic changes in UML 2.0. Several outgoing edges from an action node
    are semantically equivalent to a fork. The new semantic is absolutely ok,
    but I have problems with the notation.

    Especially in business process modelling it is common that a decision
    follows each action. Now I have to draw a decision node after each action
    node. That blows up the diagrams and makes them hard to read. With UML 2 I
    need two pages for a diagram that fits on half a page with UML 1.x.

    Is it possible to use a notational shortcut to keep the diagrams small and
    readable?
    I heard from several people that they think about workarounds for that problem.
    But I think that's the wrong way.

    Any solutions?

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Stereotypes for Actions

  • Key: UML14-284
  • Legacy Issue Number: 6235
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I just recognized a change in UML 2.0 from UML 1.x.
    Stereotypes can only be attached to elements derived
    from Class. In UML 1.x a stereotype can be attached to
    elements based on ModelElement.

    Does that mean that I cannot define a stereotype for Actions?

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is the same issue as issue 6199

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Superstructure: 03-08-02 / Typos

  • Key: UML14-283
  • Legacy Issue Number: 6234
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    Some more typos:

    p. 191, figure 134
    Figure 134 does not show a deployment specification.

    p. 194, Manifestation
    "A manifestation is the concrete physical unit of one..." instead of "A manifestation is the concrete physical of one..."

    p. 200, table 9
    The manifestation relationship is shown with a solid line. Notation definition on p. 195 specifies a dashed line.

    p. 228, Presentation Option, last line
    "...than the operation name,..." instead of "...than the operaiton name,..."

    p. 233, CreateObjectAction
    The definition is not quite clear. The first constraint says "The classifier cannot be abstract". But
    the description says "The semantics is undefined for creating objects from abstract classifiers."
    The last one means that abstract classifiers are allowed, but the semantic is undefined. So the constraint
    is wrong. On the other hand if the constraint is correct, the sentence about the abstract classifier
    is suerfluous.

    p. 259, TestIdentifyAction, first line
    "...are identical objects." instead of "...are identical objects.t"

    p.286, 3rd paragraph from bottom
    "An activity with a classifier context..." instead of "An activity with a a classifier context..."

    p. 304, Semantics, first line
    "When an activity is invoked,.." instead of "When an activity in invoked,..."

    p. 355, Examples
    "The diagram on the left uses a decision diamond; the one on the left uses parameter sets
    to express the same notion".
    Text refers twice to the diagram on the left. The figure 279 does not show what the text describes.

    p. 473, below figure 373
    "A choice pseudostate is shown as a diamond-shape symbol as exemplified by Figure 374".
    Fig. 374 does not show a diamond-shape symbol, but the circle notation.

    p. 497, Rationale below figure 394
    "The rationale for statemachine extension..." instead of "The rationale for statemachie extension..."

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Compliance points/confusing and redundant

  • Key: UML14-282
  • Legacy Issue Number: 6233
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The idea of the fine-grain compliance points that allow different ways of configuring the UML standard lead to all kinds of practical problems with very little gain:

    There is no facility provided to indicate which particular compliance points are assumed in a given model – hence two standard-compliant implementations based on different compliance point subsets may not be able to exchange models. Furthermore, with the plethora of different combinations of compliance points, this is a very likely situation, practically a certainty. This makes something of a mockery of the whole notion of standard.
    The extreme granularity of the compliance points combined with the package merge mechanism results in a very complex API for model repositories. For instance, there are over 30 separate variations of Classifier. A programmer wanting to extract model information from a model repository will be required to know precisely which particular variant is desired. This is likely to lead to a lot of confusion and programming errors. Furthermore, as has been pointed out in several different issue reports, there are problems when trying to realize this using traditional and widespread programming languages such as C++ or Java.
    Given that there is the concept of "partial" compliance to a given level, the whole fine-grained compliance scheme seems redundant.

    This needs to be simplified significantly. One possibility is to define a small number of pre-defined compliance levels (maybe even just one?).

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of issue 6248.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.81/semantics of subsetting-specialization-redefinition

  • Key: UML14-281
  • Legacy Issue Number: 6232
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 81: Association: subsetting, generalization, redefining: Just what is the precise difference among subsetting, specialization, and redefining? The explanations are vague and don't offer distinctions or examples showing the difference. They seem to do the same thing. If there is no semantic difference, why do we have them all? This is an important thing to clarify, preferably with examples for each of the possibilities. Other people are confused about this too.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.379/anyTrigger clarifications

  • Key: UML14-280
  • Legacy Issue Number: 6231
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 379: AnyTrigger: It is obviously illegal to have 2 anyTriggers in the same state (but the specification should say that, which it doesn't). What about multiple anyTriggers in nested states? The specification is silent on this point. It should probably be allowed with the most specific state taking precedence. This is a useful situation. Need to define it in any case.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg. 556/notation for template binding inconsistency

  • Key: UML14-279
  • Legacy Issue Number: 6230
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 556: Classifier (in templates): Bound collaboration (Fig. 435): Separator should be arrow (->) not backslash () to be consistent with text on TemplateBinding on pg. 548

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg. 471/choice pseudostate notation

  • Key: UML14-278
  • Legacy Issue Number: 6229
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 471: PseudoState/Semanctics Choice – The text says the symbol is a diamond but the figure 374 on pg. 473 shows a circle. Probably an error in the figure but make them consistent. In UML1 it is a diamond so a circle would be a bad idea

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.471/unclear terminate state semantics

  • Key: UML14-277
  • Legacy Issue Number: 6228
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 471: PseudoStatel/Semancis terminate – What are the semantics of terminate? Are exit actions performed (to return to the root state) or is the object just killed outright with no clear up? Probably need a SVP. In any case, the wording is too spare. It isn't very useful as it stands with vague semantics.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.519/multiplicity semantics of use case associations

  • Key: UML14-276
  • Legacy Issue Number: 6227
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 519: UseCase – semantics of multiplicity on Actor-UseCase association not explained. State what the multiplicity means and show an example

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Question about InterruptibleActivityRegion

  • Key: UML14-295
  • Legacy Issue Number: 6247
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I am not sure about the semantics of the InterruptibleActivityRegion.

    If I have such a region with an Accept Event Action to wait for an
    event to terminate the region, what happens if there is no token
    flow within the region, but the event occurs?

    I think the Accept Event Action is active. I did not found another
    statement in the specification. That means that all outgoing
    egdes get tokens after event occurence.

    Normally that is not the semantic the modeler wants. Nothing should happen
    if there is no token flow in the activity region.

  • Reported: UML 1.5 — Thu, 11 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

fig 141 p205 and 7.13.2 p101 / just what sort of relationship is <

  • Key: UML14-294
  • Legacy Issue Number: 6246
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    medium significance

    The text for Figure 141 says "The package dependencies of the Actions chapter are shown in Figure 141." Then the diagram shows IntermediateActivities packages as dependent on StructuredActivities.

    This conflicts with the text for fig 141, the text of section 12.1 page 265 says "The Intermediate and structured levels are orthogonal. Either can be used without the other or both can be used to support modeling that includes both concurrency and structured control constructs."

    This statement implies that there is NO dependency between StructuredActivities and IntermediateActivities, none in either direction. Yet the Figure 175 says otherwise

    Suggested resolution:

    The root of this problem may be:

    a. Merge is intuitively a symmetrical relationship, whereas it is defined in UML2 as directed.
    b. In 7.13.1 on p 99, the description of the fundamental modeling element Package says "...a package can be merged with other packages." It is noteworthy that only one other package-to-package relationship was thought important enough to call out in the text introducing Package, and that is the containment ownership of nested packages. This prominence suggests that the meaning of 7.13.1 "... a package can be merged with other packages" is that "Any package can be merged wih any other package." or more exactly, a PackageMerge is valid between any two packages, without restriction.
    c. Merge is defined in a way that makes it appear to be a dynamic function that takes two packages and produces a new package which is not the same as either of the two. This means it is not a relationship, but some kind of meta-operation, a very interesting but hairy concept.

  • Reported: UML 1.5 — Wed, 10 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Metamodel for applying a stereotype

  • Key: UML14-293
  • Legacy Issue Number: 6244
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What part of the metamodel is for applying a stereotype to a single
    element in a user model? I can only find the appliedProfile association
    for applying profiles to packages. Figure 458 shows a repository model
    for it, but doesn't give the name of the relation between a class and
    the Clock stereotype.

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the solution to issue 6347.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association not affecting ends

  • Key: UML14-292
  • Legacy Issue Number: 6243
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Restore UML 1.x capability of modeling associations without modifying
    the end types. This is needed for database modeling, for profiles to be
    used with fixed-schema repositories, and is the differentiator of UML
    over OWL, etc.

  • Reported: UML 1.5 — Mon, 8 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.427/missing notation description for lifelines

  • Key: UML14-275
  • Legacy Issue Number: 6226
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 427: Lifeline/Notation—need to add text stating that multiple activation rectangles (overlapped and offset) may be used to represent recursion. This shows in some examples but not in the text.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.429/incorrect constraint for Message

  • Key: UML14-274
  • Legacy Issue Number: 6225
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 429: Message/Constraint 5: It says that relations sendEvent and receiveEvent are mutually exclusive. The rest of the entry suggests that they are normally both present. The constraint appears erroneous

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.416/incorrect multiplicities for event occurrence

  • Key: UML14-273
  • Legacy Issue Number: 6224
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 416: Associations EventOccurrence::startExec and finishExec should have multiplicity * as in figure 328 on pg.407

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.395/multiple meaning of exception

  • Key: UML14-272
  • Legacy Issue Number: 6223
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 395: Multiple meanings of exception (signal, stack mechanism). The use of exception to be a kind of signal was a mistake in UML1 that goes against all practice. We have now defined it (in the action semantics) to be a proper synchronous nonlinear control mechanism, as in all programming languages. Eliminate all references to it as a kind of signal, otherwise much confusion will ensue.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.235/missing semantics of destroy action

  • Key: UML14-271
  • Legacy Issue Number: 6222
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 235: DestroyAction: Must destroy links involving the object, at least, as they no longer have valid referents after the destruction. This is needed even if parts are not destroyed automatically. It is part of the essential semantics of links and objects, not an optional semantic variation point (as automatic part destruction is).

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.130/incorrect stereotype name

  • Key: UML14-270
  • Legacy Issue Number: 6221
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 130: – private package import shown as «use» in chart, but should be «access» according to previous text for private import

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.109/Permission redundant

  • Key: UML14-267
  • Legacy Issue Number: 6218
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 109: Permission – this used to be a superclass of access and import. Doesn't serve a useful purpose otherwise. It now seems to be a useless relict. Get rid of it. There is no need to give "permission" to access another element—the fact of the access itself means that you meant to do it. Giving "permission" is more of a tool thing to prevent errors, not a modeling thing. In any case, it now seems obsolete.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.64/Classifier redefinition notation

  • Key: UML14-265
  • Legacy Issue Number: 6215
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 64: Classifier/Notation: Attribute with same name as one that would have been inherited is interpreted as a redefinition. Very dangerous. .It would be better to make it explicit with a <redefines> statement

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.95/attributes in data types clarification

  • Key: UML14-266
  • Legacy Issue Number: 6217
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 95: DataType::ownedAttribute – is the intent to permit record types by allowing attributes in data types? Maybe should say that somewhere or give an example

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.99/misnamed "packageMerge" attribute

  • Key: UML14-268
  • Legacy Issue Number: 6219
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 99: Packages Diagram – association to PackageMerge should be called packageMerge, not packageExtension (as in text on pg. 100)

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is addressed by the proposed resolution to Issue 6190

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.130/missing notation explanation

  • Key: UML14-269
  • Legacy Issue Number: 6220
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 130: Realization/Notation –dashed generalization notation is not mentioned, but it is shown in the chart on pg. 130. Add it to the text

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.79/underlined operation syntax missing

  • Key: UML14-264
  • Legacy Issue Number: 6214
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 79 Operation/Notation: Syntax for operation does not show underlining but example does show it.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PackageMerge (from Kernel)

  • Key: UML14-312
  • Legacy Issue Number: 6279
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    A package merge defines how one package extends another package by merging their contents.

    Description

    A package merge is a relationship between two packages, where the contents of the target package (the one pointed at) is merged with the contents of the source package through specialization and redefinition, where applicable.

    This is a mechanism that should be used when elements of the same name are intended to represent the same concept, regardless of the package in which they are defined. A merging package will take elements of the same kind with the same name from one or more packages and merge them together into a single element using generalization and redefinitions.

    It should be noted that a package merge can be viewed as a short-hand way of explicitly defining those generalizations and redefinitions. The merged packages are still available, and the elements in those packages can be separately qualified."

    The text implies that PackageMerge is an operation on an ordered pair of two packages (respectively the target package and the source package) to produce a third package, whose contents differs from the contents of the source package, differs from the contents of the target package, and differs from the union of the source and target (taking "union" in the set-theoretic sense, where the elements owned by a package are regarded as a set.

    This operation known as PackageMerge is performed when it is desired to produce new elements (with generalization relationships and redefinitions that did not exist "prior to" performing this operation) in a new package, which (to repeat myself) is distinct from either of the two packages one had to start with .

    This implication comes thru use of the English verb "to merge" , used to explain PackageMerge, and the characterization of PackageMerge as "a mechanism", and from the statement in the Associations subsection that "mergingPackage references the Package that is being extended…". After being extended, a package is not what it was prior to being extended. Further, it comes from the statement, in the Semantics subsection, that "A classifier from the target (merged) package is transformed into a classifier with the same name in the source (merging) package, unless the source package already contains a classifier of the same kind with the same name."

    Note in the sentence just quoted, the condition "unless the source package already [emphasis added] contains a classifier of the same kind with the same name. By saying this, the spec implies there is a distinction to be drawn between what th source package contains before the PackageMerge operation is performed, and what it contains afterwards .

    A reductio ad absurdum argument can be posed, as follows:

    Suppose for the sake of argument that a given package S, which plays the role of source (merged) package in a PackageMerge relationship, owns a classifier named E1 of kind K1, but does not own a Classifier named E2 of kind K2.

    Suppose further that another package T (for Target), not the same as S, does have a Classifier named E2 of kind K2, but none named E1 of kind K1.

    If S has a PackageMerge relationship with T, and PackageMerge is not an operation creating a third package distinct from S and from T, then S both does, and does not, have a Classifier named E3 of kind K2.

    Therefore, PackageMerge is either an inconsistent relationship between S and T, or it is an operation on S and T which produces a third package, X, distinct from S and T.

    Suggested resolution: rewrite the PackageMerge section to explicitly present it as an operation producing a new package distinct from both target and source.

  • Reported: UML 1.5 — Mon, 29 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequence diagram conditions on Message arrows

  • Key: UML14-311
  • Legacy Issue Number: 6278
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. James J. Odell)
  • Summary:

    Sequence diagrams in UML 1.x supported a conditional expression to a
    message arrow that was inadvertently omitted from the UML 2.0 Superstructure
    specification. This annotation enabled the modeler to – in essence –
    place guards on messages. Such guards, or more properly ConditionalActions,
    would be evaluated at run time to determine which message arrow(s) would be
    executed. In particular, the UML 1.5 Superstructure document specifies the
    following:

    -In Section 3.60.5.1: "Any condition ... expression attached to the arrow
    becomes, in a detailed action model, the test clause action in a
    ConditionalAction ... in the dispatching Procedure.

    -In section 3.63.2: "An arrow may also be labeled with a condition and/or
    iteration expression."

    -In Section 3.63.3: "A branch is shown by multiple arrows leaving a single
    point, each possibly labeled by a condition. Depending on whether the
    conditions are mutually exclusive, the construct may represent
    conditionality or concurrency."

    -In 3.72.2.4: "A condition represents a Message whose execution is
    contingent on the truth of the condition clause. The condition-clause is
    meant to be expressed in pseudocode or an actual programming language; UML
    does not prescribe its format. An example would be: [x > y]."
    A "branch" condition, or ConditionalAction, is expressed in the form:
    Œ[¹ condition-clause Œ]¹

    Recommendation:

    The UML 2.0 Superstructure FTF team should determine how to reinstate
    ConditionalActions for Sequence Diagrams, given the new abstract syntax for
    Sequence Diagrams. There are two reasons for this:
    1) To maintain backward compatibility with UML 1.0 through 1.5 is important.
    2) Pragmatically, it offers a graphically simple technique to express
    messaging situations that involve branching. Granted, the ALT operation
    supports the equivalent notion; however, it comes with a graphical
    complexity that is not always desired.

    Discussion:

    {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't}
  • Reported: UML 1.5 — Mon, 29 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Instances

  • Key: UML14-319
  • Legacy Issue Number: 6317
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf

    In Figure 120, "l1", which I believe is an InstanceSpecification appears to
    be nested inside another (anonymous) InstanceSpecification, ":Car". However,
    looking at the metamodel for Instances, one InstanceSpecification cannot own
    another. So, in the repository for the diagram in Figure 120, which model
    element owns the InstanceSpecification "l1"? This is important because for
    example when it comes to delete ":Car" how does the repository know to
    delete "l1"?

  • Reported: UML 1.5 — Wed, 15 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Ports

  • Key: UML14-318
  • Legacy Issue Number: 6316
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    03-08-02.pdf:

    This from the descrciption of Ports(p169):
    "For a behavior port, the instance of the owning classifier will handle
    requests arriving at this port (as specified in the behavior
    of the classifier, see Chapter 13, "Common Behaviors"),"
    Is how this works a semantic variation point - if so then it should say so.

    IMO, the very least we should allow is that Port can participate in an
    Association so that its class can have an association end that points to its
    parent, and so can delegate behaviour appropriately

  • Reported: UML 1.5 — Tue, 14 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Recommendation for InteractionOccurrences

  • Key: UML14-310
  • Legacy Issue Number: 6264
  • Status: closed  
  • Source: Northrop Grumman ( Brian Willard)
  • Summary:

    Recommend for InteractionOccurrences be equated to ActivityNodes of Activity
    Diagrams rather than ObjectNodes as currently specified. This spec
    reference for this is: UML Superstructure 03-08-02 Chapter 14 (on page 447):

    Interaction Overview Diagrams are specialization of Activity Diagrams that
    represent Interactions Interaction Overview Diagrams differ from Activity
    Diagrams in some respects.
    1. In place of ObjectNodes of Activity Diagrams, Interaction Overview
    Diagrams can only have either (inline) Interactions or
    InteractionOccurrences. Inline Interaction diagrams and
    InteractionOccurrences are considered special forms of ActivityInvocations.

  • Reported: UML 1.5 — Fri, 26 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Interactions / No way to model reply messages

  • Key: UML14-309
  • Legacy Issue Number: 6263
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It seems that there is no direct way to specify a "reply" message in the UML metamodel for Interactions – even though there is a notation for this concept (dashed arrow).

  • Reported: UML 1.5 — Fri, 26 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

description of Component on page 137

  • Key: UML14-321
  • Legacy Issue Number: 6338
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    The description of Component on page 137 says that the provided and required
    interface associations are derived both directly, from implement and use
    dependencies, and from realizing classifiers and owned ports. What isn't
    clear to me is whether the cup and ball notation can be used for all
    provided and required interfaces, or just for those directly implemented and
    used. If it can be used for all then it isn't clear whether you can
    distinguish between direct and derived interfaces. However, I note on Figure
    89 that /orderedItem is preceded by a slash - is that how the difference is
    notated?

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 61

  • Key: UML14-320
  • Legacy Issue Number: 6337
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Figure 61 - shows a ball connected to a cup, but this notation is not shown
    in the Diagrams section (7.18). It's not clear whether this is actually an
    Assembly Connector, or some other concept. The spec should be clear on
    whether this is an additional notation or not.

  • Reported: UML 1.5 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2.super (or infra)/Profiles-Stereotype (18.3.7)

  • Key: UML14-313
  • Legacy Issue Number: 6280
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    UML2.super (or infra)/Profiles-Stereotype (18.3.7)/absence of diagram
    customization mechanism

    This feature was supported in UML1.4 by an attribute called "icon:string".
    At the time of the design of the Profile metamodel for UML2.0, it has been
    argued this this was a mechanism to be treated by the diagram interchange
    proposal. To my knowledge, this is not the case, or if it is this is not
    eplained.
    This is at least a backward compatibility issue
    Two options can at least be envisaged :
    1 if that is supported by the global "2.0" specifications, explain in the
    profile chapter how
    2 introduce back this "icon:string" attribute. In that cas, thenotation
    ch^pter has to be extended to explain how this icon can be displayed, and
    how multiple stereotype can be handled.

  • Reported: UML 1.5 — Wed, 1 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Components & Deployment chapters missing OCL constraints

  • Key: UML14-317
  • Legacy Issue Number: 6315
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The constraints in the Component and Deployment chapters are expressed in verbal English. They should ideally also be represented in OCL

  • Reported: UML 1.5 — Mon, 13 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Profiles

  • Key: UML14-316
  • Legacy Issue Number: 6310
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In figure 446, only packages that specialise Constructs::Package can contain
    a Profile Application. Whereas I think that the packages to which we need to
    apply profiles are those packages that specialise Kernel::Package

  • Reported: UML 1.5 — Thu, 9 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Composite Structures

  • Key: UML14-314
  • Legacy Issue Number: 6281
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Divergence between XMI/MDL and the PDF/FM
    The XMI and MDL files for UML 2 super both state that Port is a subclass of
    Property and yet the appropriate diagram in the spec (fig 97) doesn't - this
    fragment of the adopted XMI spec illustrates the point:

    <ownedType xsi:type="cmof:Class"
    xmi:id="_UML_CompositeStructures_Ports_Port" name="Port"
    > > superClass="_UML_CompositeStructures_InternalStructures_Property
    > > _UML_CompositeStructures_InternalStructures_ConnectableElement
    > > _UML_Classes_Kernel_StructuralFeature">

  • Reported: UML 1.5 — Thu, 2 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    The resolution of issue 6356 removes this problem.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Superstructur 03-08-02: Notation for ConditionalNode is missing

  • Key: UML14-308
  • Legacy Issue Number: 6261
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    The Notation and Presentation Options sections of
    the ConditionalNode are empty (p. 315).

  • Reported: UML 1.5 — Fri, 5 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Same as Issue 6071 (Conditional Node and Loop Node notation missing

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super/Kernel::Classifier

  • Key: UML14-315
  • Legacy Issue Number: 6309
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    In 03-08-02.pdf, page 62, attribute should be /attribute

  • Reported: UML 1.5 — Thu, 9 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.78/missing return types syntax

  • Key: UML14-263
  • Legacy Issue Number: 6213
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    78 Operation/Notation: Syntax for operation omits the return types

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is the same as issue 5951 and has been solved by the resolution to issue 7315.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/pg.78/operation redefinition

  • Key: UML14-262
  • Legacy Issue Number: 6212
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    pg. 78 Operation/Constraints: Operation redefinition is effectively covariant ("return type of redefinition must conform to the original return type"). There is a fierce controversy between covariant and contravariant redefinition. Do we mean to rule out contravariant? I wouldn't think so, as it is the most common. Better eliminate this constraint on types. The whole issue of type conformance requires more care.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::UseCases/Extend and Include are not NamedElements

  • Key: UML14-258
  • Legacy Issue Number: 6208
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Properties UseCase::extend and UseCase::include subset property Namespace::ownedMember, but classes Extend and Include are not types of NamedElement

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel/missing namespaces for metaclasses

  • Key: UML14-257
  • Legacy Issue Number: 6207
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The following types don't have obvious namespaces:

    ActivityPartition
    ConnectionPointReference
    Duration
    InstanceValue
    Interval
    LiteralBoolean
    LiteralInteger
    LiteralNull
    LiteralString
    LiteralUnlimitedNatural
    OpaqueExpression
    Pesudostate
    State
    TimeExpression
    Transition

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel/Mis-named Manifestation class

  • Key: UML14-254
  • Legacy Issue Number: 6204
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The name of class Manisfestation is misspelled; it should be "Manifestation"

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Correct the typo in figure 124 FAS.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Templates/missing return type

  • Key: UML14-253
  • Legacy Issue Number: 6203
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    OCL operation UML::AuxiliaryConstructs::Templates::TemplateableElement::parameterableElements() is missing a return type

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Spec/completing mandatory sections

  • Key: UML14-261
  • Legacy Issue Number: 6211
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The new OMG document structure requires certain mandatory sections (Scope, Confromance, Normative References, Terms and Definitions, and Symbols). Since these sections were not in the original submissions spec (or at least not in the form expected by the new OMG document structure), they need to be completed by the FTF.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::CommonBehaviors/redundant class?

  • Key: UML14-252
  • Legacy Issue Number: 6202
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Class UML::CommonBehaviors::Communications::Call is in the model, but does not participate in any associations, is not referenced, and does not appear in any diagrams

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Delete the above-mentioned class from the mdl file.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel/missing owners for metaclasses

  • Key: UML14-256
  • Legacy Issue Number: 6206
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The following types don't have obvious owners:

    AnyTrigger
    CallTrigger
    ChangeTrigger
    InformationFlow
    PrimitiveFunction
    SignalTrigger
    TimeTrigger

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel/mis-spelled implementingClassifier"

  • Key: UML14-255
  • Legacy Issue Number: 6205
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The name of property Implementation::implementatingClassifier is misspelled; it should be "implementingClassifier".

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel/missing source and target for InformationFlow

  • Key: UML14-260
  • Legacy Issue Number: 6210
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Class InformationFlow specifies neither its source(s) nor its target(s).

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ProtocolStateMachines/ProtocolStateMachine not a type of Feature

  • Key: UML14-259
  • Legacy Issue Number: 6209
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Property Interface::protocol subsets property Classifier::feature, but class ProtocolStateMachine is not a type of Feature

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Protocol state machines are not pre/postconditions

  • Key: UML14-209
  • Legacy Issue Number: 6152
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The text in the semantics of ProtocolStateMachine says:

    The protocol transition can always be translated into pre and post
    conditions of the associated operation. For example, the transition
    in Figure 9-13 specifies that:

    1. the operation "m1" can be called on an instance when it is in
    the state S1 under the condition C1,

    2. when m1 is called in the state S1 under the condition C1,
    then the final state S2 must be reached under the condition
    C2.

    The above translation is not possible by the definition of protocol
    machines. Protocol machines are a client-side view, independent of the
    the internal behavior machine of the instance. This means the protocol
    states are not necessarily the same as the internal states of the
    intance. The protocol machine is keeping track of the operations that
    have been called to enforce and order, but the internal behavior machine
    may or may not be the same. If they are the same, there would be no
    purpose to the protocol machine.

    The spec actually makes the same point at the beginning of the semantics of
    PSM:

    Using pre and post conditions on operations is a technique well
    suited for expressing such specifications. However, pre and post
    conditions are expressed at the operation level, and therefore do
    not provide a synthetic overview at the classifier level. Protocol
    state machines provide a global overview of the classifier protocol
    usage, in a simple formal representation.

    That is, If PSM's were easiy mappable to operation pre/postcondtions,
    there would be no point to having PSMs.

    Suggested change to the text:

    A protocol state machine could in theory be translated to pre- and
    postconditions on operations, but the conditions would need to account
    for the operation call history on the instance, which may or may not
    be straightforwardly represented by its internal states. A protocol
    machine provides a direct model of the state of interaction with the
    instance, so that constraints on interaction are more easily
    expressed.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Replace "initial value" with "default value".

  • Key: UML14-212
  • Legacy Issue Number: 6155
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    "Default values" should be called "initial values", for example in
    property values. Defaults are values that are assumed if no value is
    available on the instance. This can be at any time during the life of
    the object. An instance may have a value for a property at one time and
    when the value is removed, the default takes over until another value is
    given.

    The current semantics is that the "default" value is put in the property
    only when the object is created. If the value is later removed, the
    "default" value does not return. This is normally called an "initial
    value".

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TimeObservationAction can't return values

  • Key: UML14-211
  • Legacy Issue Number: 6154
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    TimeObservationAction says it returns a value, but it is a kind of
    WriteStructuralFeatureAction, which doesn't return values. Does it
    write the value to a structural feature? I assume the semantics should
    be more like DurationObservationAction

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Diamond notation for merge junctions

  • Key: UML14-208
  • Legacy Issue Number: 6151
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Merge junctions should have a diamond notation option, for readability
    and backward compatibility

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Activity attributes on Behavior

  • Key: UML14-207
  • Legacy Issue Number: 6149
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The attributes of Activity defined in CommonBehavior look like they
    belong on Behavior.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Kernel::Classifier missing "attribute"

  • Key: UML14-213
  • Legacy Issue Number: 6156
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Kernel::Classifier lists the feature "attribute", and gives semantics
    and notation, that isn't shown in the abstract syntax for
    Kernel::Classifier. There isn't an "attribute" in the MDL file.

    Kernel::Classes abstract syntax refers to "attribute" in the subsetting
    of ownedAttribute.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interactions view of state machines/activities

  • Key: UML14-210
  • Legacy Issue Number: 6153
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Interactions should be able to show a message passing view on a state
    machine or activity, by referring directly to the invocation actions in
    those models. UML 1.4 worked this way.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Concrete Behavior

  • Key: UML14-206
  • Legacy Issue Number: 6148
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Behavior should be a concrete class so behaviors can be defined without
    committing to which model will be used to specify them later

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Composite structure dependent on Behavior

  • Key: UML14-204
  • Legacy Issue Number: 6146
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Composite structure uses Classifier from Communications, but composite
    structure should be usable without behavior.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Complex port

  • Key: UML14-205
  • Legacy Issue Number: 6147
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ComplexPort is referred to in Diagrams section of composite structures,
    but it is not in the metamodel.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Interactions / no create message

  • Key: UML14-307
  • Legacy Issue Number: 6260
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    I am trying to find a mechanism to create a message that represents creation of lifeline. It used to be modeled as a relationship 'action' between Message and Action in UML 1.4.

    Note: There is a mechanism in UML 2 to create a message that represents destruction of lifeline. Its modeled as 'Stop' metamodel element.

    Shouldn't we have something symmetrical to represent creation of lifeline message?

  • Reported: UML 1.5 — Fri, 19 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super / Primitive Types / implementation issue

  • Key: UML14-306
  • Legacy Issue Number: 6259
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the UML 2, a primitive type cannot be stored directly in a Property. Instead, the Property has an association inherited from TypedElement with an end called type. This association is not composite so a Property cannot contain its own type. In the case of a complex type such as a classifier, it makes sense that the type is external to the property. But, in the case of a primitive type, it becomes impractical because for each primitive type encountered, we are forced to create a new PrimitiveType object and store the object in some package in the model. There could be an explosion of PrimitiveType objects in a model as new objects are created for "const char", "const char**", "const char **", etc. It would be unclear what model elements, if any, are using these objects.

    As a proposed solution to this problem, which is inherent to Operation and Parameter as well as Property, an additional composition could be made to PrimitiveType in TypedElement. It could be an optional [0..1] unidirectional composition for this case with a primitive type so that each Property, Operation and Parameter could have access to their primitive type information. Management of these primitive types would be alot easier because they are owned by the element that is making use of them.

    There is another solution that I have thought of while looking at this problem. All of the necessary primitive types could be referenced from a C++ or Java language model. All of the rest of the modifiers for the primitive type could simply be made available through the use of stereotypes from a C++ or Java profile so that the user could take "int" and add "*" and/or "const" modifiers to the primitive type. But, with this approach, there would have to be common C++ and Java models and profiles so that everyone's model could still be somewhat portable between implementations of UML 2.

  • Reported: UML 1.5 — Fri, 19 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML super/Section 2/Compliance points

  • Key: UML14-296
  • Legacy Issue Number: 6248
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The actual compliance levels as given on p. 1 ("no", "partial", "compliant", "interchange") are inadequate.

    For example, it is unclear what it means to "comply to the semantics", since semantics is generally stated in the proposal in terms of the system being modeled. Does a tool that simply provides a way to draw syntactically well-defined UML diagrams "comply to the semantics"?

    Furthermore, it is also unclear what it means to "comply to abstract syntax". What about a tool that presents the notation, but does not use the abstract syntax as its internal representation? Would such a tool only be able to claim "partial compliance", even if it provides 100% of the UML notation? If not, what is the criteria for compliance with abstract syntax?

    Even more problematic, XMI compliance is only required at the "interchange" level, which also requires compliance to abstract syntax, notation and semantics. This would seem to exclude any tool that processes XMI, but does not use the notation-for example, an execution engine that runs off XMI input or a tool that configures itself using an XMI-formatted UML model. There should be a way to claim XMI compliance without being a full modeling tool.

    In general, the compliance levels do not seem to be defined in a way that will be useful for the range of tools that may want to usefully claim UML compliance.

    Recommendation:

    The 2U proposal (ad/2003-01-08) contained a particularly good discussion of compliance in Section 0.8, separately addressing XMI, syntax and semantics compliance. The UML 2.0 specification as adopted should compliance discussion based on the 2U approach.

  • Reported: UML 1.5 — Thu, 11 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Defenition of redefines?????

  • Key: UML14-300
  • Legacy Issue Number: 6252
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    Redefinition of Associations is causing me some concern. I have a attached a RoseModel which expresses it better than verbiage.

    This is my first post to this group and I would appreciate a reply upon receipt just to let me know it is being reviewed

  • Reported: UML 1.5 — Mon, 15 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 super/Composite Classes/Connecting parts of parts

  • Key: UML14-299
  • Legacy Issue Number: 6251
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Consider a model where a composite class, CC, has two parts A and B, both
    typed by class CT. If CT has a part PT, then can I describe a connection
    between A.PT and B.PT? It seems to me that the metamodel can't capture this
    because Connections can only be associated to parts, not parts of parts (i.e
    the metamodel for parts has a flat structure) . So the connection would end
    up being just a reflexive connection from PT to itself, which would be typed
    by a reflexive association on the type of PT.

    If there is a way of connection parts of parts I would like to see more
    explanation somewhere in the spec.

  • Reported: UML 1.5 — Mon, 15 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super / association end naming convention

  • Key: UML14-303
  • Legacy Issue Number: 6256
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    To be consistent with the convention of other names in the spec, the names of Region::transitions, ActivityGroup::edgeContents, and ActivityGroup::nodeContents should be singular (i.e. Region::transition, ActivityGroup::edgeContent, and ActivityGroup::nodeContent).

  • Reported: UML 1.5 — Thu, 18 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super / Classes/ Incorrect reference to "access"

  • Key: UML14-302
  • Legacy Issue Number: 6255
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There are several places in the draft spec that refer to an "access" relationship when it should refer to a "uses" relationship instead. The access relationship according to the appendix is obsolete. The the incorrect reference I have found are on page 39, page 32.

  • Reported: UML 1.5 — Wed, 17 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / State machines-CommonBehavior / undefined owner of triggers

  • Key: UML14-305
  • Legacy Issue Number: 6258
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It is not clear which kind of model element owns a Trigger specification (the Behavior to which it applies or something else?)

  • Reported: UML 1.5 — Fri, 19 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of 6629.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 Super / SimpleTime package / missing multiplicities

  • Key: UML14-304
  • Legacy Issue Number: 6257
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The multiplicities for the various constraints are unspecified in the documentation and the metamodel:

    Specifically, the multiplicity of IntervalConstraint::specification, TimeConstraint::specification, and DurationConstraint::specification should be 1

  • Reported: UML 1.5 — Thu, 18 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

fig236 Datastore example/Datastore should not directly linked with actions

  • Key: UML14-298
  • Legacy Issue Number: 6250
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    A datastore is a specialized CentralBufferNode. But in figure 236
    the datastore node is directly linked with action nodes. That is not
    allowed.

  • Reported: UML 1.5 — Fri, 12 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/p125 and p126/typos

  • Key: UML14-297
  • Legacy Issue Number: 6249
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    p. 125, last paragraph, first line
    "As it turns out, this seemis redunadancy..."

    p. 126, second line
    Figures 23.4 and 23.5 are not there

  • Reported: UML 1.5 — Fri, 12 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What does redefines mean in package extensibility?

  • Key: UML14-301
  • Legacy Issue Number: 6253
  • Status: closed  
  • Source: TimeWarp Engineering Ltd. ( Steven Cramer)
  • Summary:

    What does redefines mean in package extensibility?

  • Reported: UML 1.5 — Tue, 16 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Interfaces / Cannot nest classes in interfaces

  • Key: UML14-356
  • Legacy Issue Number: 6399
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The Java spec says that it is legal to have Java Classes nested in Interfaces:

    9.1.3 Interface Body and Member Declarations
    The body of an interface may declare members of the interface:

    InterfaceBody:

    { InterfaceMemberDeclarationsopt }

    InterfaceMemberDeclarations:
    InterfaceMemberDeclaration
    InterfaceMemberDeclarations InterfaceMemberDeclaration

    InterfaceMemberDeclaration:
    ConstantDeclaration
    AbstractMethodDeclaration
    ClassDeclaration
    InterfaceDeclaration
    ;

    But UML2 Interfaces can only store nested Interfaces. This makes it impossible to model common Java programs with UML

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / state machines / restriction on redefining transitions

  • Key: UML14-355
  • Legacy Issue Number: 6397
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    On page 502, there is a constraint that says that if a transition has a non-unique par <source state, trigger> it cannot be redefined. This introduces what appears to be an unnecessary an inconsistency and should be removed.

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo on Notation for CombinedFragment?

  • Key: UML14-352
  • Legacy Issue Number: 6380
  • Status: closed  
  • Source: Unicom Systems ( Lou Varveris)
  • Summary:

    On page 413 of Superstructure spec (Adopted) – section concerning notation for CombinedFragments of Sequence diagram, for the Operator Ignore/Consider, the Textual Syntax seems to have a typo – should that be straight brackets surrounding the last <message name> to denote optional, rather than the curly brackets?

    In other words:

    Textual syntax: (ignore | consider ){ <message name>

    {,<message name>}

    * }

    Should Be:

    Textual syntax: (ignore | consider )

    { <message name>[,<message name>]* }
  • Reported: UML 1.5 — Wed, 22 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Visibility of a Package

  • Key: UML14-351
  • Legacy Issue Number: 6379
  • Status: closed  
  • Source: Unicom Systems ( Lou Varveris)
  • Summary:

    Under notation (top of page 100), says that “The visibility of a package element may be indicated by preceding the name of the element by a visibility symbol (‘+’ for public and ‘-’ for private).”

    This statement does not mention protected () or package (~) visibility; only public and private.

    Cross Reference:

    On page 31 of Adopted Superstructure spec, figure 6, the VisibilityKind enumeration class has attributes public, private, protected

  • Reported: UML 1.5 — Wed, 22 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Simple Time / incorrect multiplicities

  • Key: UML14-359
  • Legacy Issue Number: 6402
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The multiplicity of IntervalConstraint::specification, TimeConstraint::specification, and DurationConstraint::specification should be 1

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of 6257

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Interface / missing owner of operation

  • Key: UML14-358
  • Legacy Issue Number: 6401
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Operation has a relation to Class to retrieve the class that owns it, but if it is owned by an Interface, there is no corresponding relation, i.e. there should be an Operation::interface property.

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Package Templates / StringExpression inconsistency

  • Key: UML14-361
  • Legacy Issue Number: 6404
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The text for NamedElement (as specialized) on page 560 refers to a "string expression" type. Figure 438, however, only shows the type Expression. (Furthermore, the reference Rose metamodel does include a StringExpression type, indicating that the metamodel in figure 438 may be incorrect.) This inconsistency needs to be resolved.

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Activities / inconsistent naming

  • Key: UML14-360
  • Legacy Issue Number: 6403
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The names of Region::transitions, ActivityGroup::edgeContents, and ActivityGroup::nodeContents should be singular (i.e. Region::transition, ActivityGroup::edgeContent, and ActivityGroup::nodeContent) to be consistent with the rest of the specification

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is duplicate with 6256.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 395 requires a lot more explanation

  • Key: UML14-353
  • Legacy Issue Number: 6381
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Figure 395 requires a lot more explanation. The abstract syntax claims that
    the effect of a transition be expressed as an Activity and so I suppose this
    is what this diagram represents, but I don't recognise the rectangle
    notation from activities. It's also not clear whether the arrows represent
    flows or transitions - if fact they can't be either, because some of the
    arrows start on states and end on actions. It also isn't clear whether there
    are any rules about the construction of these transitions; for example, I
    assume that there can only be one signal receipt and that it has to be the
    first symbol encountered, but that isn't stated. There may be an explanation
    that I missed, in which case it should be placed nearer the figure, or an
    appropriate reference inserted. The various symbols should also appear in
    the diagrams section.

  • Reported: UML 1.5 — Thu, 23 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 super / Templates / parameters cannot have names

  • Key: UML14-363
  • Legacy Issue Number: 6407
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The specification refers to template parameters by their names, implying that they are named elements; however, TemplateParameter is defined as a specialization of Element. Should TemplateParameter be a type of NamedElement?

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is the same issue as issue 6262.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super / Deployments / node composition

  • Key: UML14-362
  • Legacy Issue Number: 6406
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Node::nestedNode should be an aggregate (containment by value) property

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Add the composition to the MDL and the spec.in figure 125

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Questions about CentralBufferNode semantic

  • Key: UML14-350
  • Legacy Issue Number: 6378
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    I have a question about the flow semantic according to
    a CentralBufferNode.

    p.312 (Examples) says:
    "...because each token can only be drawn from the object node
    by one outgoing edge."

    What exactly happens if a CentralBufferNode has more than one
    outgoing edge. Is it defined which one is used?

    In the example on p. 312 I cannot see why the edge leading to
    the action "Use parts" is prefered to the action "Pack parts" as
    described in the text ("All the parts that are not used will be packed...").

  • Reported: UML 1.5 — Fri, 5 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 super / state machines / entry and exit actions cannot be redefined

  • Key: UML14-354
  • Legacy Issue Number: 6396
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    In the current metamodel it does not appear as if state entry and exit actions can be redefined. Since transition actions can be redefined, this restriction does not make sense and should probably be removed.

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 super / Activities / structured activity node contradiction

  • Key: UML14-357
  • Legacy Issue Number: 6400
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Activity::structuredNode subsets both node and group, but structured activity nodes can only be contained in one place (either group or node); should it be derived?

  • Reported: UML 1.5 — Fri, 31 Oct 2003 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Infra/Section 5.9/missing merge rules

  • Key: UML14-244
  • Legacy Issue Number: 6190
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML2 Infrastructure specification says in section 5.9 Packages Diagram, under Package Merge Semantics: "If features from multiple classifiers are somehow conflicting, the same rules that apply for multiple inheritance are used to resolve conflicts." These rules don't appear to be defined anywhere. RedefinableElement indicates one redefining element may redefine multiple inherited redefinable elements.

    Clean Model Rule 8 says "An attrubute must be explicitly redefined in any cases where more than one attribute of the same name would be inherited from different superclasses, unless one of them already redefines the other." Rule 7 says "Attribute redefinition will be done by redeclaring an attribute in the subclass with the same name." This means that a redefinition in a subclass redefines all the inherited properties of the same name in all superclasses, and hides those inherited properties in the subclass. However, no common OO language supportes these semantics.

    As a result, performing the transformation specified by package merge semantics on UML2 Superstructure results in many name collisions caused by multiple inheritance of merged classes. This causes problems for XMI Schema and Java API generation.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel/package merge and visibility

  • Key: UML14-243
  • Legacy Issue Number: 6189
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The package merge rules say that private elements from the merged package are not merged into the merging package. However, this can result in inconsistencies if for example, an association is public but its ends are private. And it would not work at all for define merge since the merged types are not retained. The merge implementation currently ignores visibility

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::BasicActivities/inGroup problem

  • Key: UML14-247
  • Legacy Issue Number: 6193
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    BasicActivities has edgeContents:ActivityEdge <--> inGroup:ActivityGroup. CompleteActivities has edgeContents:ActivityEdge

    {redefines edgeContents} <--> inGroup:InterruptibleActivityRegion {subsets inGroup}. inGroup ends up redefining and subsetting the inherited inGroup Should this have been interruptingEdge:ActivityEdge {redefines edgeContents}

    <--> interruptibleRegion:InterruptibleActivityRegion

    {redefines inGroup}

    and the other association removed? Or does inGroup need a new name?

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::StructuredClasses/erroneous association

  • Key: UML14-246
  • Legacy Issue Number: 6192
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package StructuredClasses contains class Class and an association +:Class ->+ownedAttribute:InternalStructures::Property which does not appear on any diagram. This association does not match the similar one in Constructs: +class:Class <->+ownedAttribute:Property because it is missing an end name and navigability in both directions. It is not clear if this was intended to constrain the Constructs association so that a property does not know the class that contains it, or if the association was meant to be deleted. It cannot simply be corrected by adding the missing end and making it navigable in both directions as this would result in Property having two properties called class. Either the association should be removed, or StructuredClasses needs to redefine Property instead of referencing it directly from InternalStructures

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Package Merge/redefinition rules and standard OO languages

  • Key: UML14-245
  • Legacy Issue Number: 6191
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    There are cases where the same property goes from derived, to non-derived, and back to derived in different merged classes. Are there any constraints on subclasses redefining non-derived properties to be derived? If not, what would it mean for the subclass to inherit the non-derived property? Secton 5.3 says: "A derived property can redefine one which is not derived. An implementation must ensure that the constraints implied by the derivation are maintained if the property is updated." It doesn't mention the other way around.

    A redefinition hides the redefined model element. That is, if a subclass redefines a property, the inherited property is no longer visible. See section 5.3: "Note that a redefined attribute is not inherited into a namespace where it is redefined, so its name can be reused in the featuring classifier, either for the redefining attribute, or alternately for some other attribute."

    This does not conflict with the usual ability of OO languages which allow a subclass to specialize its superclasses and overrider methods, but still access the super class through keywords suchs as "super". Such keywords refer to the superclass namespace. However, Java does not allow a subclass to redefine a member variable unless it is private in the superclass. The same property in a superclass can't be private in contexts where it is redefined in some subclasses, and public in other subclasses where it is not redefined.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Constructs/inconsistency with Kernel

  • Key: UML14-241
  • Legacy Issue Number: 6186
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Constructs has association mergingPackage:Package[1..1] c-> packageMerge:PackageMerge[0..*] while Kernel has mergingPackage:Package[1..1] c-> packageExtension:PackageMerge[0..*] without a renames. Should this be changed to packageMerge to be consistent with Constructs?

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Resolved as part of the resolution to issue 6918.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::BasicBehaviors/missing redefinition

  • Key: UML14-240
  • Legacy Issue Number: 6185
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    BasicBehaviors has association context:BehavioredClassifier[0..1] c-->ownedBehavior:Behavior[0..*]. BehaviorStateMachines has :BehavioredClassifier[0..1]

    {subsets redefinitionContext}

    c--> ownedStateMachine: StateMachine[0..*]

    {redefines ownedBehavior}

    . StateMachine specializes Behavior thereby inheriting context:BehavioredClassifier. Property redefinitionContext comes from RedefiningElement, but the inherited property context is skipped. Is the role name missing? Should context:Behavior subset redefinitionContext?

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Package Merge/missing rule for operations

  • Key: UML14-250
  • Legacy Issue Number: 6198
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package merge rules do not specify how operations match when being merged, or how they are merged if they do match

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    The appropriate rules for this case are now spelled out in the resolution to issue 6279.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Compliance::L3/Missing merges

  • Key: UML14-249
  • Legacy Issue Number: 6196
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    UML::Compliance::L3 doesn't merge: InfrastructureLibrary::Profiles, UML::AuxiliaryConstructs.Templates, UML::CompositeStructures.StructuredActivities, UML::Profiles, UML::StateMachines::MaximumOneRegion

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel/merging of non-redefinable model elements

  • Key: UML14-242
  • Legacy Issue Number: 6188
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Model elements, like Constraint, that are not RedefinableElements are always copied from the merged model element to the merging model element. When a package like Kernel is merged into many packages which are then in turn merged into another common package, these non-redefinable elements are copied down multiple times in the leaf merging package. For example, L3::Classifier has a large number of ownedRules named general_equals_parent which it gets from Dependencies::Classifier. Dependencies is merged into Kernel which is merged into many packages in Superstructure. Perhaps a Constraint should be a RedefinableElement, or package merge should only copy down these elements once

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::Kernel::Packages/missing redefinition

  • Key: UML14-239
  • Legacy Issue Number: 6184
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Kernel/Packages has association package:Package <--> ownedClassifier:Type without a redefinition while its ownedType in Basic and Constructs

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue was resolved by the resolution to issue 6918.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2 Super/Metamodel::StructuredActivities/double redefinition

  • Key: UML14-248
  • Legacy Issue Number: 6195
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    StructuredActivities has association activity:Activity

    {redefines activity, redefines activity}

    <--> structuredNode:StructuredActivityNode. It should only redefine activity once.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profile/inability to attach a stereotype to an element

  • Key: UML14-251
  • Legacy Issue Number: 6199
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package Profile does not specify any way to attach a Stereotype to an Element.

  • Reported: UML 1.5 — Sun, 7 Sep 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the solution to issue 6347.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SendObjectAction

  • Key: UML14-191
  • Legacy Issue Number: 6132
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clean up SendObjectAction so it doesn't refer to signals. It can send
    any object, including a signal.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification of insert

  • Key: UML14-190
  • Legacy Issue Number: 6131
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify in AddStructuralFeatureAction, etc, that insert is not needed
    when isReplaceAll = true.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Colon notation for pins

  • Key: UML14-185
  • Legacy Issue Number: 6125
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that parameter notation can be used for pins even when they
    aren't invocation actions.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Local pre/postcondition example

  • Key: UML14-184
  • Legacy Issue Number: 6124
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide a local pre/postcondition example that is really local

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter semantics clarification

  • Key: UML14-182
  • Legacy Issue Number: 6122
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of parameters "Either all non-stream outputs must be
    posted when an activity is finished, or one of the exception outputs
    must be." Reword and clarify that exception outputs are non-streaming.
    Also state that exception outputs cannot be streaming.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExceptionHandler 1

  • Key: UML14-192
  • Legacy Issue Number: 6133
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add a constraint to ExceptionHandler that the input of the exception
    handler body must be one value of same type as the exception input
    object node, and constraint that the input object node must be a pin
    on/part of the protected node.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No-token activity termination clarification

  • Key: UML14-189
  • Legacy Issue Number: 6130
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify that activities terminate if there are no tokens in it,
    including tokens inside actions. The semantics of Parameter only states
    the necessary conditions now.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for for global pre/postconditions actions

  • Key: UML14-187
  • Legacy Issue Number: 6128
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide notation for actions invoking beahviors with global
    pre/postconditions

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Behavior execution instances

  • Key: UML14-183
  • Legacy Issue Number: 6123
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Executing behavior creates an instance of the behavior class.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for isSynchronous

  • Key: UML14-188
  • Legacy Issue Number: 6129
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide notation for isSynchronous on CallAction.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Value Pin notation

  • Key: UML14-186
  • Legacy Issue Number: 6127
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide notation for value pins.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectFlowEffect

  • Key: UML14-171
  • Legacy Issue Number: 6109
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ObjectFlowEffect requires edges from pins to actions.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Optional parameters

  • Key: UML14-170
  • Legacy Issue Number: 6108
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What is the semantics for invocation actions on behaviors that have
    parameters with multiplicity with lower bound of zero? Currently, the
    execution semantics requires all data inputs to arrive.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate with 6105.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter set corrections 2

  • Key: UML14-176
  • Legacy Issue Number: 6116
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint that two parameter sets should not have exactly the
    same parameters in them

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ObjectNode.isUnique

  • Key: UML14-174
  • Legacy Issue Number: 6113
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add constraint that ObjectNode.isUnique = false

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reentrancy 3

  • Key: UML14-173
  • Legacy Issue Number: 6112
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide a notation for isReentrant.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pin multiplicity

  • Key: UML14-169
  • Legacy Issue Number: 6107
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What is the semantics of pin multiplicity? If it has no execution
    effect, then remove it. If it is the same as the multiplicity inherited
    from TypedElement, then use that. If multiplicity has the same
    semantics as bound, then multiplicity should be used instead of bound

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    See discussion and resolution to Issue 6090.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter set corrections 1

  • Key: UML14-175
  • Legacy Issue Number: 6115
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The end names on the association between Parameter and ParameterSet
    are reversed.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExecutableNode, ControlNode should be abstract

  • Key: UML14-172
  • Legacy Issue Number: 6110
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    ExecutableNode, ControlNode should be abstract

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML's use of the word "unique" for multiplicity is ambiguous

  • Key: UML14-133
  • Legacy Issue Number: 5976
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    UML's use of the word "unique" for multiplicity is ambiguous. It means
    "distinct", but it could be mistaken to mean "unique across all instances".
    For example, if someone says that the employee-number attribute of employee
    is unique, it would likely be understood to mean that each employee has an
    employee-number that is different from every other employee. But that's not
    what UML defines "unique" to mean. I recommend that the FTF change
    "

    {unique}

    " to "

    {distinct}

    " or "

    {set}

    ".

  • Reported: UML 1.5 — Thu, 19 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 Superstructure: Operation vs. Attribute notation

  • Key: UML14-132
  • Legacy Issue Number: 5951
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    For reference, my copy here is ad/03-04-01.

    I wonder about an inconsistency between the notations for attributes
    (section 1.8, page 41, in "Classifier (from Kernel, Dependencies,
    PowerTypes)") and operations (section 1.10, page 55, in "Operation
    (from Kernel)").

    For attributes, the notation is (slightly simplified)

    visibility name : type [multiplicity]

    {property-string}


    and for operations, it is


    visibility name (parameter-list) : property-string


    So in the case of attributes, a colon separates the name from the
    type, and the property-string is in curly braces, whereas for
    operations, the colon separates the name and signature from the
    property-string, which is not in braces.


    I think this discrepancy is counter-intuitive, I would expect the
    same atoms to be used in both blaces. I realize that the syntax for
    operations changed from UML 1.5 because of promoting the "return
    value" to a parameter.


    My suggestion is to change the notation for operations to


    visibility name (parameter-list) {property-string}

    i.e. to remove the colon, and to add braces around the property-
    string. This would be more consistent with both the attribute
    notation and the old UML 1.x notation.

  • Reported: UML 1.5 — Fri, 13 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above - resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The description of DataType is plainly wrong in the specification

  • Key: UML14-135
  • Legacy Issue Number: 5979
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The description of DataType is plainly wrong in the specification. A
    data type is a classification of data values. The identity of a data value
    is based on the value itself. And the identity definitely exists.
    Otherwise you would not be able to know when you had two occurrences of the
    same value. If a value has no identity, it would not be possible to
    distinguish different values of the same data type. Someone has confused
    the concept of having identity with the concept of having a memory address.
    Note also that an instance specification is capable, according to the
    specification, of identifying a data value, so it is a contradiction to say
    a data value has no identity. Perhaps the specification is using the word
    "identity" in a way that is completely different from anything in my
    dictionary. The key point to make is that a data value is not to be
    confused with a data variable or a slot in an object that can hold a data
    value.

  • Reported: UML 1.5 — Thu, 19 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above - resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

notation for shared aggregation

  • Key: UML14-134
  • Legacy Issue Number: 5978
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    3. The notation for shared aggregation appears to be missing from the
    association notation section

  • Reported: UML 1.5 — Thu, 19 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Add text to explain the so-called “white diamond” notation for shared aggregation.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Question on Connectors - fig 2-17

  • Key: UML14-139
  • Legacy Issue Number: 5995
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    On fig 2-17, the left-hand of the diagram shows Order with two interfaces,
    OrderableItem and OrderEntry. On the right hand, the assembly connector
    lists only OrderableItem. Yet, the text above -

    "When this notation is used to connect "complex" ports that are typed by
    multiple provided and/or required inter-faces,
    the various interfaces are listed as an ordered set, designated with

    {provided}

    or

    {required}

    if needed."

    might be interpreted as indicating that on the Order side of the assembly
    connector, the adornment should read "OrderableItem,OrderEntry" (as an
    aside, the text above seems to indicate that this list is ordered, but I
    don't know what the order should be). There are a number of possible
    explanations for the current figure:

    • It's a mistake and both interfaces should be listed;
    • Only interfaces supported by both sides of the connector need to be
      listed, (but how about compatible interfaces that are not related by
      classification?)
    • The text above does not apply to parts, but that seems unlikely -
      they are connectable elements after all and can implement and use multiple
      interfaces
    • Something I haven't though of

    Can someone please enlighten me?

  • Reported: UML 1.5 — Fri, 11 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There appears to be a typo on page 2-148, in section 2.12.2.13 on StubState

  • Key: UML14-138
  • Legacy Issue Number: 5992
  • Status: closed  
  • Source: Honeywell ( Steven Hickman)
  • Summary:

    There appears to be a typo on page 2-148, in section 2.12.2.13 on StubStates. In this section it states that StubState is a child of State. However, in Figure 2-24 on page 2-141 it shows StubState as derived from StateVertex

  • Reported: UML 1.5 — Tue, 8 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Well-Formedness Rules for Procedure on Common Behavior Package

  • Key: UML14-137
  • Legacy Issue Number: 5982
  • Status: closed  
  • Source: Freelance Developers ( Francisco Araujo)
  • Summary:

    Well-Formedness Rules for Procedure on Common Behavior Package are wrong, document is actually showing same content as Abstract Sintax for Procedure on Common Behavior Package.

  • Reported: UML 1.5 — Tue, 24 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

An error in Figure 464

  • Key: UML14-141
  • Legacy Issue Number: 6066
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I found there still is an error in Figure 464 from ptc/03-07-06 to 03/08/02 of UML 2.0 Superstructure Specification, ie. Collaboration Diagram should be replaced with Communication Diagram

  • Reported: UML 1.5 — Fri, 15 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PackageableElement

  • Key: UML14-140
  • Legacy Issue Number: 6049
  • Status: closed  
  • Source: Anonymous
  • Summary:

    there was declared and inheritance relationship between NamedElement and
    PackageableElement defining in both cases an attribute "visibility". I
    suggest to suppress the declaration in PackageableElement because it is
    inherited from NamedElement

  • Reported: UML 1.5 — Thu, 31 Jul 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 63 missing notation

  • Key: UML14-145
  • Legacy Issue Number: 6070
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    Also Figure 63 is missing "<<" from in front of Interface>> IAlarm

  • Reported: UML 1.5 — Thu, 21 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface Figure 62 uses wrong notation

  • Key: UML14-144
  • Legacy Issue Number: 6069
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    Figure 62 uses the wrong notation. The text says that it is using dependcy arrows - they are solid - one of them has a generalization arrow head. Also the interface 'ISensor' rectangle does not include <<interface>> with the name

  • Reported: UML 1.5 — Thu, 21 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Description of GeneralizationSet

  • Key: UML14-136
  • Legacy Issue Number: 5980
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The description of GeneralizationSet uses the words "general" and
    "specific" to mean "specific" and "general" respectively. The description
    also uses unclear terms like "maps to classifier" without identifying which
    association. Also, the semantics has: "All of the Generalization links that
    share a given general Classifier are divided into disjoint sets (that is,
    partitions) using the generalizationSet association." This statement is
    nonsense. First, the metamodel does not require all generalizations to be
    put into partitions using "the generalizationSet association". Second,
    partitions are not required by the metamodel to be disjoint - the same
    generalization can be in multiple generalization sets (as should be the
    case).

  • Reported: UML 1.5 — Thu, 19 Jun 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 1.3, ElementImport semantics on page 10 of ad/2003-04-01

  • Key: UML14-142
  • Legacy Issue Number: 6067
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Mr. J.D. Baker)
  • Summary:

    In this section the following statement appears:

    "An imported element can be further imported by other namespaces using either element or member imports."

    This is the first and only reference I have found to "member import." Please provide a definition of member import and include an example if it may be required to complete the understanding of the concept.

  • Reported: UML 1.5 — Mon, 18 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Obsolete notation used in state machine - transition examples

  • Key: UML14-143
  • Legacy Issue Number: 6068
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    Section 15.3.14 Transition

    Figures 395 and 396 use lozenge shapes (a rectangle with rounded ends - the notation for an activity in UML 1.4). However, these are state machine examples and this notation is meaningless in this context.

  • Reported: UML 1.5 — Wed, 20 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Profile Notation

  • Key: UML14-55
  • Legacy Issue Number: 4219
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    I raised this issue at the AB level. I didn't recommend holding up approval
    of UML 1.4 over this but we agreed that the new RTF would take this matter
    up with dispatch.

    Pages 3-59 to 3-63 (Section 3.35): The new notation for defining Stereotypes
    and TaggedValues (i.e. for defining a Virtual Metamodel or "VMM") raises an
    issue. I can speak to this as a practical matter based on the profiling
    work I've done. When I define a Stereotype on a UML metamodel element, as
    in figure 3-32 on p. 3-61, I would like to reuse the official OMG definition
    of the UML metamodel element. I don't want to have to define it again
    before defining the relationship between my new Stereotype and that UML
    metamodel element. Thus, requiring the <<metaclass>> Stereotype on the UML
    metamodel element means that, in the UML metamodel itself, I would have to
    Stereotype all the metaclasses this way so that, if I need to, I can reuse
    them in VMMs. True, I could opt not to display the <<metaclass>>
    Stereotype in a pure UML metamodel diagram and opt to display it a VMM
    diagram, but all the UML metamodel elements would be carrying the
    <<metaclass>> Stereotype.

    The best solution I can think of to this problem is to to drop the
    requirement to use the <<metaclass>> Stereotype in VMM diagrams. As long as
    the requirement to use the <<stereotype>> Stereotype on Stereotypes (sic!)
    is adhered to, it should be pretty clear in a VMM diagram what is a
    Stereotype and what is a UML metamodel element. Also, the the standard
    metamodel Stereotype of Package indicates that the elements in the
    Package are elements of a metamodel.

    I am open to other suggestions as to how to resolve this issue.

  • Reported: UML 1.3 — Fri, 9 Mar 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Appendix A, UML Standard Elements

  • Key: UML14-54
  • Legacy Issue Number: 4218
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In Appendix A, UML Standard Elements, it is stated that the stereotypes document, executable, file, library, source and table are based on the element Abstraction. This however is in conflict with p. 2-20, where they are indicated to belong to Artifact.

  • Reported: UML 1.3 — Thu, 8 Mar 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Conflicting WFRs on Transition

  • Key: UML14-58
  • Legacy Issue Number: 4298
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    UML 1.4 Specification, Section 2.12.3, p. 2-165

    Description:
    WFR 5 for the class Transition states that "Transitions outgoing
    pseudostates may not have a trigger" and the OCL supports this absolute
    statement. However, WFR 6 is intended to allow transitions out of initial
    states, which are a kind of pseudostate, to have "a trigger with the
    stereotype 'create'". Unfortunately, WFR 5 prevents this from ever being
    legal.

    Recommendation:
    Change WFR 5 as follows.

    [5] Transitions outgoing pseudostates other than initial states may not have
    a trigger.

    self.source.oclIsKindOf(Pseudostate) implies
    self.source.oclAsType(Pseudostate).kind<>#initial implies
    (self.trigger->isEmpty())

  • Reported: UML 1.3 — Thu, 10 May 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add Multiplicity to Parameter.

  • Key: UML14-57
  • Legacy Issue Number: 4292
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    Adding multiplicity to Parameter would enable modeling of arrays,
    collections, sequences etc. I would like to model BehavioralFeatures that
    can return an array and take an array as an argument.
    The notation would simply add the [multiplicity] after the Parameter type.
    The initial value syntax would be

    { initial-value, initial-value..}
  • Reported: UML 1.3 — Tue, 1 May 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Events, signals, stimuli, etc.

  • Key: UML14-56
  • Legacy Issue Number: 4263
  • Status: closed  
  • Source: Ecole Polytechnique Federale de Lausanne ( Shane Sendall)
  • Summary:

    Here is my understanding of communication between instances on an
    example (all quotes are from UML 1.4 draft (Feb 2001) of the spec).
    An instance i1 performs a SendAction, according to the spec: "A send
    action is an action that results in the (asynchronous) sending of a
    signal". Then, the signal is delivered to say instance i2, and as a
    consequence of the receipt, a SignalEvent is generated (according to the
    spec, "A signal event represents the RECEPTION of a particular
    (asynchronous) signal")
    Now the problems:
    1) the spec goes on further to say about the signal event that "A signal
    event
    instance should not be confused with the action (e.g., send action) that
    generated it". The problem I have with my above understanding is that
    the send action should not be the one generating the send event but
    rather the reception of the signal should be the one generating it.
    2)According to the spec: "A signal is a specification of an asynchronous
    stimulus communicated between instances" where a stimulus is more
    general "In the metamodel Stimulus is a communication, i.e. a Signal
    sent to an Instance, or an invocation of an Operation". Thus, I conclude
    that the things sent between instances are stimuli.
    However, I'm a little confused of the relationship between events and
    stimuli with the following sentence taken from the spec "Event instances
    are generated as a result of some action either within the system or in
    the environment surrounding the system. An event is then conveyed to one
    or more targets. The means by which event instances are transported to
    their destination depend on the type of action, the target,..."
    Furthermore, how are stimuli and signals related in the metamodel?

  • Reported: UML 1.3 — Tue, 10 Apr 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Predefined datatypes

  • Key: UML14-61
  • Legacy Issue Number: 4452
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The various datatypes that are the result of expressions are not
    defined in UML. For example, there is no subtype of Datatype
    called Boolean. This means users will all define their own Boolean,
    Integer, etc., breaking interchangeability.

    The datatypes defined in the Datatypes packages are not model
    elements, so theoretically cannot be used in M1 models. However,
    the interchange model for UML includes these types, making them
    available for user models. If this is the case, it should be made
    clear in the UML spec. The overview of the Datatypes package
    (section 2.7.1) says it contains types used in defining UML, so
    they formally belong to the MOF.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The definition of Multiplicity in Datatypes does not list the range associa

  • Key: UML14-60
  • Legacy Issue Number: 4449
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The definition of Multiplicity in Datatypes does not list the range association

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Component notation: logical compartments

  • Key: UML14-65
  • Legacy Issue Number: 4464
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    The current component notation does not provide for separate
    logical compartments when nesting implementation classes and artifacts in a
    component, as shown in Notation, Figure 3-95. It would be useful to provide
    separate logical compartments for this, as we do for subsystems and classes.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exceptions do not correspond to common usage

  • Key: UML14-64
  • Legacy Issue Number: 4457
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Exceptions in UML are signals, but the normal usage of the term is
    for non-local flow of control that is trapped in procdural code.
    No signal is normally sent with exceptions.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the origin of an Action in a Collaboration.

  • Key: UML14-53
  • Legacy Issue Number: 4123
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    Actions seem to be owned by the Message in the following paragraph.

    Section 2.10 page 2-130. "In the metamodel a Message defines one specific
    kind of communication in an Interaction. A
    communication can be e.g. raising a Signal, invoking an Operation, creating
    or destroying an
    Instance. The Message specifies not only the kind of communication, but also
    the roles of the
    sender and the receiver, the dispatching Action, and the role played by the
    communication
    Link. Furthermore, the Message defines the relative sequencing of Messages
    within the
    Interaction."

    Is the Action a reference to a Action in the Sender, as the meta-model
    suggests, or is it owned by the Message as the above suggests?

    Please clarify.

  • Reported: UML 1.3 — Mon, 18 Dec 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguous semantics of classifier targetscope

  • Key: UML14-59
  • Legacy Issue Number: 4447
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The semantics of classifier targetscope is ambiguous for
    associations with participating classifiers that have children. It
    is not defined whether this specifies links for the classifier and
    all its descendants, or links for the classifier and each
    descendant separately.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Event => Event Specification

  • Key: UML14-63
  • Legacy Issue Number: 4456
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The event metaclass would better called "event specification". Or
    at least the runtime event should be called "occurences" rather
    than instances.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This issue is resolved by the resolution to issue 6682.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The text and OCL of rule #5 for Method do not say the same thing.

  • Key: UML14-62
  • Legacy Issue Number: 4455
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The text and OCL of rule #5 for Method do not say the same thing.

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Another State machine issue

  • Key: UML14-37
  • Legacy Issue Number: 3202
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    State Machines

    The metaclass StateVertext, including its subclasses PseudoState,
    StubState and SyncState is not owned by a StateMachine.

    The associations from StateVertext to

    • container : CompositeState
    • outgoing : Transition
    • incoming : Tranision
      can all be empty.
      If they are all empty in a model, we do not know to which statemachine
      this StateVertex belongs. IS this the intention ?
  • Reported: XMI 1.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Data Types Misplaced in the "Physical" Metamodel (uml-rtf)

  • Key: UML14-36
  • Legacy Issue Number: 3127
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    All data types used in the UML metamodels are clumped together in a
    Data_Types package in the Foundation metamodel. When a new type is needed
    by some other metamodel, such as for Activity Graphs, the type is added into
    Foundation. This breaks the whole concept of extensibility. Data types,
    like other model elements, should be defined in the specific packages where
    they are needed. A new package that requires new types should include those
    types itself and not impose a change on UML Foundation.

    Recommendation: In the "physical" metamodel, put data types into the
    packages where they are first used. For example, PseudostateKind should be
    defined in Behavioral_Elements.State_Machines, not in Foundation.Data_Types.

  • Reported: XMI 1.1 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inheritance violation in "Auxiliary Elements"

  • Key: UML14-30
  • Legacy Issue Number: 2361
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Source: HO Wai-Ming, PhD research Student, IRISA, France

    Reference: UML Semantics 1.1, Sep. 1997 and UML Semantics 1.3 Beta, Jan
    1999 and the associated Rational Rose model files

    Specification section reference: UML Semantics 1.1 Part 2, Section 4.3
    Well-formedness rules, pp.32 and UML Semantics 1.3, Part 2, Section
    2.5.3, pp.2-49

    Nature: Clarification

    Severity: Medium
    Summary: In the 1.1 model file, there is an inheritance relationship
    between
    "Presentation" (in "Auxiliary Element") and "Element" (in "Core").
    "Presentation" is an association class and "Element" is a normal class.
    The two types are not the same, this this brings up the following
    constraint in the semantic document:

    self.subtype.oclType = self.supertype.oclType

    Question:
    1) Is "Presentation" suppose to inherit from "Element"? The other
    association classes "ElementOwnership" and "ElementReference" do no
    appear to do so.

    2) If the answer to (1) is yes, then isn"t it a violation of the UML
    semantics" well-formedness rule.

  • Reported: XMI 1.0 — Mon, 1 Feb 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

class EnumerationLiteral issue

  • Key: UML14-33
  • Legacy Issue Number: 2582
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I think that the class EnumerationLiteral should be an heir of DataValue
    (this inheritance relationship is currently missing).

    Once this is fixed, the association between EnumerationLiteral and Enumeration
    should be seen as a refinement of the association between DataValue and DataType
    (itself implicitly inherited from the association between Instance and classifier),
    with a supplementary OCL constraint in the case of EnumerationLiteral,
    namely that self.classifier.oclIsKindOf(Enumeration)
    (to ensure covariance, as is done for DataValue wrt DataType).

    BTW, shouldn"t there be a symetric OCL constraint in DataType
    specifying that its Instances are all DataValues,
    and similarly in Enumeration specifying that its instances are all EnumerationLiterals ?

  • Reported: XMI 1.0 — Mon, 12 Apr 1999 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operations and Constraints Missing from "Physical" Metamodels

  • Key: UML14-35
  • Legacy Issue Number: 3126
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The "physical" metamodel should include the OCL constraints and operations
    defined in the UML Specification. This has been done in the MOF 1.3
    specification. The operations provide valuable capabilities and should be
    part of the standard UML facility interfaces. Making the operations part of
    the "physical" metamodel allows them to be used when defining new
    constraints in extension metamodels, such as in CWM.

    Recommendation: Add the specification's constraints and operations to the
    "physical" metamodel.

    Note that adding constraints and operations will affect IDL, but it will not
    affect XMI DTDs.

  • Reported: XMI 1.1 — Wed, 15 Dec 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incomplete Inheritance Specification

  • Key: UML14-31
  • Legacy Issue Number: 2362
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Source: HO Wai-Ming, PhD research Student, IRISA, France

    Reference: Rational Rose model files for UML 1.1 and UML 1.3 beta

    Specification section reference: None

    Nature: Clarification

    Severity: Minor

    Summary: There is an oddity in the inheritance relationship of
    "Classifier" in "Core". Is "Classifier" suppose to inherit from
    "Taxon-Datatype", but the specification is incomplete. Rational Rose
    and Rose98 raises an error for this association during a "Check Model".

  • Reported: XMI 1.0 — Mon, 1 Feb 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Datatypes: Expression

  • Key: UML14-32
  • Legacy Issue Number: 2541
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the metaclass Expression includes an attribute called "language" of type
    Name. To enable tools to check OCL expressions, it is neccesary to
    define a standard value for this attribute, which denotes the fact that the
    expressions is an OCL expression.
    Without such a standard defined value tools cannot distinguish OCL
    expresions and cannot interpret them (for purposes of typechecking,
    code generation, etc....)

    I propose to add the value "OCL" as a standard value for the attribute
    "language" of metaclass "Expression" to the chapter on datatypes.

  • Reported: XMI 1.0 — Mon, 15 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interfaces on Nodes

  • Key: UML14-34
  • Legacy Issue Number: 2613
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In looking through the UML 1.3 alpha R2 documentation set, I cannot
    determine if interfaces are allowed on Nodes. Since a Node is a kind
    of classifier, it seems possible that a Node can realize an interface.
    However, since this relationship is not explicitly mentioned as allowed
    or not, I am unclear as to the intention.

  • Reported: XMI 1.0 — Mon, 19 Apr 1999 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML RTF 1.4 Issue: Dynamic concurrency arguments

  • Key: UML14-38
  • Legacy Issue Number: 3276
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Actions in dynamically concurreny states in activity graphs need
    some way to access the arguments provided by the concurrency
    expression. The Reference manual suggests the "implicit" event,
    but does not define what that is (p 437). Perhaps it is an the
    action language issue.

  • Reported: XMI 1.1 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML RTF 1.4 Issue: Parallel action iteration

  • Key: UML14-39
  • Legacy Issue Number: 3285
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Actions should have a isParallel attribute to specify if the iteration
    is sequential or parallel.

  • Reported: XMI 1.1 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pin/parameter matching 4

  • Key: UML14-168
  • Legacy Issue Number: 6106
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clarify in CallBehaviorAction and CallOperationAction that the operation
    and behavior may have out or results and still be called asynchronously.
    The constraints on these actions regarding pin/parameter matching only
    applies in the synchronous case.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pin/parameter matching 3

  • Key: UML14-167
  • Legacy Issue Number: 6105
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    If the multiplicity of a parameter has zero lower bound, how does that
    affect the execution semantics of an invocation action on the
    behavior/operation? If the pin value is optional in this case, then it
    violates the current semantics.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Weight=all

  • Key: UML14-158
  • Legacy Issue Number: 6096
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The weight attribute on activity edges says:
    "A null weight means that all the tokens at the source are
    offerd to the target."

    But a figure specifies

    {weight=all} for the same purpose.


    Which one is the correct one?


    I think {weight=all}

    is the better alternative to express the
    semantic.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide notations for Loop and Conditional

  • Key: UML14-157
  • Legacy Issue Number: 6095
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Provide notations for Loop and Conditional

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Same as Issue 6071 (Conditional Node and Loop Node notation missing)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiple outputs of object flow transformations

  • Key: UML14-163
  • Legacy Issue Number: 6101
  • Status: closed  
  • Source: ThoughtWorks ( Martin Fowler)
  • Summary:

    It would be useful to allow object flow transformations to produce
    multiple tokens from one token.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Keywords or properties

  • Key: UML14-162
  • Legacy Issue Number: 6100
  • Status: closed  
  • Source: ThoughtWorks ( Martin Fowler)
  • Summary:

    Should the keywords "parallel", "iterative", and "stream" for
    ExpansionRegions be in guillemets like localPrecondition? Or is it a a
    property that should be in curly braces, like streaming parameters.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Tokens at fork

  • Key: UML14-159
  • Legacy Issue Number: 6097
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Fork won't let tokens pass on all outgoing edge unless all outgoing
    edges accept the copied token. Guards or backed up flows may prevent a
    token from being accepted on an outgoing edge. This causes a dependency
    between the outgoing edges.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is duplicate with 6512.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExpansionRegions keywords

  • Key: UML14-161
  • Legacy Issue Number: 6099
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    The keywords "parallel", "iterative", and "stream" are defined for
    ExpansionRegions, but the example figures use "concurrent" instead of
    "parallel". The metamodel type ExpansionKind solely defines parallel"
    and the other two keywords mentioned above, not "concurrent".

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pin/parameter matching 1

  • Key: UML14-165
  • Legacy Issue Number: 6103
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    How are pins matched to parameters for invocation actions when there is
    only one parameter list for behaviors and two for actions? There should
    be a general action-pin association specialized for inputs and outputs.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ActivityFinalNode

  • Key: UML14-160
  • Legacy Issue Number: 6098
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What happens to running actions within the activity when a token reaches
    an ActivityFinalNode? Are the actions terminated immediately or do they
    run to completion. Would prefer that they are terminated immediately

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    This is a duplicate of 6504.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pin/parameter matching 2

  • Key: UML14-166
  • Legacy Issue Number: 6104
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    What kind of pin is used for inout parameters? If two pins are used,
    how are they matched to the same parameter?

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Duplicate of 6103.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pins owned twice

  • Key: UML14-164
  • Legacy Issue Number: 6102
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Pins are owned twice: by activities and actions

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

representation of arrays of values in an action language

  • Key: UML14-131
  • Legacy Issue Number: 5924
  • Status: closed  
  • Source: FAU Erlangen ( Martin Jung)
  • Summary:

    While looking at the representation of arrays of values in an action language we discovered, that it is not clear whether arrays may be represented as structural features with a multiplicity according to the array dimension. Example: int[23] foo; would be represented as attribute foo:int [0..23];

    However, an attribute is a structural feature and the multiplicity of it is defined as "the cardinality of the set of values" (chap. 2.5.2.37, p. 2-49). This leads us to the conclusion, that attributes with a multiplicity range greater than one have set characteristics (in a mathematical sense), that is, no duplicate values would be allowed. Is our assumption to use multiplicities for representation of arrays wrong, or is our view of a "set of values" as a mathematical set too strict?

    Anyway, another question in this context arises: Regarding the figure 2-47 (chap. 2.21.2 p. 2-254) we wonder if the association with the "insertAt" rolename at InputPin of AddAttributeValueAction is an indicator for bag characteristics (array semantics)? On the other hand the definition of RemoveAttributeValueAction suggests that every value exists only once, in other words, set characteristics.

  • Reported: UML 1.5 — Wed, 30 Apr 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above - resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2.29 Node

  • Key: UML14-130
  • Legacy Issue Number: 5805
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text "resident The set of resident elements may differ. Often it is more restrictive on the child." has no corresponding association or attribute in any diagram.

  • Reported: UML 1.4 — Fri, 20 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2.15 Dependency

  • Key: UML14-128
  • Legacy Issue Number: 5802
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text "client The element that is affected by the supplier element. In some cases (such as a Trace Abstraction) the direction is unimportant and serves only to distinguish the two elements." disagrees with the 1..* cardinality on the client association end of the association between Dependency and ModelElement (Figure 2-7 on page 2-15).

    The same issue applies to the supplier association end and its documentation.

  • Reported: UML 1.4 — Thu, 19 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above and below - resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2 Abstract Syntax

  • Key: UML14-123
  • Legacy Issue Number: 5797
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The binary association between ModelElement and Flow is undocumented both in the ModelElement and Flow documentation.

  • Reported: UML 1.4 — Mon, 16 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 2.5.2.10 Classifier

  • Key: UML14-122
  • Legacy Issue Number: 5796
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text:

    specifiedEnd Indicates an AssociationEnd

    does not agree with the cardinality * on the association end specifiedEnd between Classifier and AssociationEnd in Figure 2-6 Core Package - Relationships on page 70.

  • Reported: UML 1.4 — Mon, 16 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2 Abstract Syntax

  • Key: UML14-129
  • Legacy Issue Number: 5803
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The association end named container that belongs to the aggregation association between Component and ModelElement (Figure 2-8) is not documented in Section 2.5.2.27 ModelElement.

    2.5.2.27 ModelElement DOES document implementationLocation as "The component that an implemented model element resides in." This association is not on any of the Class Diagrams in Section 2.5.2.

    Should the implementationLocation association be renamed to container in Section 2.5.2.27 ModelElement?

  • Reported: UML 1.4 — Thu, 19 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Designates a Generalization (02)

  • Key: UML14-121
  • Legacy Issue Number: 5795
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text:

    Designates a Generalization whose child GeneralizableElement is the immediate descendant of the current GeneralizableElement.

    disagrees in plurality with the * cardinality of the specialization association end between GeneralizableElement and Generalization in the Core Package - Relationships diagram (Figure 2-6) on page 2-14.

  • Reported: UML 1.4 — Sun, 15 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2.27 ModelElement

  • Key: UML14-125
  • Legacy Issue Number: 5799
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text:

    implementationLocation The component that an implemented model element resides in.

    disagrees with the * cardinality of the implementationLocation association end of the ModelElement - Component association in Figure 2-8 Core Package - Classifiers on page 2-16.

  • Reported: UML 1.4 — Mon, 16 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2.10 Classifier

  • Key: UML14-126
  • Legacy Issue Number: 5800
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The text:

    "specifiedEnd Indicates an AssociationEnd..."

    disagrees with the cardinality * on the association end labeled specifiedEnd of the association between Classifier and AssociationEnd. (Figure 2-6 on page 2-14)

  • Reported: UML 1.4 — Thu, 19 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2.16 Element

  • Key: UML14-124
  • Legacy Issue Number: 5798
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    Element cannot have tagged values. There is no tagged values attribute or association for class Element. Should the taggedValue feature be moved from ModelElement to Element?

  • Reported: UML 1.4 — Mon, 16 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5.2 Abstract Syntax

  • Key: UML14-127
  • Legacy Issue Number: 5801
  • Status: closed  
  • Source: yahoo.com ( Jeff Barnes)
  • Summary:

    The association end named typedParameter that belongs to the association between Classifier and Parameter is not documented in the Classifier section (2.5.2.10 Classifier on page 2-28).

  • Reported: UML 1.4 — Thu, 19 Dec 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: ClassifierRole contents problem

  • Key: UML14-82
  • Legacy Issue Number: 4736
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The UML 1.4 standard states [UML 1.4, pp. 2-121] that a ClassifierRole
    "...specifies a restricted view of a [base] classifier.." and defines "...a
    set of Features, which is a subset of those available in the base
    classifier, as well as a subset of ModelElements contained in the base
    classifier...".

    The ClassifierRole wellformedness rules [UML 1.4, pp. 2-125] states that the
    "feature" association inherited from Classifier must be empty - instead the
    ClassifierRole must select features from the base classifier using the
    "availableFeature" association [UML 1.4, pp. 2-121].

    The ClassifierRole also has an "availableContents" association [UML 1.4, pp.
    2-121] indicating "the subset of ModelElements contained in the base
    Classifier, which is used in the Collaboration". There is however no
    restriction in the wellformedness rules restricting the ownedElements
    contents of the ClassifierRole itself, meaning that a ClassifierRole can
    contain the following meta-elements:

    Method
    Attribute
    Operation
    Reception
    State
    ActionState
    ObjectFlowState
    Transition
    CallState
    Pseudostate
    SimpleState
    SubactivityState
    SynchState
    CompositeState
    SubmachineState
    SubState
    FinalState
    CallAction
    TerminateAction
    CreateAction
    DestroyAction
    SendAction
    ActionSequence
    UninterpretedAction
    ReturnAction
    ExtensionPoint
    Stimulus
    Parameter
    Permission
    UseCase
    ProgrammingLanguageDataType
    StateMachine
    Comment
    LinkObject
    Enumeration
    Association
    Dependency
    ClassifierInState
    SignalEvent
    Constraint
    NodeInstance
    Usage
    Signal
    Actor
    Interface
    Component
    Link
    Primitive
    Collaboration
    SubsystemInstance
    ChangeEvent
    Generalization
    Stereotype
    Subsystem
    TagDefinition
    Abstraction
    Extend
    ActivityGraph
    Flow
    UseCaseInstance
    DataType
    Object
    Class
    TimeEvent
    ComponentInstance
    Exception
    Include
    CollaborationInstanceSet
    AssociationClass
    CallEvent
    Binding
    Package
    Node
    Artifact
    Model
    DataValue
    TaggedValue

    So the question is: is this lack of restriction intentional? And if so, why
    are ownedElements handled differently from features? And what is the
    semantic difference between entities selected using the "availableContents"
    association and those contained directly?

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: Node, Artifact, Package and Model contents problem

  • Key: UML14-81
  • Legacy Issue Number: 4735
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, the abstract metaclass Namespace
    compositely contains any type of ModelElement, but does however state that
    subclasses may restrict this containment [UML 1.4, pp. 2-45].

    The metaclasses Node, Artifact [UML 1.4, pp.1-16], Package and Model [UML
    1.4, pp.1-188] - all deriving from Namespace - make no such restrictions
    however.

    This means that Node, Artifact, Package and Model can compositely contain
    the following concrete metaclasses as ownedElements:

    Method
    Attribute
    Operation
    Reception

    State
    ActionState
    ObjectFlowState
    Transition
    CallState
    Pseudostate
    SimpleState
    SubactivityState
    SynchState
    CompositeState
    SubmachineState
    SubState
    FinalState

    CallAction
    TerminateAction
    CreateAction
    DestroyAction
    SendAction
    ActionSequence
    UninterpretedAction
    ReturnAction

    ExtensionPoint
    Stimulus
    Parameter

    Permission
    UseCase
    ProgrammingLanguageDataType
    StateMachine
    Comment
    LinkObject
    Enumeration
    Association
    Dependency
    ClassifierInState
    SignalEvent
    Constraint
    NodeInstance
    Usage
    Signal
    Actor
    Interface
    Component
    Link
    Primitive
    Collaboration
    SubsystemInstance
    ChangeEvent
    Generalization
    Stereotype
    Subsystem
    TagDefinition
    Abstraction
    Extend
    ActivityGraph
    Flow
    UseCaseInstance
    DataType
    Object
    Class
    TimeEvent
    ComponentInstance
    Exception
    Include
    CollaborationInstanceSet
    AssociationClass
    CallEvent
    Binding
    Package
    Node
    Artifact
    Model
    DataValue
    TaggedValue

    The question is: are all these ownedElement types intended for all the
    mentioned containers? Especially the first 28 in the list appear out of
    place.

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Suggest that alternate syntax used in section 6.5.5 be adopted thoughout

  • Key: UML14-89
  • Legacy Issue Number: 4816
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Subclassing of associations for various reasons leads to having duplicate opposite association ends with in the same class hierarchy unless the association ends are renamed for each subclass. A specific example where this has been miss-used is throughout the DMTF CIM specification.

    This rule is derived from section 6.5.4 and is expressed in the well-formedness rules in 2.5.3.8 for Classifiers. However, if opposite association end name(rolename) was qualified by association name, then the navigational reason to not allow duplicates goes away.

    Suggest that the alternate syntax used in section 6.5.5 be adopted thoughout. Specifically, define "rolename = associationName[oppositeassociationend]" Then specify "classifier.rolename" instead of "classifier.oppositeassociationend." Can then optionally allow use of "classifier.oppositeassociationend" when usage would not be ambiquous.

  • Reported: XMI 1.3 — Tue, 29 Jan 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Invalid XMI.link.atts in UML 1.4 DTD

  • Key: UML14-88
  • Legacy Issue Number: 4810
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The DTD for UML 1.4 (ad/01-02-16)(which claims to be XMI 1.1) has a
    XMI.link.att declaration as follows:

    <!-- _______________________________________________________________ -->
    <!-- -->
    <!-- XMI.link.att defines the attributes that each XML element that -->
    <!-- corresponds to a metamodel class must have to enable it to -->
    <!-- function as a simple XLink as well as refer to model -->
    <!-- constructs within the same XMI file. -->
    <!-- _______________________________________________________________ -->

    <!ENTITY % XMI.link.att
    'href CDATA #IMPLIED xmi.idref IDREF #IMPLIED xml:link
    CDATA #IMPLIED xlink:inline (true|false) #IMPLIED
    xlink:actuate (show|user) #IMPLIED xlink:content-role
    CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:show
    (embed|replace|new) #IMPLIED xlink:behavior CDATA
    #IMPLIED'>

    The XMI 1.1 (and XMI 1.2) standard specifies only href and xmi.idref out of
    these (p4-81 of formal/00-11-02).

    The others seem to be copied from the "UML 1.1" DTD in the XMI 1.1 appendix
    (this appendix was removed at XMI 1.2 since it was wrong and misleading).

    Many of the above link attributes seem actually to be invalid:

    • xml:link is invalid since this is not part of the xml namespace
    • xlink:inline, xlink:behavior and xlink:content-role are not part of xlink
      namespace
    • xlink:actuate has invalid values - the standard values are
      (onLoad|onRequest|other|none)
    • xlink:show is missing values - the full set is
      (new|replace|embed|other|none) [I guess it is not so much of a problem to
      exclude certain values]
  • Reported: XMI 1.3 — Mon, 21 Jan 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4.1 should use MOF 1.4

  • Key: UML14-95
  • Legacy Issue Number: 4946
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In the case of MOF 1.4 there are far more important reasons for moving to
    it. The main change in MOF 1.4 is a 'proper' modeled datatype system as
    opposed to CORBA datatypes hidden away in typeCodes. Because of this:
    a) MOF 1.4 is the basis of the Java Metadata Interface (JMI) which provides
    Java APIs to metamodels and is being adopted by a number of repository and
    UML tool vendors. Without an official version of UML expressed in MOF 1.4
    people will have to do their own conversion with subsequent interoperability
    problems

    b) MOF 1.4 is also the basis of XMI 1.2 and XMI 2.0 (XMI for XML Schemas).
    Without being expressed in MOF 1.4, the UML interchange definition cannot be
    expressed as an XML Schema.

    c) the proper datatype model provides the opportunity to 'clean up' a
    number of datatype-related issues in UML (e.g. issue 4452). And represent
    UML's datatypes such as Multiplicity and MultiplicityRange as MOF
    (structure) datatypes rather than MOF classes.

    I would expect this to only affect the UML 1.4.1 Concrete metamodel. I would
    be willing to draft a proposal for this. Is there a version of this with
    already-agreed 1.4.1 changes incorporated?

  • Reported: XMI 1.3 — Thu, 7 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add action for invoking an activity

  • Key: UML14-94
  • Legacy Issue Number: 4940
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Add action for invoking an activity

  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: Wrong target for StateMachine.top association

  • Key: UML14-84
  • Legacy Issue Number: 4739
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A StateMachine compositely contains a State through the "top" association
    [UML 1.4, pp. 2-147, fig. 2-24].

    However, the wellformedness rules for StateMachine state that "A top state
    is always a composite: self.top.oclIsTypeOf(CompositeState)" [UML 1.4, pp.
    2-158].

    If that is the case, the top association should target a CompositeState, not
    the more general State.

    Note: of course this is not an error as such, but if a wellformedness rule
    can be expressed just as easily in UML, there is no reason to complicate
    matters

  • Reported: XMI 1.3 — Thu, 6 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: AttributeLink containment error

  • Key: UML14-83
  • Legacy Issue Number: 4738
  • Status: closed  
  • Source: Anonymous
  • Summary:

    AttributeLink is unconditionally contained in an Instance [UML 1.4, pp.
    2-97, fig.2-16], as well as being contained in a LinkEnd [UML 1.4, pp. 2-98,
    fig.2-17].

    The former containment obviously prevents the latter from ever being
    realized.

    Note: If changing the former containment from mandatory to optional, please
    remember to exclude AttributeLink from other composite containments
    implicitly enabled by such a change - such as being an ownedElement of a
    Namespace, or a parameter of a template.

  • Reported: XMI 1.3 — Thu, 6 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definitions in glossary don't conform to any standard for definitions

  • Key: UML14-87
  • Legacy Issue Number: 4800
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The definitions in the glossary are often incomplete, vague, and, most importantly, DO NOT CONFORM TO ANY STANDARD FOR DEFINITIONS.

    For those of us in IT who have studied concepts such as "language" and "word" and "definition" it is very disturbing to find people purporting to develop a new "language" who do know how to define words.

    Please get QUALIFIED help immediately. The work you are doing is too important to too many people. If you want OMG and UML to be taken seriously, do it right.

    People in the information business should understand that wrong information is much worse than no information. Do it right or just don't do it.

  • Reported: XMI 1.3 — Wed, 2 Jan 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Composite relationship between Event and StateMachine

  • Key: UML14-86
  • Legacy Issue Number: 4746
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    As previously mentioned in issues 3558 (Who owns an Event?) and
    4734 (Event containment problem).
    Based upon issue 3558 response I believe that an Event should be owned by a
    StateMachine.
    A composite relationship should be added between Event and StateMachine in
    the UML Meta-Model.

  • Reported: XMI 1.3 — Wed, 12 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Simplify inputs/outputs of procedures

  • Key: UML14-92
  • Legacy Issue Number: 4927
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [Conrad Bock, Jim Rumbaugh] Simplify inputs/outputs of procedures so
    they point at inputs/outputs of contained actions. Groups referred
    input pins together that receive the value from the same parameter.

  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

match/correspond clarfication

  • Key: UML14-91
  • Legacy Issue Number: 4917
  • Status: closed  
  • Source: International Business Machines ( Mr. Sridhar Iyengar)
  • Summary:

    [Sridhar Iyengar] 33. Chapter 7 : Collection Action Classes. The
    specification text does not clearly explain how 'match' and 'correspond'

    • dependencies are to be used. See figure 2-57, page 2-307 are used in
      the spec. Are these intended to be illustrative? Are they constraints
      on the values passing thru input and output pins. What is the
      difference between 'match' and 'correspond'?
  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

StartStateMachine clarification

  • Key: UML14-93
  • Legacy Issue Number: 4936
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [Conrad Bock] Does StartStateMachine cause the intial state to be
    entered and its outgoing transition taken? Ie, what is the semantics in
    relation to the RTC step.

  • Reported: XMI 1.3 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Namespace.contents

  • Key: UML14-90
  • Legacy Issue Number: 4848
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The current definition of the operation Namespace.contents is:

    The operation "contents" results in a Set containing all ModelElements
    contained by the Namespace.
    contents : Set(ModelElement)
    contents = self.ownedElement -> union(self.namespace, contents)

    (UML Specification, version 1.4 page 2-64, version 1.3 page 2-55)

    The last line of this definition seems wrong, since the "union" operation
    must have a single parameter.

    The former definition of this operation did not present any contradiction
    between text and OCL expression:

    The operation "contents" results in a Set containing all ModelElements
    contained by the Namespace.
    contents : Set(ModelElement)
    contents = self.ownedElement

    (UML Semantics, version 1.1 page 32)

  • Reported: XMI 1.3 — Tue, 26 Feb 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Adding events to the class definition

  • Key: UML14-85
  • Legacy Issue Number: 4740
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The proposal is to add an optional fourth compartment to the
    class artifact that lists events that are accepted by that
    class.

    If a class is 'Active', it will have an associated
    state/activity model. This state/activity model will respond to
    events sent to that class. At the moment the only way to
    determine what events can be accepted by a class is to observe
    its state/activity model. Very clumsy!

    A workaround is to list events in the operations compartment
    and label them with an appropriate stereotype <<event>> for
    example. This should only be a temporary solution, since events
    are no more operations than they are attributes.

    Events need to be part of the class definition.

  • Reported: XMI 1.3 — Fri, 7 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parametrizable model elements not shown

  • Key: UML14-17
  • Legacy Issue Number: 1209
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 5.11.1 pg. 39 says "Parametrisation can be applied to other
    ModelElements". Implicitly not to all ModelElements. Which ModelElements
    can
    and which cannot be templates?
    Some clarifications would be welcome, in what concerns the
    parametrisation of other kind of model elements, such as packages,
    operations and methods.

  • Reported: XMI 1.0 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency regarding guards on forks

  • Key: UML14-119
  • Legacy Issue Number: 5745
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This applies to UML 1.4.1. ad/02-06-05. There seems inconsistency as to whether forks can have guards.
    The notation, section 3.9.4, states: "In Activity Diagrams, transitions outgoing from forks may have guards. This means the region initiated by a fork transition might not start, and therefore is not required to complete at the corresponding join. The usual notation and mapping for guards may be used on the transition outgoing from a fork."

    However this seems contradicted by Section 2.12.2.7, PseudoState, which states: "fork vertices serve to split an incoming transition into two or more transitions terminating on orthogonal target vertices. The segments outgoing from a fork vertex must not have guards."

    Is this a real inconsistency or do activity diagrams really override the constraint on Pseudostates in State Machines?

  • Reported: XMI 1.3 — Fri, 1 Nov 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

spelling of the word Use Case

  • Key: UML14-118
  • Legacy Issue Number: 5744
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    I have a question about the spelling of the word Use Case. The different
    >spellings used everywhere are a little bit irritating to me (but this may
    >not be the case for other people). I think that it should be one fixed
    >spelling of the word defined i UML. But even in the UML specification I
    >found three different spellings on the same side: Use Case, use case and
    >UseCase. In a book I'm reading they use the following spelling: Use Case
    >and, when used with other words, Use-Case (Realization for example).

  • Reported: XMI 1.3 — Fri, 25 Oct 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is an unnecessary condition in rule 1 of the Namespace element

  • Key: UML14-110
  • Legacy Issue Number: 5732
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There is an unnecessary condition in rule 1 of the Namespace element – “me2.name<>’’”. Also we should add the following condition to the OCL expression: “not me1.oclIsKindOf (Generalization) and not me2.oclIsKindOf(Generalization)”.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rule 6 of the Method element isn't formulated well

  • Key: UML14-109
  • Legacy Issue Number: 5731
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    Rule 6 of the Method element isn't formulated well. It’s better to write so: “self.owner.allMethods->select( me | me.operation = self.operation).size = 1”.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is a misprint in rule 2 of the Object element: “Stimuli” instead of “

  • Key: UML14-115
  • Legacy Issue Number: 5738
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There is a misprint in rule 2 of the Object element: “Stimuli” instead of “Stimulus”.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There are misprints with numeration of rules of the Instance element

  • Key: UML14-114
  • Legacy Issue Number: 5737
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There are misprints with numeration of rules of the Instance element

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

there is something wrong with rule 3 of the Trace element

  • Key: UML14-112
  • Legacy Issue Number: 5735
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    think there is something wrong with rule 3 of the Trace element. The “model” additional operation of the ModelElement element yields the set of Models to which it belongs. Maybe we should add “allModels” operation and use it in rule 4 of the Trace element.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The first sentence is not consistent with figure 2-9 on page 2-17

  • Key: UML14-120
  • Legacy Issue Number: 5763
  • Status: closed  
  • Source: Combitech Systems ( Per Tengdahl)
  • Summary:

    The first sentence is not consistent with figure 2-9 on page 2-17! It seems reasonable to accept the sentence and to clarify in figure 2-9 that the 'subject' end of the association has multiplicity "1.." and not "".

  • Reported: XMI 1.3 — Tue, 19 Nov 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong alphabetical order: DataValue section should be before DestroyAction

  • Key: UML14-113
  • Legacy Issue Number: 5736
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    Wrong alphabetical order: DataValue section should be before DestroyAction section.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add rule to Namespace element

  • Key: UML14-111
  • Legacy Issue Number: 5734
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    I think we should add the following rule to the Namespace element: “not self.allContents->includes(self)”.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is a misprint in rule 1 of the SubsystemInstance element

  • Key: UML14-116
  • Legacy Issue Number: 5739
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    There is a misprint in rule 1 of the SubsystemInstance element: “Stimuli” instead of “Stimulus

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

font sizes

  • Key: UML14-117
  • Legacy Issue Number: 5740
  • Status: closed  
  • Source: Anonymous
  • Summary:

    “self.stateMachine->notEmpty” and “and not oclIsKindOf(self.stateMachine, ActivityGraph))” are in different font size.

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Using or implementing an interface of a Subsystem

  • Key: UML14-69
  • Legacy Issue Number: 4619
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Problem: The specification part of the UML Subsystem element does not consider the two ways to make use of an interface: 1.) Direct calls. When a client subsystem should invoke operations of the subsystem. 2.) Notifications (extensions). When a client subsystem should receive notifications from the subsystem.

    Note that the static dependency can be directed the same way in both cases, but a call can either propagate along or against the dependency, depending on what subsystem that is implementing the interface. One-way static dependencies are crucial when a system should be easy to maintain. Therefore, one should distinguish between if a client needs to invoke an operation of the subsystem (implemented by the subsystem) or if the client should implement the interface in order to be notified by the subsystem. If needed, I can provide more information about how this can be seen.

    Suggestion: I introduced a usage dependency from the subsystem border to the interface in order to show that the subsystem provides and uses an interface which is to be implemented by a client subsystem that is to receive notifications.

    Background: I have been involved in different projects for Ericsson (the Telecom Business) and for the Swedish Airforce Defence Industry. Basically, the Subsystem modelling element is of great help when modelling large complex systems, such as Telecom systems for Radio Network Management. These systems do not only require robust software architectures, their architectures have to be considered on different architectural levels in order to reduce complexity. Also, the Subsystem modelling element is of great help when delegating and managing responsibility.

  • Reported: UML 1.4 — Mon, 15 Oct 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XML attribute "isPolymorphic" does not exist in UML 1.3 or UML 1.4 XMI DTD

  • Key: UML14-68
  • Legacy Issue Number: 4617
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The cited sections refer to the property "isPolymorphic" for operations of a class (2.5.4.3), operations in an interface (2.5.4.6), and receptions (2.9.2.17). Issue 1165 indicates that "Operation:isPolymorphic" was renamed to "Operation:isLeaf" in UML 1.3. The XML attribute "isPolymorphic" does not exist in either the UML 1.3 or UML 1.4 XMI DTD. The cited sections should be changed to accurately describe the means by which polymorphism is indicated.

  • Reported: UML 1.4 — Thu, 11 Oct 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Optimize Instance data values

  • Key: UML14-67
  • Legacy Issue Number: 4504
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Although the DataValue class claims to 'have no identity' it nonetheless inherits from ModelElement and is represented as a 'normal' object in the interchange as well as the logical metamodel (so will also inherit annotation and name - though presumably it's 'name' that is used to hold the actual value of the DataValue since no attribute seems to be actually defined for that purpose). And will it end up becming a first class object by default in most automatically-generated repositories or tool implementations.

    There are applictions of UML, and CWM which reuses it, which require a large number (several thousand) of data instances to be modeled - for which requiring a separate physical/interchange object for each data value is extremely inefficient. Not only does it double the number of objects, the DataValues have to be contained somewhere - which results in a parent package not only owning the Instance objects but a large number of DataValues also which must be filtered out if wanting to navigate from an Instance Model (for example) to its instances.

    Since a DataValue in practice has a 1-1 relationship with an AttributeLink, it is proposed that in the Interchange Model at least that DataValues be represented as a String attribute on AttributeLink. For forward compatibility it might be necessary to introduce a subclass of AttributeLink for this - which could even be called 'DataSlot' for compatibility with CWM (an equivalent proposal has been made to CWM RTF which uses 'Slot' instead of 'AttributeLink') And one could retain DataValue in deprecated mode.

    NB There is no practical benefit in having the current Link from dataValue to Classifier (DataType), since this is already linked from the Attribute (and the ability to record that a DataValue has a subtype of its Attribute's type seems too obscure in comparison to the cost).

  • Reported: XMI 1.2 — Thu, 16 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Component notation: showing delegation of messages

  • Key: UML14-66
  • Legacy Issue Number: 4465
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    The current notation does not provide for showing how method calls
    or messages to a component interface are delegated (or propagated) to the
    interfaces in components or implementation classes that reside in the
    component. This is sometimes referred to as the "wiring problem."

  • Reported: XMI 1.2 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: State containment problem

  • Key: UML14-75
  • Legacy Issue Number: 4729
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 metamodel, a State can either be contained as a
    "subvertex" in a CompositeState [UML 1.4, pp. 2-147], as the "top" state in
    a StateMachine [UML 1.4, pp. 2-147], or as an "ownedElement" [UML 1.4, pp.
    2-13] in a Model, Package, Artifact, Node or ClassifierRole (all other
    concrete subclasses of Namespace restrict their owned elements to exclude
    State). The latter containment does not seem to make a lot of sense.

    Fortunately, the description of a StateMachine states that "This means that
    a state machine owns its transitions and its top state. All remaining states
    are transitively owned through the state containment hierarchy rooted in the
    top state." [UML 1.4, pp. 2-153].

    The question is: does this mean that a State is restricted to being
    contained in a CompositeState or a StateMachine? If not, please explain the
    meaning of e.g. a State contained directly in an otherwise empty Package?

    If the mentioned restriction is intended, it should be stated
    unambiguously so in the wellformedness rules for State:

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: Action problem in Collaborations

  • Key: UML14-74
  • Legacy Issue Number: 4728
  • Status: closed  
  • Source: Anonymous
  • Summary:

    n UML 1.4, an Action is only used in the context of a StateMachine or a
    CollaborationInstanceSet.

    In a CollaborationInstanceSet, an Action is required as the cause of a
    Stimulus [UML 1.4, pp. 2-97], but since the Action can only be contained in
    a Namespace (or in the context of a StateMachine, which is irrelevant here),
    it cannot be contained in the Stimulus, nor in the Instances the Stimulus
    connect, nor in the InteractionInstanceSet or CollaborationInstanceSet they
    are part of. The "nearest" possible container is the Package that happens to
    contain the CollaborationInstanceSet.

    Intuitively, this makes no sense - used in this context, the Action is
    clearly part of the InteractionInstanceSet, or the participating Instances
    or Stimuli.

    If this error report is rejected, please elaborate on the intended
    containment structures for Collaboration instances.

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: Event containment problem

  • Key: UML14-80
  • Legacy Issue Number: 4734
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, an Event is defined as "...a
    specification of a type of observable occurrence" [UML 1.4, pp. 2-150]. It
    is used exclusively in the context of state machines, as triggers of state
    transitions [UML 1.4, pp. 2-147, fig. 2-24].

    Because Event is a direct subclass of ModelElement - and because no other
    composite containments are specified for Event or any of its subclasses - it
    must be compositely contained as an ownedElement in a ClassifierRole, Model.
    Package, Artifact or Node (all other concrete subclasses of Namespace have
    restricted their owned elements to exclude Event).

    The question is: is this containment intended, or should an Event be
    contained in e.g. the StateMachine in which it is used? If the currently
    allowed containment IS intended, please explain the semantics of e.g. an
    Event contained in an otherwise empty Package (or even Model).

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: Stimulus containment

  • Key: UML14-79
  • Legacy Issue Number: 4733
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, a Stimulus is a ModelElement representing
    a communication between two instances [UML 1.4, pp. 2-106]. It is used
    exclusively in the context of collaborations, as part of an
    InteractionInstanceSet [UML 1.4, pp. 2-120].

    Because Stimulus is a direct subclass of ModelElement - and because no other
    composite containments are specified for Stimulus - it must be compositely
    contained as an ownedElement in a ClassifierRole, Model. Package, Artifact
    or Node (all other concrete subclasses of Namespace have restricted their
    owned elements to exclude Stimulus).

    Having the Stimulus be part of any of these classes makes no sense, as it is
    intuitively part of the InteractionInstanceSet.

    Proposed remedy: change the association between InteractionInstanceSet and
    Stimulus [UML 1.4, pp. 2-120, diagram 2-20] to a mandatory composite
    containment (with Stimulus as the part).

    Alternatively, please clarify the intended semantics of each of the
    currently allowed containments listed above

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: Transition containment problem

  • Key: UML14-77
  • Legacy Issue Number: 4731
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, a Transition [UML 1.4, pp. 2-147] is
    contained either as an "internalTransition" in a State, as a "transition" in
    a StateMachine, or as an "ownedElement" [UML 1.4, pp. 2-13] in a Model,
    Package, Artifact, Node or ClassifierRole (other containers excluded because
    of restrictions they make on the "ownedElement" containment in their
    wellformedness rules). The latter containment does not seem to make a lot of
    sense.

    The question is: is the containment of a Transition as an "ownedElement"
    intended? If so, please explain the meaning of e.g. a Transition contained
    directly in an otherwise empty Package.

    If not, it should be stated unambiguously so in the wellformedness rules for
    Transition, e.g.:

    self.namespace = null

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: ExtensionPoint containment problem

  • Key: UML14-76
  • Legacy Issue Number: 4730
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 metamodel, an ExtensionPoint [UML 1.4, pp. 2-135]
    can be contained as an ownedElement [UML 1.4, pp. 2-13] in a Model, Package,
    Artifact, Node or ClassifierRole (other containers excluded because of
    restrictions they make on the "ownedElement" containment in their
    wellformedness rules).

    The questions are: what is the intended meaning of an ExtensionPoint in eg.
    an otherwise empty Package? Why isn't the ExtensionPoint contained in the
    UseCase it extends, as would appear more logical to the uninitiated?

    Suggestion: change the association between ExtensionPoint and UseCase [UML
    1.4, pp. 2-135] to an unconditional composite containment (with
    ExtensionPoint as the part).

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: Feature containment problem

  • Key: UML14-78
  • Legacy Issue Number: 4732
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to the UML 1.4 standard, a Feature [UML 1.4, pp. 2-13] is
    contained either as an "feature" in a Classifier, or as an "ownedElement"
    [UML 1.4, pp. 2-13] in a Model, Package, Artifact, Node or ClassifierRole
    (other containers excluded because of restrictions they make on the
    "ownedElement" containment in their wellformedness rules). In addition an
    Attribute (subclass of Feature) may be contained as a "qualifier" in an
    AssociationEnd [UML 1.4, pp. 2-14].

    The question is: is the containment as an "ownedElement" intended? If so,
    please explain the meaning of e.g. an Operation contained directly in an
    otherwise empty Package.

    If not, it should be stated unambiguously so in the wellformedness rules for
    Feature:

    self.namespace = null

    Remarks:
    ========
    It should be noted that the standard does make a number of partly
    contradictory statements which seem to indicate that Features can not be
    used as ownedElements:

    Page 2-25: "BehavioralFeature specifies a behavioral aspect of a
    Classifier."
    Page 2-36: "A feature [...] is encapsulated within a Classifier."
    [contradicts with the statement below].
    Page 2-37: "Note that an Attribute may be owned by a Classifier (in which
    case it is a feature) or an AssociationEnd (in which case it is a qualifier)
    but not both."
    Page 2-42: "Method is a declaration of a named piece of behavior in a
    Classifier"
    Page 2-45: "Operation is a BehavioralFeature that can be applied to the
    Instances of the Classifier that contains the Operation.".

    These statements could however be made unambiguous by adding the mentioned
    wellformedness rule.

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Compliance to the UML" pp xxxi -- Editorial?

  • Key: UML14-72
  • Legacy Issue Number: 4662
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I was just reading the intro to UML 1.4, and may have found a typo. In the
    "Compliance to the UML" pp xxxi, it shows a table of package dependencies
    and states that complying with a package requires compliance with it's
    dependent packages.

    Core is shown as dependent on Data Types and Extension Mechanisms, and
    Extension Mechanisms is shown as dependent on Data Types and Core, leading
    to a circular relationship.

  • Reported: UML 1.4 — Sun, 21 Oct 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Nameclash in UML 1.4

  • Key: UML14-71
  • Legacy Issue Number: 4645
  • Status: closed  
  • Source: University of Technology, Sydney ( Brian Henderson-Sellers)
  • Summary:

    As far as I can see there is a name clash in UML 1.4.
    <<implementation>> is used as both
    (1) a stereotype of Generalization to mean implementation (or private)
    inheritance
    and
    (2) a stereotype of Class to mean the coding or implementation details of
    a Class

  • Reported: UML 1.4 — Sat, 27 Oct 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Using OCL at the meta-model level

  • Key: UML14-70
  • Legacy Issue Number: 4626
  • Status: closed  
  • Source: Colorado State Univ, Dept of Computer Science ( Robert France)
  • Summary:

    A. page 2-55; 2.5.3.6 Binding
    constraint [1]

    self.client.oclIsKindOf(self.supplier)

    Using my current understanding of OCL this seems wrong for the following
    reason:
    1. self.client returns an element at the M1 level (a UML model construct)
    2. the oclIsKindOf predicate compares the type of self.client
    (I assume the type of self.client is a metaclass at the M2 level) with the
    argument (which I assume from the definition of the predicate
    is a type and is thus an M2 element).
    3. self.supplier is not an M2 element.

    B. page 2-61 constraint [5] (similar comments as above)

    Am I misinterpreting self, OclIsKindOf, ...?

  • Reported: UML 1.4 — Wed, 17 Oct 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4: Action containment error

  • Key: UML14-73
  • Legacy Issue Number: 4727
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Because Action is a ModelElement, it may be contained as an ownedElement
    [UML 1.4, pp. 2-13, fig. 2-5] in a ClassifierRole, Model, Package, Artifact,
    Node or Collaboration (all other concrete subclasses of Namespace restrict
    their owned elements to exclude Action).

    Because Actions are only used in the context of either a StateMachine or a
    CollaborationInstanceSet, this containment does not seem to make sense.

    In order to exclude these containments, the wellformedness rules for Action
    could include the following statement:

    self.namespace = null

  • Reported: XMI 1.3 — Wed, 5 Dec 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Guard in current metamodel can be replaced by Constraint with stereotype

  • Key: UML14-19
  • Legacy Issue Number: 2020
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Guard metatype in the current metamodel contains only one attribute
    of type BooleanExpression. Since a guard is semantically equivalent to
    a Constraint on the transition, we can remove the Guard metaclass and
    add e standard stereotype <<guard>> for Constraints, with the same
    semantics.

    It simplifies the metamodel by unifying the Guard and Constraint concepts.
    It also allows OCL as the optional language to write the guard expression.

    Within the OCL specification, it should be checked if there are any
    additions that need to be made to support everything neded to express
    udseful guards.

  • Reported: XMI 1.0 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need for notation for dealing with evolution of UML models

  • Key: UML14-18
  • Legacy Issue Number: 1512
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is a need for a notation for dealing with evolution of UML models. Currently, UML does not provide adequate support for dealing with evolution of software components in a disciplined way. With disciplined evolution we mean that there should be a general mechanism to express how a modelling element evolves over time by adding, removing or changing parts of it. In the current version of UML, 2 mechanisms could be used to describe the evolution process, but they both have their shortcomings:

  • Reported: XMI 1.0 — Mon, 8 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing OCL

  • Key: UML14-25
  • Legacy Issue Number: 2289
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I would like to note that in the UML Semantics specification (versions 1.1
    and 1.2) the third well-formedness rule for Association does not have an
    OCL expression. It has only the natural language expression.

  • Reported: XMI 1.0 — Tue, 5 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OCL needs to be added

  • Key: UML14-24
  • Legacy Issue Number: 2278
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Only binary associations may be aggregates. There needs to
    be OCL added to do this.

  • Reported: XMI 1.0 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Add the missing OCL

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ElementOwnership

  • Key: UML14-26
  • Legacy Issue Number: 2290
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In UML versions 1.1, 1.2, and 1.3 the class diagram for the Core Backbone
    declares ElementOwnership as an AssociationClass. This appears to be a
    violation of MOF compliance, since the MOF meta-meta-model does not support
    the notion of an AssociationClass.

    Of course one could extrapolate AssociationClass from the MOF
    meta-meta-model since it does support both Association and Class, and one
    could also logically extrapolate a MOF-IDL and MOF-XML mapping for an
    extrapolated MOF AssociationClass. However, two architects might
    extrapolate these mappings in perfectly valid but different manners, since
    there is no standard mapping for a MOF AssociationClass. Apparently such
    an extrapolation has been performed in order to derive the IDL for the UML
    meta-model that concerns ElementOwnership, but doing this without a
    standard mapping seems dangerous.

  • Reported: XMI 1.0 — Tue, 5 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

extension to the notation for a transition

  • Key: UML14-28
  • Legacy Issue Number: 2336
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I would like to make an appeal for an extension to the notation for a transition
    to allow its effect to be specified declaratively rather than only imperatively by
    means of an action sequence, e.g.

    e() / [p]

    While I realize there are ways to work around this (e.g. by writing "e() / pTrue()"
    where the query pTrue() has the postcondition "result = p and in targetState"), I
    think the issues are readability and ease of use.

  • Reported: XMI 1.0 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 19 semantic doc. name

  • Key: UML14-23
  • Legacy Issue Number: 2277
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 19 semantic doc. name is described here but is not shown as
    a metalevel attribute on Figure 6. It should be.

  • Reported: XMI 1.0 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.1.section 4.2:editorial

  • Key: UML14-22
  • Legacy Issue Number: 2276
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Aggregation: "when on target end, specifies whether target end
    with respect to source end". I think target and source are the wrong
    way round here.

  • Reported: XMI 1.0 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

User-defined symbols for tagged values and properties

  • Key: UML14-27
  • Legacy Issue Number: 2291
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML allows users to define specific symbols and icons for stereotypes. It should also be allowed to define specific symbols and icons for tagged values and properties. For example, users that often use the properties

    {ordered}

    ,

    {frozen}

    and

    {add only}

    may define they own user-defined icons for those properties, because UML does not define them.

    Suggested Solution:
    UML users should be allowed to define specific symbols and icons for tagged values and properties.

  • Reported: XMI 1.0 — Wed, 6 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Associate a predicate with a state

  • Key: UML14-29
  • Legacy Issue Number: 2337
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Related to the previously submitted issue regarding the declarative specification of
    the effects of transitions, I would like to suggest that it be possible to associate
    a predicate with a state.

    Such a predicate (e.g. written in OCL) would appear within the state box in the
    notation, just below the name of the state.

    Rather than extend the notation directly, I suggest this be a predefined property,
    e.g.

    {predicate = boolean-expression}

    .

  • Reported: XMI 1.0 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 7 p. 43 of the UML semantics guide

  • Key: UML14-21
  • Legacy Issue Number: 2208
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On Figure 7 p. 43 of the UML semantics guide,
    Template is described as a shared aggregate of its templateParameters,
    while Binding (representing an instantiation of a Template) is described
    as a composite aggregate of the actual arguments.

  • Reported: XMI 1.0 — Fri, 13 Nov 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AssociationEnd needs ownerScope

  • Key: UML14-20
  • Legacy Issue Number: 2083
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I believe AssociationEnd needs an ownerScope attribute. How else could one
    model a static (as in Java) relationship? Currently, it appears to only be
    possible using an Attribute of Classifier.

  • Reported: XMI 1.0 — Thu, 15 Oct 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

running a “Check Model” in Rose you get the following errors

  • Key: UML14-151
  • Legacy Issue Number: 6089
  • Status: closed  
  • Source: Anonymous
  • Summary:

    When running a “Check Model” in Rose you get the following errors. Of which I am sure you are aware of. But do these errors indicate the absence of the parent element in the particular package or should the Specialize relation be deleted?

    12:52:41| [Check Model]

    12:52:42| Error: Unresolved reference from Package "Profiles"

    12:52:42| to Item with name ::Constructs::Packages

    12:52:42| by Dependency "<unnamed>".

    12:52:42| Error: Unresolved reference from Package "Profiles"

    12:52:42| to Item with name ::Constructs::Classes

    12:52:42| by Dependency "<unnamed>".

    12:52:42| Error: Unresolved reference from Package "Collaborations"

    12:52:42| to Item with name ::Deleted::Infrastructure_v069 (old)::Core

    12:52:42| by Dependency "<unnamed>".

    12:52:42| Error: Unresolved reference from Package "InternalStructures"

    12:52:42| to Item with name ::Deleted::Infrastructure_v069 (old)::Core

    12:52:42| by Dependency "<unnamed>".

    12:52:42| Error: Unresolved reference from Package "CompositeStructures"

    12:52:42| to Item with name ::Deleted::Infrastructure_v069 (old)::Core

    12:52:42| by Dependency "<unnamed>".

    12:52:42| Error: Unresolved reference from Class "ActivityEdge"

    12:52:42| to Item with name Logical View::UML::Behavior::Use Cases::ExtensionPointReferenceableElement

    12:52:42| by Generalize "<unnamed>".

    12:52:42| Error: Unresolved reference from Class "OutputPin"

    12:52:42| to Item with name Logical View::UML::Infrastructure::Core::Foundation::Classifiers::TypedElement

    12:52:42| by Generalize "<unnamed>".

    12:52:42| Error: Unresolved reference from Class "Message"

    12:52:42| to Item with name Logical View::UML::Behavior::Use Cases::ExtensionPointReferenceableElement

    12:52:42| by Generalize "<unnamed>".

    12:52:42| Error: Unresolved reference from Class "Type"

    12:52:42| to Item with name Logical View::InfrastructureLibrary::Core::Constructs::Type

    12:52:42| by Generalize "<unnamed>".

    12:52:42| Error: Unresolved reference from Class "State"

    12:52:42| to Item with name Logical View::UML::Behavior::Use Cases::ExtensionPointReferenceableElement

    12:52:42| by Generalize "<unnamed>".

  • Reported: UML 1.5 — Sat, 9 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify wording on executable activity nodes

  • Key: UML14-154
  • Legacy Issue Number: 6092
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Name: Jim Frank
    Company: IBM
    mailFrom: joachim_frank@us.ibm.com
    Nature: Clarification
    Severity: Significant
    Subject: Clarify wording on executable activity nodes

    In the Activities chapter, an action "is an executable activity node
    that is the fundamental unit of executable functionality in an activity,
    as opposed to control and data flow among actions." Aren't control and
    data flow required to execute an action? The clause after the comma
    should be removed, and perhaps replaced with a sentence saying actions
    are used with control/data flow.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Outgoing edges from input pins

  • Key: UML14-153
  • Legacy Issue Number: 6091
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    (Quote from Semantics of CompleteStructuredActivities) "An object
    node attached to a structured activity node is accessible within the
    node. The same rules apply as for control flow. An input pin on a
    structured activity node implies that no action in the node may begin
    execution until all input pins have received tokens. An output pin on
    a structured activity node will make tokens available outside the
    node only after no tokens left in the node or its contained nodes
    recursively."

    So input pins on structured activity nodes are "accessible within the
    node" (as one would expect), but a constraint on InputPin says "input
    pins have incoming edges only". So how are they accessed from within
    the structured activity node? Analogous question for output pins of
    structured activity nodes, which can have outgoing edges only.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 super/pg. 580/Stereotype typo

  • Key: UML14-150
  • Legacy Issue Number: 6076
  • Status: closed  
  • Source: Daimler AG ( Mario Jeckle)
  • Summary:

    The second paragraph of subsection "Notation" reads "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 the name of the Stereotype."

    I think the sentence should end with "... name of the model element".
    Otherwise the stereotype's name would be mentioned twice.

  • Reported: UML 1.5 — Wed, 27 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    End the sentence with “name of the model element”.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 super/pg.470/entry and exit points for composite states

  • Key: UML14-149
  • Legacy Issue Number: 6075
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Two OCL constraints for entry and exit pseudostates of state machines (numbered [9] and [10]) only allow these psuedostates to be defined for the topmost regions of a state machine. This restriction is completely unnecessary and precludes common design patterns and should be removed. (In fact, from discussions with the authors of the spec, it seems that they were included due to a misunderstanding between two of the authors.)

  • Reported: UML 1.5 — Fri, 22 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicities diagram in section 7.4

  • Key: UML14-148
  • Legacy Issue Number: 6074
  • Status: closed  
  • Source: DeveloPeer Inc. ( Javier Estrada)
  • Summary:

    The Multiplicities diagram in section 7.4 defines two associations with ValueSpecification, namely upperValue and lowerValue. However, the constraints stated in section 7.4.1 for MultiplicityElement, are defined in terms of upperBound() and lowerBound()

  • Reported: UML 1.5 — Tue, 19 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Action should be concrete

  • Key: UML14-156
  • Legacy Issue Number: 6094
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Action should be concrete. The description of the "effect" attribute
    says: "An optional text specification of the effect of the action. This
    may be used to indicate the behavior of an action without specialization
    into a subclass, ... " We think this is a good concept, and would like
    to instantiate Action for activity nodes whose behavior is only verbally
    described. Behavior, too.

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    In Figure 176, make Action concrete.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Edge constraint for control nodes

  • Key: UML14-155
  • Legacy Issue Number: 6093
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The constraint for ControlNode ("The edges coming into and out of a
    control node must be either all object flows or all control flows.") is
    inconsistent with the semantics for JoinNode, which permit mixed types
    of incoming edges. Likewise a merge node can merge control and data
    flows. What type of edge should be outgoing in this case?

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Remove constraint [1] for Control Node, p 317.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Strange notation in Figure

  • Key: UML14-146
  • Legacy Issue Number: 6072
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    The figure showing a use case with an associated state machine behaviour use lozenges (rectangles with rounded ends). This notation is obsolete

  • Reported: UML 1.5 — Thu, 21 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Variable and Pin multiplicity

  • Key: UML14-152
  • Legacy Issue Number: 6090
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The text refers to multiplicity of Variable and Pin, but they do not
    inherit from MultiplicityElement

  • Reported: UML 1.5 — Sat, 30 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No Glossary in 03-08-02

  • Key: UML14-147
  • Legacy Issue Number: 6073
  • Status: closed  
  • Source: CA Technologies ( Andrew Haigh)
  • Summary:

    The certification includes the glossary. However, it is missing from 03-08-02, it was there in in 03-07-06.

  • Reported: UML 1.5 — Thu, 21 Aug 2003 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Initial state for composite states - OCL example and missing constraint

  • Key: UML14-100
  • Legacy Issue Number: 5273
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    This issue was triggered by what seemed to be an ill-formed state machine
    example which revealed a deeper lack of rigor in the spec.

    The example state machine in section 6.5.10 (illustrating oclInState) does
    not have an initial pseudostate within the 'Off' state. Section 3.80.2
    indicates that this is mandatory:
    "A transition drawn to a composite state boundary indicates a transition to
    the
    composite state. This is equivalent to a transition to the initial
    pseudostate within the
    composite state region. The initial pseudostate must be present."

    [Aside: There's also typo in the list of valid OCL expressions in 6.5.10:
    object.oclInState(Off:NoPower) should have a double colon:
    object.oclInState(Off::NoPower)].

    If indeed it is mandatory to have an initial state where there is a
    transition to a composite state (this does seem sensible for
    predictability), this should be reflected in a constraint within the
    abstract Syntax (section 2.12) to the effect that a CompositeState with
    'incoming' Transitions must contain an initial PseudoState.

    For example 2.12.4.3 contains the following which implies an initial
    pseudostate, though uses the ill-defined 'default transition' as well as
    'initial transition':
    "Entering a non-concurrent composite state
    Upon entering a composite state, the following cases are differentiated:
    • Default entry: Graphically, this is indicated by an incoming transition
    that
    terminates on the outside edge of the composite state. In this case, the
    default
    transition is taken. If there is a guard on the transition it must be
    enabled (true). (A
    disabled initial transition is an ill-defined execution state and its
    handling is not
    defined.) The entry action of the state is executed before the action
    associated with
    the initial transition."

    Proposed Resolution
    -------------------

    1. Change example in 6.5.10 to add an initial pseudostate within the 'Off'
    composite with a transition to 'Standby'.

    2. Correct typo in 6.5.10 valid expressions: object.oclInState(Off:NoPower)
    should have a double colon: object.oclInState(Off::NoPower)

    3. Add the following constraint to section 2.12.3.1
    [7] A composite state with an incoming transition must have an initial
    state.
    self.incoming->notEmpty() implies
    self.subvertex->select (v | v.oclIsKindOf(Pseudostate))->select(p :
    Pseudostate | p.kind = #initial)->size = 1

    4. Alter the section in 2.12.4.3 to read as follows:
    "Entering a non-concurrent composite state
    Upon entering a composite state, the following cases are differentiated:
    • Default entry: Graphically, this is indicated by an incoming transition
    that
    terminates on the outside edge of the composite state. In this case, there
    must be an initial state and the initial
    transition is taken. If there is a guard on the transition it must be
    enabled (true). (A
    disabled initial transition is an ill-defined execution state and its
    handling is not
    defined.) The entry action of the state is executed before the action
    associated with
    the initial transition."

  • Reported: XMI 1.3 — Thu, 9 May 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4 - Partition relates to nothing

  • Key: UML14-99
  • Legacy Issue Number: 5269
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    UML 1.4 has no association for showing what a Partition relates to.
    Typically this would be something representing a role in a process.

  • Reported: XMI 1.3 — Tue, 7 May 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In v1.4, section 3.84.1 the paragraph on semantics

  • Key: UML14-104
  • Legacy Issue Number: 5657
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    "An Activity Diagram is a special case of a state machine in which the
    states represent performance of actions or subactivitities and the
    transitions are triggered by the completion of actions or subactivities. It
    represents the state machine of a procedure itself."

    But in Section 2.13.1 it says:

    "An activity graph is a special case of a state machine that is used to
    model processes involving one or more classifiers. Its primary focus is on
    the sequence and conditions for the actions that are taken, rather than on
    which classifiers perform those actions. Most of the states in such a graph
    are action states that represent atomic actions; that is, states that invoke
    actions and then wait for their completion. Transitions into action states
    are triggered by events, which can be

    • the completion of a previous action state (completion events),
    • the availability of an object in a certain state,
    • the occurrence of a signal, or
    • the satisfaction of some condition.
      "

    The latter statement implies that (a) events other than completion of prev
    activity can be triggers and (b) entire processes, not just procedures can
    be modeled in ADs.

    Which one is it?

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 2.13.4.3

  • Key: UML14-103
  • Legacy Issue Number: 5656
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    2) Section 2.13.4.3 says

    "Unless there is an explicit "fork" that creates orthogonal obect
    states only one of an object flow state's outgoing transitions will fire as
    determined by the guards of the transitions",

    which seems to require that if you want to "feed" the object to multiple
    actions, you will need a "fork" bar. But then 3.90.2.2 says:

    "The same object may be (and usually is) the output of one action
    and the input of one or more subsequent actions".

    This would seem to suggest that a "fork" bar is not required. Please
    clarify.

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Issue - Inconsistency between UML 1.3 XMI and DTD

  • Key: UML14-101
  • Legacy Issue Number: 5525
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The UML 1.3 DTD implies a reference ModelElement.taggedValue which does not
    exist in the UML metamodel XMI file. This causes problems for my product
    which is metamodel-driven so reports an error when an import attempts to
    supply a value for the non-existent reference. This is strictly speaking a
    bug in the DTD (since it's not generated according to the XMI rules):
    however changing the DTD might cause inconvenience for vendors who are
    making use of it, and because not having the reference would make processing
    the tags much harder.

    At UML 1.4 the reference has been added to the metamodel, which suggests
    that the metamodel rather than the DTD be fixed. However this could require
    a restructuring to avoid circular package dependencies [see UML issue 3735].

    The same issue applies to the 'stereotype' reference on ModelElement - again
    it should ideally be added to the metamodel.

    The reason I'm raising the issue on UML 1.3 is that this is the chosen
    version for interoperability work. A decision is needed as to which way to
    resolve the inconsistency within UML 1.3 without forcing an upgrade to UML
    1.4.

  • Reported: XMI 1.3 — Fri, 19 Jul 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section number duplicated

  • Key: UML14-107
  • Legacy Issue Number: 5685
  • Status: closed  
  • Source: Alcatel-Lucent ( Julien Maisonneuve)
  • Summary:

    Probably an Action Semantics RTF Issue, but one that may be addressed
    in an UML RTF.

    In the UML 1.5 spec in the action semantics chapter, sections numbers
    2.16 and 2.17 are duplicated. The section content appears all right
    but the succession of titles is : 2.15, 2.16, 2.17, 2.16, 2.17, 2.18.

    The document simply needs consistent renumbering of that chapter.

  • Reported: XMI 1.3 — Mon, 14 Oct 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 3.90.2.2

  • Key: UML14-106
  • Legacy Issue Number: 5659
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    Section 3.90.2.2 says

    "In other words when a state prodices an outpout that is input to the
    subsequent state, that object flow relationship implies a control
    constraint."

    I take it that this is not the same as isSynch being true? That is isSynch
    means that an object in an object flow is rather like a token in a Petri
    net. ie once it flows out to the consuming state, its gone from its place.
    Is that correct?

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Well-formedness rules 4 and 6 on 2.12.3.4 PseudoState

  • Key: UML14-97
  • Legacy Issue Number: 5267
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Well-formedness rules 4 and 6 on 2.12.3.4 PseudoState make incorrect use of
    oclIsKindOf, which should only take a single argument.

  • Reported: XMI 1.3 — Tue, 7 May 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A_context_raisedSignal

  • Key: UML14-96
  • Legacy Issue Number: 5005
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    The
    association in question is not named in the UML 1.4 interchange model. The
    name "A_context_raisedSignal", is an artificial one that was created by the
    program that created the DTD. It was using an algorithm recommended by the
    MOF RTF for naming unnamed associations. However, it would seem to be wise
    policy for this association to have a name. This would remove any
    dependency on the vagaries of various MOF tools.

  • Reported: XMI 1.3 — Tue, 19 Mar 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How does one indicate the target object for a CallState

  • Key: UML14-102
  • Legacy Issue Number: 5655
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    How does one indicate the target object for a CallState (i.e. the actual
    object that executes the stated action/method)? If the target action takes
    no parameters then it may be possible to say that the target object is just
    the object flowing into the CallState. But what if it does take parameters?
    (e.g. the Person.Drive(to: Place) example in Fig. 3-88). That would require
    more than one object to be flowing into the CallState and leads to an
    ambiguity about which constitutes the target and which the parameter.

    P.S. The actual object may be passed around by the activity diagram, so it
    is not possible to show it statically on a swimlane (even if that is the
    recommended way)

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

parameters of object flow states

  • Key: UML14-105
  • Legacy Issue Number: 5658
  • Status: closed  
  • Source: Texas Department of Human Services ( Srinivas Nedunuri)
  • Summary:

    parameters of object flow states – The Notation section of the UML 1.4
    Spec does not discuss it, nor is an example provided. I am still in the dark
    about how parameters are supposed to be used in the context of object flow
    states. Are output parameters supposed to be like reference parameters in
    the Algol style languages?

  • Reported: XMI 1.3 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Well-formedness rules for 2.12.3.8

  • Key: UML14-98
  • Legacy Issue Number: 5268
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Well-formedness rules for 2.12.3.8 Transition numbered 1, 3 and 4 make
    incorrect use of oclIsKindOf, which only takes one argument.

  • Reported: XMI 1.3 — Tue, 7 May 2002 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Swap rule 2 and rule 3 of the Binding element

  • Key: UML14-108
  • Legacy Issue Number: 5730
  • Status: closed  
  • Source: St. Petersburg State Technical University ( Nikolai Andreev)
  • Summary:

    Swap rule 2 and rule 3 of the Binding element. It improves readability

  • Reported: XMI 1.3 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF rules should disallow certain composition relationships

  • Key: UML14-49
  • Legacy Issue Number: 3735
  • Status: closed  
  • Source: Anonymous
  • Summary:

    MOF rules should disallow composition relationships in instance metamodels
    where the container is in one MOF Package and the contained item is in
    another MOF Package and a dependency of the first package on the second is
    not allowed by the physical version of the metamodel due to MOF-imposed IDL
    generation rules.

    Reason for the issue:

    In the process of implementing an XMI-based interchange for UML 1.3, I have
    encountered a serious problem.

    This problem has to do with a divergence between the "Logical" and
    "Physical" model for UML 1.3 caused by rules imposed by MOF.

    In particular, in section 5.5 of the MOF 1.3 specification (27 Sep 99
    version), "Preconditions for IDL Generation", requires that there be no
    cyclical dependencies between ModelElements in a meta-model.

    However, the UML 1.3 specification (June 1999) has a cyclical dependency
    between the Core and the Extension Mechanisms packages in the metamodel (See
    Figure 2-4). This cyclical dependency is explicitly disallowed by the
    precondition cited above.

    This circular dependency was removed from the "Physical Model" for UML 1.3
    in order to allow CORBA IDL and XMI DTD declarations in conformance with the
    precondition. As a result of the removal of this dependency, there are
    tremendous difficulties expressing the composition relationship between the
    UML ModelElement and the UML Tagged Value (see figure 2-10). In fact, the
    TaggedValue XML elements cannot even be in the exported UML Package element
    – they must be placed outside of it. This greatly complicates the export
    and import of UML 1.3 model files.

  • Reported: UML 1.3 — Fri, 30 Jun 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for inherited associations

  • Key: UML14-48
  • Legacy Issue Number: 3682
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    The CWM submitters needed to display inherited associations on some class
    diagrams to enhance understandability. These were not intended to be
    derived associations; that is, there was no intention to specify additional
    computational machinery when showing these inherited associations.
    Unfortunately, the MOF and UML have no succint way to display inherited
    associations. The CWM submitters placed the "/" derived prefix on the
    association end names in the class diagrams. At the same time, in order to
    prevent the generation of additional computational machinery, they omitted
    the inherited association from the normative XMI rendition of the metamodel.
    This was probably a reasonable choice under the circumstances. However, it
    means that the class diagrams and the XMI representation of the metamodel
    conflict with one another.

    It is very common to need to show inherited associations on a class diagram.
    We ran into this when we specified the CORBA metamodel for the CORBA
    Component Model submission. We used derived associations in the class
    diagrams as well. However, we retained the derived associations in the XMI
    rendition of the metamodel. In order to prevent additional computational
    machinery from being generated, we stereotyped the associations as
    <<implicit>>. This stereotype is defined in the UML specification but not
    in the MOF specification and says that an association is only conceptual and
    not manifest. We then made sure that the generator producing the IDL and
    XML DTDs was sensitive to the <<implicit>> stereotype. This had the
    advantage of maintaining consistency between the class diagrams and the XMI
    rendition of the metamodel. Of course this is also a non-standard
    approach--since <<implicit>> is not defined in the MOF, we can't expect MOF
    generators to understand it.

    The lack of a standard means for representing inherited associations in
    class diagrams is thus resulting in a proliferation of non-standard
    approaches in adopted OMG metamodels. This could become unmanageable as the
    number of metamodels grows. A standard means should be specified.

  • Reported: UML 1.3 — Mon, 3 Jul 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Conflicting constraint between ActivityGraph and StateMachine.

  • Key: UML14-52
  • Legacy Issue Number: 4083
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    Since an ActivityGraph is derived from a StateMachine its
    constraints must be consistent with that of a StateMachine. If an
    ActivityGraph has a Package as its context it violates the constraint
    inherited from StateMachine.

    ActivityGraph Constraint (Semantics 2.13.3, Pg. 2-188):
    (self.context.oclIsTypeOf(Package) xor
    self.context.oclIsKindOf(Classifier) xor
    self.context.oclIsKindOf(BehavioralFeature))

    StateMachine Constraint (Semantic 2.12.3, Pg. 2-165) :
    self.context.oclIsKindOf(BehavioralFeature) or
    self.context.oclIsKindOf(Classifier)

    One way to avoid this problem is to change the StateMachine constraint to be
    applicable when self is oclIsTypeOf(StateMachine) so the constraint is not
    applied to it children.

    A general mechanism to disable inherited constraints could also solve the
    problem.

  • Reported: UML 1.3 — Wed, 29 Nov 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Attributes obsolete in UML 1.3

  • Key: UML14-51
  • Legacy Issue Number: 3999
  • Status: closed  
  • Source: Anonymous
  • Summary:

    the association between StructuralFeature and Classifier should be
    removed. Attributes can not describe more information than
    Associations/AssociationEnds can. Therefore it is obsolete and confuses
    the user of UML, which to choose when modeling.

    On page 3-40 in the UML 1.3 specification it says: "Note that an
    attribute is semantically equivalent to a composition association;
    however, the intent and usage is normally different."

    If the semantics are equivalent, then it is impossible to distinguish
    between them. There is no extra layer of meaning above the semantics
    layer that can distinguish between two things with equal semantics.
    Semantics is meaning. I think this sentence is contradictory. I have not
    been able to find out what the difference in "intent and usage" is. If
    this is defined, it will obviously make the semantics of the two
    different.

    To improve the readability of class diagrams when everything is
    associations, I propose that associations should be possible to
    represent as text in the compartment where attributes are written today.

  • Reported: UML 1.3 — Wed, 25 Oct 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface of an object

  • Key: UML14-50
  • Legacy Issue Number: 3783
  • Status: closed  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    This is a request for an interpretation of UML 1.3.

    The question is: Is there a UML 1.3 model element that represents the concept of an interface on an object?

    -------- Background -------

    Evidently the way to get an interpretation of the meaning of an OMG specification is this: "If you file the interpretation request as an issue against the relevant FTF/RTF then the resolution will be your interpretation."

    The UML submission said:

    "... An interface is only a collection of operations with a name; it cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..."

    "UML objects are not modeled as presenting interfaces. A UML interface is not instantiable, so there is not a UML model element that corresponds directly to the interface of an OMG object."

    UML 1.3 says:

    "2.5.4 Semantics

    "Interface

    "... An interface is only a collection of operations with a name. It cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..."

    In UML 1.3, there are Instance and Link, which stand for instances of Classifier and Association. Instance includes DataValue, NodeInstance, ComponentInstance, Object, and LinkObject. SubsystemInstance has been proposed for UML 1.4. There is not any model element that is a subtype of Instance and corresponds to Interface. (That is, the association, classifier, of Instance and Classifier does not associate any model element with Interface.)

    [It is clear that a UML model may include an object that is an instance of a class that realizes an interface.]

    --------

    I am hoping this is easy to interpret and can be resolved quickly.

  • Reported: UML 1.3 — Tue, 15 Aug 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Why is a StateMachine's top a State instead of a CompositeState?

  • Key: UML14-46
  • Legacy Issue Number: 3569
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    Every StateMachine must have one top State. However, there is an
    OCL constraint that says that the top State must be a CompositeState
    (Semantics 2.12.3 Well-FormednessRules, StateMachine Section, rule [2], p
    2-141). So, why not make the top relationship from StateMachine to
    CompositeState instead of from StateMachine to State. The constraint can
    then be eliminated.

  • Reported: UML 1.3 — Tue, 18 Apr 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4 RTF Issue: Multiple languages for uninterpreted strings

  • Key: UML14-45
  • Legacy Issue Number: 3391
  • Status: closed  
  • Source: ObjectSwitch ( Conrad Bock)
  • Summary:

    Multiple languages for uninterpreted strings

    The various places that uninterpreted strings are used in UML should
    support multiple languages. For example, the Expression metaclass has
    an metaattribute for language and another for the uninterpreted string.
    This should be a set of such pairs. Then code generators can target
    multiple languages from the same model.

  • Reported: XMI 1.1 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    resolved, see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Efficient diagrammatic notation for Collaboration Specifications

  • Key: UML14-42
  • Legacy Issue Number: 3368
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I have played a lot with different ways of showing how several collaboration specifications may appear in one class diagram.

    Right now, there are collaboration specification diagrams, and there are class diagrams that feature template instantiations, but no class diagrams that feature collaboration specifications. If you use a round ellipse for hooking up a collaboration specification into a class diagram, you will see ellipses all over the place, but will not see how the collaboration specifications relate to the associations between the classes.

    I can show you the variations of how to draw collaboration specifications in class diagrams. In case you wonder whether you really need this, I can offer you my whole Ph.D. thesis, which is on framework design using role modeling ) There is plenty of other work going into this direction, for example Erich Gamma’s pattern annotations in class diagrams.

  • Reported: XMI 1.1 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Statemachine/state as Namespace

  • Key: UML14-41
  • Legacy Issue Number: 3341
  • Status: closed  
  • Source: University of Oslo ( Birger Møller-Pedersen)
  • Summary:

    I am not sure if this qualify as an Issue, but I what just wondering
    why Statemachine and State are not Namespaces. Is it so that names are not supposed to be defined within these, or do names end up in the Namespace of the context model element?

  • Reported: XMI 1.1 — Mon, 28 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML RTF 1.4 Issue: Missing notation mapping for association in composite

  • Key: UML14-40
  • Legacy Issue Number: 3291
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    No mapping for this in mapping section, p 3-77:

    [p 3-75, Notation section for Composition] An association drawn
    entirely within a border of the composite is considered to be
    part of the composition.

  • Reported: XMI 1.1 — Sat, 5 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Document 99-06-08 - UML Spec

  • Key: UML14-47
  • Legacy Issue Number: 3632
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I'd find the document easier to digest if Chap 2 had some pictures in it.
    >>
    >>I know that the semantics is supposed to be independent of the
    >>representation. However, Chap 3 does contain some semantics in it for
    >>explanitory purposes (eg: section 3.55.1), so it's not unreasonabnle for
    >>Chap 2 to contain some notation. If section 2.5.4 (Association) had a
    >>picture of the diamond shaped association end for aggregations, it would be
    >>easier to follow what the document is talking about.
    >>
    >>At least sections 3.55.1 and 2.11.4 for instance might have links, even if
    >>only footnotes, to connect actor notation and semantics.

  • Reported: UML 1.3 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ClassifierRoles should be independent of specific underlying base Classifi

  • Key: UML14-43
  • Legacy Issue Number: 3376
  • Status: closed  
  • Source: Anonymous
  • Summary:

    ClassifierRoles should be independent of specific underlying base Classifiers. Otherwise, you can not specify OOram role models properly. You need "free" ClassifierRoles (=without base) if you want to span layers, for example.

    Collaboration Templates don't do the trick; templates serve a different purpose.

    Please contact me at riehle@acm.org if you want to know more. I have long worked on this topic.

  • Reported: XMI 1.1 — Sat, 26 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.4 issue: Top state in activity graphs

  • Key: UML14-44
  • Legacy Issue Number: 3382
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Top state in activity graphs

    The state machine meta-model currently requires a top state, whereas
    activity graphs should not. Composite states are not required for
    activity graphs (wf [2] for PseudoState, p 2-166).

  • Reported: XMI 1.1 — Tue, 29 Feb 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

issues and bugs on the UML 1.4 Draft

  • Key: UML14-7
  • Legacy Issue Number: 4300
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This text contains an number of (mostly minor) issues and bugs on the UML 1.4 Draft of February 2001 (formal OMG document number : ad/2001-02-13). The issues are listed along with their pagenumbers in the order, in which they appear in the UML document.

    Note: Since the number of issues is quite large, it was decided tot put them in one piece of text. Submitting each item as a seperate issue, utilizing the predefined form at the OMG site would have incurred too much overhead.

    ---Begin of issues---------------------------- (p. xi) Typographical/Editorial: The page-footer still refers to OMG-UML V1.3.

    (p. xxi) Typographical/Editorial: The reference to the UML Extensions chapter is not valid anymore.

    (p. 2-34, Component) It is stated that "In the metamodel <text removed>. A Component is specified by the interfaces is <sic!> exposes". However, there is no meta-association linking Component (or Classifier ?) to Interface, nor is there an OCL contraint indicating this relation. This should be added.

    (p. 2-46, Interface) Same as the previous comment. Here the relationship between Interface and Classifier could/should be made explicit in the Abstract Syntax.

    (p. 2-47, ModelElement) It is stated that "It is the base for all modeling metaclasses in the UML". However, this is not true for the following constructs:

    ElementOwnership ElementResidence ElementImport TemplateParameter TemplateArgument Argument

    Please clarify or correct the statement.

    (p. 2-95, 2-98, Integer, String, UnlimitedInteger) It is stated that each of these is "a classifier element that is an instance of Primitive". This is cofusing, since the text on p. 2-92 makes it clear that this Primitive cannot be the subclass of DataType: this is used for datatypes defined by users of the UML. So which Primitive is this ? Is it a MOF (meta-meta-)class ? Please clarify.

    (p. 2-98, Uninterpreted) It is not clear why this construct is mentioned at all, since it is not shown in the Abstract Syntax, nor referenced anywhere else.

    (p. 2-106) Typographical/Editorial: The sequence of DestroyAction and DataValue is not according to alphabetic ordering

    (p. 2-111, Stimulus) A reference is made to MessageInstance. This is not an UML metaclass. Please correct.

    (p. 2-139, Overview and 2-142, UseCase) In both pieces of text references are made to instances of usecases and instances of actors (or a user playing the role of the Actor). This is confusing in the sence that the concept of a usecase instance is reified as UseCaseInstance, whereas the actor instance is not reified. Please clarify.

    (p. 2-182,2-183) Typographical/Editorial: The sequence of ActivityGraph and ActionState is not according to alphabetic ordering

    (p. 3-3) Typographical/Editorial: There is no Part 8.

    (p. 3-15, Type-Instance Correspondence) It is stated that "Examples of such pairs in UML include: <text omitted>, Parameter-Value, Operation-Invocation, and so on." This is confusing since the constructs Value and Invocation are not UML metaclasses. Please correct.

    (p. 3-22, Subsystem - Presentation Options) It is stated "As with packages, the contents of a subsystem may be shown using tree notation". Note however that this statement is not included with the passages describing the Package Presentation Options on p. 3-18. Please clarify or add.

    (p. 3-59, Stereotype Declaration - Semantics) It is stated "although it conceptually belongs in the layer below,the metamodel layer." The use of "below" is not in line with the usual representation of the meta-modeling architecture, such as in table 2-1 on p. 2-5. There the metamodel layer is "above". Please correct.

    (p. 3-60, Stereotype Declaration - Notation) The special stereotype of Dependency called <<stereotype>> is not mentioned in the semantics section of Dependency (on p. 2-36/2-37), nor in Appendix A, UML Standard Elements. Please add.

    (p. 5-21?, Chapter 5) Typographical/Editorial: The pagenumbering in the footer starts at page 5-21. Please correct.

    (p. 5-24, Figure 5-1) It is inferred from the packages shown that the Extension Mechanisms package is absorbed into the Core Package. This is not reflected elsewhere in the document. Please make the neccesary updates. If it is decided to do this only in the Interchange Model, and not in the Abstract Syntax, then this should be noted on p. 5-23 under the heading of "changes". In this case the title of Figure 5-7 on p. 5-30 should be changed to "Core - Extension Mechanisms".

    (p. 5-31, Figure 5-8) In comparison with the Abstract Syntax diagram on p. 2-91 the element Mapping has been omitted/deleted. Please clarify.

    (p. 5-32, Figure 5-9) In order to be consistent with the titling used in the other figures in this chapter, please change the title to "Datatypes - Expressions".

    (p. 5-36, Figure 5-14 and p.5-38, Figure 5-16) In comparison with the Figures 2-18 (p. 2-123) and 2-20 (p. 2-125) the follwing assoctiations have been omitted/deleted:

    Collaboration - AssocationRole Collaboration - ClassifierRole AssocationRole - AssocationEndRole

    Please clarify

  • Reported: UML 1.3 — Sun, 13 May 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

class TaggedValuewill two association-ends with the same name "stereotype"

  • Key: UML14-6
  • Legacy Issue Number: 4187
  • Status: closed  
  • Source: Capable Objects ( Anders Ivner)
  • Summary:

    In the physical metamodel for extensions (Figure 6-8) the class
    TaggedValuewill have two association-ends with the same name "stereotype".
    One
    from the association with the superclass ModelElement
    (extendedElement-stereotype) and one on its own (requiredTag-stereotype).

  • Reported: UML 1.3 — Wed, 31 Jan 2001 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    in Uml 1.4 final, there is only one association end with this name

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 2-15 of the uml 1.4 spec

  • Key: UML14-14
  • Legacy Issue Number: 4531
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Figure 2-15 of the uml 1.4 spec, Action is according to the figure derived from Model, but figure should say that Action is derived from ModelElement. The idl definition confirms that Action is derived from ModelElement

  • Reported: UML 1.3 — Thu, 23 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    editorial fix in diagram: metaclass name is truncated (ModelElement => Model…). Duplicate of 4349

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 2-163, the statemachine semantics escription

  • Key: UML14-13
  • Legacy Issue Number: 4508
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I am reading the UML 1.4 draft specification. On page 2-163, the statemachine semantics are described. There is the following semantic defined: [3] A top state cannot have any containing states self.top.container->isEmpty

    I find the text description a little bit strange. The text wants to say that the top state cannot be contained in a container state. Maybe something to refrase in the next draft? At least it should a a containing state, because a state can only be contained into 1 composite state.

    On page 2-168 the behaviour when exiting a concurrent state is described. So far as I can see there is no guarantee about the order in which the exit actions of the regions are executed. So a design in which the exit actions are dependent on each other is a malformed design. Maybe something to add?

    On page 2-176, in the c++ example, there is a small error. After the code "balance = balance + amount" a ";" is missing.

  • Reported: UML 1.3 — Fri, 17 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

isPolymorphic is never in a diagram

  • Key: UML14-16
  • Legacy Issue Number: 5923
  • Status: closed  
  • Source: HTL Villach ( Lassnig Gernot)
  • Summary:

    2.9.2.12 Reception has a attribute that states wheter an attribute is polymorphic or not (isPolymorphic);

    2.5.4.3 Class has methods which can be polymorphic (isPolymorphic)

    2.5.4.6 Interface has operations which can be polymorphic (isPolymorphic)

    But there in the diagrams there is never an attribute called isPolymorphic, this should be corrected, i think the attribute isPolymorphic should be added to BehavioralFeature

  • Reported: UML 1.3 — Sun, 30 Apr 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    This is a duplicate of issue 4617,

  • Updated: Fri, 6 Mar 2015 20:58 GMT

well-formedness rule for Package is missing inUML 1.4

  • Key: UML14-15
  • Legacy Issue Number: 4534
  • Status: closed  
  • Source: Enea Business Software ( Karin Palmkvist)
  • Summary:

    A well-formedness rule for Package stating what can be contained in a Package, similar to e.g. wfr [4] for Subsystem, is missing in UML 1.4. It is there as wfr [1] for Package in UML 1.3.

  • Reported: UML 1.3 — Fri, 24 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    The rule seems to have unintentionally disappeared from 1.3 to 1.4.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

it's => its on page 3-150.

  • Key: UML14-10
  • Legacy Issue Number: 4453
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    it's => its on page 3-150.

  • Reported: UML 1.3 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    editorial fix

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wf 2 for AssociationEnd

  • Key: UML14-9
  • Legacy Issue Number: 4450
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The second wf rule for AssociationEnd uses the OCL operation
    applied to the wrong type (max applied to multiplicities).

  • Reported: UML 1.3 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    obvious error, OCL only fix.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.9.2 Abstract Syntax

  • Key: UML14-8
  • Legacy Issue Number: 4349
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the diagram in figure 2.15 the superclass of Action is Model, this should be ModelElement. Similar there is a problem with the partner class 'Clas' of the association with class CreateAction. There instead of 'Clas' it should read 'Classifier'.

    This seems to be just a printing problem, since in the same document on page 6.13 there is the corresponding diagram for the XMI specification. In this diagram the names are correct.

  • Reported: UML 1.3 — Mon, 18 Jun 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    editorial fix : Rose truncating the diagram, Previously fixed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation example typo in Fig. 3-99

  • Key: UML14-12
  • Legacy Issue Number: 4463
  • Status: closed  
  • Source: Pivot Point ( Cris Kobryn)
  • Summary:

    In the example the dependencies between the focus class and the two
    auxiliary classes should connect to the target interfaces of the auxiliary
    classes, rather than their class rectangles. (Note: this typo may be
    corrected in the formal version of the UML 1.4 specification, which is not
    yet available.)

  • Reported: UML 1.3 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Diagram to be fixed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The glossary entry "call" should be "call state".

  • Key: UML14-11
  • Legacy Issue Number: 4454
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The glossary entry "call" should be "call state".

  • Reported: UML 1.3 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Change the name of the glossary entry

  • Updated: Fri, 6 Mar 2015 20:58 GMT

elimination of the Association Class TemplateParameter

  • Key: UML14-3
  • Legacy Issue Number: 3803
  • Status: closed  
  • Source: Anonymous
  • Summary:

    At page 6-8 there is the Core-Auxiliary Elements diagram, figure 6-4; this is the modified version of the diagram at page 2-17 , figure 2-9.

    My problem is about the elimination of the Association Class TemplateParameter. To maintain the correct semantic of the Association Class feature I will change three things in the modified version:

    1) A) Reason When I have an istance of an association class I have one association between two objects (this is the case), so I have exatly one istance of the first class and exatly one istance of the second class that are related through the association

    B) Change The cardinality of the AssociationEnd modelElement of tha Class ModelElement should be 1 instead of 0..1

    2) A) Reason In the original diagram a ModelElement instance may have 0..1 associated ModelElement instance through the ciclic association. In the modified version a ModelElement instance may have an arbitrary number of TemplateParameter instance each having 0 or 1 associated ModelElement

    B) Change The cardinality of the AssociationEnd templateParametre2 of tha Class TemplateParameter should be 0..1 instead of *

    3) A) Reason In the modified diagram when I have the whole ModelElement I can reach the TemplateParameter. If I delete the 'whole' ModelElement then I delete the TemplateParameter related classes and the pending associations but I will not delete the semantically related ModelElements 'parts'; therefore I lose the composite semantic between two ModelElement istances

    B) Change The AssociationEnd templateParameter2 of the TemplateParameter class should have the aggregation of composite kind

    Can you help me to solve this trouble?

  • Reported: UML 1.3 — Tue, 5 Sep 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2) Page 2-49, additional operation #7 for Classifier

  • Key: UML14-2
  • Legacy Issue Number: 3531
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    2) Page 2-49, additional operation #7 for Classifier: The OCL reads as
    follows:

    1 oppositeAssociationEnds : Set (AssociationEnd);
    2 oppositeAssociationEnds =
    3 self.association->select ( a | a.associationEnd->select ( ae |
    4 ae.type = self ).size = 1 )->collect ( a |
    5 a.associationEnd->select ( ae | ae.type <self ) )->union
    6 (
    7 self.association->select ( a | a.associationEnd->select ( ae |
    8 ae.type = self ).size 1 )->collect ( a |
    9 a.associationEnd) )

    In line 5, the expression 'ae.type <self' is clearly wrong. I believe the
    intention may have been to test for inequality, i.e. 'ae.type <> self'.

    In line 8 'size 1' doesn't parse. I'm not sure what the intent was.

    A greater concern is that, even if corrected to address these flaws, this
    logic doesn't seem right in the case where we are dealing with an
    association where both ends are of the same type. It appears to be relying
    on detecting whether an end is opposite by testing the end's type. A fair
    number of other well-formedness rules leverage this operation in one way or
    another, so they are affected by this apparent flaw. Correcting this would
    require comparing the end instances, i.e. something like 'ae <> self' which
    does not have the same problem as 'ae.type <> self'.

  • Reported: UML 1.3 — Mon, 27 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    This issue has been fixed in UML 1.4. The correct operator is "<>"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove uses of multiple inheritance from UML meta model

  • Key: UML14-5
  • Legacy Issue Number: 3931
  • Status: closed  
  • Source: Capable Objects ( Anders Ivner)
  • Summary:

    Issue: Remove uses of multiple inheritance from UML meta model. For instance, LinkClass inherits from Class and Association. At least, remove it from the physical (XMI) meta model.

    Rationale: This is based on a practical argument, rather than a theoretical. Many modern programming languages, most notably Java, do not support multiple inheritance, which makes it difficult to implement the meta model correctly. To spread the use of UML it is important that tool vendors can do this. The meta model is already defined in a minimalist subset of UML, it just needs to be a little bit more minimal. It’s not as if multiple inheritance is absolutely necessary, a lot of people do just fine without it.

  • Reported: UML 1.3 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Who owns a Comment?

  • Key: UML14-4
  • Legacy Issue Number: 3860
  • Status: closed  
  • Source: MotionPoint ( Eugenio Alvarez)
  • Summary:

    Source: Eugenio J. Alvarez ( eugenio-a@dataaccess.com )
    Reference: formal/00-03-01 Semantics v. 1.3, Section 2.5.2, p. 2-17, Figure
    2-9 Core Package - Auxiliary Elements
    Nature: Revision
    Severity: Minor
    Summary: A Comment is shown as having a relationship to ModelElement
    (annotatedElement). However, the ownership of a Comment is not specified
    anywhere. If it should reside in a Package the OCL-WellFormedness rule for
    Package should be updated. Also, shouldn't a Comment have a text field to
    hold the annotation?

  • Reported: UML 1.3 — Mon, 18 Sep 2000 04:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    Add Comment to wfr listing what may be owned by a Package

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 2-47, well-formedness rule #2 for Classifier

  • Key: UML14-1
  • Legacy Issue Number: 3530
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    In the UML 1.3 specification (ad/99-06-08) there are the following problems:

    1) Page 2-47, well-formedness rule #2 for Classifier: The OCL uses an
    operation 'oppositeEnds' which is not defined. This probably should be
    'oppositeAssociationEnds'.

  • Reported: UML 1.3 — Mon, 27 Mar 2000 05:00 GMT
  • Disposition: Resolved — UML 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML2 super/Profile/Unconsistent association extension description

  • Key: UML15-10
  • Legacy Issue Number: 7665
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    b) More worryingly, 18.3.5 Semantics also says "As part of a profile, it is
    not possible to have an association between two stereotypes or between a
    stereotype and a metaclass unless they are subsets of existing associations
    in the reference metamodel." I fail to see how a profile could in fact could
    cause an association between 2 stereotypes to subset an existing association
    in a reference metamodel since the stereotypes do not at all inherit from
    the baseClasses so do not inherit any of its properties or associations in
    order to be able to subset them: this is emphasized by the MOF
    representation shown in the new Figure 447.

    Indeed profiles do not support association subsetting. This should be made
    clear in the spec to avoid any confusion while using profiles.

  • Reported: UML 1.4.2 — Fri, 3 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Correction to 7336

  • Key: UML15-12
  • Legacy Issue Number: 7671
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Referring to the 040829.PDF FTF draft, in Figure 192, the two
    associations ownedParameterSet should point to ParameterSet, to be
    consistent with the text.

  • Reported: UML 1.4.2 — Wed, 1 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Dependency errors

  • Key: UML15-11
  • Legacy Issue Number: 7670
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Referring to the 040829.PDF FTF draft, the following dependencies
    should be changed:

    • Figure 141

    IntermediateActions imports BasicActions and Communications,
    rather than merge.

    CompleteActions does not depend on StructuredActions, and only
    imports BehaviorStateMachines and AssociationClasses.

    • Figure 175:

    FundamentalActivities merges BasicActions. The merge from
    StructuredActivities to BasicActions can be removed.

    CompleteActivities imports BehaviorStateMachines, rather than
    merge.

  • Reported: UML 1.4.2 — Wed, 1 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

UML2 super/Profile/Unconsistent Profile extension description

  • Key: UML15-9
  • Legacy Issue Number: 7664
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    18.3.5 says that "A profile by definition extends a reference metamodel or
    another profile."
    While in theory I could see how it might be modeled, I don't see how the
    latter could work in practice with real tools. Let's extend the current
    example and define a new Profile called ClockTechnology with Stereotype
    AtomicClock with baseClass Clock and property radioactiveElement:String..."

    Import between profiles is supported, and stereotype generalization is the
    usual way to achieve what has been called "extending a profile".

    The reference to profile extension should be simply discarded. A profile
    extends a reference metamodel.

  • Reported: UML 1.4.2 — Fri, 3 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

UML 2 Super Issue re: DI compliance

  • Key: UML15-8
  • Legacy Issue Number: 7649
  • Status: closed  
  • Source: Gentleware AG ( Marko Boger)
  • Summary:

    As the Chair of the Diagram Interchange FTF I urge you to make compliance Diagram Interchange a necessity for full compliance with UML 2 Superstructure.

    In all discussions I attended it was always pointed out that the ability to exchange UML diagrams compliant to a standard using XMI was the single most important issue missing in UML 1. The Diagram Interchange specification was specifically designed to solve this problem. It is of essence that Diagram Interchange remains a part of UML 2 compliance. Otherwise the whole UML 2 standard is drastically reduces in its value.

  • Reported: UML 1.4.2 — Wed, 25 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

UML 2/ Inconsistencies in usage of package merge

  • Key: UML15-7
  • Legacy Issue Number: 7623
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    With the adoption of the updated definition of package merge, there are a number of places in both the Infrastructure and the Superstructure metamodels where the pre-conditions of package merge are violated. These need to be fixed.

  • Reported: UML 1.4.2 — Sun, 15 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

UML 2 Super/Infra: no notation for "isQuery" characteristic of Operations

  • Key: UML15-6
  • Legacy Issue Number: 7616
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The spec does not have a way of indicating that an operation has "isQuery" set to true.

  • Reported: UML 1.4.2 — Tue, 3 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    This is a duplicate of 6514 and has been resolved as part of the resolution to 7315.

  • Updated: Fri, 6 Mar 2015 20:52 GMT

UML 2 Super/Infra: return type of an operation

  • Key: UML15-5
  • Legacy Issue Number: 7615
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    At the bottom of pg. 79 of the Super FAS there are some examples ;
    +createWindow (location: Coordinates, container: Container [0..1]): Window

    +toString (): String

    However that does not conform with the syntax of Operations (on page 78), which does not support the ":<return-type>" notation. It is probably a good idea to allow such a syntax since it is quite common, is used in most UML books and tools, and is conveniently similar to the notation for attributes.

  • Reported: UML 1.4.2 — Tue, 3 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    This is a duplicate of 6213 and has been resolved as part of the resolution to 7315.

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Need to documetn diagramming conventions for association ends

  • Key: UML15-4
  • Legacy Issue Number: 7606
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    It is necessary to fully document the notational conventions used in the UML metamodel diagrams. In particular, it is necessary to be specific about the conventions used to denote the navigability and ownership of association ends, since the UML spec does not provide a default

  • Reported: UML 1.4.2 — Thu, 29 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Remove Package Templates? Feedback requested

  • Key: UML15-3
  • Legacy Issue Number: 7577
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Package templates were a nice idea but they were never properly implemented in the UML 2 spec. At the moment, what is in the spec is incorrect and completely different from what is in the metamodel (I am not sure how that came about – maybe Birger recalls). Neither version is complete or correct.

    The concept is a nice one to have, however, at this stage I am thinking of removing it altogether and leaving it as a new feature to be added in a future version.

    Does anyone have strong objections to the removal of this concept?

    (Reminder: package templates were the mechanism that depended on string substitution for instantiation.)

  • Reported: UML 1.4.2 — Mon, 12 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

UML 2 Super/state machines/Maximum one region

  • Key: UML15-2
  • Legacy Issue Number: 7576
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The package MaximumOneRegion was intended to be used as an optional package that restricts some of the general capabilities of behavioral state machines. This kind of capability is normally provided by a profile and should not be included in the standard, since it, effectively, displaces other parts of the standard.

  • Reported: UML 1.4.2 — Mon, 12 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

StartOwnedBehaviorAction

  • Key: UML15-1
  • Legacy Issue Number: 7574
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    This action should be renamed and semantics clarified to apply to
    classifier behaviors.

  • Reported: UML 1.4.2 — Sun, 11 Jul 2004 04:00 GMT
  • Disposition: Resolved — UML 1.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:52 GMT

super AND infra / Section 11.8.3 of Infra, 7.13.2 of Super / PackageMerge

  • Key: UML2-1
  • Legacy Issue Number: 6308
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Page 155 of the Infra Adopted Spec ptc/03-09-15 [sic] I think the date order got changed from Euro to US on this
    Page 101 of the Super "Final" Adopted Spec ptc /03-08-02 [sic] The date says August 2003

  • Reported: UML 1.5 — Fri, 10 Oct 2003 04:00 GMT
  • Disposition: Resolved — UML 2.0
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 20:52 GMT