Wikipedia roughly defines Model Driven Architecture (MDA) as focusing on “forward engineering, i.e. producing code from abstract, human-elaborated modelling diagrams (e.g. class diagrams)”1. Model-Driven Architecture and Model-Driven Development (MDD) is often composed of class diagrams and “Entity relationship modeling”2 (ERM) among other things.
Basically, it seems to me that MDA/MDD advocates creating pretty pictures for collaboration between business units, designers, and developers.
I remember when Rational Rose was en vogue. But the issue I’ve always had with UML is the “round-trip” problem – meaning the artifacts we create using these abstraction tools are throw-away: once the design makes it into production, and coders maintain the code base directly, the models become obsolete.
The reason I chose this topic is because Splicer truly represents a practical way to do a type of model-centric development that does not become obsolete. Let’s start with understanding what a “Model” generally means for developers. Most developers think a “Model” is the one leg in the MVC (Model-View-Controller) design pattern. This has caused a bunch of confusion when I’m out talking about Splicer. So instead, I find it easier to call that piece of “MVC” the “Data Model”. So, our client (mobile) Data Model is conceptually a subset of an ERM. Even so, it is a non-normalized object representation of the database schema. This is how our client Data Model fits into the world of MDA: it is a component of MDA that defines the object representation of the data. These objects are sometimes described as DAOs.
Sometimes new enterprise mobile designs are “greenfield” projects, and Splicer supports those. But in the majority of designs, the backend database schema is known – we are instructed to pull data from a relational database. That database schema is often the end-result of some sort of ERM design, which is long obsolete.
So, we are asked to develop mobile apps lacking enterprise modeling tools.
Of course there are the screen mockups, etc. But the hardest part is integrating those apps to the backend – typically consuming 50-80% of the overall development effort. Fortunately, our client Data Model can be readily derived from our database schema. With Splicer, we can extract the Data Model from server artifacts. These appear on the right-hand-side in the CAM editor similar to how the database structures are shown:
Once we have our server Data Model, we can then drag various elements over to the left-hand pane to create our client Data Model. And we can create sets of both server and client Data Models to allow us to both aggregate data from multiple databases, and support sets of mobile apps. This provides a rapid upgrade for server systems (including J2EE) to host mobile app portfolios.
This process is how we create our client-server model. Once defined, we inject it into the Splicer server, which then automatically fetches object data, and delivers it as a JSON payload to our mobile apps. Splicer also generates typesafe client DAOs to consume the JSON.
There are many advantages to this approach. But within the context of MDA, our Model is now part of our build; Splicer generates typesafe objects from it. The “class diagram” that represents our Data Model are completely defined in the GUI. The trick is that the system must adhere to the MVC design pattern so that when we regenerate our data objects, we don’t overwrite our native controller and view code written by our developers. Splicer is designed for this to all work cleanly together.
At Splicer, we discovered that swaths of client-server code can be eliminated using drag-and-drop model definitions. And it provides model Agility through end-to-end type-safety. You can find more information on the Splicer “low code” development process at http://splicer.io and elsewhere in this blog.