Introduction to the ICER Tool

When we look back at software development, we find that the history of software development is actually the history of raising the level of abstractions. At the modern age of the compilers whose technique for programming languages has become so mature, people are looking for raising the compiler to the model level from the programming language level. Traditionally, a compiler for a programming language can achieve the following tasks:

find syntax and semantic errors which violate the language definitions

generate an efficient machine code to execute the source program

In this project, we are trying to expand the role of compilers from programming languages to model development. That is, we are trying to compile a model to find "syntax" and "semantic" errors. No matter what level of abstraction, almost every model should represent some static structures of a software system; our goal of this project is to support software developers to find inconsistencies/errors in models at different level of abstraction. After seeing the important role of a model compiler in software development, we decided to investigate the possibility to build a model compiler generator which lets software developers write their model compiler. That is, the model compiler generator can have developers feel free to define what a valid model is when they design a software system based on a specific development context.

Before introducing our work, let us take a look at an automatic compiler generator tool, which is called YACC/BISON. It is YACC/BISON that allows the designers of a programming language to easily write a new compiler. When a user of YACC writes a compiler for a language, he should first give the syntax of the language in terms of YACC rules. Then he can embed the actions such as some semantics checking and translation into the rules. Last a compiler for the language has been generated.

However the mechanism used in YACC to generate a compiler for a programming language is not obvious to software models. Due to the graphical characteristics of a model, developers for model compilers cannot easily write a compiler for a modeling language as programming language compiler writers have done. But when studying the definition of the UML, we see the hope. As an application of the four layer architecture, the UML is defined by a UML metamodel. Applying the instance-of relation, many inconsistencies/errors in UML models can be found. Here are the details about the meta-model mechanism.

While many errors such as the duplicated role names associated with one association can be found, we found that there still exist many inconsistencies/errors which cannot be predefined by a model compiler. Furthermore, software engineering, as an engineering task, heavily depends on many factors which affect designing a high quality software system, such as a development environment instead of one particular methodology. Thus, like the compiler writers who write their language's definition, we should leave software developers to decide what a valid model is according to a methodology they have used. Fortunately, we find it is the profile mechanism that can provide such a feature. The idea behind a profile is that software developers can extend the UML metamodel which belongs to the M₂ level by introducing some meta-elements using stereotype. Applying the instance-of relation between an application model and its profile, we can find many inconsistencies/errors which are ignored by many software developers.

Based on the above idea, we have built a tool, called ICER (Instance-of Relation ChekER), which can check the instance-of relation between an M_i level model and an M_i+1 (i=0,1). Namely, the ICER tool can check whether a class structure (M₁ level model(s)) satisfies a profile (M₂ level) and an object diagram (M₀ level model) is a valid instance of a class diagram (M₁ level). The ICER tool is based on the AsmL, which is implemented by FSE group in Microsoft. The implementation of the generator consists of the following three parts:

Analyzing and Translating UML Models

A Parser for the Object Constraint Language (OCL)

As an example to illustrate the feature of this research, we apply our tool to the following applications:

the model applications of the famous GoF design patterns. Here are the details about how to find errors which violate the design patterns.

the model refinement. All the inconsistencies/errors we have found so far are based on a model at one level of abstraction. However, software development is a process which keeps increasing the level of refinement. A model at one level of less abstraction can be regarded as a refinement of another model at a level of more abstraction. Is it possible to apply the ICER tool to check whether two models at different levels of abstraction have some refinement relations? Can the ICER tool be applied to support a software development process based on different sets of refinement rules? Our answer is yes. As an application of a model compiler to check two models of different levels of abstraction, we apply our tool to the class diagram refinement and here is an example.

From the above examples, we think that the ICER tool can play a more important role than a compiler for a programming language. The ICER tool can not only find inconsistencies/errors in a model at one level of abstraction but also check two different models at different levels of abstraction during software development. Therefore, the ICER tool can support different software development processes. Furthermore, we think that most of non-runtime errors introduced during software development can be detected by the ICER once a profile defines a metamodel appropriately. In short, the ICER tool provides developers with a tool to define their correct models without learning any new notations used by the tool. It is ALL UML!