1 / 7

UML 2.0 Compliance Points Proposal

This proposal suggests a simpler compliance scheme for UML 2.0, with a single core compliance point and additional capabilities based on usage experience for better vendor support. The aim is to ensure interoperability and user expectations while maintaining tool flexibility. The document outlines specific guidelines and possible capabilities to enhance the UML 2.0 standard.

aderr
Download Presentation

UML 2.0 Compliance Points Proposal

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 <<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

  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)?

More Related