A Research Agenda for Model-Driven Development Jordi Cabot1,2 Open University of Catalonia1 University of Toronto2

1
A Research Agenda for Model-Driven Development
Jordi Cabot1,2 Open University of Catalonia1
University of Toronto2
2
Index

• Goal
• Disclaimer
• Introduction
• A Research Agenda for
• Explicit Models
• Executable Models
• Evolving schemas
• Others
• Conclusions

3
Goal
GOAL_1 Try to say something interesting!!
(selfish) GOAL_2 Present my background and
research lines

• I will base the talk on the paper
• A. Olivé, J. Cabot A Research Agenda for
  Conceptual-Schema Centric Development in
  Conceptual Modeling in Information Systems
  Engineering, Springer (list of main problems for
  a successful MDD application)
• And emphasize some of the points I have been
  working on

• I believe that some of the problems and
  techniques are also useful for RE
• I hope at least the young ones will find the talk
  informative

4
Index

• Goal
• Disclaimer
• Introduction
• A Research Agenda for
• Explicit Models
• Executable Models
• Evolving schemas
• Others
• Conclusions

5
Disclaimer

• I am a UML fan
• I DO think that graphical models must be
  complemented with some kind of textual language
  that allows designers to express more complex
  properties of the domain-gt I am an OCL fan
• When I say the word model I usually imagine a
  UML/OCL class diagram OCL constraints,
  derivation rules and pre/post operation contracts
  (sometimes also state machines)
• In this talk Model Conceptual schema
• Some of my statements and vocabulary are biased
  because of this background
• SORRY! NO GOAL MODELS IN THIS PRESENTATION (but I
  do mention them a couple of times)

6
Index

• Goal
• Disclaimer
• Introduction
• A Research Agenda for
• Explicit Models
• Executable Models
• Evolving schemas
• Others
• Conclusions

7
Introduction

• Model-driven development (MDD) is a software
  development paradigm that emphasizes the use of
  models as key artifacts in all phases of the
  development cycle
• Models are used to validate, verify, test and
  generate the system to be built
• Also known as MDE (Model-driven engineering).
• MDA is OMGs vision of MDD

• (Unfortunately) Requirements Engineering does not
  play an important role in typical MDD approaches

8
Introduction

• Two main MDA components
• Platform-independent Model (PIM) analysis models
• Platform-specific models (PSM) design models
  (including all design decisions)
• Code is automatically generated from
  platform-specific models
• The transition between models at different stages
  and abstraction levels should be as automatic as
  possible.

9
Introduction

• To achieve the MDD vision we need that models be
  explicit, executable and evolvable.
• Explicit schema
• There must be an explicit, complete, correct and
  permanently up-to-date schema written in a formal
  language.
• Executable schema
• The schema must be executable in the production
  environment either by 1 - automatic
  transformation of the schema into software
  components or by 2 - the use of a virtual machine
  that runs on top of this environment.
• The schema is the only description that needs to
  be defined. All the others are internal to the
  system.
• Evolvable schema
• Changes must be done at the model level.
• Changes are then automatically propagated to all
  system components (including the system data) if
  needed.

10
Index

• Goal
• Disclaimer
• Introduction
• A Research Agenda for
• Explicit Models
• Executable Models
• Evolving schemas
• Others
• Conclusions

11
Very large models

• Models of a large organization may contain
  thousands of classes, associations,
  constraints,.
• The development and management of (very) large
  models poses specific problems Modeling in the
  large is not the same as modeling in the small.
• E.g. Visualization problems
• So far, work on this topic has focused mainly on
  schemas for databases -gt not considering
  behavioral elements.

12
Model Quality

• Models must be consistent. A UML model is
  consistent iff can be expressed as an
  instantiation of the UML metamodel (grammatical
  correctness)
• Models must also be complete (all the
  information) and correct. Correctness
  Validation (are we building the right system?)
  Verification (are we building the system right?)

13
The UML metamodel
PLUS WFR Only binary associations can be
aggregations. self.memberEnd-gt exists(aggregation
ltgt Aggregationnone) implies self.memberEnd-gtsize
()2
14
The UML metamodel
15
Model Quality Validation

