Initial Response to UML 2.0 OCL RFP ad000903 UML 2.0 OCL

1
Initial Response to UML 2.0 OCL RFPad/00-09-03
(UML 2.0 OCL)

• Unambiguous UML (2U)
• www.2uworks.org
• brought to you by
• Other UML Consortium Honchos

Adaptive, Data Access, Project Technology,
Kinetium, Softlab, Siemens in association with
Clark, Evans, Kent (pUML group Kings College,
University of York, University of Kent)
2
Outline

• Vision for UML 2.0
• Why bother with OCL?
• UU infrastructure approach
• Principles
• Our tools
• Language definition architecture
• Infrastructure and OCL
• Details
• Overview of packages
• Expressions
• Queries
• Constraints
• Conclusions

3
UML 2 Vision End User Model Composition

• Precise templates of domains and business
  processes
• Futures Trading orange juice, pork bellies,
  electricity, drinking water?
• Consumption auto parts, orange juice, pork
  bellies, electricity, drinking water?
• Degradation auto parts, orange juice, pork
  bellies, electricity, drinking water?
• Generate models from templates and compose with
  business specifics
• Futures Trading electricity / commodity,
  drinking water futures / payment composed
  with Consumption futures electricity purchase
  / consumable
• Generate from templates and compose patterns of
  refinements / transformation
• Through networks, databases,

• Generate and Integrate software components
• Specialize and Configure
• Generate plug-ins, bridges, adaptors
• Connect together

Example inspired by Kevin Tyson
4
UML 2 Vision Family of Languages

• Precise templates for the domains of language
  definition
• Concrete notation
• Abstract syntax
• Instances
• Mappings between these
• Generate languages (or fragments) from these
  templates
• Expressions
• Queries
• OCL
• Compose fragments
• Build consistently architected language family
• Even including relationships across languages

compose with
5
Outline

• Vision for UML 2.0
• Why bother with OCL?
• UU infrastructure approach
• Principles
• Our tools
• Language definition architecture
• Infrastructure and OCL
• Details
• Overview of packages
• Expressions
• Queries
• Constraints
• Conclusions

6
Why bother with OCL?

• Meta-modeling
• Used throughout OMG standards to express wff
  rules
• Will become more important as MDA forces modeling
  to be less ambiguous, e.g. to capture
  transformation rules
• Modeling
• Iceberg principle class diagrams are just the
  top x
• OCL provides a way of expressing the other
  (100-x), without pre-empting design decisions
• Good basis for generating checking part of test
  code from platform independent specifications
• But
• Can take time to write OCL
• Can be hard to read
• Wouldnt it be good if their was a standard
  library constraint templates?

7
Outline

• Vision for UML 2.0
• Why bother with OCL?
• UU infrastructure approach
• Principles
• Our tools
• Language definition architecture
• Infrastructure and OCL
• Details
• Overview of packages
• Expressions
• Queries
• Constraints
• Conclusions

8
Three Principles

• Repeatable Architecture
• greater consistency
• avoids duplication
• easily refactored

• Layered Definitions
• pluggable definitions
• extensible definitions
• composition avoids errors

• Unambiguous Meaning
• verifiable models
• executable models
• translatable models

9
Three Tools

• Package Templates
• greater consistency
• avoids duplication
• easily refactored

• Package Extension
• pluggable definitions
• extensible definitions
• composition avoids errors

• Instance Constraints
• verifiable models
• executable models
• translatable models

10
Structured Language Definition Java
Instance/Example
Specification
Language Element

• class A extends B
• int I
• m () .

• rules on the expression being well-formed e.g.
  extend 0..1 class

• every instance of A will
• when class A is loaded, a new class object

T x new A(p)

• rules on the expression being well-formed e.g.
  constructor available, return value type T match

• new instance of A created and variable x is bound
  to it

S s x.m (b)

• rules on well-formed expression e.g. m is a
  method of the interface for the type of x

• execute method m defined on object bound to
  variable x with parameter bound to the value of x
  bound to it by expression b

11
Structured Language Definition UML
Specification
Language Element
Instance/(Counter)Example

• rules on the expression being well-formed e.g.
  Class contains attributes Attributes have
  distinct names

• every object of class Dog has slots name, breed,
  weight
• every slot has a value of the type of the
  corresponding attribute

Dog

• rules on the expression being well-formed e.g.
  Each binary association links two classes. Each
  association has a multiplicity string

• An instance of the association (a link) links a
  specific instance of Dog, Sarzak, to a specific
  instance of owner, Sally
• The dog owner John owns no dogs

