A Unified View of Modeling and Programming

A Unified View of Modeling and Programming:
The Perspective from Executable UML
Presented at ISoLA 2016, Corfu, Greece
Ed Seidewitz
10 October 2016
Copyright © 2016 Ed Seidewitz

We can model that!We can model that!
What is a model?
A model is a set of statements in a modeling
language about some system under study or
domain.*
What is a program?
A program is a specification for a computation
to be a executed on a computer.
Models and Programs
* See Ed Seidewitz, “What Models Mean”, IEEE Software, September/October 2003 for more.

A program is a model of the specified computation, abstracting away
from the details of how the computation is actually executed on a
computer.
A programming language is a modeling language for creating models
of execution.
All programs are models
Customer customer = customers.get(customerId);
if (customer != null) {
int totalBalance = 0;
for (Account account: customer.accounts) {
totalBalance += account.balance;
}
}
Customer customer = customers.get(customerId);
int totalBalance = 0;
}
}
Java
…and a value called
“totalBalance”…
…and a value called
“totalBalance”…
… that is iteratively computed
to be the sum of the
customer’s account balances.
… that is iteratively computed
to be the sum of the
customer’s account balances.
There is a customer identified
by “customerId”…

We can model that!
Programs can also be domain models
public class Bank {
private String bankId;
private Set<Customer> customers;
private Set<Account> accounts;
...
}
public class Bank {
...
}
public class Customer {
private String customerId;
...
}
...
}
public class Account {
private String accountId;
private int balance = 0;
private Set<Customer> accountOwners;
...
}
...
}
Classes are intended to reflect
domain concepts.
Classes are intended to reflect
domain concepts.
Fields reflect properties
of those concepts…
Fields reflect properties
of those concepts…
… or relationships
with other concepts.
… or relationships
with other concepts.

We can model that!
But make implementation commitments
...
private Set<Account> accounts = new HashSet<Account>();
public void addAccount(Account account) {
if (account != null && !this.accounts.contains(account)) {
this.accounts.add(account);
account.addAccountOwner(this);
}
}
...
}
...
private Set<Account> accounts = new HashSet<Account>();
public void addAccount(Account account) {
if (account != null && !this.accounts.contains(account)) {
this.accounts.add(account);
account.addAccountOwner(this);
}
}
...
} public class Bank {
...
private Map<String, Account> customers = new HashMap<String, Customer>();
public Integer totalAccountBalance(String customerId) {
Integer totalBalance = null;
Customer customer = this.customers.get(customerId);
totalBalance = 0;
}
}
return totalBalance;
}
...
}
public class Bank {
...
private Map<String, Account> customers = new HashMap<String, Customer>();
public Integer totalAccountBalance(String customerId) {
Integer totalBalance = null;
Customer customer = this.customers.get(customerId);
totalBalance = 0;
}
}
return totalBalance;
}
...
}
Pick implementation
classes for collections.
Pick implementation
classes for collections.
Deal with bidirectional
relationships.
Deal with bidirectional
relationships.
Choose representations for
efficient computation.
Choose representations for
efficient computation.
Decide on (generally sequential)
control structuring.
Decide on (generally sequential)
control structuring.

UML began as a notation for models of programs.
But UML 2 has constructs that allow the specification of Turing-
complete computation models.
•Foundational UML (fUML) provides precise execution semantics.
•Action Language for fUML (Alf) provides a textual notation.
Executable UML models are programs
customer = Customer -> select c (c.customerId == customerId);
totalBalance = customer.accounts.balance -> reduce '+';
customer = Customer -> select c (c.customerId == customerId);
totalBalance = customer.accounts.balance -> reduce '+';
Alf
… and a value called “totalBalance”
that is sum of the customer’s
account balances.
… and a value called “totalBalance”
that is sum of the customer’s
account balances.

We can model that!
UML is common for domain modeling
public class Bank {
...
}
public class Bank {
...
}
...
}
...
}
...
}
...
}
The UML model directly
corresponds to the
program design…
The UML model directly
corresponds to the
program design…
…but abstracts away from
implementation details (like
collection classes).
…but abstracts away from
implementation details (like
collection classes).
It also shows some things
implicit in the program, like
association composition
and bidirectionality.
It also shows some things
implicit in the program, like
association composition
and bidirectionality.

We can model that!
But diagrams are just notation
class Bank {
public bankId: String;
public customers: compose Customer[*];
public accounts: compose Account[*];
}
class Bank {
}
assoc AccountOwnership {
public accountOwners: Customer[*];
public accounts: Account[*];
}
assoc AccountOwnership {
public accountOwners: Customer[*];
public accounts: Account[*];
} class Account {
public accountId: String;
public balance: Integer = 0;
}
class Account {
public accountId: String;
public balance: Integer = 0;
}
class Customer {
public customerId: String;
}
class Customer {
public customerId: String;
}
A UML class model has
semantics independent of its
mapping to any other language…
A UML class model has
semantics independent of its
mapping to any other language…
…which can be
notated textually as
well as graphically.
…which can be
notated textually as
well as graphically.

We can model that!
Computation can be modeled, too
class Bank {
public totalAccountBalance(in customerId: String): Integer[0..1] {
customer = this.customers -> select c (c.customerId == customerId);
return customer.accounts.balance -> reduce '+';
}
...
}
class Bank {
public totalAccountBalance(in customerId: String): Integer[0..1] {
customer = this.customers -> select c (c.customerId == customerId);
return customer.accounts.balance -> reduce '+';
}
...
} The underlying semantics are based
on data-flow, not an implicit von
Neumann architecture.
The underlying semantics are based
on data-flow, not an implicit von
Neumann architecture.
These actions are
inherently concurrent.
These actions are
inherently concurrent.
…with far fewer implementation
commitments.
…with far fewer implementation
commitments.

We can model that!
And declarative constraints, too
A UML constraint can
be specified using a
UML behavior.
A UML constraint can
be specified using a
UML behavior.

We can model that!
Allowing deductions to be made
Given the accounts of a
customer, the
totalBalance can be
derived.
Given the accounts of a
customer, the
totalBalance can be
derived.
Given the accountOwners of
an account, the owning bank
can be deduced (or
validated).
Given the accountOwners of
an account, the owning bank
can be deduced (or
validated).

A combined modeling/programming language
should:
•Be designed to express both problem and
solution domain models, not just abstract
hardware computing paradigms
•Have formal semantics that allow reasoning
about models, with execution semantics for
behavioral models
•Have a textual notation for representing and
reasoning on all types of models, with graphical
notations allowing multiple views of the same
model
Combining modeling and programming

• Models can be given precise semantics.
• Not all model semantics are execution
semantics.
– E.g., requirements models, architectural models,
business models…
• Some models have execution semantics, and
these are programs.
• Executable models in context of wider
modeling allows deductive or inductive
reasoning combined with execution and
testing
Why is this a good idea?

A Unified View of Modeling and Programming

More Related Content

What's hot

Similar to A Unified View of Modeling and Programming

More from Ed Seidewitz

Recently uploaded

A Unified View of Modeling and Programming