1 UML 2.0 Compliance Points Proposal Jim Amsden, Bran Selic 21 October 2003

2 Design Forces Need a much simpler compliance scheme –Consensus from Wed. Oct. 15, telecon Practicality of defining a set of compliance points that will be acceptable to different categories of users and all vendors is questionable –Insufficient understanding of UML usage patterns –Different vendors have very different requirements (led to current compliance fragmentation)

3 Proposal – Essentials Provide a single minimal compliance point that all UML vendors must support to claim compliance Define additional compliance points on the basis of usage experience –Do not provide explicit additional compliance points at this time –Provide recommendations (capability/feature sets) that may become compliance points in the future

4 Specifics Establish L1 (Basic) as the single top-level core that all tools are expected to support Flatten and remove redefinitions in L1, merge abstractions, infrastructure library, and kernel Partition the rest of L2 and L3 into a set of (mostly) orthogonal capabilities (or features) Each capability (set) may have more than one level (but less than 3?) Capabilities are added to UML2 core by using the new > merge Capabilities can add new packages and metamodel elements, and can extend existing metamodel elements in core or other prerequisite capabilities Capability extensions cannot violate, constrain or otherwise be incompatible with core Therefore XMI schema for core will get extended elements after a capability is merged, but all versions of core are compatible

5 Compliance is now simple but more flexible There are no packages for compliance levels. Compliance is basic plus a list of additional capabilities or capability sets All tools must support UML2 core to be considered UML2 compliant Tools may support any combination of capabilities If a tool advertises it supports a capability, it must implement it as specified in the UML2 specification The UML2 specification will contain a non-normative appendix that specifies recommended capability sets –This establishes user expectations and aids interoperability –While providing for tool flexibility

6 Possible Capabilities Actions (int, comp) Activities (int, comp) Information flows Templates Collaborations Components Composites Deployment Interactions Profiles State machines (int, comp) Use cases

7 Possible issues Core (L1) may still be too big Loosen some constraints or properties resulting from collapsing L1 –MaximumOneRegion –Class::superType vs. Generalization Should Core be the minimum required to provide a basis for MDA (executable, translatable models)?