• For validation we have several animation tools
  (e.g. USE) that help the designers to validate
  the schema

• BUT Validation must be done by the customers -gt
  NL.

16
Model Quality Verification

• Verification checks whether the model satisfies a
  set of correctness properties, being
  satisfiability the most basic one. Liveliness,
  redundancy, can be expressed in terms of this
  one
• A model is satisfiable if it is possible to
  create a valid instantiation of that model.
  Otherwise it is useless, users wont be able to
  work with the model
• A instantiation is valid if it satisfies all
  model constraints

17
Only empty or infinite instances!
Writes Researcher lt 2 Paper
Reviews Researcher 3 Paper
18
Model Quality Verification

• BAD NEWS! -gt Verification of UML/OCL models is
  undecidable
• Alternatives (each one with a different
  trade-off)
• Limit the expressivity of UML/OCL DL approaches
• User-assisted Theorem provers (HOL-OCL)
• Bounded verification UMLtoAlloy (SAT) or
  UMLtoCSP (Constraint Satisfaction Problem). SAT
  vs CSP?
• I believe that, to be useful, verification
  methods must be automatic and expressive enough
  -gt Bounded verification
• Bounded verification methods limit the search
  space to perform an exhaustive search -gt they are
  not complete

19
Model Quality Verification

• UML model
• Class diagram
• OCL constraints

Property?
Translate
Deduce

• Constraint Satisfaction Problem
• Variables basic types struct/list
• Domains finite
• Constraints Prolog
• Property -gt Additional Constraint

Solve
Solution?
20
Resolution of the CSP
Variables
1 ? nA ? SizeA classA( oid ) classA VA1..na
A


1 ? nB ? SizeB classB(oid, x) classB VB1..nB
1 ? nC ? SizeC classC(oid, y) classC VC1..nC
1 ? nR ? SizeRel rel (b, c) Rel VR1..nR
Constraints
C
y int

B
x int

3..
1
SizeB SizeRel
SizeB ? 3SizeC
Rel
SizeA ?? SizeB SizeC
alldifferent( oid )
21
Translation of OCL invariants
context Paper inv self.wordCount lt 10000

• invariant(Papers)-
• // Expression must be true
• // for each Paper
• ( for (Paper, Papers)
• do
• LessThan(Paper,Result),
• Result 1 ) .

22
Translation of OCL invariants
Result

• LessThan(Vars, Result)-
• // Evaluate subexpressions
• Attribute(Vars, X),
• Constant(Y),
• // Compute result
• lt(X,Y, Result).

X
Y
AttribCallExp
wordCount
Z
VariableExp
self
23
Resolution of the CSP. Backtracking constraint
propagation
Define cardinality variables
Constraints on cardinalities
Assign cardinalities (i.e. try a possible
assignment for SizeA, SizeB,) and check if a
solution can be found. If not, try a different
assignment
24
Resolution of the CSP
Define cardinality variables
Constraints on cardinalities
Assign cardinalities
Define attribute variables
Constraints on attributes
Assign attributes
25
Resolution of the CSP
Define cardinality variables
Constraints on cardinalities
Assign cardinalities
Define attribute variables
Constraints on attributes
Assign attributes
26
Resolution of the CSP
Define cardinality variables
Constraints on cardinalities
Assign cardinalities
Define attribute variables
Constraints on attributes
Assign attributes
27
Resolution of the CSP
Define cardinality variables
Constraints on cardinalities
Assign cardinalities
Define attribute variables
Constraints on attributes
Assign attributes
28
Model Quality Verification -gt Open Issues

• Efficiency issues
• Slicing/Partitioning the (very large) model in
  (independent) submodels that can be verified in
  parallel.
• Choosing the best approach depending on the model
• Giving meaningful feedback (where is the error?
  Why?)
• Suggesting repairing procedures
• Verification of N related models -gt global
  consistency global correctness

29
Schema Integration

• Models are not developed by a single analyst.
  Therefore, sub-schemas must subsequently be
  integrated in a single schema that represents the
  overall view of the system
• To identify and characterize the relationships
  between the different sub-schemas (schema
  matching).
