70 likes | 73 Vues
UML 2.0 Compliance Points Proposal. Jim Amsden, Bran Selic 21 October 2003. Design Forces. Need a much simpler compliance scheme Consensus from Wed. Oct. 15, telecon
E N D
UML 2.0 Compliance Points Proposal Jim Amsden, Bran Selic 21 October 2003
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)
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
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 <<define>> 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
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
Possible Capabilities • Actions (int, comp) • Activities (int, comp) • Information flows • Templates • Collaborations • Components • Composites • Deployment • Interactions • Profiles • State machines (int, comp) • Use cases
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)?