Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
A Unified View of Modeling and Programming:
The Perspective from Executable UML
Presented at ISoLA 2016, Corfu, Greece
Ed ...
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 sys...
We can model that!We can model that!
A program is a model of the specified computation, abstracting away
from the details ...
We can model that!
Programs can also be domain models
public class Bank {
private String bankId;
private Set<Customer> cus...
We can model that!
But make implementation commitments
public class Customer {
...
private Set<Account> accounts = new Has...
We can model that!We can model that!
UML began as a notation for models of programs.
But UML 2 has constructs that allow t...
We can model that!
UML is common for domain modeling
public class Bank {
private String bankId;
private Set<Customer> cust...
We can model that!
But diagrams are just notation
class Bank {
public bankId: String;
public customers: compose Customer[*...
We can model that!
Computation can be modeled, too
class Bank {
public bankId: String;
public customers: compose Customer[...
We can model that!
And declarative constraints, too
A UML constraint can
be specified using a
UML behavior.
A UML constrai...
We can model that!
Allowing deductions to be made
Given the accounts of a
customer, the
totalBalance can be
derived.
Given...
We can model that!We can model that!
A combined modeling/programming language
should:
•Be designed to express both problem...
We can model that!We can model that!
• Models can be given precise semantics.
• Not all model semantics are execution
sema...
Upcoming SlideShare
Loading in …5
×

A Unified View of Modeling and Programming

482 views

Published on

Presentation from the ISOLA 2016 Conference

Published in: Technology
  • Be the first to comment

A Unified View of Modeling and Programming

  1. 1. 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
  2. 2. 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.
  3. 3. We can model that!We can model that! 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); if (customer != null) { int totalBalance = 0; for (Account account: customer.accounts) { totalBalance += account.balance; } } 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”… There is a customer identified by “customerId”…
  4. 4. 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 { private String bankId; private Set<Customer> customers; private Set<Account> accounts; ... } public class Customer { private String customerId; private Set<Account> accounts; ... } public class Customer { private String customerId; private Set<Account> accounts; ... } public class Account { private String accountId; private int balance = 0; private Set<Customer> accountOwners; ... } 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.
  5. 5. We can model that! But make implementation commitments public class Customer { ... 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 Customer { ... 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); if (customer != null) { totalBalance = 0; for (Account account: customer.accounts) { totalBalance += account.balance; } } 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); if (customer != null) { totalBalance = 0; for (Account account: customer.accounts) { totalBalance += account.balance; } } 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.
  6. 6. We can model that!We can model that! 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. There is a customer identified by “customerId”… There is a customer identified by “customerId”…
  7. 7. We can model that! UML is common for domain modeling public class Bank { private String bankId; private Set<Customer> customers; private Set<Account> accounts; ... } public class Bank { private String bankId; private Set<Customer> customers; private Set<Account> accounts; ... } public class Customer { private String customerId; private Set<Account> accounts; ... } public class Customer { private String customerId; private Set<Account> accounts; ... } public class Account { private String accountId; private int balance = 0; private Set<Customer> accountOwners; ... } public class Account { private String accountId; private int balance = 0; private Set<Customer> accountOwners; ... } 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.
  8. 8. We can model that! But diagrams are just notation class Bank { public bankId: String; public customers: compose Customer[*]; public accounts: compose Account[*]; } class Bank { public bankId: String; public customers: compose Customer[*]; public accounts: compose Account[*]; } 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.
  9. 9. We can model that! Computation can be modeled, too class Bank { public bankId: String; public customers: compose Customer[*]; public accounts: compose Account[*]; public totalAccountBalance(in customerId: String): Integer[0..1] { customer = this.customers -> select c (c.customerId == customerId); return customer.accounts.balance -> reduce '+'; } ... } class Bank { public bankId: String; public customers: compose Customer[*]; public accounts: compose Account[*]; 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.
  10. 10. 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.
  11. 11. 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).
  12. 12. We can model that!We can model that! 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
  13. 13. We can model that!We can model that! • 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?

×