• Link matching elements in a coherent schema
  (schema merge).
• There is a lot of ongoing research in this area.
  But
• Schema integration in the presence of general
  integrity constraints and derived elements?
• Integration of behavioral schemas?
• Incremental Merge? (i.e. how to resynchronize the
  integrated model after changes in one of the
  subschemas)

30
Reverse Engineering

• MDD requires eliciting the models of all legacy
  systems
• Many approaches are able to extract the static
  elements of the class diagram (classes,
  associations,) from databases or O.O. code
• Some also deduce a sequence diagram from the
  analysis of method calls within the OO code.
• Extraction of integrity constraints, derivation
  rules and behaviours is yet to be done
• Ex. Analysis of triggers in a DB to determine the
  constraints of the schema

31
Workflows, BRules and GORE in MDD

• MDD approaches are not well-integrated with
  current efforts in related areas as Business
  Process Management, Business Rules or
  Goal-Oriented Requirements Engineering
• A tighter integration could benefit both
  approaches
• Example

32
Workflows, BRules and GORE in MDD
33
(No Transcript)
34
Workflows, BRules and GORE in MDD
context B inv seq1 previous-gtsize()1 and
previous-gtexists(a a.oclIsTypeOf(A) and
a.statuscompleted)
context B inv seq2 B.allInstances()-gt
isUnique(previous)
context Case inv seq3 statuscompleted implies
self.activity-gt select(a a.oclIsTypeOf(A) and
a.statuscompleted)-gtforAll(aa.next-gtexists(
b b.oclIsTypeOf(B)) and a.next-gtsize()1)
35
Workflows, BRules and GORE in MDD
36
Index

• Goal
• Disclaimer
• Introduction
• A Research Agenda for
• Explicit Models
• Executable Models
• Evolving schemas
• Others
• Conclusions

37
Code-generation

• Almost all UML CASE tools publicize their great
  code-generation capabilities but the truth is

38
Code-generation
Type not restricted to employees

• the typical result would be

Cardinality not restricted
Code is not generated
This constraint cannot be violated when adding
new employees
Maximum cardinality not checked
This constraint cannot be violated when changing
the name
Number of Senior Employees not checked
39
Code-generation

• So, are Executable UML methods (and others) a
  fake?
• Yes and No. They achieve the promised 100
  code-generation but at the expenses of
  restricting the expressivity of the UML language
  till a point it can be easily translated -gt
  Designers must directly draw design models
• Examples
• Multiple inheritance not allowed (Java)
• Only predefined types of constraints are allowed
• Operations are written in pseudocode (Action
  semantics).
• This is the easy but not the right solution. We
  need to keep working in code-generation
  techniques able to deal with more expressive
  models (even if then code-generation is not fully
  automatic)

40
From declarative to imperative operations

• There are two different approaches to specify the
  effect of an operation over the system state the
  declarative and the imperative approaches
• In an imperative specification the designer
  explicitly defines the set of actions (i.e.
  structural eventsinsert,update,delete) to be
  applied over the system state
• For declarative specifications the designer
  defines a contract (set of pre and
  postconditions). A postcondition states the set
  of conditions to be satisfied by the system state
  at the end of the operation execution
• From a specification point of view, declarative
  specifications are preferable (they are more
  concise and abstract)

• BUT
• Declarative specifications are underspecifications
  (there are several possible final states
  satisfying the postcondition). Exframe problem
• This is specially relevant in OCL contracts due
  to the OCL expressiveness
• This hinders the practical use of declarative
  specifications

