Puan
28,728
Çözümler
0
- Konum
- Freanchey
- Mesajlar
- 3,047
- Katılım
- 2 Eki 2026
- Tepkime puanı
- 3,565
- Puan
- 28,728
- Web sitesi
- glomaxgpt.com
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 even 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.Model Structure and DataA 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.Example Scenario and ModelFor 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.Customer 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!Example Model StructuresConsider 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 alternate associations (note for these that I need to add some reference properties to “formalize” these 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 this has some effec
