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

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

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

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

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 (sort of…)
4

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

SOFTWARE ENGINEERING:
THE TRADITIONAL 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)

AUTOMATION
(OLD FASHIONED: OMG’s MDA)
7
analysts
(less) programmers
code generator
General Purpose
Specification
Mechanism
(Solution space)
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

AUTOMATION:
DOMAIN-SPECIFIC LANGUAGES (DSLs)
8
Programming
Specification
Mechanism
(Solution space)
Specification
Mechanism
(Problem space)
Very large gap
(this is done manually)
Smaller gap (this is done automatically)
General Purpose
General Purpose

9
Specification
Mechanism
(Solution space)
Specification
Mechanism
(Problem space)
Domain-specific
notation
Make the gap smaller
Automating this bigger gap
yields bigger gains
AUTOMATION:

10
Specification
Mechanism
(Solution space)
Specification
Mechanism
(Problem space)
Domain-specific
notation
Automating this bigger gap
yields bigger gains
(no need to look at this code)
AUTOMATION:

11
Specification
Mechanism
(Solution space)
Specification
Mechanism
(Problem space)
Domain-specific
notation
interpreter
AUTOMATION:

AUTOMATION…
FOR MORE PEOPLE?
12
Specification
Mechanism
(Solution space)
Specification
Mechanism
(Problem space)
Domain-specific
notation
interpreter
domain experts
Domain-specific modelling:
• For specific, well-understood domains
• High investment in build DSLs and infrastructure
• High gain by automation

DSLs AND 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

META-MODELS
AND MODELS
14
Task
name: String
start: Date
duration: int
coding1: Task
name=“code M1”
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=“code M2”
start= 8/7/24
duration=12
:next
:next
:previous
:previous
«conforms to»
Meta-model
• Primitives of the language, properties, relations
• Conceptual model of the domain
•  class diagram (classes, attributes, associations)
Model
• Instance of the meta-model
•  object diagram (objects, slots, links)
0..1

FULLY PRECISE AT ALL TIMES:
OCL INTEGRITY CONSTRAINTS
15
Meta-model
• Integrity constraints, invariants
• Object Constraint Language
(OCL)
Task
name: String
start: Date
duration: int
coding1: Task
name=“code M1”
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=“code M2”
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
Meta-model
• Integrity constraints, invariants
• Object Constraint Language
(OCL)
Model
• Needs to satisfy al invariants
Task
name: String
start: Date
duration: int
coding1: Task
name=“code M1”
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=“code M2”
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

DSLs :
CONCRETE SYNTAX
17
Task
name: String
start: Date
duration: int
coding1: Task
name=“code M1”
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=“code M2”
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

DSLs :
CONCRETE SYNTAX
18
Task
name: String
start: Date
duration: int
coding1: Task
name=“code M1”
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=“code M2”
start= 15/7/24
duration=12
:next
:next
:previous
:previous
«conforms to»
0..1
Textual syntax specification
Abstract syntax Concrete syntax
Task coding1 {
start: 8/7/24
duration: 5
next: testing, coding2
}
Task testing {
start: 15/7/24
duration: 10
}
…
Task returns Task:
‘Task’ name=String ‘{‘
‘start:’ start=Date
‘duration:’ duration=Int
(‘next:’ next+=[Task|String]
(‘,’ next+=[Task|String])*)?
‘}’

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

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

SOLUTIONS
21
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
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

SOLUTIONS
22
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
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

SOLUTIONS
23
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
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

SOLUTIONS
24
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
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

SOLUTIONS
25
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
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

SOLUTIONS
26
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
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

SOLUTIONS
27
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
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

SOLUTIONS
28
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
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 8th 2024, lasts 5 days.
After “code M1”, both tasks “test M1” and “code M2”
can start.
Task “test M1” starts July 15th 2024, lasts 10 days.

SOLUTIONS
29
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
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
can start.
Conversational
assistant
When was M1 coded?

SOLUTIONS
30
code M1
8/7/24 (5)
test M1
15/7/24 (10)
code M2
15/7/24 (12)
Model
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
can start.
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.

MDE: THE GOOD
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
Modelling for Telephony Services. ECMFA 2013: 179-191
[1]

MDE: THE BAD
MDE solutions are often very technical, hard to use
Frequently, oriented to developers
• Many deployed on Eclipse
• Installation, dependencies, etc
Rigidity of the solution
Evolving an MDE solution is hard
• Evolving the DSLs
• Co-evolution of all the associated artefacts
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)

LOW-CODE…
TO THE RESCUE?
Cloud-first
• Zero-cost instalation
• Usable from the browser
• Lifecycle management of the developed app
Oriented to citizen developers
• Graphical DSLs
• Forms, drag & drop
Domains
• Business applications (Microsoft PowerApps, OutSystems, Mendix)
• IoT (Nodered)
• Task-oriented chatbots (Google’s Dialogflow, Amazon Lex, IBM Watson)
• Machine Learning applications (Google’s AutoML, DataRobot, Akkio)
• …
33

LOW-CODE…
OLD WINE IN NEW BOTTLES?
34
D. Di Ruscio, D. Kolovos, J. de Lara, A. Pierantonio, M. Tisi, M. Wimmer: Low-code development and model-driven
engineering: Two sides of the same coin? Software and Systems Moeling 21(2): 437-446 (2022)
Many vendors of MDE solutions just rebranded as “low-code” tools
There are differences, though:

