ADORA

When we started our work on object-oriented specification some years ago, we were motivated by the severe weaknesses of the then existing methods. In the meantime, the advent of UML (and to a minor extent, OML ) has radically changed the landscape of object-oriented specification languages. However, also with UML and OML, several major problems remain.

There is still no true integration of the aspects of data, functionality, behavior and user interaction. Neither do we have a systematic hierarchical decomposition of models (for example, UML packages are a simple container construct with nearly no semantics). Models of system context and of user-oriented external behavior are weak and badly integrated with the class/object model. There is no notation for system behavior above the level of elementary objects that integrates well with the other elements of the model.

Moreover, an industrial-scale requirements language should allow people to adapt the degree of formalism in a specification to the difficulty and the risk of the problem at hand. To do so, they need a language with a broad spectrum of formality in its constructs, ranging from natural language to completely formal elements. A common syntax must provide a consistent framework for the use of these constructs. None of the existing approaches features such an adaptable degree of formality.

So there is still enough motivation not to simply join the UML mainstream and to pursue alternatives instead. We are developing an object-oriented modeling method for software that we call ADORA (Analysis and Description of Requirements and Architecture)

The goals and the basic concepts of our approach are illustrated below (Fig. 1).