(Created page with "For prose document writers and for nothing but code cowboys there is a missing link – a way to describe system gist separated from the flavor of the year implementation meth...") |
No edit summary |
||
| Line 1: | Line 1: | ||
For prose document writers and for nothing but code cowboys there is a missing link – a way to describe system gist separated from the flavor of the year implementation method in a format that is not as flimsy and open to interpretation as prose documents. | For prose document writers and for nothing but code cowboys, there is a missing link – a way to describe system gist separated from the flavor of the year implementation method in a format that is not as flimsy and open to interpretation as prose documents. | ||
What I propose here and what many | What I propose here and what many have proposed before me is that we can document with models. The models are more descriptive than prose text, leaving less room for alternate interpretations. At the same time, models are less complex and easier to read than code written in the flavor and style of the year. | ||
The model is then home | The model is then home to the system gist. Here it can be understood, discussed, criticized, and evolved long before it has taken the expensive form of implementation code. | ||
What is somewhat new in what I say is that | What is somewhat new in what I say is that models can be compiled and executed just like code. We can then focus on using the current modern technique to execute the model. This way the modeled solution can have a much longer lifespan than the user interface or delivery method that is heavily subjected to modernity and fashion. | ||
Models can cover the uniqueness and true solution of your software. | Models can cover the uniqueness and true solution of your software. | ||
A model | A model executor brings your model to life in a specific environment. When one model executer goes out of style and something new is requested by the market – we do not rewrite the system gist – we create a new model executer – and feed it the very same model. | ||
MDriven is the latest model executer we have | MDriven is the latest model executer we have created – but we have been involved in making many. A model that was executed with Delphi 1999 (BoldSoft) can be executed with c# MVC5 or with WPF (CapableObjects) today. It was executed with Windows Forms in 2003 (Borland, Embarcadero), with Silverlight in 2007, and with ASP.NET in 2005. No doubt there will there be new model executors when modernity so requires – and sure enough, MDriven Turnkey that brings any system gist to AngularJS is currently available. | ||
One key to a good investment in software is to avoid entangling things that change for different reasons and with different intervals and | One key to a good investment in software is to avoid entangling things that change for different reasons and with different intervals and speeds. Your system gist change and evolve along with the business it supports. The modernity of the solution changes by market forces no one can control but everyone must adapt to. | ||
I propose that we | I propose that we keep these two areas apart so that they do not get confused as being one and the same problem. | ||
Model driven development is by me | Model-driven development is defined by me as developing a system gist in its own machine-readable format. Build a software machine that turns the system gist into a complete software system and fulfills the required modernity aspects. Giving such a machine a descriptive name: ModernGistExecuter – we at CapableObjects call our implementation MDriven Framework. | ||
[[Category:The MDriven Book]] | [[Category:The MDriven Book]] | ||
Revision as of 06:57, 7 June 2023
For prose document writers and for nothing but code cowboys, there is a missing link – a way to describe system gist separated from the flavor of the year implementation method in a format that is not as flimsy and open to interpretation as prose documents.
What I propose here and what many have proposed before me is that we can document with models. The models are more descriptive than prose text, leaving less room for alternate interpretations. At the same time, models are less complex and easier to read than code written in the flavor and style of the year.
The model is then home to the system gist. Here it can be understood, discussed, criticized, and evolved long before it has taken the expensive form of implementation code.
What is somewhat new in what I say is that models can be compiled and executed just like code. We can then focus on using the current modern technique to execute the model. This way the modeled solution can have a much longer lifespan than the user interface or delivery method that is heavily subjected to modernity and fashion.
Models can cover the uniqueness and true solution of your software.
A model executor brings your model to life in a specific environment. When one model executer goes out of style and something new is requested by the market – we do not rewrite the system gist – we create a new model executer – and feed it the very same model.
MDriven is the latest model executer we have created – but we have been involved in making many. A model that was executed with Delphi 1999 (BoldSoft) can be executed with c# MVC5 or with WPF (CapableObjects) today. It was executed with Windows Forms in 2003 (Borland, Embarcadero), with Silverlight in 2007, and with ASP.NET in 2005. No doubt there will there be new model executors when modernity so requires – and sure enough, MDriven Turnkey that brings any system gist to AngularJS is currently available.
One key to a good investment in software is to avoid entangling things that change for different reasons and with different intervals and speeds. Your system gist change and evolve along with the business it supports. The modernity of the solution changes by market forces no one can control but everyone must adapt to.
I propose that we keep these two areas apart so that they do not get confused as being one and the same problem.
Model-driven development is defined by me as developing a system gist in its own machine-readable format. Build a software machine that turns the system gist into a complete software system and fulfills the required modernity aspects. Giving such a machine a descriptive name: ModernGistExecuter – we at CapableObjects call our implementation MDriven Framework.