Rainer Paffrath

During my time as a business analyst in a consulting firm I developed market simulation models in different sectors of industry. We used the models for market share prediction and in order to derive optimal marketing strategies. The way the applications were built was quite dissatisfying. I used MS-Excel and VBA and restarted analyzing, designing and coding with every new project though the different models resembled each other very much. When I started my PhD-studies I thought that it would be interesting to evolve the domain and to develop an object-oriented reference model on the analysis level. Scheer´s reference model can be taken as an example though he actually uses non oo-techniques (Scheer 1998). The reference model is not only intended to structure the domain but also to be reused in software engineering.

At this point two (highly depending) questions arise from the software technology point of view: What is a favorable shape of an object-oriented reference model on the analysis level? And, how to develop this for reuse-asset? (The second question will not be pursued further.)

Concerning the shape of the model there are two major approaches requiring different shapes. These two major approaches are compositional reuse and generative reuse. If you support compositional reuse you might judge a conceptual framework being the right choice of an object-oriented reference model. It is an elegant way to derive concrete models from the framework using black-box and/or white-box technology. The degree of flexibility is quite high though one needs to pay dearly due to relatively high runtimes and redundant code segments. A framework contains some portion of design decisions which might be unfavorable with regard to further aspects running through an application simultaneously. Though a framework is the most consequent way of an object-oriented reference model as it uses the object-oriented concepts itself.

Alternatively the reference model can be used as the input of a software generating code on the base of concrete configurations and fixed transformation rules. If that is the case it will be better to do without predefined designs. In generative reuse the role of a reference model is the one of a configuation tool´s. A generator is assumed to produce lean code as it avoids dynamic polymorphism if possible. Some authors use even non object-oriented domain models (for example feature models) as the input for their generators which appears quite unconventional in an oo-environment. In some cases it will cause problem to integrate varying aspects using relatively rigid transformation rules.

As a summary neither compositional reuse nor generative reuse is dominant. So, what is the most favorable shape of an object-oriented reference model if widespread industry reuse is intended? In the talk I would like to present an approach I developed for my thesis. It takes into account what has recently been published on object-oriented models stimulated by ideas taken from domain engineering (for example Jacobson et al. 1997, Griss et al. 1998, Cohen/Northrop 1998, Eisenecker/Czarnecki 1999). A catalogue of criteria for the choice of an object-oriented reference model will also be presented. It includes software technology arguments and arguments taken from a business data processing perspective. 

References: