Software development... for all? (keynote at ICSOFT'2024)

Our world runs on software. It governs all major aspects of our life. It is an enabler for research and innovation, and is critical for business competitivity. Traditional software engineering techniques have achieved high effectiveness, but still may fall short on delivering software at the accelerated pace and with the increasing quality that future scenarios will require.
To attack this issue, some software paradigms raise the automation of software development via higher levels of abstraction through domain-specific languages (e.g., in model-driven engineering) and empowering non-professional developers with the possibility to build their own software (e.g., in low-code development approaches). In a software-demanding world, this is an attractive possibility, and perhaps -- paraphrasing Andy Warhol -- "in the future, everyone will be a developer for 15 minutes". However, to make this possible, methods are required to tweak languages to their context of use (crucial given the diversity of backgrounds and purposes), and the assistance to developers throughout the development process (especially critical for non-professionals).
In this keynote talk at ICSOFT'2024 I presented enabling techniques for this vision, supporting the creation of families of domain-specific languages, their adaptation to the usage context; and the augmentation of low-code environments with assistants and recommender systems to guide developers (professional or not) in the development process.

1. SOFTWARE DEVELOPMENT…
FOR ALL?
ComputerScience Department
Universidad Autónoma de Madrid (Spain)
http://miso.es
@miso_uam
Juan de Lara

2. SOFTWARE, SOFTWARE,
SOFTWARE…
Importance of software nowadays
Enabler for most aspects of our daily live
•Energy systems
•Transportation
•Communications
•Work
•Leisure
“Our civilization runs on software”
“Our civilization is as reliant on software as it is on water”
—Bjarne Stroustrup
(creator of C++)
2

3. MORE SOFTWARE…
FASTER
Increasing demand for software
Professional software
•All sort of devices, IoT
•Apps on mobiles
•Web applications
•Desktop applications
Develop more software, faster, with higher quality
•More automation
•More powerful languages and frameworks (higher level of abstraction)
•Better tools
3

4. MORE SOFTWARE…
BY MORE PEOPLE
“Do-It-Yourself” (DIY) software
•Spreadsheets
•IFTT automation flows
•…
•Low-code platforms
Make software construction accessible to more profiles
•Lower the entry barrier to software development
•Make software development environments adaptable to the profile
in the future, everyone will be a developer for 15 minutes
—Andy Warhol (sortof…)
4

5. IN THIS TALK…
Overview techniques for
•automation in software development (to developsoftware faster)
and
•democratization of software development (to enablemore peopledevelopsoftware)
Founded on
•Model-driven engineering
•Low-code development
•Software product lines
•Conversational assistants and LLMs
5

6. SOFTWARE ENGINEERING :
THETRADITIONAL WAY
6
Programming
General Purpose
Programming Language (e.g., Java)
Specification
Mechanism
(Solution space)
Requirements (NL, notations)
Specification
Mechanism
(Problem space)
(and lots of testing)
(and iterations and increments)
clients, users
analysts
SW designers,
architects
programmers
manual work
manual work
General Purpose
Design notation (e.g., UML)

7. AUTOMATION
(OLDFASHIONED: OMG’sMDA)
7
analysts
(less) programmers
code generator
Programming
General Purpose
Programming Language (e.g., Java)
General Purpose
Design notation (e.g., UML)
Specification
Mechanism
(Solution space)
Requirements (NL, notations)
Specification
Mechanism
(Problem space)
manual work
Model-driven Architecture (MDA):
•Inflexibility of code generators
•Low gain: now UML is the programming language (not invented for that!)
•Not very agile
clients, users
SW designers,
architects

8. AUTOMATION :
DOMAIN-SPECIFICLANGUAGES (DSLs)
8
Programming
Specification
Mechanism
(Solution space)
Specification
Mechanism
(Problem space)
Verylarge gap
(this is done manually)
Smallergap (this is done automatically)
General Purpose
Design notation (e.g., UML)
Requirements (NL, notations)
General Purpose
Programming Language (e.g., Java)

9. 9
Programming
General Purpose
Programming Language (e.g., Java)
Specification
Mechanism
(Solution space)
Specification
Mechanism
(Problem space)
Domain-specific
notation
Make the gap smaller
Automating this bigger gap
yields bigger gains
Requirements (NL, notations)
AUTOMATION :
DOMAIN-SPECIFICLANGUAGES (DSLs)

10. 10
Programming
General Purpose
Programming Language (e.g., Java)
Specification
Mechanism
(Solution space)
Specification
Mechanism
(Problem space)
Domain-specific
notation
Make the gap smaller
Automating this bigger gap
yields bigger gains
Requirements (NL, notations)
(no need to look at this code)
AUTOMATION :
DOMAIN-SPECIFICLANGUAGES (DSLs)

11. 11
Specification
Mechanism
(Solution space)
Specification
Mechanism
(Problem space)
Domain-specific
notation
Make the gap smaller
Requirements (NL, notations)
interpreter
AUTOMATION :
DOMAIN-SPECIFICLANGUAGES (DSLs)

12. AUTOMATION …
FORMORE PEOPLE?
12
Specification
Mechanism
(Solution space)
Specification
Mechanism
(Problem space)
Domain-specific
notation
Make the gap smaller
Requirements (NL, notations)
interpreter
domain experts
Domain-specific modelling:
•For specific, well-understood domains
•High investment in build DSLs and infrastructure
•High gain by automation

13. DSLsAND MDE
Modelling languages
•Abstract syntax: meta-models
•Concrete syntax: textual, graphical, tabular, AR
•Semantics: code generation, interpreter
Models
Model transformations
•Model-to-model (in-place, out-place)
•Model-to-text
•Text-to-model
13
Language
engineering
DSL service
development
DSL use
DSL
DSL-based
automation
solution
Language
engineers
Domain
experts
programmers
Language
engineers
Domain
experts

14. META-MODELS
AND MODELS
14
Task
name: String
start: Date
duration: int
coding1: Task
name=“codeM1”
start= 8/7/24
duration=5
meta-model
model
*
next
testing: Task
name=“test M1”
start= 15/7/24
duration=10
previous
coding2: Task
name=“codeM2”
start= 8/7/24
duration=12
:next
:next
:previous
:previous
«conforms to»
Meta-model
•Primitivesofthelanguage,properties,relations
•Conceptualmodelofthedomain
•classdiagram(classes,attributes,associations)
Model
•Instanceofthemeta-model
•objectdiagram(objects,slots,links)
0..1

15. FULLY PRECISE AT ALL TIMES:
OCL INTEGRITY CONSTRAINTS
15
Meta-model
•Integrityconstraints,invariants
•ObjectConstraintLanguage
(OCL)
Task
name: String
start: Date
duration: int
coding1: Task
name=“codeM1”
start= 8/7/24
duration=5
meta-model
model
*
next
testing: Task
name=“test M1”
start= 15/7/24
duration=10
previous
coding2: Task
name=“codeM2”
start= 8/7/24
duration=12
:next
:next
:previous
:previous
«conforms to»
0..1
someInitial inv:
Task.allInstances()exists(e|
e.previousisEmpty())
nextAfter inv:
nextforAll(n|n.start>start)

16. 16
Meta-model
•Integrityconstraints,invariants
•ObjectConstraintLanguage
(OCL)
Model
•Needstosatisfyalinvariants
Task
name: String
start: Date
duration: int
coding1: Task
name=“codeM1”
start= 8/7/24
duration=5
meta-model
model
*
next
testing: Task
name=“test M1”
start= 15/7/24
duration=10
previous
coding2: Task
name=“codeM2”
start= 8/7/24
duration=12
:next
:next
:previous
:previous
«conforms to»
0..1
someInitial inv:
Task.allInstances()exists(e|
e.previousisEmpty())
nextAfter inv:
nextforAll(n|n.start>start)
FULLY PRECISE AT ALL TIMES:
OCL INTEGRITY CONSTRAINTS

17. DSLs:
CONCRETE SYNTAX
17
Task
name: String
start: Date
duration: int
coding1: Task
name=“codeM1”
start= 8/7/24
duration=5
meta-model
model
*
next
testing: Task
name=“test M1”
start= 15/7/24
duration=10
previous
coding2: Task
name=“codeM2”
start= 15/7/24
duration=12
:next
:next
:previous
:previous
«conforms to»
0..1
«name»
previousisEmpty()
(conditional style)
Graphical concrete syntax specification
Abstract syntax
«start» («duration»)
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Concrete syntax

18. DSLs:
CONCRETE SYNTAX
18
Task
name: String
start: Date
duration: int
coding1: Task
name=“codeM1”
start= 8/7/24
duration=5
meta-model
model
*
next
testing: Task
name=“test M1”
start= 15/7/24
duration=10
previous
coding2: Task
name=“codeM2”
start= 15/7/24
duration=12
:next
:next
:previous
:previous
«conforms to»
0..1
Textual syntax specification
Abstract syntax Concrete syntax
Taskcoding1 {
start: 8/7/24
duration:5
next: testing, coding2
}
Task testing {
start: 15/7/24
duration: 10
}
…
Task returnsTask:
‘Task’ name=String ‘{‘
‘start:’ start=Date
‘duration:’ duration=Int
(‘next:’ next+=[Task|String]
(‘,’next+=[Task|String])*)?
‘}’

19. DSL-BASED AUTOMATION
SOLUTIONS
19
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model

20. DSL-BASED AUTOMATION
SOLUTIONS
20
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
Model (Time Petri Nets)
code M2
test M1
code M1
[5, 5]
complete
code M1
complete
test M1
complete
code M2
[10,10]
[12,12]
M2M
transformation
Petri nets tool

21. DSL-BASED AUTOMATION
SOLUTIONS
21
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
Model (Time Petri Nets)
code M2
test M1
code M1
[5, 5]
complete
code M1
complete
test M1
complete
code M2
[10,10]
[12,12]
M2M
transformation
Petri nets tool

22. DSL-BASED AUTOMATION
SOLUTIONS
22
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
Model (Time Petri Nets)
code M2
test M1
code M1
[5, 5]
complete
code M1
complete
test M1
complete
code M2
[10,10]
[12,12]
M2M
transformation
Petri nets tool

23. DSL-BASED AUTOMATION
SOLUTIONS
23
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
Model (Time Petri Nets)
code M2
test M1
code M1
[5, 5]
complete
code M1
complete
test M1
complete
code M2
[10,10]
[12,12]
M2M
transformation
Petri nets tool

24. DSL-BASED AUTOMATION
SOLUTIONS
24
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
Model (Time Petri Nets)
code M2
test M1
code M1
[5, 5]
complete
code M1
complete
test M1
complete
code M2
[10,10]
[12,12]
M2M
transformation
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
M2M
transformation
(in-place)
date=8/7/24
Simulator

25. DSL-BASED AUTOMATION
SOLUTIONS
25
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
Model (Time Petri Nets)
code M2
test M1
code M1
[5, 5]
complete
code M1
complete
test M1
complete
code M2
[10,10]
[12,12]
M2M
transformation
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
M2M
transformation
(in-place)
date=15/7/24
Simulator

26. DSL-BASED AUTOMATION
SOLUTIONS
26
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
Model (Time Petri Nets)
code M2
test M1
code M1
[5, 5]
complete
code M1
complete
test M1
complete
code M2
[10,10]
[12,12]
M2M
transformation
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
M2M
transformation
(in-place)
date=25/7/24
Simulator

27. DSL-BASED AUTOMATION
SOLUTIONS
27
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
Model (Time Petri Nets)
code M2
test M1
code M1
[5, 5]
complete
code M1
complete
test M1
complete
code M2
[10,10]
[12,12]
M2M
transformation
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
M2M
transformation
(in-place)
date=27/7/24
Simulator

28. DSL-BASED AUTOMATION
SOLUTIONS
28
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
Model (Time Petri Nets)
code M2
test M1
code M1
[5, 5]
complete
code M1
complete
test M1
complete
code M2
[10,10]
[12,12]
M2M
transformation
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
M2M
transformation
(in-place)
date=8/7/24
Text/Code
M2text
transformation
The following is a project plan:
Task “code M1” starts July 8
th
2024, lasts 5 days.
After “code M1”, both tasks “test M1” and “code M2”
can start.
Task “test M1” starts July 15
th
2024, lasts 10 days.
Task “code M2” starts July 15
th
2024, lasts 12 days.

29. DSL-BASED AUTOMATION
SOLUTIONS
29
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
Model (Time Petri Nets)
code M2
test M1
code M1
[5, 5]
complete
code M1
complete
test M1
complete
code M2
[10,10]
[12,12]
M2M
transformation
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
M2M
transformation
(in-place)
date=8/7/24
Text/Code
M2text
transformation
The following is a project plan:
Task “code M1” starts July 8
th
2024, lasts 5 days.
After “code M1”, both tasks “test M1” and “code M2”
can start.
Task “test M1” starts July 15
th
2024, lasts 10 days.
Task “code M2” starts July 15
th
2024, lasts 12 days.
Conversational
assistant
When was M1 coded?

30. DSL-BASED AUTOMATION
SOLUTIONS
30
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
Model (Time Petri Nets)
code M2
test M1
code M1
[5, 5]
complete
code M1
complete
test M1
complete
code M2
[10,10]
[12,12]
M2M
transformation
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
M2M
transformation
(in-place)
date=8/7/24
Text/Code
M2text
transformation
The following is a project plan:
Task “code M1” starts July 8
th
2024, lasts 5 days.
After “code M1”, both tasks “test M1” and “code M2”
can start.
Task “test M1” starts July 15
th
2024, lasts 10 days.
Task “code M2” starts July 15
th
2024, lasts 12 days.
Conversational
assistant
Task "code M1" was scheduled to
start on July 8, 2024, and lasted for 5
days, meaning it was coded from July
8, 2024, to July 12, 2024.

31. MDE: THEGOOD
Many examples of success
Reported productivity improvements
31
[1] Buezas, Guerra, de Lara, Martín, Monforte, Mori, Ogallar, Pérez, Sánchez Cuadrado: Umbra Designer: Graphical
ModellingforTelephonyServices. ECMFA 2013: 179-191
[1]

32. MDE: THEBAD
MDE solutionsare oftenverytechnical, hardto use
Frequently, orientedto developers
•ManydeployedonEclipse
•Installation, dependencies, etc
Rigidityof thesolution
EvolvinganMDE solutionishard
•EvolvingtheDSLs
•Co-evolutionof alltheassociatedartefacts
32
Bucchiarone, Cabot, Paige, Pierantonio: Grand challenges in model-driven engineering: an analysis of the state of
the research. Softw. Syst. Model. 19(1): 5-13 (2020)

33. LOW-CODE…
TO THERESCUE?
Cloud-first
•Zero-costinstalation
•Usable fromthebrowser
•Lifecyclemanagementofthedevelopedapp
Orientedto citizendevelopers
•GraphicalDSLs
•Forms, drag& drop
Domains
•Business applications(Microsoft PowerApps, OutSystems, Mendix)
•IoT(Nodered)
•Task-orientedchatbots (Google’sDialogflow, Amazon Lex, IBM Watson)
•Machine Learningapplications(Google’sAutoML, DataRobot, Akkio)
•…
33

34. LOW-CODE…
OLD WINEIN NEW BOTTLES?
34
D. Di Ruscio, D. Kolovos, J. de Lara, A. Pierantonio, M. Tisi, M. Wimmer: Low-codedevelopmentand model-driven
engineering: Twosidesof thesamecoin? Software and SystemsMoeling21(2): 437-446 (2022)
Many vendors of MDE solutions just rebranded as “low-code” tools
There are differences, though:

35. LOW-CODESOFTWARE DEVELOPMENT …
OLD WINEIN NEW BOTTLES?
35
D. Di Ruscio, D. Kolovos, J. de Lara, A. Pierantonio, M. Tisi, M. Wimmer: Low-codedevelopmentand model-driven
engineering: Twosidesof thesamecoin? Software and SystemsMoeling21(2): 437-446 (2022)
Many vendors of MDE solutions just rebranded as “low-code” tools
There are differences, though:
MDE for automating
tasks like simulation,
formal verification,
software optimization,
or reverse engineering

36. LOW-CODESOFTWARE DEVELOPMENT …
OLD WINEIN NEW BOTTLES?
36
D. Di Ruscio, D. Kolovos, J. de Lara, A. Pierantonio, M. Tisi, M. Wimmer: Low-codedevelopmentand model-driven
engineering: Twosidesof thesamecoin? Software and SystemsMoeling21(2): 437-446 (2022)
Many vendors of MDE solutions just rebranded as “low-code” tools
There are differences, though:
models to reduce the
code required (e.g. via
generation or
interpretation) but
without offering
deployment or lifecycle
management capabilities
for the produced system

37. LOW-CODESOFTWARE DEVELOPMENT …
OLD WINEIN NEW BOTTLES?
37
D. Di Ruscio, D. Kolovos, J. de Lara, A. Pierantonio, M. Tisi, M. Wimmer: Low-codedevelopmentand model-driven
engineering: Twosidesof thesamecoin? Software and SystemsMoeling21(2): 437-446 (2022)
Many vendors of MDE solutions just rebranded as “low-code” tools
There are differences, though:
models and offer
deployment/lifecycle
management
capabilities for the
produced system

38. LOW-CODESOFTWARE DEVELOPMENT …
OLD WINEIN NEW BOTTLES?
38
D. Di Ruscio, D. Kolovos, J. de Lara, A. Pierantonio, M. Tisi, M. Wimmer: Low-codedevelopmentand model-driven
engineering: Twosidesof thesamecoin? Software and SystemsMoeling21(2): 437-446 (2022)
Many vendors of MDE solutions just rebranded as “low-code” tools
There are differences, though:
models not used, but offer
deployment/lifecycle
management capabilities
for the produced system

39. LOW-CODESOFTWARE DEVELOPMENT …
OLD WINEIN NEW BOTTLES?
39
D. Di Ruscio, D. Kolovos, J. de Lara, A. Pierantonio, M. Tisi, M. Wimmer: Low-codedevelopmentand model-driven
engineering: Twosidesof thesamecoin? Software and SystemsMoeling21(2): 437-446 (2022)
Many vendors of MDE solutions just rebranded as “low-code” tools
There are differences, though:
models not used, and do not
offer deployment/lifecycle
management capabilities for
the produced system

40. LOW-CODE…
FORALL?
Notevery(citizenorprofessional) developerhas
•thesamebackground…
•thesameknowledgeand skills…
•thesameinterest…
•thesamedevice
ButinteractswiththeIDE in thesameway
•Frequently, as requiredfromthemostexpertuser
•Onemodellinglanguageshouldfitallusersand scenarios
•“visual monolinguism” [1]
40
[1] Daniel L. Moody: The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in
Software Engineering. IEEE Trans. Software Eng. 35(6): 756-779 (2009)

41. FROMLANGUAGES TO
LANGUAGE FAMILIES
Define languagevariants, appropriatefor
•Differentuserskillsand backgrounds
Example: Classdiagramswithdifferentlevelsofsophistication
•Differentexpressivity: modellingpurpose, analyses
Example: Petri nets withinhibitor, readarcs, time, colours
•Differentcontextsofuse
Example: DSL withdifferentsyntaxdependingondevice
•Differentprojectstages(levelsofprecision)
Example: Fromsketch-likediagramstofullyprecise models
•People withdifferentroles in theproject
Example: DSL presentingdifferentinformationdependingontherole
•…
41

42. LANGUAGE FAMILIES:
NAIVEAPPROACH
Example: variantsof classdiagrams
•differentskills(w/woaggregation, composition, associativeclasses, …)
•differenttarget programminglanguages(w/womultipleinheritance, interfaces, …)
•differentprojectphases(w/womethods)
“Clone and own”
•Onemeta-modelper variant
Hundredsorthousandsof variants
•Exponentialnumberof languageswiththenumberof features 42
(1) (2)
…
(288)

43. MDE+PRODUCT LINES=
LANGUAGE FAMILIES
43
Variability
•Describe thevariabilityof thelanguagefamily
•Featuresand theirrelations
Mapping
•Mapfeaturesto languageelements
Configuration
•A validset of features
•Specifiesa languagewithinthefamily
Derivation
•Extractingthelanguageassociatedto a configuration

44. VARIABILITY:
FEATUREMODEL
44
alternative
(exactlyone)
or
(at leastone)
mandatoryoptional
Configuration: set of features satisfying all constraints
Admits 288 configurations, like
•
A= {Multi, FullAssoc, Decorations, Card}
•
D= {Methods, Multi, FullAssoc, Decorations, Comp, Aggr, Navig, Card}
•
J= {Methods, Single, Ref, Interfaces, Decorations, Comp, Aggr, Navig, Card}

45. MAPPINGFEATURES TO
LANGUAGE ELEMENTS
45
Annotative approach [1]
•150% meta-model
•Presence conditions
Modular approach [2]
•Language modules
•Composition mechanism
[1] Guerra, de Lara, Chechik, Salay: Property Satisfiability
Analysis for Product Lines of Modelling Languages. IEEE
Trans. Software Eng. 48(2): 397-416 (2022)
[2] de Lara, Guerra, Bottoni. Modular Language
Product Lines: Concept, Tool and Analysis. 2024.
Software and Systems Modeling, Vol in press (2024)
Class
name: String
isAbstract: boolean
Attribute
name: String
type: String
*
attributes
ClassDiagram
Class
Method
name: String
methods
* Class
parents
*
Class parent
0..1
Class
… …Methods
Multi Single No

46. SELECTING LANGUAGES
FROMTHEFAMILY
46
A configuration extracts a
language from the family
•Derivation
Annotative approach
•Delete elements with
presence condition false
Compositional approach
•Compose the selected
fragments within modules
Class
name: String
isAbstract: boolean
Attribute
name: String
type: String
*
attributes
Association
name: String
Role
name: String
min: int= 0
max: int=-1
roles2
*
playedBy
parents
*

A= {Multi, FullAssoc, Decorations, Card}

47. LANGUAGE FAMILIES:
SEMANTICS
47
Rules to express behaviour
•In-place transformation
•Graph transformation
:Message
ack= false
n1 :Node
broken= false
n2 :Node
broken= false
n3 :Node
broken= false
linkedTo linkedTo
from
to
at
Meta-model
Model «conforms to»

48. LANGUAGE FAMILIES:
SEMANTICS
48
Rules to express behaviour
•In-place transformation
•Graph transformation
:Message
ack= false
n1 :Node
broken= false
n2 :Node
broken= false
n3 :Node
broken= false
linkedTo linkedTo
from
to
at
Meta-model
Model «conforms to»
match

49. LANGUAGE FAMILIES:
SEMANTICS
49
Rules to express behaviour
•In-place transformation
•Graph transformation
Meta-model
:Message
ack= false
n1 :Node
broken= false
n2 :Node
broken= false
n3 :Node
broken= false
linkedTo linkedTo
from
to
at
Model «conforms to»
rule application

50. LANGUAGE FAMILIES:
SEMANTICS
50
Compositional approach
•Rules
•Extension rules

51. LANGUAGE FAMILIES:
SEMANTICS
51
Behavioural derivation

52. LANGUAGE FAMILIES:
CONCRETE SYNTAX
52
Extend modules with Concrete Syntax Specification
These are models, conformant to a meta-model
Product Lines of Graphical Modelling Languages. Garmendia, Guerra, de Lara. Proc MODELS’2024

53. LANGUAGE FAMILIES:
CONCRETE SYNTAX
53
Extend modules with Concrete Syntax Specification
Product Lines of Graphical Modelling Languages. Garmendia, Guerra, de Lara. Proc MODELS’2024

54. CAPONE: TOOLSUPPORT FOR
LANGUAGE FAMILIES
54https://capone-pl.github.io/

55. CAPONE:
GENERATED EDITORS
55https://capone-pl.github.io/

56. ADAPTIVE LANGUAGES :
BEYONDLANGUAGE FAMILIES
56
Triggers
•Reconfiguration of the language
•Manual or based on model analysis
Model migration
•Update the current model to the new
language variant

57. WHATABOUTAIASSISTANTS?
GenerativeAI
LLMs
•Transformer-basedarchitecturestrainedonvastamountsof data
•General-purpose(GPT, Llama, Mistral, …)
•Orientedto code(Codex, StarCoder, CodeLlama, …)
Chatbots ontop
•ChatGPT, Gemini
Allsortsof applications
•LangChain
57

58. AIASSISTANTS…
FORPROFESSIONAL PROGRAMMERS
58
(but also helps in other tasks, like testing, debugging, documentation, etc)
Programming
General Purpose
Programming
Language (e.g., Java)
Specification
Mechanism
(Solution space)
Requirements (NL, notations)
Specification
Mechanism
(Problem space)
clients, users
analysts
SW designers,
architects
programmers
manual work
General Purpose
Design notation (e.g., UML)
code
NL
AI assistant

59. AIASSISTANTS: THEBAD
Trustworthyness
•Quality assurance for the proposed code
AI-aware IDEs!
•Integration with the IDE, not just text & copy-paste
•Context
•Integration of multiple assistants, for multiple tasks?
•Extension to other tasks?
•Traceability?
59

60. EXTENSIBLE AI-ASSISTANCE
ARCHITECTURE FORIDES
60
Contreras, Guerra, de Lara: Conversational Assistants for Software Development: Integration, Traceability and
Coordination. Proc. ENASE 2024: 27-38

61. AITRACEABILITY
61
Annotations in generated code
https://caretpro.github.io/

62. AI-ASSISTANTS
FORCITIZENDEVELOPERS ?
62
Specification
Mechanism
(Solution space)
Specification
Mechanism
(Problem space)
Domain-specific
notation
Requirements (NL, notations)
domain experts
NL
notation
AI assistant
AI assistant

63. CHALLENGE: AI-ASSISTANTS
FORCITIZENDEVELOPERS !
63
Specification
Mechanism
(Solution space)
Specification
Mechanism
(Problem space)
Domain-specific
notation
Requirements (NL, notations)
domain experts
NL
notation
AI assistant
AI assistant
Domain-specific languages and tools
•Not trained on such DSLs!
•Makes assistance difficult
•Few shot learners

64. 64
CHALLENGE: AI-ASSISTANTS
FORCITIZENDEVELOPERS !
Severallow-codeplatformsincludeassistants
•Microsoft powerapps(Copilot)
•Mendix(Maia)
•..
Still, largeroomforimprovement!
•Notnearlyas impressiveas LLMsforcode
LLMsvs conversationalsyntaxforDSLs[1]
[1] Sara Pérez-Soler, Mario González-Jiménez, Esther Guerra, Juan de Lara: Towards Conversational Syntax for
Domain-Specific Languages using Chatbots. J. Object Technol. 18(2): 5:1-21 (2019)

65. WRAPPING UP…
Respondtheincreasingdemandforsoftware
•Howtodevelopsoftware faster, bymore people?
Professional vs. Amateur (“DIY”) programming
•Codevs. DSLs
•TraditionalIDEsvs Low-codeplatforms(web)
Onelanguagedoesnotfitall
•Familiesof(domain-specific) languages
•Languagescan be adaptive, too!
AI assistants
•Currently, mostlyforprofessionals(currentorfuture)
65

66. SO WHAT’SAHEAD?
Adaptive modellinglanguages
•Makelanguagesand IDEsmore awareofusagecontext(pragmatics)
AI assistantsforprofessionals
•More streamlinedintegrationwith: IDEs, languages, devprocesses
•ImpactofAI assistantsonIDEs, languagesand processes?
AI assistantsforcitizendevelopers
•AI assistantswithinlow-codeplatforms
•Democratizesoftware development
66

67. THANKS!
Questions?
[email protected]
67
http://www.miso.es
modelling&
software engineering
researchgroup