Apr 01, 2015
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