41
context DepartmentGoalEvaluation() post
self.sumSalesself.employee.sales.amount-gtsum()
and if self.sumSalesgtself.goal then
self.employee-gtforAll(e e.salary
e.salary_at_pre e.category.raise) else
self.carFleet-gtexcludesAll(CarallInstances-gtsele
ct(c c.typeLuxury)) endif
context DepartmentGoalEvaluation()
AddAttributeValue(sumSales, self,
self.employee.sales.amount-gtsum()) if
self.sumSalesgtself.goal then foreach e in
self.employee AddAttributeValue(salary,
e, e.salary_at_pre e.category.raise)
endfor else foreach c in
CarallInstances-gtselect(c c.typeLuxury)
DestroyLink (DepartmentCar, self, c)
endfor endif
42
Now, what is the expected behavior of
GoalEvaluation?
If employees have sold enough to fulfill the
goal, their salary is increased as indicated by
their category. Otherwise, employees are not
longer allowed to use luxury cars
context DepartmentGoalEvaluation() post
self.sumSalesself.employee.sales.amount-gtsum()
and if self.sumSalesgtself.goal then
self.employee-gtforAll(e e.salary
e.salary_at_pre e.category.raise) else
self.carFleet-gtexcludesAll(CarallInstances-gtsele
ct(c c.typeLuxury)) endif
43
Heuristics Approach

• Heuristics try to represent common assumptions
  used during the specification of operation
  contracts to disambiguate the contract semantics
• X.aY (Order matters)
• Possible final states satisfying the
  postcondition
• States where a takes the value of Y
• States where Y takes the value of a
• States where a value c is assigned to both a and
  Y
• Default interpretation The desired state is the
  one where a takes the value of Y
• X-gtforAll(Y) (Do not empty the source)
• Possible final states satisfying the
  postcondition
• States where Y evaluates to true for all objects
  in X
• States where X is empty
• Default interpretation Do not empty the
  collection X. A solution removing all objects in
  X is not acceptable

44
Some translation patterns

• o.oclIsNew() and o.oclIsTypeOf(Cl)
• oCreateObject(Cl)
• not o.oclIsTypeOf(OclAny) Cl.allInstances()-gtex
  cludes(o)
• DestroyObject (o)
• o.atY (where at is a univalued attribute)
• RemoveAttributeValue(at,o)
• AddAttributeValue(at,o,Y)
• X-gtforAll(Y)
• foreach o in X do
• if not (o.Y) then Translate(o.Y)
• endif
• endfor

45
Imperative version of GoalEvaluation (input of
ExecutableUML methods)
context DepartmentGoalEvaluation()
AddAttributeValue(sumSales, self,
self.employee.sales.amount-gtsum()) if
self.sumSalesgtself.goal then foreach e in
self.employee AddAttributeValue(salary,
e, e.salary_at_pre e.category.raise)
endfor else foreach c in
CarallInstances-gtselect(c c.typeLuxury)
DestroyLink (DepartmentCar, self, c)
endfor endif
46
Discussion My solution

• Heuristic-based translation
• ? Designers do not need to define additional
  information
• ? Some of the heuristics are generally accepted
• ? Evolving the schema does not affect the
  interpretation of existing operations
• X Consensus on the heuristics is required (at
  least within the particular company/group using
  this approach)
• X This solution does not cover (yet) all kinds of
  OCL expressions nor all combinations between them
  (rules to combine the basic patterns are required
  for elements appearing in different parts of the
  post)

47
Alternatives

• Frame axioms
• Designers explicitly define which parts of the
  system may (or may not) change during the
  operation
• ? No hidden interpretations
• X Additional burden for the designer (feasible?)
• X Not all ambiguities solved (things that do
  change may change in different ways. Ex
  multivalued properties)
• X Depending on the axioms evolving the schema may
  imply adding new frame axioms (more things that
  do not change)

Computing all possible final states Designers
review them and select the one they prefer
48
2nd Problem Incremental integrity checking
context Sale inv self.shipment-gtforAll(s
s.plannedShipDateltself.paymentDate30)
UpdateAttribute(Sale, paymentDate, s1, 20/6/6)
UpdateAttribute(Shipment, plannedShipDate, sh3,
1/9/06)
InsertRT(DeliveredIn, s4,sh5)
Sale s1,1000, 1/8/06 s2,2000, 1/8/06 s3, 30,
10/8/06 s4, 200, 10/8/06 . . . sn, 1200,
15/1/07
Sale s1,1000, 20/6/06 s2,2000, 1/8/06 s3, 30,
10/8/06 s4, 200, 10/8/06 . . . sn, 1200,
15/1/07
Shipment sh1, 25/8/06, Porto sh2, 25/8/06,
Trondheim sh3, 1/7/06, Luxembourg sh4,
1/9/06, Riga sh5, 12/8/06, Klagenfurt . .
. shn, 18/1/07,Toronto
Shipment sh1, 25/8/06, Porto sh2, 25/8/06,
Trondheim sh3, 1/9/06, Luxembourg sh4,
1/9/06, Riga sh5, 12/8/06, Klagenfurt . .
. shn, 18/1/07,Toronto



UpdateAttribute(amount, s2,32)? DeleteSale(s3)?
Irrelevant!!
49
Incremental checking Goal

• Given a a constraint c and a structural event ev
  only the subet of instances affected by ev can
  violate c

GOAL For each type of event evt we determine an
incremental expression exp that when applied over
the intance i modified by an event of type evt
suffices to verify c
i.exp evaluates to true ? c is not violated

• Code-generation methods may use these expressions
  to generate an efficient checking code

50
Incremental checking Code Generation

• The generated expressions may be used for
  code-generation methods to efficiently check the
  constraints in the final platforms

UpdateAttr(paymentDate,Sale,s) Constraint
ValidShipDate
s.shipment-gtforAll(sh sh.plannedShipDatelts.paym
entDate30)
51
Incremental checking Outline of our method

1. Simplify the constraints
2. Determine the structural events that may violate
   the IC (PSE)
3. Specialize the constraint for that PSE
4. Analyze the effect of the PSE to detect the
   affected instances and construct the incremental
   expression

52
1. Determining the set of PSEs

• An event is a PSE for a constraint when its
  execution may induce a violation of the
  constraint
• To determine the PSEs we must take into account
  not only which elements appear in the constraint
  but also where they appear

IC Category self.customer-gtsize() gt 3 can be
violated by DeleteRT(Category-Customer) IC
Category self.customer-gtsize() lt 3 can be
violated by InserRT(Category-Customer)
53
1. Determining the set of PSEs

• context Category inv self.customer-gtforAll(
  c c.sale-gt select(paymentDategtnow()).import-gtsum(
  )ltself.maxPendingAmount)

InsertRT(BelongsTo)
UpdateAttribute(maxPendingAmount)
UpdateAttribute(amount)
InsertRT(Purchases)
UpdateAttribute(paymentDate)
54
Step 0 Constraint simplification

• Our method aplies a set of transformation rules
  over the original constraints. This simplified
  form facilitates the definition of the rest of
  the steps of the method

context Sale inv MinAmount not
Sale.allInstances()-gtexists(s s.amountlt10)
not X-gtexists(Y) ? X-gtforAll(not Y)
context Sale inv MinAmount Sale.allInstances()-gtf
orAll(s not (s.amountlt10))
not XltY ? XgtY
context Sale inv MinAmount Sale.allInstances()-gtf
orAll(s s.amountgt10)
ct.allInstances()-gtforAll(Y) ? Y
context Sale inv MinAmount self.amountgt10
55
Step 2 Appropriate representation/s for each IC

• Due to the high expressiveness of the OCL, the
  designer has different possibilities to express
  each constraint c
• Not all of them are equally adequate to verify c
  after events of type ev (where ev ? PSEs(c))

context Sale inv self.shipment-gtforAll( sh
sh.plannedShipDatelt self.paymentDate 30)
UpdateAttribute(paymentDate, Sale)
context DeliveredIn inv self.shipment.plannedShi
pDatelt (self.sale.paymentDate 30)
InsertRT(DeliveredIn)
context Shipment inv self.sale-gtforAll( s
self.plannedShipDatelt s.paymentDate 30)
UpdateAttribute(plannedShipDate, Shipment)
56
Code-generation Open issues

• Code-generation for derived elements
• Which types should we materialize?
• Automatic maintenance of materialized derived
  types
• Code-generation for behaviour elements
• Keep working on the declarative-gt imperative
  tranformation
• Integration of several behavioural diagrams
  before the code-generation phase
• Model transformations Code-generation is a
  sequence of model-to-model and model-to-text
  transformations
• Verification of model transformations
• Choosing the right model transformation language.
  Will QVT become the standard some day?

57
Code-generation Open issues

