1. Introducing Allors Applications, Tools & Platform

2. The Goal To Increase Software Manufacturability – Design for manufacturability (DFM) describes the process of designing or engineering a product in order to facilitate the manufacturing process in order to reduce its manufacturing costs. » http://en.wikipedia.org/wiki/Design _ for _ manufacturability

3. How to Achieve our Goal Ubiquitous Language Separation of Concerns Embrace, Extend and Evolve OO Support Agile Software Development Integrated, but Open and Extensible The KISS principle ("Keep it Simple, Stupid") states that design simplicity should be a key goal and unnecessary complexity avoided » http://en.wikipedia.org/wiki/KISS_principle

4. Separation of Concerns Functional Separation of Concerns – Use Subject Orientation Technical Separation of Concerns – An Integrated Pattern Language

5. Subject Orientation

6. In contrast with – Component Based Development – Service Oriented Architecture – Bounded Context in DDD Can be applied at – Source level (Allors) – Binary level (HyperJ)

7. Integrated pattern language An integrated pattern language – Strategy Based – Factory of Factories – Inversion of Control Dependency Injection Service Locator Event-driven programming

8. Strategy Based

9. Factory of Factories

10. Dependency Injection Constructor Injection public abstract class ObjectBase : IStrategyBased, IDeletable { private IStrategy strategy; protected ObjectBase(IStrategy allors) { this.strategy = allors; } public virtual IStrategy Strategy { get { return this.strategy; } }

11. Injection & Service Locator

12. Service Locator Management Static allocation of objects – Through configuration file – Through population Dynamic allocation of objects (JIT) – Through SessionCreated Event on Population – Through PropertyNotFound Event on Properties

13. Event-driven programming No need for explicit Observer Pattern Use of Association side of Relation

14. Embrace, Extend & Evolve OO Meta Domain Population Independence Rolling Transactions Disconnected Working Relation Oriented Analysis and Design (ROAD) – Multiple Type Declarations – 3 rd Generation OOAD – Relation Methods

15. Meta Domain

16. Subject Orientation

17. Population Independence Use ‘Best Fit for the job’ Population Currently available Populations – Memory (Connected & Disconnected) – Sql Scheduled Populations – File based

18. Rolling Transactions No explicit Transaction demarcation Always in a Transaction

19. Disconnected Working Just in Time Checkout & Explicit Check in

20. Relation Oriented Analysis & Design Relation Oriented vs Object Oriented Relation Oriented Methods Multiple Type Declarations 3 rd Generation OOAD

21. Who defines the behavior Is it the Object Type or the Relation Type!

22. Overloading RO Methods Same signature, Different behavior

23. Overloading RO Methods - Advantages New level of polymorphism More robust (contrary to Contract Based) – No null pointer exceptions Half way technology for Relation Orientation

24. Multiple Type Declarations Definition Advantages Example Implementation

25. Muldecs - Definition A Multiple Type Declaration (muldec) declares that the specified object should implement multiple types – the objects assigned to the variable should implement all types (usually interfaces) Muldecs can be supported at – The platform level (JVM, CLR, C++ linker …) – The language level (Java, C#, C++, …) – The framework level (Allors, …) Muldecs can be overloaded

26. Muldecs - Advantages Reduces the gap between statically and dynamically typed languages Less casting Higher level of modularization – Looser coupling is possible Better evolution – More additive Especially suited for 3 rd generation OOP

27. Muldecs - Example

28. Muldecs – Implementation in Allors

29. Muldecs - Notations C derivatives – type1 type2 … variable – methodName( type1 type2 … argument) Uml

30. 3 rd Generation Object Oriented Programming (OOP) Can be seen as a evolution from – 1 st Generation OOP (Inheritance) – 2 nd Generation OOP (Delegation) Builds upon – Relation Oriented Method Overloading – Multiple Type Declaration

31. 1 st Generation OOP

32. 2 nd Generation OOP

33. 3 rd Generation OO

34. Support Agile Software Dev. Focus on Customer Valued Functionality Automatic upgrades Unified Testing Immersive UI Testing

35. Integrated, but Open & Extensible Applications Meta Domain Roll your own Population Use Inversion of Control (IOC) – And everything is Open Source!

36. Allors Applications Prebuilt Subject Domains – To use either directly, or to extend – With a horizontal or vertical scope – Allowing flexible upgrades

37. Meta Domain Design time – Extend the Meta Domain Compile time – Use template engine to generate code/artefacts Runtime – Use Meta Domain at Runtime

38. Questions?