2. 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

3. 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!

4. I want to see my domain model again

5. Some issues Model and code is the same thing!

6. 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

7. 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?

8. 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

9. 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

10. 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

11. ”The other approach” Domain model code UI code Clustering, distribution, transaction code Persistence code I define the domain model and contain the details of business logic I work with the infrastructure Weaving code

12. 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)

13. 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

14. Client Rich client weaving Application Server Weaving – figure II Domain model App server weaving 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

15. ClientApplication Server Weaving – figure II Rich client weaving Domain model App server weaving 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

16. 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”

17. 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

18. 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

19. 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”

20. 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

21. Implementation strategies Define pluggable interfaces in Java Frameworks with dynamic proxies Aspect-oriented programming Example SPIF Store chain CacheRemoteServerLocking AuthorizationCache Database

22. 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!

23. 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

24. 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

25. 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 result end