• Using NFRs to drive the transformation when
  several alternatives exist

• Alternative option create a separate table for
  MeetingInPreparation bad for complexity but good
  for evolvability -gt Which option best satisfices
  the designers NFRs ?

58
Reusability

• One of the main promises of O.O. (and COTS and
  web services,) is the possibility of reusing
  previously developed software pieces in the
  implementation of a new system
• The main obstacle is the problem of selecting the
  right software component/s to reuse.
• Currently, the selection process is not
  completely automatic and requires a formal
  definition of the software components and a
  semantic comparison between the components and
  the model
• Ex. Web services (signature comparison Ok,
  semantic comparison Poor)
• Ideally, the selection process should also
  consider possible non-functional requirements of
  the system and the cost of integrating the
  selected component into the rest of the system.

59
Index

• Goal
• Disclaimer
• Introduction
• A Research Agenda for
• Explicit Models
• Executable Models
• Evolving schemas
• Others
• Conclusions

60
Model Elements Evolution

• Changes on the model elements (adding/removing
  classes, attributes,) must be propagated to the
  design models and the code
• Changes should be made 1 - incrementally and 2
  respecting the manual changes done by the
  designer on the design models or the code.
  Traceability!
• Changes may also affect other elements in the
  same model
• Ex The formal definition of constraints,
  derivation rules and operations events may need
  to be adjusted since they may refer to elements
  that no longer exist or whose specification
  (cardinality, data type, etc.) has been changed
• Even more important, changes must also be
  propagated to the system data. Part of the data
  may become inconsistent with the new model.
• Further work on these topics must take into
  account the considerable amount of existing work
  on database schema evolution

61
Constraint and Derivation Rules Evolution

• Constraints evolution.
• Adding a constraint may turn the data
  inconsistent. When a constraint is added, we have
  to (efficiently) check whether or not the current
  system state satisfies it.
• Derivability evolution.
• The derivability of classes and associations may
  change (a base type may become derived or vice
  versa and the rule definition may change). This
  affects the population of the model element (and
  indirectly in the population of other types using
  the derived element)

62
V V of the Evolved Schema

• We need to efficiently VV the evolved schema.
• This process should be incremental we should
  only verify the subset of the schema affected
  by the evolution
• Current approaches for the efficient verification
  of evolved schemas focus on the detection of its
  consistency
• Much work is required to efficiently verify other
  quality factors of the evolved schema (as
  satisfiability).

63
Index

• Goal
• Disclaimer
• Introduction
• A Research Agenda for
• Explicit Models
• Executable Models
• Evolving schemas
• Others
• Conclusions

64
Benchmarks for MDD

• Benchmarks are widely used in other areas
  (databases, computer architectures, programming
  and so on) to test the performance and coverage
  of new techniques
• They facilitate the comparison between different
  techniques addressing the same goal
• We would need a set of large and complete models
  to test verification, validation, code-generation
  techniques
• The Repository for Model Driven Development
  (REMODD) Project (Jim Bieman, Betty Cheng and
  Robert France) is a step forward but not solves
  the problem
• Still active?

65
Education for MDD

• It must change from code-centric to
  model-centric.
• Ex (at least in Spain) all Dist. Soft. Eng.
  courses are basically JEE programming courses.
• Be careful not to focus too much on the
  notational aspects of modeling languages (as most
  courses do)
• We must concentrate on clearly explaining the
  semantics of the different modeling constructs
  and how they can be combined to construct
  complete and correct conceptual schemas.
• A body of examples of good and bad schemas
  for well-known domains would therefore be very
  useful.

66
Index

• Goal
• Disclaimer
• Introduction
• A Research Agenda for
• Explicit Models
• Executable Models
• Evolving schemas
• Others
• Conclusions

67
Conclusions

• MDD is a promising paradigm but not yet a reality
  except for simple domains
• Support in CASE tools is limited
• Industrial adoption of MDD techniques is unclear
• We already have the basic techniques, it is
  mostly a matter of
• Improving their expressivity
• Improving their efficiency
• based on already existing techniques in the
  programming/database world
• Problem Is research on MDD still fashionable?