I have been teaching Object-Oriented (OO) Modeling [1] for a few years, then I taught an advanced course on Foundations of Software Engineering (SE) [2] for several years, and recently, I lead a workshop on developing a software engineering application [3]. In the Object-Oriented Modeling course we teach UML using a pragmatic view-point, i.e., emphasize how and when to use various features, based on their semantics and properties. In addition we teach a process of project development, using the taught models. In the Foundations of SE course we teach selected chapters including testing, project development methods, design patterns, refactoring, design by contract, and more. The workshop on project development consists of 5-student groups that collectively develop an application construction, guided by a sta member. Following such an extensive education, my expectations were that students will recognize the value of early modeling, and will get used to analyze and design software with models, as a standard practice. I was rather surprised to nd out that once out of the OO Modeling course, most students do not use models unless enforced. Moreover, somehow, most students live under the impression that models are kind of \annoying documents" that accompany software, and can be written as an afterthought, when software is submitted. This is, for example, the way that most students use models in their nal, year long project. In extreme cases students use automatic model creation procedures, available in advanced integrated development environments. This poor situation of actually using models as documentation rather than for analysis, design and development of software, can be explained by multiple factors, some essential to model nature, and others more pragmatic, based on available tools. On the pragmatic reasons we suggest four reasons: 1. Lack of model-level tool support, at the level of modern compilers. 2. Lack of support for model-code coordination all along the software life cycle. Development environments do not keep models consistent with code. Therefore, models become irrelevant very quickly, and programmers nd it di cult to preserve model-code agreement. 3. Software development environments do not support advanced modeling features. 4. There are no commercial model processing tools that enable model testing. USE [4,5] is an academic tool for UML/OCL class diagram validation, using instance creation and veri cation.
On the more essential reasons, we point on two reasons:
1. There is a technical di culty in creation of visual models, while writing
symbolic speci cations poses no technical problems. The heavy-use of visual
tools does not help either.
2. The third essential reason involves the declarative nature of analytic
knowledge and the di culty of abstraction speci cation: Declarative expression
of (what is) knowledge is harder and requires deeper understanding and
analytic capabilities, in comparison to procedural (how to) knowledge [
Model properties: Formal de nition and visualization
Traditionally models have been developed as visual notations, since they were intended as intuitive sketches of business level abstractions. Models were understood as a means for intuitive explanations, either to non-professionals, or as a means for initial analysis or design of software. In most cases, there was no intention of being coordinated with applications along their life cycle, and smooth model evolution was not a goal.
Some exceptions are the Statecharts model, and Description logics. The rst,
was developed as a visual Domain Speci c Language for automated realtime
systems. It was formally designed, implemented, and used in actual industrial
applications [
The need for symbolic de nition of models
The emergence of the Model Driven Engineering (MDE) approach has changed the picture with respect to models for software analysis and design. Automatic translation, processing and code coordination require well-de ned speci cation of semantics, processing, evolution and management techniques. Models are not anymore just pictures drawn on a wipe board. Indeed, the OMG and other industries supported a wide development of modeling languages, standards, and tools. Nevertheless, while usage of models is growing in modeling Domain Speci c Languages, they are still scarcely used in the process of application development.
The thesis I try to raise in this position paper is that if models need to live and evolve with the software, they should be appealing not only to naive users, but also to the community of developers. The pragmatic reasons listed above suggest four points for improving the performance of model processing tools, but this is not within our reach. The two essential reasons involve the technical di culties posed by visual speci cations and the essential di culty of abstract and declarative speci cation. While the latter reason requires long range education, the problem of visual speci cation can be solved relatively easily. Developers, and even students, with some program writing experience, prefer symbolic code writing over drawing visual models. One class in the ObjectOriented Modeling course that I taught, has used the USE system for validation of UML/OCL class diagrams. I noticed that after mastering the USE symbolic speci cation of class diagrams, students preferred the symbolic writing, over visual model drawing.
The obvious conclusion is that while visualization is certainly advantageous as a presentation layer, it is not appealing to programmers. That is: Every MDE modeling language must have symbolic syntax, in addition to its concrete visual syntax. Teaching of modeling languages must concentrate on the dual existence of the visual and the symbolic syntax.
The expectation is that the design of modeling languages using symbolic syntax will improve their theoretical status. More concretely, the expectations are as follows: 1. The distinction and inter-relationship between concrete and abstract syntax will be de ned. 2. It will be clari ed that models are not visual presentation layers on top of textual code, but rather abstraction layers on top of more concrete speci cations. 3. The use of symbolic syntax will enable employment of standard language techniques for de ning semantics and implementing application tools. The Description Logics experience shows that symbolic theoretical language development can yield deep and advanced theoretical and practical results. 4. The use of symbolic syntax will enable the development of testing tools.
Finally, I hope that making models symbolic will clarify that models are formal representation languages, at a higher abstraction level, rather than just visual, intuitive, not executable pictures of problem aspects. I suggest that modeling courses will follow the USE example, and teach a modeling language using symbolic and visual representation.