To resume the thread of the Descriptions and Models (1) - Four surprises: 'modelling' is synonymous with 'describing' even in the world of physics. E.g. modelling the physical system of a mechanical pendulum, we describe its structure with an expression, which has to be interpreted as a differential equation by all competent readers. So the model of the pendulum refers to some internal representation within the interpreter of the structure description of the physical pendulum. Models in this sense are therefore unobservable, as they exist only within interpreters. Once we look inside an interpreter, we see only states of physical systems. As announced in the first blog of this small series, two surprises remain to be revealed.
The Computer as an Interpreter
Computer are often portrayed as symbol manipulating mechanisms, assuming tacitly that they operate in a purely syntactical and not semantical realm. From a physical perspective, we can only state that computers are definitively physical systems, which can be described to an almost perfect approximation as discrete state transition systems. Their internal error rate of less then 1e-15 may serve as degree of correctness of this approximation. But, computers are usually not described this way but much more conveniently as these symbol manipulating kind of thing, which can be advised how to process symbols according to lists of instructions called programs. My thesis is now that we cannot define the meaning of programs , whithout stating, how the state of a computer is supposed to change while executing the program commmands. So, it is a consequence of our description of some of the states of a computer as representing a formal description that we have to describe other states of the computer as representing internal representations of the described entities, which are - according to the model theoretic terminology - models of the descriptions and therefore we have to view the computer as an interpreting entity. In other words, by applying the model of a 'programming language' to explain the behavior of some physical system, we already qualify this system as an interpreter. Now, that was the model theoretic perspective. But outside model theory, we usually say that a program describes an application. So it seems obvious to identify the model of the program with the application. Now, an interesting consequence of such a view is that the architecture of an application is nothing else than its structure in the model theoretic sense. As a result, the term "model driven architecture" becomes a tautology, as every application architecture is per definition 'model driven'. And it is a matter of course that the description language, which is used to describe the application structure according to the needs of the computer, has to have an unequivocal and therefore formalizable semantic if it claims to be of any runtime relevance. If application architecture is about application structure in the model theoretic sense, then object orientation appears as an attempt to provide a description paradigm, which largely defines the structure (in a model theoretic sense) of an application already at design time of the OO-entities (classes). The relevance of these thought becomes even clearer if we start pondering about why object orientation seems to have its difficulties with respect to mass processing, change management and its limitations in providing loose coupling. Some stuff, which surely justifies some more blogs.
Good enough Models
As said in the last blog, to be of pragmatic value, models need only to be "good enough" and are seldom uniquely specified. In other words, usually many different application structures are valid models of a given specification as the relevant requirements generally heavily underspecify our application architecture. One immediate consequence is that we have to learn to what extent it is necessary for an application to share or to be part of a common model for possibly different types of cooperation. It is my feeling that the issue of tight versus loose coupling will find its solution only on this stage of theory. We possibly have to distinguish between applications, using other applications for their objectives, applications pursuing identical objectives, applications pursuing complementary or mutual objectives or applications which share common objects to pursue unrelated objectives. Another consequence is that arguing about the perfect architecture is not so much a question about correctness but much more a discussion within the realm of estimated costs to adapt the application structure according to expected future requirements. Again, stuff for some more blogs.
