On the difference between analysis and design, and why it is relevant for the interpretation of models in Model Driven Engineering
Journal of Object Technology
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
... resent (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. 1 solution 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 (more or less orthogonal) dimensions in order to enrich the definition of the modeling space, such as "subject area", "aspect", "authorship", "version", etc. [Kent 02], but they are not necessarily related with the duality of analysis and design. Our initial concern stems from this question: which is the characteristic difference between an analysis model and a design model? Our research on the related literature will show that there is not a unanimously accepted understanding of this difference among the community of software engineers. In other words, we think this traditional duality conveys really a triple difference that cannot be properly expressed through a single dimension, but rather requires three orthogonal dimensions (see Figure 1 ). Failing to acknowledge this triple difference leads to confuse the meaning of models, which has a practical relevance for the way models are interpreted and used in real software projects. Briefly, the "reality" dimension is related to the thing represented in the model, either a software system or its application domain. Besides, a model can be used with two different purposes, to describe an existing system/domain or to specify a system/domain to be built: this is what we identify as the "purpose" dimension. Finally, something can be represented in a model from a more abstract point of view (black-box model, logical view) or from a more concrete point of view (white-box model, physical view): this is VOL. 8, NO.