In this paper we try to clarify the confusions that lie around the widely used terms "analysis model" and "design model" in software engineering. In our experience, these confusions are the root of some difficulties that practitioners encounter in system modeling, and sometimes lead to bad engineering practices. Our approach consists of placing the duality of analysis and design within a three-dimensional modeling space. Models are classified according to the reality they represent (first dimension), the purpose of the model (second dimension) and the abstraction level expressed in the model (third dimension). This classification facilitates the interpretation of models and the comprehension of model transformations as shiftings within this space. ON THE DIFFERENCE BETWEEN ANALYSIS AND DESIGN, AND WHY IT IS RELEVANT FOR THE INTERPRETATION OF MODELS IN MODEL DRIVEN ENGINEERING 108 J OURNAL OF OBJECT TECHNOLOGY V OL. 8, NO. 1solution for the analyzed problem; a "model" is some kind of simplification that is used to better understand the problem ("analysis model") or the solution ("design model") [Rumbaugh et al. 91]. However, this view is too simplistic, especially for the term "analysis model", since different kinds of models fall into the "analysis phase" of systems development and not all of them have analytic character [Karow & Gehlert 06]. But let's go deeper into the meaning of these terms. Analysis is a Greek word that equates to the Latin decomposition: "breaking a whole into its component parts (in order to better understand it)". It is opposed to synthesis (Greek), or composition (Latin): "building a whole out of its component parts". Design, instead, is related to drawing or making a blueprint of something before constructing it. The design anticipates and guides the production process, the "synthesis". In this view, we can say that design is part of synthesis, in a wider sense that includes the preparatory phases of synthesis, i.e. not only the pure construction activities.The duality of analysis and synthesis, or analysis and design, has been traditionally used in software engineering for structuring the preliminary phases (or better, the activities, to avoid temporal connotations) of the software development process, where modeling is of crucial importance. As we will show in this paper, this single dimension is not enough to define the modeling space, i.e. the coordinate system where we can locate the different models employed in a software project. Other authors, such as Kent, have already studied some dimensions of this space, revealing that this is a field worthy of more research [Kent 02]. In this work, we are going to present three dimensions we consider particularly useful, without pretending they are the only ones that can be defined. We call them "dimensions" because they are independent (orthogonal) ways to classify the models and they serve to structure the modeling space. Each one of these three dimensions is related in its own way with the duality of analysis and design. We can add other ...
