Why am I here

• Development techniques are headed down the wrong path!

• Our world should be getting simpler – it is not

• The solutions that will solve the problem does not get enough attention

• I want you to start thinking about the right solutions

What is the problem?

• The promise of OO failed:– The code should clearly reflect our

understanding of the world

• Plumbing, infrastructure, mechanical, technical code takes the #1 position in the program

• Architecture fragments and hides domain model

• I drown in technical details!

I want to see my domain model again

I want to see my domain model again

Some issues

• Model and code is the same thing!

What happened?

• OO started out too naively

• There are three parts of the development process– Business level code– Infrastructure code– ”Weaving” of business and infrastructure

• Traditional J2EE development mixes all this into one big bowl of distasteful gooey

How do we solve it?

• Treat the different parts of the process apart

• Handle them orthogonally

• Maybe this is the way our profession should specialize?

The two approaches

• Model driven architecture– Standards defined (OMG)– Focuses on visual models– Model transformation and code generation

• ”The other approach”– Advocates are ”hacker” types – not ”suits”– Code model sufficient (visual views of code

welcome)– Many implementations – none really complete

Infrastructure code

PIM

Model Driven Archicture

We weave in technology

But we still have work to

do!

PSM

Code

I define the domain model

I contain all the technology decisions

I contain the details. The functionality is

written here

How MDA gets it wrong

• Graphical does not automatically mean more abstract

• The code is a model, too– The source code models the machine-code– The machine code models the idealized von

Neumann machine

• Weaving technology into the model too early is not good for the developer– When generating 80% of the code, the remaining

20% can be 5 times as hard to write

• Increases total complexity instead of reducing it

”The other approach”

Domain model code

UI codeClustering, distribution,

transaction codePersistence code

I define the domain model and contain the details of

business logic

I work with the infrastructure

Weaving code

Examples

• The totality of Totto’s ideas

• Aspect Oriented Programming-approaches

• Model Centric Development/spif (”simples possible infrastructure framework”)

• Naked Objects

• Many others (my own ”cerise” work)

Example: Using smart proxies

I write• Order.printInvoice• Order.getTotalPrice• for OrderLine in lines• total += line.getPrice• ...

• All business code!

The framework does:• Read the order from the

database• Send the order data to the

client• Cache the order data in the

client proxy• Cache the lines collection –

deeply

Or: something completely different:

• PrintInvoice is marked as being a server side method

Client

Rich client weaving

Application Server

Weaving – figure II

Domain model

App server weaving

Domain model

Domain model

Persistence weaving

Domain model

Database

Written by ”business analysts”

Written by ”architects”

Written by scalability, distribution etc, experts

Written by database experts

Written by Swing experts

Application specific code

Client Application Server

Weaving – figure II

Rich client weaving

Domain model

App server weaving

Domain model

Domain model

Persistence weaving

Domain model Database

Written by ”business analysts”

Written by ”architects”

Written by scalability, distribution etc, experts

Written by database experts

Written by Swing experts

Application specific code

Why is it cool?

• Write domain code in one place:– Easier to check with customers domain– Easier to understand– Easier to specialize in domain code

• Write infrastructure code in one place– Easier to develop– Easier to reuse – internally and externally– Easier to specialize in technical code

• Make domain code behave ”right” in many environments– Easier to test– Easier to understand– Easier to change and extend ”architecture”

Why is it cool?

• Write domain code in one place:– Easier to check with customers domain– Easier to understand– Easier to specialize in domain code

• Write infrastructure code in one place

• Make domain code behave ”right” in many environments

Why is it cool?

• Write domain code in one place:

• Write infrastructure code in one place– Easier to develop– Easier to reuse – internally and externally– Easier to specialize in technical code

• Make domain code behave ”right” in many environments

Why is it cool?

• Write domain code in one place:

• Write infrastructure code in one place

• Make domain code behave ”right” in many environments– Easier to test– Easier to understand– Easier to change and extend ”architecture”

Example environments to weave to

• UI Dialogs• UI Interaction• Distribution• Persistence• Schema generation• Single-tier• Test harness

Naked Objects automatically maps Java objects to dialogs

Implementation strategies

• Define pluggable interfaces in Java

• Frameworks with dynamic proxies

• Aspect-oriented programming

Example SPIF Store chain

Cache Remote Server Locking

AuthorizationCacheDatabase

The problems of the other approach

• The harder the weaving code is to write, the less the idea is worth

• We don’t know how much weaving is needed in practice

• We don’t know if we can really write infrastructure independent business logic

• In other words:– Not really tried out– Might not work!

What I want you to do

• Evaluate at least one approach

• If you think it will work:– Ask for it from vendors– Donate time to open source projects

• The ”suits” don’t understand why MDA is wrong:– MDA will be the standardized solution– We must fix the situation ourselves

Graphical programming

• Hass been tried• Just as complex as

textual programming• The value of graphical

representation is when we can abstract

• Class diagrams don’t abstract from classes, they just show them in another language!

Prograph example - Method “sort'' for topological sort algorithm

Comparison Topo in Ruby def topo indeg = indegrees() # Find the number of incoming links on each node result = [] remaining_nodes = self.nodes

(ready_nodes, remaining_nodes) = remaining_nodes.split { |node| indeg[node] == 0 } until ready_nodes.empty? current_node = ready_nodes.pop

current_node.adjecent.each { |node| indeg[node] -= 1 } (ready_nodes, remaining_nodes) = remaining_nodes.split { |node| indeg[node] == 0 }

result.push(current_node) end

if result.size < nodes.size raise "Graph contains cycles" end

resultend