1 / 10

UML 2.0 Compliance Points Issue

UML 2.0 Compliance Points Issue. Bran Selic 15 October 2003. 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

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 15 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 compliance options 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