The three stones: Is that a model?

There are three stones. Is that a model? My answer is unknown, but one can use it in some case as a model by mapping the stones to the Earth, Moon and Sun.

Thus, however, is that a good model? Some one may be said: It’s so ugly, of course it’s a poor model… but I’ll still say: unknown.

One day, I used the three stones as a model to interpreted what is a lunar eclipse, successfully. In this case, I can say, the three stones was a good enough model.

Lunar Eclipse, December 21, 2010, by Jiyang Chen

This example concerned in almost all of the secrets about that what is a model. I have been thinking about this questions over the years. So far, my answer is as follows. Borrow Wittgenstein’s definition of meaning as use^[1], it could be said, for a large class of cases—though not for all—in which we employ the word ‘model’ it can be defined thus: a model is a role in the situation where the role carries certain properties of a thing directly or indirectly and works by the properties. In other words, we say an entity modeled on the thing when it playing the role in a case as the satiation. Any entity has the properties and meets some conditions, will be used as a model in the situation.

——

[1] By Wittgenstein: “For a large class of cases—though not for all—in which we employ the word ‘meaning’ it can be defined thus: the meaning of a word is its use in the language”,  Philosophical Investigations, cited from: Biletzki, Anat and Matar, Anat, “Ludwig Wittgenstein”, The Stanford Encyclopedia of Philosophy (Summer 2011 Edition), Edward N. Zalta (ed.), URL = <http://plato.stanford.edu/archives/sum2011/entries/wittgenstein/>.

[2] The picture Lunar Eclips got from Wikimedia Commons and licensed under the Creative Commons Attribution-Share Alike 3.0 Unported

(Sorry I did not well use the schedule, so, issued a draft before this version to subscribers.)

In the “Presentation on Model-Driven Mechanism in Information Systems and Enterprise Engineering“, mentioned that “MDM is the common fundament for both MDS and MDA/MDD.” Yet, presented a illustration for “A demand-driven architectural framework for development of ISs, based on MDM” and pointed out “this is also an explanation about the system of model driven development.”(P16)

The Figure 1 is a simplified graph for MDM, may be called as the triangle of MDM. Note that, for the relationship between the applied models and the operational device, from a black-box perspective (i.e. the whole of the system), we can dynamically change some functions or behaviors (output) through changing the models, this is why called it model-driven; from a white-box perspective (i.e. inside of the system), the device reads and uses the data of the models according to the modeling knowledge to make of its functions and behaviors. (It has used executing but it may be referred to some special meanings in the context.)

MDM in traditional software development system

In a traditional software development system (organization), the programmers reading and understanding the design documents according to some specifications for them. In fact, there are much knowledge for understanding / using the documents correctly, from languages, glossaries to rules, habits and so on. You can give the different models (the documents) according to the knowledge the programmers known, then they will produce the code expected.

MDM in a model driven software development system using a model-transformation approach

In a model driven software development system, for example, by a model-transformation approach, the applied model will be of the target application system in such as UML at the level 1 of the metamodeling layers of MDA. The modeling knowledge will be the metamodels to the level 2, including the transforming rules (model) as well. A code-generator as the operational device in MDM will reads / uses the models of the target than produces the code. You can give it different models to get different expected code of the target system, as long as in compliance with the metamodels.

A model driven enterprise application framework based on MDM

Of course, these may merely be the common sense in the field of MDE, but they are good examples to prove the universality of MDM, at least. One of our focus for MDM is the Model Driven Systems (MDS), which has the characteristics to dynamically changing its functions or behaviors through change the applied models at runtime. For example, see the Figure 4.

From a programmer’s perspective, a huge difference between a traditional application and the model driven application is, the enterprise / business models (such as a data structure of a purchase order) will be hard-coded in software for the former, and for the latter, it will be only hard-coded some rules / specifications (the metamodel) to define an order, so, the users will be able to change such the order format (or define a new form) when running the application system.

Finally, we can see, MDSD and MDS are the different things on the same principle, that is, the model driven mechanism (MDM). They are not contradictory. One can use the MDSD approach to develop a MDS as well.

[*] The original file of the lecture at http://www.ee-forum.org/downloads/ty_jnu070917a.pps (in Chinese)

Last updated on January 15, 2012

1. P20, removed the PDCA cycle: it was with more explaining but not included in this vision.
2. P22, the order to showing the 4 labels on the MDM triangle, it is now appeared at the beginning.
3. P24, corrected the error at “Martin, James (2005)” to (1995).

(previous version: ty_jnu07_mdm.ppt)

Figure 1. Cognitive Architecture Model

Thinking making Thories, Thories deciding Action, Action imposing on Objects, Objects providing Feeling, Felling building Models, Models supporting Thinking… In this model, all the positions and the sequence are important. However, my motive to think of these was not to attempt to cross-border to research cognitive issue. To me, this model, almost a model of architecture for information systems, though it might not be quite obvious.

Firstly, the ‘objects’ just common objects but not the OO’s objects, and it needs to make more sophisicated or rigorous definations to the concepts such as models and theories, and the relationships with the concepts in software field…

In the essay, however, I will a bit avoid this common sense, as the use ‘for enterprises’ implied: the ‘enterprises’, is referred to as a generalized user, that is, businesses or organizations which could be commercial, nonprofit, government, and so on. And, in comparison, there are the applications for Individuals.

“As a user,” it reflected the primary position I like to stand on: talking about the applications from the using perspective, and then, it would be (naturally) taken into some technical issues/needs and some thing could be out of the common views, such as the model-driven as an essential requirement come from Customers^[1].

In fact, to an application for an enterprise, who is a user, that is a question: the users could be an organic group comprised of different roles, which cooperates with each other, with some scheduled objectives and management.

For example, the multi-users (mass users) is not a unique characteristic to the applications for enterprises. (yet, the mass data, concurrent operations, etc.) An application for individuals can also has huge users (such as an email system) or mass-data, and so forth.

So, what is the characteristics of the applications for enterprises? In to my experience and understanding, there are three basic characteristics:

