26
1 1 Overview 1. Find out why software engineering is important see some software engineering failures 2. Get acquainted with – the Chair of Software Engineering the research the people the teaching Opportunities and Challenges for Deep Constraint Languages Colin Atkinson Ralph Gerbig Thomas Kühne Ottawa, Camada 28 September, 2015 OCL 1015 @MODELS 2015

1 1 Overview 1.Find out why software engineering is important ■ see some software engineering failures 2.Get acquainted with – ■ the Chair of Software

Embed Size (px)

Citation preview

1

1

Overview

1. Find out why software engineering is important■ see some software engineering failures

2. Get acquainted with –■ the Chair of Software Engineering

■ the research

■ the people

■ the teaching

Opportunities and Challenges for Deep Constraint Languages

Colin AtkinsonRalph GerbigThomas Kühne

Ottawa, Camada28 September, 2015

OCL 1015@MODELS 2015

2

2

The Challenge

■ Structural models (e.g. in UML) are often augmented with (additional) constraints (e.g. in OCL) to rule out unwanted instance configurations

■ Constraints add further requirements that (token) models (instances) must obey to be considered instances of their (type) model■ provide additional well-formedness requirements■ rule out unwanted configurations of instances■ improve the precision of the semantics of the type model

■ Today’s constraint languages are designed to support traditional “two-level” modeling languages and thus assume that constraints -■ are attached to types and evaluated on their instances■ are implicitly universally-quantified, i.e., use a “for-all”-semantics ■ have only one instance level to control, i.e., deep control beyond

more than one classification boundary is not possible

3

3

Goals

■ the goal of this paper is to ■ re-evaluate the role of constraints for deep modeling■ identify di erent kinds of constraints possible on deep modelsff■ establish terminology for referring to them■ explore what language features might be useful

■ It is NOT the goal of the paper to■ resolve all tradeoffs necessary in the design of a Deep

Constraint Languages (DCLs)■ propose specific concrete syntax for DCLs■ present a complete, fully thought out DCL

■ The focus is exclusively on ■ structural modeling■ contraint languages

4

4

Deep Modeling

5

5

Realization Strategy 1

■ Make the linguistic (meta) model the tool meta-model and add support for ontological classification at the “instance” level

Ecore

6

6

Realzation Strategy 2

■ Transformation chains between “two-level” windows

Tool 1

Tool 2

Transformations

7

7

Opportunities and Challenges for DCLs

■ The features of deep modeling that present the biggest opportunities and challenges from the perspective of defining constraints are■ the two distinct, orthogonal classification dimensions■ dual facets of model elements (i.e. the existence of linguistic

and ontological attributes)■ an unbounded number of ontological classification levels.

8

8

Linguistic Constraint Example 1

■ The value of the potency of every clabject must be one lower than that of its direct type

9

9

Linguistic Constraint Example 2

■ The value of the potency and level of every clabject must be equal

10

10

Linguistic Constraint Example 3

■ The number of levels in a deep model must be 3

11

11

More General Forms of Constraints

■ Linguistic constraints ■ reference concepts in terms of linguistic types and therefore

have no knowledge of any ontological types

■ Ontological constraints■ operate within level L0 to express well-formedness conditions

on the content of ontological levels■ access ontological attributes and model information■ have more than one immediate instance level to constrain

■ Universal “for-all” at the immediate level below is no longer optimal■ need a more general form for constraints

12

12

Ontological Constraint Example 1

■ the constraints that end users (i.e. modellers) write in conventional modeling environments are typically ontological constraints

■ The value of a ProductType’s price attribute has to be smaller than or equal to its RRP attribute

13

13

Hybrid Constraints

■ Limiting constraints to operating in just the linguistic dimension or the ontological dimension (but not both) is too restrictive ■ need to allow statements about both forms of instantiation to be

mixed (i.e. need hybrid constraints)

■ But how should ambiguities (i.e. name clashes) be avoided?

a) rule out the use of linguistic model names in the ontological levels (i.e. in the domain content)

b) provide a special syntax for selecting between linguistic and ontological elements

c) introduce default rules based on the “location” of the constraint

d) support some mixture of (b) and (c)

14

14

Example Hybrid Constraint

■ The (default) prices for instances of CarType, and their instances, must be greater than zero

(DeepOCL)

(Metadepth)

15

15

Deep Constraints

■ may target one or more levels somewhere below the origin clabject

■ Instances versus offspring■ instances of a clabject exist at the level immediately below that

clabject, and can be direct or indirect instances■ o spring of a clabject are all clabjects in the transitive closure ff

of the “classifies” relationship starting with that clabject

■ constraints can be level-specific or level-spanning■ level-specific constraints restrict the properties of clabjects to

one specific level relative to the origin clabject■ they have a SCOPE of 1

■ level-spanning constraints restrict the properties of clabjects to a range of levels relative to the origin clabject■ they have a SCOPE of greater than 1

16

16

Level-Specific Constraints

■ Constrain the clabjects at one specific level relative to the origin clabject

■ can either be -■ Inter-level

■ constrain some arbitrary, specified level containing offspring of the origin clabject

■ constrain the lowest level containing o spring of the origin ffclabject

■ Intra-level■ constrain the level containing the origin clabject element itself

17

17

Inter-Level Constraint Example 1

■ The recommended retail price of a CarType must be between 10k and 400k

18

18

Inter-Level Constraint Example 2

■ The price actually paid for a car shall be no more than 80% of the recommended retail price

19

19

Intra-Level Constraint Example 1

■ Subtypes of Car with potency higher than 0 must be instances of CarType (cf. PowerType Pattern)

20

20

Intra-Level Constraint Example 2

■ Subtypes of Car with potency higher than 0 must add attributes

origin (0) Car

21

21

Level-Spanning Constraints

■ Constrain the clabjects in a specific range of levels relative to the origin clabject

■ can either be -■ all offspring of the origin clabject in a specified range of levels

below that clabject■ all offspring of the clabject as well as the clabject itself

22

22

Level-Spanning Constraint Example 1

■ All o spring of wheelTypes, over two levels immediately below it, are ffnot allowed to be older than 24 months

23

23

Level-Spanning Constraints

■ The (default-) price for a car must exceed 10000

24

24

“Advanced” Constraint Example

■ The wheels of Dragsters are not allowed to be older than 7 months

■ Clabject-specific but “type” aware

(DeepOCL)

(Hybrid)(MODELS 2015)

25

25

Conclusion

■ The paper explored the different kinds of constraints that make sense in deep modeling and proposed terminology for referring to them■ the taxonomy is not necessarily mutually exclusive

■ In the context of deep modeling it is possible to write kinds of constraints that cannot be specified in SCLs, such as ■ hybrid constraints

■ deep constraints

■ intra-level constraints

■ we do not use higher-order constraints (constraints on constraints) like other approaches that try to support the effects of hybrid constraints

■ some of these ideas have been implemented in existing deep modeling environments such as ■ Metadepth, DeepOCL (available in Melanee)

26

26

That’s It

Thank you for your attention