LOW-CODE SOFTWARE DEVELOPMENT…
35
MDE for automating
tasks like simulation,
formal verification,
software optimization,
or reverse engineering

36
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
models and offer
deployment/lifecycle
management
capabilities for the
produced system

38
models not used, but offer
deployment/lifecycle
management capabilities
for the produced system

39
models not used, and do not
offer deployment/lifecycle
management capabilities for
the produced system

LOW-CODE…
FOR ALL?
Not every (citizen or professional) developer has
• the same background…
• the same knowledge and skills…
• the same interest…
• the same device
But interacts with the IDE in the same way
• Frequently, as required from the most expert user
• One modelling language should fit all users and 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)

FROM LANGUAGES TO
LANGUAGE FAMILIES
Define language variants, appropriate for
• Different user skills and backgrounds
Example: Class diagrams with different levels of sophistication
• Different expressivity: modelling purpose, analyses
Example: Petri nets with inhibitor, read arcs, time, colours
• Different contexts of use
Example: DSL with different syntax depending on device
• Different project stages (levels of precision)
Example: From sketch-like diagrams to fully precise models
• People with different roles in the project
Example: DSL presenting different information depending on the role
• …
41

LANGUAGE FAMILIES:
NAIVE APPROACH
Example: variants of class diagrams
• different skills (w/wo aggregation, composition, associative classes, …)
• different target programming languages (w/wo multiple inheritance, interfaces, …)
• different project phases (w/wo methods)
“Clone and own”
• One meta-model per variant
Hundreds or thousands of variants
• Exponential number of languages with the number of features
42
(1) (2)
…
(288)

MDE+PRODUCT LINES =
LANGUAGE FAMILIES
43
Variability
• Describe the variability of the language family
• Features and their relations
Mapping
• Map features to language elements
Configuration
• A valid set of features
• Specifies a language within the family
Derivation
• Extracting the language associated to a configuration

VARIABILITY:
FEATURE MODEL
44
alternative
(exactly one)
or
(at least one)
mandatory optional
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}

MAPPING FEATURES 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

SELECTING LANGUAGES
FROM THE FAMILY
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
roles
2
*
playedBy
parents
*
A = {Multi, FullAssoc, Decorations, Card}

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»

LANGUAGE FAMILIES:
SEMANTICS
48
• Graph transformation
:Message
ack = false
n1 :Node
broken = false
n2 :Node
broken = false
n3 :Node
broken = false
linkedTo
linkedTo
from
to
at
Meta-model
match

LANGUAGE FAMILIES:
SEMANTICS
49
• Graph transformation Meta-model
:Message
ack = false
n1 :Node
broken = false
n2 :Node
broken = false
n3 :Node
broken = false
linkedTo
linkedTo
from
to
at
rule application

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

LANGUAGE FAMILIES:
SEMANTICS
51
Behavioural derivation

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

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

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

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

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

WHAT ABOUT AI ASSISTANTS?
Generative AI
LLMs
• Transformer-based architectures trained on vast amounts of data
• General-purpose (GPT, Llama, Mistral, …)
• Oriented to code (Codex, StarCoder, CodeLlama, …)
Chatbots on top
• ChatGPT, Gemini
All sorts of applications
• LangChain
57

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

AI ASSISTANTS: THE BAD
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

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

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

AI-ASSISTANTS
FOR CITIZEN DEVELOPERS?
62
Specification
Mechanism
(Solution space)
Specification
Mechanism
(Problem space)
Domain-specific
notation
domain experts
NL
notation
AI assistant
AI assistant

CHALLENGE: AI-ASSISTANTS
FOR CITIZEN DEVELOPERS!
63
Specification
Mechanism
(Solution space)
Specification
Mechanism
(Problem space)
Domain-specific
notation
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
CHALLENGE: AI-ASSISTANTS
FOR CITIZEN DEVELOPERS!
Several low-code platforms include assistants
• Microsoft powerapps (Copilot)
• Mendix (Maia)
• ..
Still, large room for improvement!
• Not nearly as impressive as LLMs for code
LLMs vs conversational syntax for DSLs [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)

WRAPPING UP…
Respond the increasing demand for software
• How to develop software faster, by more people?
Professional vs. Amateur (“DIY”) programming
• Code vs. DSLs
• Traditional IDEs vs Low-code platforms (web)
One language does not fit all
• Families of (domain-specific) languages
• Languages can be adaptive, too!
AI assistants
• Currently, mostly for professionals (current or future)
65

SO WHAT’S AHEAD?
Adaptive modelling languages
• Make languages and IDEs more aware of usage context (pragmatics)
AI assistants for professionals
• More streamlined integration with: IDEs, languages, dev processes
• Impact of AI assistants on IDEs, languages and processes?
AI assistants for citizen developers
• AI assistants within low-code platforms
• Democratize software development
66

THANKS!
Questions?
Juan.deLara@uam.es
67
http://www.miso.es
modelling &
software engineering
research group

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

More Related Content

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

More from miso_uam (20)

Recently uploaded (20)

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