The first, organizational objectives and strategy: it can be decomposed into a complex structure or organic composition, can include many different levels and interrelated goals. Organizational objectives for the applications are always of the business, rather than software features.

The second, collaboration: It not merely need to support open and dynamic work groups, but also to support individuals, organizations, internal, external, multi-layered, complex collaboration.

The third, the fitness for management: a concept I coined^[2] according to Dr. Joseph M. Juran’s concept fitness for use, that is, the quality which satisfy the requirements for managing the applications. For example, from the using planning, the process and outcomes, the authorization and state of operators, the logs of the operations and the traceability, to the configuration, deployment, etc., all of these are required to provide specific functionality to support.

In contrast to these, all of the pure technical features are not the nature of the applications for enterprises, though, of course, some technical features are necessary in most cases, but it may also be needed for some applications for individuals. Based on the user’s and the organizational position but not the IT position, this is the key point for the essay, and it can also bring us new demands and inspiration to our technology.

—-

[1] Model-Driven: An Essential Requirement Come from Customers

[2] From Fitness for Use to Fitness for Management – A Subject for Quality Management in Depth (in Chinese)

Cognitive (Triangle) Cycle

A brain can be considered as an information system. It gains raw data on feeling, makes some theories and programs on thinking, then executes the programs to take actions. there is a simple model for the cognition on brain, so-called feeling-thinking-action cognitive triangle^[2]. The order is significant (not as Action-Thinking-Feeling) and it needs to emphasize the dynamic characteristic of the loop, therefore, a more appropriate term may be as cognitive cycle.

Two Forms for Representation of Information

Introduced a basic assumption: there are two, and only two of the basic forms for the representation of information, that is, images and statements. The images are presentations for features; the statements are expressions in language, i. e., texts. These two forms are not mutually exclusive and often mixed together.

The images from sensory organs as the raw data of the objects, which are depicting some features such as color, odor, shape and so on. In general, the memories from sensory organs can be stored, modified and used repeatedly by a brain, but the raw data from sensory organs are not able to be directly expressed in a language. We can not rebuild a particular sensory memory by a language but only reproduce it through the same process on sensory organs. This would be called as reproducibility of sensory images (a characteristic for reproduction).

Further, the statements can be relatively divided into two kinds: the statements in fact and the statements in theory.

The statements are corresponding to the theories in Model Theory and the images corresponding to the models.

Relationships among Cognitive Elements

There are four basic elements for cognition: the sensory images, the statements in fact, the statements in theory and the cognitive objects. The relationships among the four cognitive elements as Figure 1.

Actually, sensory images and its descriptions–the statements in fact–may be combined together very closely and plays an important role in whole cognitive structure: the models of cognitive objects, which are the representatives of the real things in mind. Thus, the four basic elements can be further attributed into the three: objects, models and theories. Their relationships are also appeared as a triangle, called it cognitive structure triangle, shown as Figure 2.

The most significant essence discovered by the cognitive structure triangle, may be the dual relationship from a model to its object and relative theory. It joined together the two key theoretical bases for models in the past researches: Model Theory and Homomorphism. (that is, the homomorphic mapping between a model and its object and the satisfying relationship from the same model to some theory.)

Note:

These are some my thoughts on models and modeling, Model Theory and so on. After I posted some of the essays, I read Smith 1985 and found that it was very similar between his opinion and my thought, such as his picture (look at here) and my cognitive structure triangle, and the position of Model Theory on the left side as well. Furthermore, I think in the above description, there were perhaps some thing not included in such Smith’s opinions yet, though it may be very subtle.

Although the discussions were on the cognition and brain but my goal was always on computing. They were not academic papers, just pointed out or implied some of clues to the guys who had the same or the similar interesting or understanding on the topics.

—-

[1] The original below:

