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 Basic SubLang1 -Intermediate SubLang1 - Complete SubLang1 -Intermediate SubLang1 - Complete...

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

5 Current Subject Areas and Compliance Packages 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)

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 “Build your own” UML... UML Blue UML Black

8 Implications of Current Strategy Too many variants defeat the purpose of a standard –No. of variants >> 4 38 (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)