Some Classification of Models for Software Applications

In Models: Execution or More, I cited some Ed’s view points on models. In my view, it appears there is a dichotomy between executable models and non-executable models (of course, I am not sure if it is fitting Ed’s idea). On the other hand, there are two basic aspects for modeling: the application system and the domain it will be applied in, I call this applied domain, and accordingly, an application system domain (system domain for short) is the domain of all thing about the applications system development. This will divide all models into two group: the first is the models in applied domain; the second is the models in application system domain.

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.


  1. “most of the discussions in MDE context were merely about the models in system domain” – yes, often I find it very confusing when people talk about system models only, stating they have a solution for any kind of models.

    Think AppDom to SystemDom transformation requires a high quality of AppDom models. Definitely higher than it is common industry practice today, and I would say also higher than our theoretical foundations of modelling today allow us to go. (i.e. we know how to express models, but we have still quite naive notions of what is happening during their creation)

    Have fun

    1. Yes, I think it touched some key points, but in my thoughts, the quality (precision, formalization, etc.) of AppDom models are important but this is not a real barrier, it might no harder than such as build the app system model in UML. I prefer believing there are some simple principles/ways which are ignored.
      Happy weekend :-)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.