1. Cognitive Process Triangle, April 2010 (http://ee-forum.org/pub/ty/2010-04-p1290.html)
2. Cognitive Structure Triangle and Conceptions of Images, Models and Theories, April 2004 (http://ee-forum.org/pub/ty/2010-04-p1341.html)
3. Talking again about Cognitive Process (Triangle) Cycle for “Feeling-Thinking-Action”, October 2011 (http://ee-forum.org/pub/ty/2011-10-p3007.html)

[2] I have seen a few of the narratives about Cognitive Triangle as Feeling-Thinking(Thought)-Action(Do) but did not discern the original.

I just read an idea by Stephen Hawking and Leonard Mlodinow, called Model-Dependent Realism^[2]:

“the idea that a physical theory or world picture is a model (generally of a mathematical nature) and a set of rules that connect the elements of the model to observations.”

This statement is rather matching with my thoughts, almost in each word. (Of course, we perhaps may ignore the “physical” and take some extension for “observations”)

This reminded me of the Smith’s opinion^[3]: (see the Figure 1 below)

“You are to imagine a description, program, computer system (or even a thought – they are all similar in this regard) in the left hand box, and the very real world in the right. Mediating between the two is the inevitable model, serving as an idealized or preconceptualized simulacrum of the world, in terms of which the description or program or whatever can be understood.”

Figure 1: Computers, Models, and the Embedding World (Smith 1985)

Is this the apposite worldview for software or computing? Whatever, Smith have pointed out some key relationships for models with computers, and with the real world — of course, it still needs more — but it seems have been somewhat lost or ignored, isn’t it?

—-

[1] Liles, D. H., Mary E. Johnson, Laura M. Meade, and D. Ryan Underdown, “Enterprise Engineering: A Discipline?“, Society for Enterprise Engineering Conference Proceedings, June, 1995.

[2] The phrase “model-dependent realism” appears to have been coined by Stephen Hawking and Leonard Mlodinow in their 2010 book The Grand Design. (quoted from: “What Is Model-Dependent Realism?” by Andrew Zimmerman Jones, About.com Guide)

[3] Smith, B. C., “The limits of correctness“, ACM SIGCAS Computers and Society, v.14,15 n.1,2,3,4, p.18-26, Jan 1 1985

An assertions are often frivolous, but I believe the models will ultimately be succeeded, it will eventually become the protagonist of software engineering. Why? I think, there is some useful insight from a variety of sophisticated engineering fields. It could be observed that, a sophisticated engineering – a discipline on a class of complex systems — is based on its sophisticated, unique modeling system, such as the building, mechanical, electrical, etc., where it seems no doubt about the need for models and modeling, no one asked what are models and how models work, but almost all of their work are model-based.

I also believe, in the software field, however, we have to face more complex and diverse models and model-working mechanisms, that is, relative to other engineering fields, models and modeling are more important and more difficult to be grasped in software field.

—-

(The illustration Memory from dollwei’s collective drawings, with the permission of the author.)

Firstly, it needs to repeat that, the default context are computer (software) and applications, some main subject (for me) is models and modeling, and in addition, the models and modeling for the app domain, such as the business and enterprise^[2]. Then, there are the basic topics on the three spaces including: entities, models, representations and abstractions.

Entities 

An entity is a thing we would treat or deal with in the context, which is able to be defined, identified, described, operated and, to be regarded as an object. On entities, we can further discuss the operations, relations, events, activities, roles, and process, … and more complicated things.

I prefer use “entities” instead of “objects”, since the term objects with specific meaning in the context: the use in Object-Oriented programming, and this is also somewhat a continuation of the tradition from information/data modeling.

There are three types of entities which are corresponded to the three spaces, can be called as physical entities, conceptual entities and computational entities. In other words, we can say, an entity of (belonged to) the physical space, the conceptual space or the computational space.

From a particular perspective, all types of entities are real-world things, and have some physical presence, such as the mass, shape, color of an object, the state of computer memory, the neurons or certain constructs in brain, and so on.

The basic criteria of the judgment to the ownership for an entity, is the operations (or measurements^[3]) on/to the entity. For example:

• As a computational entity (not an entity of a computer), a hard disk is a data storage device when it working in a computer to be stored/accessed of some data. The attributions are such as the format, capacity of data, etc.
• A hard disk is also as a physical entity, its attributions are such as the size, turning speed, input voltage, etc.
• In the conceptual space, a hard disk is some of memory (data) in brain, or in some text/picture on paper that can be read by human being.

There are different operations on the hard disk in different spaces:

• in the physical space, such as the motor rotation and the magnetic head movement;
• in the computational space, such as the data accessing;
• in the conceptual space, such as the thinking activities.

There is a nature of the three spaces: each space has its own operations by its own mechanisms.

Models 

Both a model and the object it modeled are some type of entity in certain space(s). Models can also be classified into three group: physical models, computational models and conceptual models, as well as the three types of entities. The ownerships in the three spaces for a model is consistent with the type of the entity of the model. For example, a group of records such as (S/N 093425235, SATA, 500 G, 7200 rps) in a computer memory may be a computational model of a physical hard disk (it depends on if the computer can process with the meaning of the data); in such a piece of paper (or, as in the essay) is a conceptual model (because it can be read and understood by us), of the physical hard disk. A model and its object are often in different spaces, this is one of the reason for emphasizing the three spaces. See the illustration below: it is very clear that the relationships among the disk, the model in the conceptual space and the model in computational space, and we can find that, the relationship between the conceptual model and computational model is different then with the physical disk.

Representations, Abstractions

One of my basic concern related to the three spaces are the representations of model (for example, also see the illustration), this involves in the way of the corresponding between a model and its object.

Finally, abstractions is a common and unavoidable topic in the context, it can be discussed on the three spaces more clearly, as will as for models and representations.

—-

[1] I changed the word from “computing space” to “computational space”, this is inspired from the comment by |= (his blog) on the previous post.

[2] Such the models and modeling of business/enterprise (and the uses) are logically independent of computer and applications, but in fact, from a technical/practical or a using aspect, it is still dependent on computer. it is important that to maintain a clear understanding of both.

[3] In essence, I think the three spaces can be attributed to some metric space. This is a significant topic which related to the foundations of mathematics.

( Last edited on November 13, 2011)

The perspective in the discussions of abstraction and my three space view are a bit different but closely related. See the figure below, it come from my subject “General Thing Modeling” where I tried to build a framework of models and modeling for applications, and I use it as basic world view for computer applications^*.

Each entity in one of the three spaces is with certain physical phenomenon — appears as a physical object individually or some physical trace can be measured (accessed) — but the specific operation/process will be only done by the special way of the space. For example, a statement writing on a paper or a computer file in text, the “meanings” will be read/understood by human so it is belonged to conceptual space; a record of a customer in a database will be accessed by the computer (program) so it is belonged to computing space, especially, it will represented the customer in physical space (which known as a concept in conceptual space) that is, a model of the customer. See the picture. In general, an entity in the physical space may be known as a concrete concept in the conceptual space, and may has a data entity’1 in the computing space; an abstract concept in the conceptual space has no entity in the physical space but has the entity’ 2 in the computing space. Yet, there are many cases on it, and the cases are quite complicated then my primary imagination, while attempt to depict and clarify all of relationships on this view. In deed, I think this is the actual background of the analysis for models and modeling to applications.

This view of three spaces seems simple and natural but in my experience, it is often unwittingly confused, especially with the correspondence among different models (and its objects), in the practice of modeling and the uses of models.
—-
* It is different to Karl Popper’s three worlds but, the physical space is basically equal to Popper’s World 1, the conceptual space is closed to the World 2, and the computing space do not correspond to any of Popper’s three worlds.

However, what factors led to this situation? It’s worth thinking about, deeply. In the abstract of keynote (I’m looking for the whole), he mentioned one of the aspect: “ambiguous relation between programming languages and modeling languages.” It is no surprising – this is one of the topic that we discussed about – and yet, I tend to believe that the difference between the models and programs may be more essential then the difference of the languages.

After such a long time, with so much research and practice, it requires certain radically rethinking but not just some amendments and additions that confined to existing ideas, if we want to achieve certain new breakthroughs. I think, there are many aspects/points which will probably be worth or need to do further exploration or research, such as ,

• For MDA^TM. It has been dominating the basic path to now called MDE but, some new ideas, with a standardized way, in a strong business background, control the direction of development/research in a field so long, I think this is probably not a healthy phenomena. (so the following aspects basically with MDA);
• For the basic concepts. Models (and the difference to programs), abstractions, abstract hierarchy, execution and interpretation (for models or code/programs), the ambiguous relations among such as graphical and textual notations, meta-models and languages, etc.;
• For the basic principles. The timeliness of a model, the object and/or purpose of a model, model working mechanisms, the conditions for model transformation, etc.;
• For the theoretical basis. The general theory and mathematical basis for models and modeling, an appropriate world view or philosophical foundation;
• The gap between its goal (motivation) and business (end users) demand;
• Be bound to OO, and so on.

It should be a lot of discussion on this topic — whatever, from academia to industry have spent countless resources for this, nearly two decades.

Models are never failed but the uses could, I think.

(Just a note, very preliminary.)

—-

[1] I read from here: Jean Bezivin, abstract of “Why did MDE miss the boat?”, a keynote address to the second Brazilian Workshop on Model Driven Software Development.

* The illustration “the imagination to a time travel may be irresponsible which relies on a high-mass/energy object, as well as a tiny wormhole” from dollwei’s collective drawings, with the permission of the author.

I think it maybe appear as a little difference but, in fact, it reflects an essential distinction between E-R models and UML models.

It is known that E-R model (diagram) is a meta-model for data modeling, which the data are about the entities in real words (outside of software application). An entity (an instance of a type of entities) is an individual thing so, has its own special attribute(s) to identifying itself uniquely, called as the key. In deed, the E-R modeling is fact-oriented.

UML, however, is an object-oriented meta-model, the objects is inside of software so it naturally uses the internal identifiers.

This is a meaningful distinction.

Where the abstract levels based on

In the previous discussion, I thought, a basic features of an abstraction is that it is abstracted away from some basis (source). Indeed, an abstraction must had a source or basis: it seems no any counter example in all things called as abstraction. In another aspect, the basis of an abstraction is often an abstraction yet; some of abstractions can be classified into an abstract hierarchy — such as the abstract levels that often mentioned in software field — all abstractions in the same hierarchy should be traced to an original basis, here, call it the base of an abstract hierarchy. It appears to be repeatedly forgotten or ignored in many cases, such as, some discussions of MDA/MDE.

Understanding computing from an abstract perspective

In essence, from an abstract perspective (see the figure), a software application is a union of two kind of abstractions which are from two different sources: the outside world and the computer world^[2], it has two kind of abstractions: the abstractions of the things of outside world (the domain it applied in, or the problem domain ), and the abstractions of things inside world of computer (or from the IT domain, such as code/software, resources/hardware)^[3], where the abstractions may be appeared as some models that defined explicitly, or in some other forms. Furthermore, these two kind of abstractions should have two different abstract hierarchies which have different bases, perhaps can be called as the outside abstract hierarchy from applied domain and the inside abstract hierarchy from computer/IT domain.

Is software an abstraction of real world

It has become very clear when changing the real world to outside world: there are two things — two bases (sources), as stated above — which need to be abstract from. So, the answer is, software is not an abstraction of real world or of a problem domain but, it has/processes some abstractions from both the outside world and the computer itself.

—-
[1] some previous discussions see part I and part II on the blog, and some relative discussions on MDSN at Is Software Abstraction of Real World? and Note on Languages and Abstraction.
[2] some times maybe using “real world”, as well as the “real world” and “brain” in cognitive topics.
[3] see discussions on this blog, such as Talking Models and Domains to Enterprise Applications: an Addition, etc. It needs more discussion about the meanings and the relation between IT domain and “the world inside a computer”, and the outside world.

(a discussion for the opinions in this post on MSDN at here)

A little of summary:

• All the things involved in an enterprise application can be divided into two basic domains – referred to Andreas’ comments – may call them as IT domain and business domain. They are a basic background to discussing about enterprise applications.
• About the concepts of Solution Domain and Problem Domain. They may be seen as a part of IT domain and business domain, roughly – it would need more discussion.
• Thus, as the place of the system model (black-box) and application system in the figure, the intermediate region should be a focus to us: for such the topic of separation of concerns and the bridge over the gap between business and IT.

• In much discussions about the subject, the AS IS and TO BE distinction was ignored, I want to highlight that, this is an significant understanding for some sort of applications, such as enterprise applications: an application is not mechanically inserted into the old business (AS IS) but will be an organic component of a new business (TO BE).

The new Fig. 1 presented a whole triangle of relationships among application system and black/white-box models. It was discussed in another essay Modeling on Black/White-boxes, and Abstract Level. So, here, we will starting from the other part of Fig. 1.

Domain models and entities

Typically, a comprehensive enterprise application system would be involved in many matters — from an information modeling perspective, generally called ‘entities’ – such as products and servers, work centers (a concept from ERP), organizations (corporations, organizational units and roles), business processes and so on. Notice that, the application system itself will be a part of the enterprise, and associated to others entities on an equal basis, see Fig. 2. Of course, these entities have complicated relationships/interactions each other, they are constituted a complex, open system.

One of important message from this illustration is, a black-box model of system will belonged to the applied domain (TO BE), as well as the entity of the application system, and we may be need to model many of entities such as product and server model, work center model, organization model, business model, and so forth, not only the application system, though we have only the purpose to developing an application system.

In the applied domain (AS IS)

Look at the applied domain (AS IS), see Fig. 3, there are no the application system yet. The only thing I want to mention here, is that it is not a linear combination from “AS IS” (plus an application system) to “TO BE”. The entities (the business) will be changed while the system be applied into the enterprise.

The primary thinking for this, may be traced back to two decades ago, Michael Hammer‘s famous paper, “Reengineering Work: Don’t Automate, Obliterate”, Harvard Business Review, July August 1990.

Based on the thoughts like in this discussion, when one talks about domain models (somewhat a vague concept, isn’t it?), I will ask, what entities you modeled? Is all the related entities (and the business) with the application system as a black-box, or the functions of the system only? What facts the domain models captured? AS IS or TO BE? Who is able to design and describe the “TO BE” but not only the system? These are very hard questions.

By the way, to talk about the problem domain. It may be reflected such a thinking: we don’t need to understanding/describing the whole enterprise/business but only the part related to the system we want to develop. But unfortunately, there may be not a clear boundary, or exact criteria to demarcate it, because the requirements (problems) and the possible solutions are naturally various and changeable. Moreover, the system will only be existed in the TO BE domain which is in some imagination in developing time. In other words, an applied domain (or problem domain) may be hard to be demarcated around the application system it self, it may be had to be divided by the business. So, this is also one of the reasons, we had to grasp some approach to modeling the whole enterprise/business.

The term black-box is usually referred to a device, object or system^[1]. The concept of black/white-boxes implies an assumption, that is, the view or description of a system under study ^[2] is able to be separated into outer or inner aspects. The outer aspect involves such as functions, behaviors, or characteristics, and the inner aspect may involve into structure, composition, processes, etc.

Definition of black-box models and white-box models

Black-box and white-box is a pair of relative concepts. For black-boxes, there is an input, output and processing pattern in many discussions. To software and application, however, it seems suggesting the structured programming strongly — I don’ t know whether it is the cause to that, the concept seems to be ignored in the field in a certain extent — today, it may need to be defined more carefully.

My recent interest in this concept is focus on that, it is a basic perspective for modeling (of software and application). It would be led two different models for the same system, they are called as ‘black-box models’ and ‘white-box models’ in my last essay. A black-box model is taken from an external perspective, to represent the functions and behaviors in the environment, it is a view of use; relatively, a white-box model describe the internal structure, it is a view of constructing. It perhaps can still be attributed to the distinction about what and how, but I think, this is different from some common views, such as declarative, descriptive or specifications, and executive, procedural or instructions, and the concept of granularity, even the concept of abstract level.

Relationship of black-box models from using view and white-box models at different abstract levels

We can also see the concept of black/white-boxes as a principle to reduce the details in a model, but this principle is different from all the principles that served at each abstract level of software (computing).

From a using view in a context of an application (application environment), all the models at different abstract level of software is a white-box model, though it may be ignored many of the details on a higher abstract level. It never be black unless changing the perspective of view. In other words, the black-box models are out of the range of the abstract hierarchy based on software.

This is an intimation that, for a software application system, we would need/have two kind of models: a black-box model from the using view and white-box model from the view of implementation of software.

A triangle of relationships among application system and black/white-box model

As stated above, the relationships among the black-box model and the white-box model with the system, form a triangle, shown in the figure 1. It presented three basic relationships in software development and application:

• system to black-box model(s)
• black-box model to white-box model(s)
• white-box model to system

It may be a basis to develop some architecture for software and application systems.

—-

The Models in Applied Domain. The main models in applied domain are such the business models, or more general, the enterprise models. Another impotent division for applied modes, is AS IS and TO BE, each corresponding to the domain before or after the system applying.

The Models in Application System Domain. The most main kind of models in this group, is the model of the application system, the application system model. Further, this model can be two important types: black-box models and white-box models. For example, the models based components, or programs as models, are white-box models; a model that mealy descriptive to the functions or behaviors or say what but not how, will be a black-box model. Yet, there are another important divisions for this group: such as the models of system design, test, and the models of system itself configuration, deployment, and so on.

The Black-Box Model of an Application System. Actually, this kind of models can divided into both the system domain or the applied domain. It can be used as a bridge between the applied domain and the system domain.

See the Fig 1. The usage of domain model, and its relationship with system model, such as a business (process) model, can be well understanding from the perspective of Enterprise Architecture. Moreover, the fig also illustrated that, the Requirements Analysis usually do not describe some exist thing but create a new thing.

On the basic classification of models, we may have some new revelation or inspiration. For example, in the citation mentioned above, Ed enumerated some models that are not programs and may not be executable, such as requirements models, business process models, enterprise architecture models etc. some of this models are belonged to the applied domain, and it is executable in applied domain, such a business process models. Deeply, I think this is an important aspect to the semantics of execution.

In addition, a black-box model of application system, may be regarded as a part of the applied domain, or in other words, the whole model of an applied domain TO BE, included all of the functions and behaviors of the application system, and we can aggregate all the elements of/for it, to establish a black-box model of this application system. For the black-box model in the applied domain, the application system is supporting the execution, but not executing it directly.

I think, most of the discussions in MDE context were merely about the models in system domain, we can extending the view more broadly, to think how do we gain more benefits from models and modeling.

On the preliminary study, I think abstractions is not fiction or imagination. An abstraction itself is certain object/entity in the world – in a physical, cognitive or computational space – however, it is never an isolated thing but has certain source or basis that the abstraction is abstracted from, to distinguished from such as fictitious or imagined thing. It has a source where there are objects/entities which are more concrete than the abstraction, and have certain correspondence with the abstraction, that is, a source-objects-to-the-abstraction (source-abstraction for short) correspondence. Notice that the ‘objects’ in this essay are in general sense but not in the Object-Oriented sense.

Abstractions in Computational Aspect

In the field of IT and applications, ‘abstraction’ are often appeared not about cognitive nor physical. So I extended the Table I-1 from the previous essay, as Table II-1.

Table II-1: Extending Types for Abstractions to Computational

In the table, I added a new space for abstractions, the computational aspects. For the examples in the table, say an abstraction “a class abstraction from the objects” is homogeneous, in the sense that both the class and the objects are carried on the same media, such a language/program (and do not depends on the specific physical materials); an abstraction “data abstraction from the real world” is non-homogeneous, obviously, data in an computer have different media (materials) from the actual thing.

Simplification is a bad word for Abstraction

In such the software field, it appears often explaining abstraction with some words such as ‘simplify’, ‘refine’, ‘reduce’ etc. These words are quite matching the simplest abstraction, as the  example “water abstraction from rivers” in the table, yet, a basic definition in many dictionaries: “remove something from somewhere.” However, I have many reasons to argue that, those words, such as ‘simplification’, are bad words for abstraction. It sounds obvious but too apparent to most types of abstraction we concerned.
If you want represent – abstract – some thing from a reality, It had to be expressed in certain data. So I will talk above issue on data modeling. In Navathe&Sham’s book Fundamentals of Database Systems (4th ed.), discussed four abstraction concepts for data abstraction process, which are used in semantic data models or KR schemes (p110-113): (1) classification and instantiation, (2) identification, (3) specialization and generalization, (4) aggregation and association. The (1) and (3) are inverses but (4) are not, I divided them into two types of abstractions. (see explaining later)

Table II-2: Types of Abstractions for Data Modeling

Note. In data modeling, it is usually using ‘entity/type’. All ‘object’ and ‘class’ can also add/replace with ‘entity’ and ‘type’ in the table.

Based upon the discussions above, it may

• say a classification (class/type) is an abstraction, since that it has certain common properties/attributes that are selected/copied from some objects/entities at the source;
• say a specialization is an abstraction, since that classes/types themselves can also be objects/entities, and thereby be instances of some super class. A super class/type abstraction from some subclasses is usually homogeneous but the classification is possibly non;
• say an aggregation is an abstraction, since that it is a collection of certain objects/entities at the source, but can be played as an object/entity on another level;
• say an association is an abstraction, since that it is an object/entity with some roles which are played by some objects/entities, and the roles is belonged to the abstraction but not the objects/entities at the source;
• say an identification is an abstraction since that it is denoted an individual object/entity as the source.

Notice that, all the abstractions are not as a simplification, not like “remove something from somewhere” as “water abstraction from rivers”, even if for a class from some objects in data – as a homogeneous abstraction – the class itself ought be a data entity and have certain construct but not some thing that simply extracted from the source. We can find more examples, such as an assembly instruction from machine instructions, an API from operational system, and so on. I think, almost all of the types of abstractions in computational space cannot be understood as ‘simplification’.

Overall, The word ‘simplify’ is not suited to most types of abstraction that interested by us, and, on other hand, it is easy to lead astray, to lead us understanding the modeling for some software and the applied domain as a simple mapping between the Objects of software and the entities in the domain, even more, to lead us to be under a delusion that see a whole of software as a ‘simulation’ or an ‘abstraction’ that extracted some objects what concerned, from the real word.

I always had some doubt to so-called ‘Executable Model’, although it seems an inevitable result in the logic of MDA, but it also like a trap: if the models are fully executable or transformable, what are the difference with programs? Why we must say they’re models but not programs? To rise the abstract level is necessary and useful but not need to rename programming to modeling… From programming to visual programming, to modeling (visually), to modeling (textually and to be executable), it seems somehow return to the origin, isn’t it?

I would have more discussion on the related issues.

Inevitability of executable models

Why I think executable model somewhat an inevitable result in the logic of MDA? Simply put, precision and formalization of system (software). In MDA Guide V1.0.1 (OMG, 2003), defined

A model of a system is a description or specification of that system and its environment for some certain purpose. A model is often presented as a combination of drawings and text. The text may be in a modeling language or in a natural language.

Notice that the description, drawings and natural language implying that imprecise or uncertain. Naturally, this seems quite closed to the strategy that partially automated code generation from models. However, I think, most people who use the models to design/implement the system directly would not be satisfied with some imprecise models which are put a great deal of effort – if so, what the essential difference with well-prepared written document?

Consequently, precision will be necessary and essential to the modeling and the models, and the exact expressions would naturally be in some formalized way, that is, programmable. Thus, the models will be able to processed by computer automatically, thereby, the first thought would be generating code form the models of the system, directly and automatically. Further, if we are able to program to generating all the executable code from the models, why we can’t construct a virtual machine to run the models directly?

Moreover, “The three primary goals of MDA are portability, interoperability and reusability through architectural separation of concerns.”(MDA Guide V1.0.1) This goals are somehow fixed on the final code, so, the modeling of software system seems have almost only one end: to make models to be executable.

If models are executable, what is the difference with programs?

My whole understanding for MDA early, was from David S. Frankel’s book Applying MDA to Enterprise Computing. He stated that:

“MDA is about using modeling languages as programming languages rather than merely as design languages. ”

I had to admit, this words left me a deep impression. Recently, in a discussion on Vincent’s blog, Ed Seidewitz emphasized that

“all programs are models. They are models of a desired computation that are detailed enough that computation may be mechanically executed.”

Of course, this is fully in compliance with his definition (2003)

“A model is a set of statements about some system under study.”

Such and such, aren’t the concept of models here very closed to programs? Furthermore, let us do some review on Fourth-Generation Programming Language (4GL), there were some key words such as higher abstraction, problem-oriented, non-procedural, declarative, defines what but not how and so on, yet, I see, almost all of the key words can also be used on the topic without any change.

I think, CASE, 4GL, and perhaps DSL, declarative programming, and so on, are all related some common points and purposes, but seems lacked certain breakthrough, all along. It seems too many concepts have the similar essentials but might have no satisfactory results. So, for the executable models, I have also some concern that whether it somehow returns to the origin, or in other words, how much surprise will it bring us? I know, there is a basic answer, that is, it isn’t go back to the origin, but to a higher abstraction level and covered more details of implementation and so on, but I want to say, maybe, perhaps, we can still go forward along the track the programming evolution, like as on 4GL and/or DSL? Meanwhile, anyway, mix up programs and models, would probably lead us miss the concerns on other important or valuable possibility.

Gain more benefits from models and modeling

In the discussion mentioned above, Ed told about another aspect of models yet, He said

“I would certainly say that there are still models that are of great interest that are not programs and may not be executable. I may have requirements models, business process models, enterprise architecture models, conceptual models, and so forth. Some of these may be ‘executable’ in the sense of simulation or enactment, but I don’t think I would consider any of them programs. ”

Such a business (process) model, or more general and clear, the models of an applied domain what the software system will work in, as a role or part — this is what my mostly interested in — to bridge applied domain with software design on models and modeling. This is a long story but first, it must be separated clearly (models of domain and of software), then, to find the exact way of them interrelated. And further, there is no simple mapping between the domain models and the software system (or its models). For this, there is a little discussion on the Vincent’s essay above mentioned firstly. Vincent use ‘weaving’ to refers the connection between them. I think it’s better then ‘mapping’, however, I think it is the nature of design of applications (software), and “as a whole, it had to be done by human-beings, unless the computer has reached a human like intelligence.”

Furthermore, These is a very different way to bring models into software applications world. The models – of applied domain – will be able to working at run-time of the software applications, while keeping the capacity that can be change (I called this model evolvability). I called this way the models work, as model-driven mechanism(MDM), the system with MDM, as model-driven systems(MDS), the applications as model-driven applications*. Compare with the model-execution, both them are use models at run-time, but the mechanism is completely different. In an earlier talk with a senior architect of software, I have distinguished as ‘execute/run models’ vs. ‘driven with models’. This is not only a theory, there are many instances in practice. Today, in this context, the best example is, the BPMS. Other classical example is the DBMS (and some sort of applications on DBMS). For the BPMS, the model is, as Ed’s comment mentioned, the business process models. And for DBMS, it is more complicated – for a clear description, it needs to define models in a more sophisticated way.

—-

[*] I got this idea from 1999 (such the first publish and the roadmap in Chinese), yet some introduction about the issue on this English blog:

• Model-Driven: An Essential Requirement Come from Customers
• A Roadmap of Research for Enterprise Applications (a simplified version)

—-

Updated on Aug 15, 2011

1) For emphasis, Marked the two paragraphs with bold font style.

2) The original sentence “there is no simple mapping on the correspondence between the domain models and the software system (or its models).” is probably not exact or clear. It has changed as “there is no simple mapping between the domain models and the software system (or its models).”

Two classes of the meanings of ‘abstraction’

Firstly, a basic explanation from Encyclopædia Britannica Online as below:

abstraction, the cognitive process of isolating, or “abstracting,” a common feature or relationship observed in a number of things, or the product of such a process.

(http://www.britannica.com/EBchecked/topic/1994/abstraction)

Applying this explanation as a boilerplate, say, ‘abstraction’ refer to some process or act, or the product of such a process or act. Then, divide the meanings of ‘abstraction’ into two classes: physical and cognitive.

Abstraction as a physical process

A definition about abstraction from the Oxford Advanced Learner’s Dictionary as below:

3 [uncountable, countable] (technical)
the action of removing something from something else; the process of being removed from something else

* water abstraction from rivers

(http://www.oxfordadvancedlearnersdictionary.com/dictionary/abstraction)

I think this is the most trivial definition about ‘abstraction’. Notice that, there is no material conversion, that is, obtaining or removing something from a source without a conversion of the material, e.g., water from more water in a river; text from more text in an article: they are abstracted from one place into another place but still (can) keep the original/same materials of the source objects and the abstractions.

Another example is taking photos: to abstract the image of some objects with some media. The important thing is, the materials of a photograph is usually different with the original objects, in addition to some of the optical characteristics.

Abstraction as a cognitive process

This is the main meaning of ‘abstraction’, just as the definition in Oxford Advanced Learner’s Dictionary:

1 [countable, uncountable] (formal)

a general idea not based on any particular real person, thing or situation; the quality of being abstract

(http://www.oxfordadvancedlearnersdictionary.com/dictionary/)

There are two sorts of the abstracting process in our mind (mental space):

abstraction within a mental space Most of concepts in our mind is an abstraction from abstract concepts else. For example, the term ‘life’ is abstracted from organisms, it more abstract then ‘organisms’, but the term organisms itself is also an abstract term.

abstraction from the real world The term ‘moon’ is so-called concrete term, it mapping onto the moon of real word, and therefore, according to above definition, it is not an abstraction. However, it is also a symbol onto the aggregation of data in our mind which are the result observed: the time it rose; the color or image; the path; etc., so, I think, it is also an abstraction from the real word, under the sense that based on a aggregation of the data in our mind – they are not particular real thing or situation. This perhaps regards as a duality, but I prefer say it is one of the most concrete abstractions in our mind. There are more reasons to supporting ‘moon’ is also an abstraction yet: such the ‘electron cloud’, it is always an interpretation (the result) of certain theory, regardless of whether there are sufficient observational data to support it. In other words, your can say it is an abstraction or not, with different reasons to different situations, but there is no essential difference or change for the term/idea.

Homogeneity of Abstraction

The above two aspects both involved into the issue about the material of an abstraction and the source objects. I want introduce a concept homogeneity for this situation, say

• An abstraction is non-homogeneous if the abstraction has different materials with the source object(s).
• An abstraction is homogeneous if the abstraction has the same materials with the source object(s).

Obviously, the abstractions in our mind has different materials with the real world objects, so it is non-homogeneous, but the abstractions in our mind has the same material with things else in mind, it is homogeneous.

Consequently, I am sorting the abstractions into four types with the classes of physical and cognitive, and homogeneity, as the table.

Table I-1: Four Types for Abstractions

By the way, I think this classification can also be applied to representations and models.

The writing is very hard, I don’t know whether it’s enough to read. Leave your comment please!

“A human language, such as English or Standard Mandarin, as opposed to constructed language, artificial language, machine language, or the language of formal logic.”

(About.com, http://grammar.about.com/od/mo/g/natlangterm.htm)
but these are not the well definition I want. A better definition got from Wikipedia (English):

“In the philosophy of language, a natural language (or ordinary language) is any language which arises in an unpremeditated fashion as the result of the innate facility for language possessed by the human intellect. ”

(http://en.wikipedia.org/wiki/Natural_language)
These are my understandings:

• A natural language is generated in the process of the communication among intelligent individuals’ community, naturally and gradually.
• The progress of evolution of the natural language is the progress of cognition (like as Wittgenstein‘s language-game).
• The evolvability of cognition dominates the evolvability of a natural language.
• The differences between artificial language and natural language are: the artificial is purposefully designed but natural language is naturally occurring.
• In fact, the evolution of a natural language is ever made by human but has no explicit planning or objectives, as a whole.
• And actually, to emphasis on ‘human being’ is unnecessary.

Based upon these understandings, I made a little improvement to the proposition at the beginning:

A natural language will be able to express any thing that can be expressed by any formal languages, while the formal language(s) is designed by the people who thinking in the natural language.

The question is about ‘able’ but not ‘suitable’, although it seems not the same of many people’s intuition.
At last, Zhang3 has mentioned to me that natural languages maybe corresponding to Chomsky hierarchy type-0. I agree but not sure, because I do not know more about that discipline. What is your comment?

Original: Zhang3, 2011-04-19

1. Relational algebra is a subset of first-order logic and what it represented is, the logical relationship between things.

2. E-R model has deviated from the real  intention of  relational logic. The ‘E’ should not be an entity but just a name. Relational modeling should not by the E-R way.

3. Some of well design patterns be destroyed by OO analysis. Most people lay the blame on that the idea of database is not advanced than the idea of OO. However, in fact, the relational algebra is much profound than the OO theory (if even say that OO having some theory).

4. Some models will be simple in relational database, which are complex on OO thinking, and will be simpler if the relational database providers a Turing-complete language instead of the SQL way.

5. ORM is a serious mistake, which forced modeling a real world relationship by OO, and then mapping it onto a relational database, that is, to build a bridge incompatible to both, between two originally compatible worlds. Nothing is more absurd than this.

Original URL: http://www.douban.com/note/146255104/

(Translated by TY)

A real cup is an entity but, never an OO’ s object.

Any classes are in your mind or your code but, not in the world.

• This expression sounds some vague, it could lead to questions, such as the following comments by Vhanniet. An improved version as follow:
  Any classes are in your mind or your code but not in the real world outside the mind or the code.
  (Jan 26, 2012)

Often said that “a picture is worth a thousand words”.

I would rather believe that is true and, at least, to my poor English;-D

What you think about the picture?

Updated, 1 June:  change the title OO’s Cup to OO’s Magic Cup

Recently, Vincent Hanniet discussed the topic in his essay “MDA/MDD: don’t round-trip!” focus on another concern about round-trip. He said also “Mode is not code.” and implied that we should not be “coupling modeling and coding through round-trip”, “So please, don’ t round-trip!” Further, in a  comment on the post, he stated his opinion more clearly

In brief:
1) Model is not code,
2) Code may be (partly) generated from models,
3) Code may be reverse-modelized but this usage is not appropriate in MDA/MDD

Here, I want to try to write some of my thoughts relating and following Vincent’s excellent thinking.

First, I think, the round-trip engineering is not the matter but the basic question is: whether it is feasible, and by what kind of restrictions? It may be not “To Do or Not To Do” but “Can Be or Can Not Be”, that is the question.

Perhaps, this issue can be boiled down to transformation-ability or transformation-ness (Sorry, I’m not sure is it the appropriate expression?) It can be investigated in many certain situations: A transformation from certain models to code or certain code to model(s) is possibly effective, non-effective, effective and reversible, or effective and non-reversible. Further more, even if a transformation is reversible, the result is possibly recovered fully or partially, or as the same or similar.

More specifically,

• Whether should the models or code be taken (required) certain restrictions for the implementation of a transformation? and what influence, on our means or purposes that using models, will be brought by the restrictions?
• What kind of a model can be transform into code?
  (and what is the meaning about “a model is transformed into code”?)
• What kind of code can be transform into certain model(s)?
  (and what is the meaning about “some code is transformed into model”?)
• Is a result of trasformation unique?
  (or what factors/conditions/context will affect the results of transformation?)
• If a “model” is so-called executable, finally, is it code or model?
• Is the code generation (from model) equal to model transformation?

Ultimately, these issues will lead to a more general question, as I often mentioned:

• What is a model?
• How does a model work?

They need more explicit answers.

—-

Updated:  April 23, May 30 (to correct a serious mistake in grammar)

I (1), the author said:

From my perspective:

Programming: using a very expressive language and restrict it by coding rules.

Modelling: using a very restricted language, s.t. it is expressive enough, but also easy enough to handle (read, write, …), for creating different views on a thing.

… …

what I mean is that independent from its domain, even if it comes in different notations, every languages has a certain level of expressiveness. think e.g. of the chomsky hierarchy.

According to the author’s clues, I imagined a rough view as follows:

• a machine language maybe close to recursively enumerable or context-sensitive language corresponding to Chomsky hierarchy Type-0 or Type-1, and
• a high-level programming language maybe more close to a contex-free language at the Type 2, thus
• a modeling language such as UML is basically close to a regular language at Type-3, it (a model by it) can be taken such as some business context then has rich semantics to describe a system include software intended.

For this, the author commented:

roughly, yes. where I think in much smaller bits than the whole UML.

by the way, regular languages have the same expressiveness as (relational) Monadic Second Order Logic. This is how Finite Model Theory comes in.

the point is that languages from propositional logic up to chomsky-0 form a hierarchy, where modeling comes from the low and programming from the high end.

(the bold is added by me)

And at (2), I said:

I think, Model Theory (mathematical) may be the most important foundation for models.

However, it seems there are some basic puzzles, such as some inconsistencies in the use for term of model?

The author replied:

Totally agree, Model Theory is it, but please let it be finite (here’s why: http://bit.ly/eg9VHb )

Finite Model Theory has provided the essential basis for database theory. Think it could also do for modeling.

Above discussions maybe touched some meaningful issues,  I think the author point out certain propositions clearly, also I was looking for. Maybe it is one of the important piece of a jigsaw – about models and modeling.

I want to try to explain it a bit more. I have been having the basic viewpoint, that is, a model (or a domain) must be finite (so-called “universe of discourse” is ambiguous). This is a premise for our cognition – more specifically, this is a premise of that we gain stable, reasonable outcome from requirements analysis for a system.

In other words, to face the infinite and open world, our logical premise has to opened but any effective cognition always based upon a finite model (e.g. a theory with a model satisfied it), the closed word assumption^[2]. Perhaps someone would say it is simply obvious but, it maybe one of the primary premise to introduce mathematical basis for models and modeling we are interested.

By the way, how do we get a finite domain? It is to do modeling. Here, the meaning of “models” have being reduced insensibly.