Issue 6495: ptc-03-09-15/Separate classification and generalization in Core::Basic (uml2-rtf) Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com) Nature: Uncategorized Issue Severity: Summary: Issue: One of the main requirements for a core that can be reused by CWM hinges on whether it is possible to reuse the abstract syntax that supports classification and supports having properties (or features), without pulling in generalization constructs. U2P’s Core::Basic package, upon which EMOF is based, does not appear to adequately separate these concerns. The most abstract level of Core::Basic's inheritance hierarchy at which the ability to have properties appears is in the Class metaclass. But Class also carries the “baggage” of a definition of superclass. The Core::Abstractions package does appear to adequately separate these concerns. It does so by defining a simple Classifier in the Core::Abstractions::Classifiers package that supports features but not generalization. The Core::Abstractions::Super package defines another Classifier metaclass that subclasses Core::Abstractions::Classifiers::Classifier and adds support for generalization. Presumably, then, the intent is that CWM metamodels that support classification and properties but not generalization can reuse Core::Abstractions::Classifiers::Classifier. However, Core::Basic does not reuse either of these basic definitions of Classifier from Core::Abstractions, and EMOF is based on Core::Basic. Thus, if a CWM metamodel reuses Core::Abstractions::Classifiers::Classifier, it will not share a common definition of Classifier with EMOF. That could mean that a metamodel expressed solely via EMOF will not be able to be the source or target in a unified approach to transformations. This is not a problem for CMOF, though, because CMOF is based on Core::Constructs, whose Classifiers are based on Core::Abstractions. Recommendation: Solving the problem for EMOF would require some refactoring of Core::Basic to separate concerns between classification and generalization. Resolution: Discussion This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification. Disposition: Closed - No Change Revised Text: Actions taken: November 7, 2003: received issue February 18, 2005: moved from infrastructure February 20, 2015: closed issue Discussion: Disposition: Deferred to UML 2.4 RTF End of Annotations:===== m: "David S. Frankel" To: Subject: UML2Infra-MOF2Core/ptc-03-09-15/Separate classification and generalization in Core::Basic Date: Fri, 7 Nov 2003 22:03:51 -0800 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Issue: One of the main requirements for a core that can be reused by CWM hinges on whether it is possible to reuse the abstract syntax that supports classification and supports having properties (or features), without pulling in generalization constructs. U2P’s Core::Basic package, upon which EMOF is based, does not appear to adequately separate these concerns. The most abstract level of Core::Basic's inheritance hierarchy at which the ability to have properties appears is in the Class metaclass. But Class also carries the “baggage” of a definition of superclass. The Core::Abstractions package does appear to adequately separate these concerns. It does so by defining a simple Classifier in the Core::Abstractions::Classifiers package that supports features but not generalization. The Core::Abstractions::Super package defines another Classifier metaclass that subclasses Core::Abstractions::Classifiers::Classifier and adds support for generalization. Presumably, then, the intent is that CWM metamodels that support classification and properties but not generalization can reuse Core::Abstractions::Classifiers::Classifier. However, Core::Basic does not reuse either of these basic definitions of Classifier from Core::Abstractions, and EMOF is based on Core::Basic. Thus, if a CWM metamodel reuses Core::Abstractions::Classifiers::Classifier, it will not share a common definition of Classifier with EMOF. That could mean that a metamodel expressed solely via EMOF will not be able to be the source or target in a unified approach to transformations. This is not a problem for CMOF, though, because CMOF is based on Core::Constructs, whose Classifiers are based on Core::Abstractions. Recommendation: Solving the problem for EMOF would require some refactoring of Core::Basic to separate concerns between classification and generalization. ================================================================= David S. Frankel David Frankel Consulting Email: df@DavidFrankelConsulting.com Web: www.DavidFrankelConsulting.com Tel: +1 530 893-1100 Fax: +1 530 893-1153 David Frankel's MDA book: www.DavidFrankelConsulting.com/book.htm =================================================================