Thirteen years ago I developed to my knowledge the first and currently the only fully featured model oriented programming language and IDE. I utilized this technology (Mo+) to great effect on my own and workplace enterprise projects, but failed to sell the ideas to a wider audience. Six years ago I left my software engineering career in favor of wielding an ax and building Viking and Anglo Saxon ships in Norway, UK and other future places in Scandinavia. Even so, I still think about model oriented programming from time to time and its potential.
The purpose of this article is not about the technology I developed, but to inspire research, development, and use of model oriented languages. Amongst other things, I would love to make a contribution to any research going on at a university or business. Please let me know if you are aware of any research and development of model oriented programming languages going on out there!
I firmly believe that the family of model oriented programming languages has great future potential, even and maybe especially in the current world of AI. I hope this article will inspire a deeper look into such potential.
Below, I will outline some principles and features I think are key to make the most of model oriented programming languages. Unless otherwise noted, these principles and features are not pure theory, but were actually utilized in enterprise systems over several years. There are many concepts to go over here. If the earlier sections get a little dry and tedious, at least skip down to the language features section.
What Is a Model?
There are of course many kinds of models and many ways to describe a model. At its core, the purpose of a model is to concisely represent something else that is larger or more complex. For model oriented programming, we will need an electronic definition of a model, and the following definition can be used:
Model – A model can be described in terms of structure and data. The structure defines the rules or “schema” of a model and is always hierarchical. A particular model is populated with data that conforms to the model structure.
A model structure can simply be defined in terms of nodes and attributes:
- A model structure has a single root node.
- The root node can have any number of child nodes. Any node in turn can have any number of child nodes to form a hierarchy of any given depth.
- Nodes are identified with at least a name. In addition, nodes can be further described with any number of attributes.
You may not believe me yet that model structures can always be hierarchical with a single root node. Let’s use the following diagram of a portion of the Northwind database as an example:
You may say “this is not hierarchical!!”. But, what are we looking at here? In our context, it is not model structure, but model data. You can say that the Northwind database schema is an example of populating a standard relational database structure with data. Rows of data in database tables is run time data, and not what I am talking about here. The schema is an example of model data.
You can see the hierarchical structure in a relational database IDE as the schema can be displayed in a tree view:
So the model structure of a relational database includes nodes such as database, table, column, and key that fall neatly into a hierarchy. You may say “wait, the hierarchy is broken, as foreign keys refer to tables!”. This is handled very simply as follows:
- An attribute of a model structure node can refer to another node in the model structure.
With the above rule, we can have very complex model structures that fall neatly into a hierarchy. I would add that in a good model structure definition, nodes are defined at the highest level where they can stand on their own.
The Restaurant Scenario
For the remainder of this article we will use a very simplified restaurant scenario with which we will model in various ways and explain how we could program to the scenario with model oriented programming languages.
The simplified restaurant scenario is described as such:
- We want to manage a number of restaurants and need to track their name and location.
- A restaurant has any number of customers and we want to track customers by name and when they visit (we are ignoring repeat customers in this simple scenario).
- A restaurant has any number of staff, and we want to track staff names and their role.
- Customers eat food and we want to track what menu items they order.
- Staff serve customers and food and we want to track which customers and menu items they serve.
Following is an entity relationship model (in pseudo Shlaer-Mellor format) illustrating this scenario:
Again, in our scenario this model represents data, not structure. So now let’s get into some model structures.
Model Structures
Consider the following entity relationship diagram that can represent a structure to support the model data above:
The structure has a root node of Model and child nodes of Entity and Relationship, etc. The solid lines represent the model structure hierarchy, while dashed lines represent alternate associations. In populating this structure, instances of Entity include Restaurant, Customer, Staff, etc. and instances of Restaurant Entity properties include Id, Name, and Location, etc.
Is this the only or best structure to represent our data? Certainly not — there are many possibilities. Consider the following alternate entity-relationship model structure:
This structure puts Entity, Relationship, and Property on the same level. This might make sense if relationships and properties can exist in their own right independent of entities.
Finally, consider this alternative entity relationship model structure:
In this structure, relationships and properties need an entity to exist and the relationships are children of their source entity. The reason I bring up alternative structures is that this has some effect on a model oriented programming language, where hierarchies are slightly more convenient to traverse. This will be explained in more detail later.
I strongly feel that the definition of a model in terms of structure and data is an extremely important foundational principle that opens up a family of model oriented programming languages.
Key Definitions
Before we continue, here are a few more definitions:
Modeling – Modeling can simply be defined as the process of populating a model structure with data.
Model Oriented Programming (MOP) – MOP can simply be defined as the process of utilizing a model to create and maintain a system (for the purpose of this article, a software system).
Model Oriented Development (MOD) – MOD can simply be defined as the process of creating and utilizing a model to create and maintain a system. In other words, MOD includes Modeling and MOP.
I will use the MOP and MOD acronyms in the remainder of the article for convenience.
Forms of Model Oriented Development
To my knowledge, there are no standard names for the different forms of MOD, but it is useful to describe them and their implications for MOP.
Informal MOD
Informal MOD involves utilizing any form of non-standard model. The model could be ideas in your head, chicken scratchings on a piece of paper or whiteboard, or utilizing a drawing tool. There are no rules that constrain how you create and utilize an informal model.
Informal MOD for our purposes can be roughly defined as:
- Having an ad hoc model definition outside of your source code. The models might just be ideas in your head, written descriptions, drawings, or diagrams of your own design or standard.
- There are no software tools that can utilize your model towards managing source code.
Following is a whiteboard drawing that models the basic ideas for our restaurant scenario:
Inline MOD
The inline form of MOD is very popular these days with the advent and use of many frameworks that greatly enable you to effectively design and develop your applications.
Inline MOD can be roughly defined as:
- Having a formal model defined in your source code. That model is usually relevant to a particular layer in your application.
- Having a framework that typically has supporting infrastructure to allow you to manage and utilize your model, create some code for you, and/or provide infrastructure software to help manage part of your system.
Some examples of Inline MOD include ORMs such as Entity Framework or NHibernate and UI frameworks such as Angular and React.
Models for inline MOD are often defined in code. Below is an example Entity Framework (code first) model definition for our restaurant scenario:
public class Restaurant
{
public int Id { get; set; }
public string Name { get; set; }
public string Location { get; set; }
public ICollection<Customer> Customers { get; set; }
public ICollection<Staff> Staff { get; set; }
}Model oriented programming languages represent a promising direction for software development — one that remains largely unexplored despite the clear advantages of treating models as first-class citizens in the development process. Whether inline, informal, or fully realized as a dedicated language, the model oriented approach offers a powerful lens through which complex systems can be designed, reasoned about, and maintained with greater clarity and consistency.
