Next: Object-orientation, systems and models Up: Models and Systems Previous: Systems
Once we have a more clear view on what a system is we can come back to the definition of model, which we said is ``an abstract representation of a system''. The main goal when analyzing a system is to come up with a valid model for a given purpose. If it is possible to alter the actual system and evaluate it under the new conditions, it may be desirable to do so. But this is seldom the case. It is usually necessary to build a model and study it in place of the actual system.
A model consciously focuses on some of the subject matters leaving others out. Therefore a model needs not be complete. But incompleteness and a high degree of abstraction does not mean imprecision.
It is important to note that a given system can be represented by many different models. These models may have different level of abstraction and purpose and the ``best'' model is only the one that is the most useful for a particular application or purpose[Hall and Fagen, 1956]. On the other hand a single model may have multiple interpretations, where the interpretation is defined as the relation of the model to the thing being modeled [Seidewitz, 2003]. Finally, the relation of all the possible models derived from a particular system is called a theory. More precisely, and according to [Anderson, 1983], a theory is a precise deductive system that is more general than a model. As a matter of fact, a model is the application of a theory to a specific phenomenon. We can deduce the quality of a theory by the quality of the models that it generates.
A first classification of models is into static and dynamic models. A static model is a representation of a system at a particular time. A dynamic model represents a system as it evolves over time.
Another way of classifying models is according to the domain in which the model will be deployed. We can then classify models into physical models, mathematical models and software models. Out of these we are interested in the latter but as software and mathematical models share many of their properties we will first summarize the main properties of a mathematical one.
A mathematical model is a set of mathematical expressions that are sufficient to explain the behavior of a given system for a particular purpose. Once a mathematical model is built, if it is simple enough, it may be possible to get an exact ``analytical'' solution. But this is almost impossible in many cases and then it is necessary to study the model by simulation (numerically exercising the model and studying how input variations affect outputs). If a simulation model does not contain any probabilistic (random) components, it is called deterministic: once the input and the internal relations are known, the outputs can be determined. Many systems though must be modeled as having one or more random inputs, these are called stochastic simulation models [Law and Kelton, 2000].
Software models built in order to have an executable software version of the system under study are called constructive or executable models [Hylands et al., 2003]. Constructive models define a computational procedure that mimics a set of properties of the system. Software models that are clearly different from the system are often referred to as simulations. But in many systems a model that starts off as a simulation ends up being a software implementation, blurring the distinction between the model and the system itself.
The use of executable models in software engineering has given place to a methodology known as model-driven development (MDD) [Ambler, 2003,Meller et al., 2003,Seidewitz, 2003]. In traditional or code-driven development models are treated as simple sketches that are thrown away once the code is done but in model-driven development the models themselves become the primary artifacts in the development in software. In MDD different models are use throughout the developing process and are divided into two main categories: conceptual or analysis models that express requirements and engineering or design models that are ready to be turned into code or an executable. Successive model transformation offer a way of mapping analysis models to design models. Model-driven development is also very much related to the Meta Object Facility or MOF (see section 1.4.3)
Nevertheless it is probably in the Analysis phase of the development cycle when it is most used. We talk about the ``domain model'' to describe a high-level, abstract model that is used to partition the original domain of the application (e.g. ``cattle growing'' or ``car traffic regulation'') usually into objects. When building the domain model we do not intend to have a nearly implementable design, we are only trying to understand the context of the application, partitioning the problem to make it more understandable and easily translatable to the software domain. The domain model focuses on requirements (either functional or non-functional) that a particular domain comprises.
The domain model is many times combined with the ``business model''. While the domain model focused on requirements, this latter focuses on the internal processes involved in the business we are trying to model. It is somehow in between the domain model and the design model that will latter become the real application. Note though that, in any case, the model is neither the original problem, nor the solution given to the problem in the software application. Both the original problem and the final software implementation have an abstract representation through either a domain model or a design model. As M.A. Jackson points out, from the domain we get a description model true only of the domain, from the machine we get a description true only of the machine; but in the middle we have an intermediate description that is true of both domain and machine maybe under certain restrictions [Jackson, 1995].
Software models are usually expressed using the Unified Modeling Language (UML) but can also be expressed in any other programming language.
To summarize, we can say that a model is a representation of a system that has been built for one of the following purposes:
2004-10-18