Name Breed Weight Owner
0..
1
Dog Owner
A counter-example discovered during instance
modeling
Name Address Dogs
12
Language definition

• In other words, to define a language we need
• definition of expressions as abstract syntax
  structures
• Java class, variable, constructors,
• UML Class, Attribute, Association
• definition of notation of expressions that create
  a specification
• Java strings, parentheses,
• UML boxes, lines, text strings
• definition of instances
• Javaobjects, method invocations, thread
  instances,
• UML Objects, Slots, Links
• rules about how instances must behave
• Javainstantiation, binding, execution
• UML instantiation, deletion, query, computation,
  trigger

13
Language definition

• From the RFP
• Proposals shall enforce a clear separation of
  concerns between the specification of the
  metamodel semantics and notation, including
  precise bi-directional mappings between them.
• Proposals should stipulate the mechanisms by
  which compliance to the specification will be
  determined

14
Language definition template 1
15
Language definition template 2
16
Outline

• Vision for UML 2.0
• Why bother with OCL?
• UU infrastructure approach
• Principles
• Our tools
• Language definition architecture
• Infrastructure and OCL
• Details
• Overview of packages
• Expressions
• Queries
• Constraints
• Conclusions

17
Infrastructure and OCL

• Uniform definition
• Concrete notation, underpinning concepts for both
  specification and instance sides can all be
  defined using the same language
• All defined to the same level of formality
• One of a family of expression languages
• Supported by templates and package extension
• Other examples include an action language, and
  may include more specialised constraint languages
• Integration with UML
• At both specification and instance (semantics)
  levels
• Separation of concerns
• Clear separation in definition between concrete
  notation from underpinning concepts (abstract
  syntax)
• Allows different concrete notation to be used
  (text, diagrams, XML)
• EBNF is a platform specific implementation of
  meta-model specification of mapping between text
  notation and concepts
• Submission document
• Same document for infrastructure and OCL
  submissions
• See sections 5.6, 5.7, 5.8

18
Outline

• Vision for UML 2.0
• Why bother with OCL?
• UU infrastructure approach
• Principles
• Our tools
• Language definition architecture
• Infrastructure and OCL
• Details
• Overview of packages
• Expressions
• Queries
• Constraints
• Conclusions

19
Packages
20
DataTypes
21
Data Types Specification Concepts
22
Data types Instance Concepts
23
Datatypes SpecificationXInstance
24
Expressions Specification Concepts
25
Expressions instances

• Plus stuff already defined in DataTypes.Instance.C
  oncepts (inheritance tree of Object)
• There will be a matching inheritance tree off
  Calc, with specialised associations between the
  two trees.
• The type of the value produced by a calculation
  must conform to the type of the classifying
  expression.
• These associations would be generated by a basic
  template for association generalisation.

26
Expressions spec instance mapping

• Remember matching class hierarchies on Exp and
  Calc
• Generated from templates as in DataTypes case.
• There are specific templates that will bring
  specialised constraints in each case.
• Candidates are mentioned on p130.

27
Queries

• Queries are just specialised functions
• Classes contain queries, objects contain
  instances of queries (query calculations)
• Can be generated from templates

28
Constraints

• Constraints are boolean queries
• Classes/packages contain constraints,
  objects/snapshots contain instances of
  constraints
• Additional rules to ensure that constraint
  instances in an object/snapshot always evaluate
  to true
• Generated from templates like queries

29
Constraints further specialisation

• Expression language is more expressive than OCL,
  but can be more cumbersome in its raw form (see
  e.g. p126)
• We will define all the OCL constructs in the
  meta-model on top of this language
• Similar to how one might decide to define an
  association as a pair of attributes (attribute is
  more fundamental concept here) or a state as a
  boolean attribute, and so on.

30
Outline

• Vision for UML 2.0
• Why bother with OCL?
• UU infrastructure approach
• Principles
• Our tools
• Language definition architecture
• Infrastructure and OCL
• Details
• Overview of packages
• Expressions
• Queries
• Constraints
• Conclusions

31
Conclusions

• Use of templates to generate architecturally
  consistent and complete definitions of expression
  languages
• Use of package extension to organise families of
  constraint languages that integrate with UML
• Constraints specialise queries specialise general
  expression language
• Still a need for class inheritance (and
  association specialisation) in cases where object
  polymorphism is required
• Expressions are made up of sub-expressions
• Consistent approach across OCL, infrastructure,
  superstructure
• Current direction
• Finish off templates
• Extend to dynamic case (action languages,
  pre/post specs, concurrency, )