1 / 10

UML 2.0 Compliance Points Issue

This proposal suggests modularizing the UML language into two dimensions - subject areas/formalism and semantic sophistication. The aim is to enhance language understanding, learning, and flexibility. By incrementally building up towards a single top-level language with subsettable features, the proposal aims for finer granularity, clearer compliance points, and easier interworking. However, the current strategy's multiple variants pose challenges to standardization. Advantages of a single top-level UML model are highlighted for conceptual clarity and compliance checking.

brownann
Download Presentation

UML 2.0 Compliance Points Issue

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 Issue Bran Selic 14 October 2003

  2. Original Intent (1 of 2) • Modularize the language in two orthogonal dimensions: • According to subject area/formalism • According to semantic sophistication • Rationale: • Language becomes easier to understand and learn • Flexibility to use/support only interesting subset

  3. Original Intent (2 of 2) • Incremental build-up towards a single (but subsettable) top-level language that includes all features SubLang1- Complete SubLang1- Complete . . . SubLang1-Intermediate SubLang1-Intermediate Basic

  4. Actual Language Structure • Much finer granularity (15 subject areas spread across 37 compliance point packages) . . . . . .

  5. Actions (2 packages) Activities (5) Information flows (1) Models (1) Primitive Types (1) Templates (1) Classes (5) Common Behavior (3) Components (2) Composites (6) Deployment (3) Interactions (2) Profiles (1) State machines (3) Use cases (1) Current Subject Areas and Compliance Packages

  6. Current Compliance Strategy • Compliance defined relative to individual compliance points rather than the language as a whole • Possible levels of compliance per compliance point: • No compliance – i.e., compliance point not supported at all • Partial compliance – means only subset supported(?) • NB: there can be many, many ways in which this occurs • Compliant compliance – means full compliance (but not for XMI?) • Interchange compliance – includes XMI compliance • A compliance statement consists of a 37-item enumeration

  7. Result: Many Possible Top-Level UML Variants UML Blue • “Build your own” UML . . . UML Black . . .

  8. Implications of Current Strategy • Too many variants defeat the purpose of a standard • No. of variants >> 438 (because of partial compliance) • No meaningful interworking possible (also, no mechanisms provided to identify variants) • Problem compounded somewhat by profiles • Impractical to define a “reference version” for conformance checking • Complex API for repository (MOF) models • E.g., 35 flavors of “Classifier”

  9. Single Top-Level UML or Multiple Ones? • Some confusion in the current spec: • The L3 package implies a single top-level UML with “everything” in it • But, some compliance packages were designed to constrain the general case (e.g., package MaximumOneRegion for state machines) • Others were designed for special purposes (e.g., Time, Deployment) that reduce the generality of the single model • These compliance points reduce the generality of the single model and the overall applicability of UML

  10. Advantages of a Single Top-Level UML • Conceptual clarity • Single reference model for compliance checking and XMI • All language variants are proper subsets of the same reference model • Fully consistent with the profile mechanism for specializing UML • Consistent with earlier proposal for removing problems introduced by package merge • Would need to deal somehow with “specialization” packages (Time, MaximumOneRegion)

More Related