Modeling is the core competence

When I started as Developer at LS telcom in 1995 the most important thing to learn was Object Oriented Analysis and Design. For me it is still the most important skill and it is also the hardest thing to learn, whereas  technologies are coming, growing and going over the years.

There is a rule of tumb, that you are an professional in  a job after you have worked for 10 000 h. For a full-time job therefore you need around 6 years . I have to say, I needed 12 years – around 20 000 h – to learn modeling so that I can be satisfied with the outcomes. A survey on jaxenter in 2015 shows, that around 80 % of the developers see it most important and most difficult to find appropriate names for classes, attributes and methods …

Pojo to go?

From 1999 on I spend several years on developing J2EE Applications. It was a landmark in both Architecture and Design, with the promise to write once run everywhere (on any compatible Application Server). The roundtrip for deploying there EJB components on the server and rich client was complicated and has felt bad, but it was running smoothly. When I was at T-System we even had a architecture, where the developer can work standalone – without Application Server – testing all in the swing client. It was just a configuration flag, where to deploy.

Over the years, the overhead of the „ugly remote interfaces“, which causes a coupling between several components, became more and more criticized. And Spring was born with it „PoJo Paradigm“ – coding a simple java class without dependencies to a „huge framework monster“. But over the years more and more functionality was added to the Java Enterprise Frameworks. Today there is no PoJo anymore, instead annotations will weave all together. The dependency hell is present even for small solutions. In my oppion it often looks like repeating yourself

Model Driven Development

Meanwhile – from 2004 till 2014 – I was member of the Framework and Tools Team at harman international infotainment systems. There were hundreds of C++ components sending and receiving messages powered by our asynchronous messaging framework. The overall system modeling was supported by our Eclipse RCP based modeling editors and generators, also the application deployment with assigning components to service threads etc..

All 1000+ developers per project were using our „MoCCA – IDE“ and code generation of messaging and deployment leads to well known component code with great quality. More and more the model editors were exchanged by xText base solutions, which the developers liked more. It was a great experience at harman and I think: what works for 1000+ developers and hundreds of services will also work with 15 people working on 10 services …

So it is time for a:

Dynamic OO – How to build a „Surround“ Framework

all you need – the building Blocks:

Your Special Purpose

do it yourself was the only option for developing enterprise systems in the early days. Now we have the developer heaven with hundreds of general purpose solutions. But this solutions have to be „open“ to match any domain. This is totally different, if you are developing your product. You can concentrate on the features you really need, collecting your building blocks with KISS and YAGNI in mind. These you can combine to create nice and easy to maintain systems.

Typesystem for Models

The Foundation of this Approach is modeling a rich type system, which will be used as base for all other framework components. It will contain primitive types like string, integer, double with type conversion. Other types from string derived might be a file , folder or url type. Collections like list and map are given and in addition a entity type with a list of base type members. A model might be an entity with a „coordinate“ for finding it in a database or whatever.

This basic building blocks of Dynamic OO should be a minimal set of which is really needed – according to YAGNI: less is often enough. You can compare it with the JavaFX Properties, but without any dependencies to UI or Other Frameworks.

JSON Support for Models

Nowadays JSON is everywhere: used in messaging of restFul web services, or many NoSQL datastore. Any data exchange will be benefit from that. So a build in  JSON support in the Modeling component will be a great leverage for all other features. On Entities and others you can also implement a upward/downward compatibility ignoring unknown fields or filling missing members with default values.

Dynamic UI – show Models

since you are building your software with a well known set of model classes it is easy to present these on the fly using conventions. So a list of entities might be given as tableview if entity contains only primitive types or as tabletree or master detail view, if there are complex children. Both will have and add or delete button, if list is enabled. If you have a derived class and the default behavior is not suitable you might register a special Presenter for your Types.

Using this approach you can rely on a dynamic ui creation with might be enough for 80% and may be extended for 20%.

Datastore – save Models

a little data abstraction using the model types can be easily implemented for any wanted datastore. Especially NoSQL datastore with JSON support can be integrated with low effort. Besides using the „dao“ classes directly a generic persistency service in a message channel will „transport“ query and results from client to server. Normally the server than is not forced to know all concrete model classes, JSON itself is enough.

Messaging – send/receive Models

Messaging with client/server or actor classes is also build on top of model classes. You can create all this components in the same way. This will really ease development and offer several extension for system testing, etc. It also will allow to change the messaging system without changing the applicative code add all.

Embedding Frameworks – use concrete Technologies

Dynamic OO in principle has the greatest focus on model classes and the dynamic UI. Middleware components should be integrated as messaging channels with minimal glue code, so that you may benefit from the middleware as much as possible.

DSL – model Models

Coding Applications using the Model classes is straight forward, but there is a lot of boiler plate code anyway. Using a DSL with code generation will especially increase the „visibility“ of the overall application. Besides modeling data and messaging even the ui can be build by model blocks in the data layer – like composing a dashboard from several models.

Summary

Dynamic OO will avoid doing the same things again and again. Instand You can rely on conventions, which normally leads to better  quality and nice UIs. And more important: if you have a problem by performance or stability (memory and cpu) you will fix this in a central place instead of hundreds of different code blocks. Furthermore you may let your best developers, framework and tools people – these with the magic hat – solve this problem in the most consistent way.

Having these pieces puzzled surround will open doors for several extensions. My favorite one is a Workbench for System Modeling, Monitoring and Testing ….