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.