Abstract*

We present the ADORA approach to object-oriented modeling of software (ADORA stands for analysis and description of requirements and architecture). The main features of ADORA that distinguish it from other approaches like UML are the use of abstract objects (instead of classes) as the basis of the model, a systematic hierarchical decomposition of the modeled system and the integration of all aspects of the system in one coherent model.
This introduction shows the concepts of ADORA and the rationale behind them, gives an overview of the language, sketches a novel concept for visualizing the model hierarchy with a tool and reports the results of a validation experiment for the ADORA language.

* This introduction is based on the paper: Glinz, M., S. Berner, S. Joos (2002). Object-oriented modeling with ADORA. Information Systems 27, 6. 425-444.

1. Introduction

Modeling requirements and architectural design has a long tradition, rooted in simple block diagrams back in the early days of computing. Between 1970 and 1980, the first systematic modeling techniques appeared, for example the entity-relationship approach [1] and structured analysis [2]. The entity-relationship approach had a tremendous influence. In particular, it led to the so-called object-oriented analysis and design methods around 1990, for example OOA/OOD [3], OMT [4] or OOAD [5]. However, these approaches had severe deficiencies that were mainly due to two problems: no systematic decomposition of models and the inability to model dynamic and behavioral aspects of a system. Both problems are inherited from the entity-relationship  approach, which also has no decomposition and—by its nature—does not model dynamic and behavioral aspects. On the other hand, structured analysis, which had the features lacking in the OO-approaches, had other, equivalently severe deficiencies, in particular the paradigm  mismatch between analysis and design, missing locality of data definitions, only partial information hiding and no types [6]. Jacobson [7] tried to oercome some defects of the object-oriented approaches by introducing the notion of use cases. OML [8] was another attempt to create a better object modeling language. The beginning of our own work on object-oriented specification [6,9] was also motivated by the weaknesses of structured analysis and the problems of the early object modeling approaches.We are developing an object-oriented modeling method for software that aims at overcoming some of the major problems mentioned above. We call our approach ADORA which is an acronym standing for Analysis and Description Of Requirements and Architecture [12,13]. ADORA is intended to be used primarily for requirements specification and also for logical-level architectural design. Currently, it has no language elements for expressing physical design models (distribution, deployment) and implementation models.dora models are object-oriented, we can implement a smoothtransiti on from an ADORA architecture model to detailed design and code written in an object-oriented programming language.

UML [10] was created withth e goals of unifying the best features of different existing languages and of creating an industry standard. In achieving the last of these goals, UML was stunningly successful. However, this success was no reason for us to stop our work or redirect it towards UML, because  also with UML (and to a minor extent, withOML), several critical 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 withnearly no semantics). Models of system context and of user-oriented external behavior are weak and badly integrated with the class/object model [11]. Thus, UML is definitely not the ultimate answer to the problem of creating a good language for modeling requirements and architecture.

However, as ADORA models are object-oriented, we can implement a smoothtransiti on from an ADORA architecture model to detailed design and code written in an object-oriented programming language.

The main reason why we pursue a new approach and do not integrate our ideas into UML is because basic concepts of ADORA are essentially different from those of UML (see Section 7). In this introduction, we present the ADORA approach, focusing on the general concepts and on the language. The main contributions of ADORA are:

Throughout this introduction, we will use a distributed heating control system as an example. The goal of this system is to provide a comfortable control for the heating system of a building with several rooms. An operator can control the complete system, setting default temperatures for the rooms. Additionally, for every room, individual temperature control can be enabled by the operator. Users then can set the desired temperature using a control panel in the room. The system shall be distributed, consisting of one master module serving the operator and many room modules.

However, ADORA is not only applicable for the specification of industrial control systems. It can as well be used for the specification of information systems, in particular distributed ones. For example, in an experimental validation of the ADORA language (see Section 6), we have modeled a distributed ticket information and vending system.
The rest of the introduction is organized as follows. In Sections 2–4 we present the main features of ADORA, starting with the key concepts and then presenting the language and the visualization  concept of the tool. Section 5 sketches how ADORA fits into software processes. Finally, we compare the concepts of ADORA withth ose of UML and conclude with a discussion of results, state of work and future directions.

 

2. Key concepts and rationale of the ADORA approach

ADORA is based on five principal ideas:

In this section, we briefly describe these five principles and give our rationale for choosing them.

2.1. Abstract objects instead of classes

When we started the ADORA project, all existing object-oriented modeling methods used class diagrams as the cornerstone of their model. However, class models are inappropriate when more than one object of the same class and/or collaboration between objects has to be modeled [11,14]. Both situations frequently occur in practice. For an example, see the buttons in Fig. 1. Moreover, class models are difficult to decompose. As soon as different objects of a class belong to different parts of a system (which often is the case), hierarchical decomposition no longer works for class models [14]. Wirfs-Brock [15] tries to overcome the problems of class modeling by using classes in different roles. However, decomposition remains a problem: what does it mean to decompose a role?

We therefore decided to use abstract, prototypical objects as the core of an ADORA model (Fig. 1). An equivalent to classes (which we call types) is only used to model common characteristics of objects: types define the properties of the objects and can be organized in subtype hierarchies. In order to make models more precise, we distinguish between objects (representing a single instance) and object sets that represent a set of instances. Modeling of collaboration and of hierarchical decomposition (see below) becomes easy and straightforward with abstract objects.

In the meantime, others have also discovered the benefits of modeling withabstract objects. UML, for example, uses abstract objects for modeling collaboration in collaboration diagrams and in sequence diagrams.1 However, without a notion of abstraction and decomposition, only local views can be modeled. Moreover, class diagrams still form the core of a UML specification.

fdsa

Context of classes
Left: ADORA model of a distributed heating control system. MasterModule and Room- Module are partially visualized (indicated by dots after name); showing the control panels only. Display and Button are types.

Top right: Conventional class model of the
control panels

Fig. 1: An ADORA object model (left) vs. a conventional class model (top right).

2.2. Hierarchical decomposition

Every large specification must be decomposed in some way in order to make it manageable and comprehensible. A good decomposition (one that follows the basic software engineering principles of information hiding and separation of concerns) decomposes a system recursively into parts such that

The current object-oriented modeling methods typically approachth e decomposition problem in two ways: (a) by modeling systems as collections of models where each model represents a different aspect or gives a partial view of the system, and (b) by providing a container construct in the language that allows the modeler to partition a model into chunks of related information (e.g. packages in UML). However, neither way satisfies the criteria of a good decomposition. Aspect and view decompositions are coherent only as far as the particular aspect or view is concerned. The information required for comprehending some part of a system in detail is not coherently provided. Container constructs suchas UML packages have semantics that are too weak for serving as composites in the sense that the composite is an abstract overview of its parts and their interrelationships. This is particularly true for multi-level decompositions. Only the ROOM method [16] can decompose a system in a systematic way. However, as ROOM is also based on classes, the components are not classes, but class references. This asymmetry makes it impossible to define multi-level decompositions in a straightforward, easily understandable way.

In ADORA, the decomposition mechanism was deliberately chosen so that good decompositions in the sense of the definition given above become possible. We recursively decompose objects into objects (or elements that may be part of an object, like states). So we have the full power of object modeling on all levels of the hierarchy and only vary the degree of abstractness: objects on lower levels of the decomposition model small parts of a system in detail, whereas objects on higher levels model large parts or the whole system on an abstract level.

2.3. Integrated model

With existing modeling languages, one creates models that consist of a set of more or less loosely coupled diagrams of different types. UML is the most prominent example of this style. This seems to be a good way to achieve separation of concerns. However, while making separation easy loosely coupled collections of models make the equally important issues of integration and abstraction of concerns quite difficult.

In contrast to the approach of UML and others, an ADORA model integrates all modeling aspects (structure, data, behavior, user interaction, etc.) in one coherent model. This allows us to develop a strong notion of consistency and provides the necessary basis for developing powerful consistency checking mechanisms in tools. Moreover, an integrated model makes model construction more systematic, reduces redundancy and simplifies completeness checking.

Using an integrated model does of course not mean that everything is shown in one single diagram. Doing so would drown the user in a flood of information. We achieve separation of concerns in two ways. (1) We decompose the model hierarchically, thus allowing the user to select the focus and the level of abstraction. (2) We use a view concept that is based on aspects, not on various diagram  types. The base view consists of the objects and their hierarchical structure only. The base view is combined with one or more aspect views, depending on what the user wishes to see. These two concepts—hierarchy and combination of views—constitute the essence of organizing an ADORA model.

So the complete model is basically an abstract one—it is almost never drawn in a diagram. The concrete diagrams typically illustrate certain aspects of certain parts of a model in their hierarchical context. However, since every concrete diagram is a view of an integrated model of the complete system, we can build strong consistency and completeness rules into the language and build powerful tools for checking and  maintaining them. Readability of diagrams is achieved by selecting the right level of abstraction, by restricting the number of aspects being viewed together, and by splitting complex diagrams into an abstract overview diagram and a number of part diagrams. For example, if Fig. 2 is perceived to be too complex, it can be split into an overview diagram (Fig. 9) and two part diagrams, one for MasterModule and one for RoomModule.

Figure 2: Overview model of a Heating Control System in ADORA
Fig. 2. An ADORA view of the heating system: base view combined with structural view and context view.


2.4. Adaptable degree of formality

An industrial-scale modeling language should allow its users to adapt the degree of formalism in a specification to the difficulty and the risk of the problem at hand. Therefore, they need a language with a broad spectrum of formality in its constructs, ranging from natural language to completely formal elements.

In ADORA, we satisfy this requirement by giving the modeler a choice between informal, textual specifications and formal specifications (or a mixture of both). For example, an object may be specified withan informal text only. Alternatively, it can be formally decomposed into components. These in turn can be specified formally or informally. As another example, state transitions can be specified in a formal notation or informally withtext or with a combination of both.

The syntax of the ADORA language provides a consistent framework for the use of constructs with different degrees of formality.

2.5. Contextual visualization

Current modeling languages either lack capabilities for system decomposition or they visualize decompositions in an explosive zoom style: the composites and their parts are drawn as separate diagrams. Hence, a diagram gives no information about the context that the presented model elements are embedded in. In ADORA, we use a fisheye view concept for visualizing a component in its surrounding hierarchical context, thereby simplifying browsing through a set of diagrams and improving comprehensibility [12,17]. This technique allows the construction of tools that support the abstraction mechanisms of the language directly by corresponding visualization mechanisms in the tool.

3. An overview of the ADORA language

An ADORA model consists of a basic hierarchical object structure (the base view, as we call it) and a set of aspect views that are combined with the base view. In this section, we describe these views and their interaction.

3.1. Basic hierarchical object structure

The object hierarchy forms the basic structure of an ADORA model.

Objects and object sets. As already mentioned above, we distinguishbetween objects and object sets. An ADORA object is an abstract representation of a single instance in the system being modeled. For example, in our heating control system, there is a single boiler control panel, so we model this entity as an object. Abstract means that the object is a placeholder for a concrete object instance. While every object instance must have an object identifier and concrete values for its attributes, an ADORA object has neither of these. An ADORA object set is an abstract representation of a set of object instances. The number of instances allowed can be constrained witha cardinality. For example, in an order processing system we would model suppliers, parts, orders, etc. as object sets. In the heating control system, we have a control panel in every room and we control at least one room. Thus, we model this panel as an object set withc ardinality (1,n), see Fig. 2.

Structure of anADORA object. An object or object set has a two-fold inner structure: it consists of a set of properties and (optionally) a set of parts.

The properties are attributes (bothpublic and private ones), directed relationships to other objects/object sets, operations and so-called standardized properties. The latter are user-definable structures for stating goals, constraints, configuration information, notes, etc., see below.

The parts can be objects, object sets, states and scenarios. Every part again can consist of parts: objects and object sets can be decomposed recursively as defined above, states can be refined into statecharts, scenarios into scenariocharts (as we call them, see below). Thus, we get a hierarchical whole-part structure that allows the modeling of a hierarchical decomposition of a system. The decomposition is strict: an element can neither contain itself nor can it be a part of more than one composite. We stick to a strict decomposition due to its inherent simplicity and elegance. Commonalities between objects in different positions of a decomposition hierarchy can be modeled by assigning them the same type (see the paragraph on types below and Fig. 1).

Graphic representation. In order to exploit the power of hierarchical decomposition, we allow the modelers to represent an ADORA model on any level of abstraction, from a very high-level view of the complete system down to very detailed views of its parts. We achieve this property by representing ADORA objects, object sets, scenarios and states by nested boxes (see Figs 1 and 2). The modeler can freely choose between drawing few diagrams with deep nesting and more diagrams withlittle nesting. In order to distinguishexpanded and nonexpanded elements in a diagram, we append three dots to the name of every element having parts that are not or only partially drawn on that diagram.

Types. Frequently, different objects have the same inner structure, but are embedded in different parts of a system. In the heating system for example, the boiler control panel and the room control panels both might have a display with the same properties. In these situations, it would be cumbersome to define the properties individually for every object. Instead, ADORA offers a type construct. An ADORA type defines:

A type defines neither the relationships to other objects/object sets nor the embedding of the objects of that type. Types can be organized in a subtype hierarchy.

An object can have a type name appended to its name (for example, RoomDisplay: Display in Fig. 1). In this case, the object is of that type and the type is separately defined in textual form. Otherwise, there is no other object of the same type in the model and the type information is included in the definition of the object. Fig. 6 shows an example of such an object definition.

Standardized properties. In order to adapt ADORA in a flexible yet controlled way to the needs of different projects, application domains or persons, we provide the so-called standardized properties. An ADORA standardized property is a typed construct consisting of a header and a body. Fig. 3 shows the type definitions for the properties goal, created and note and the application of these properties in the specification of the object HeatingControlSystem. As the name and structure of the properties are user-definable, we get the required flexibility. On the other hand, typing ensures that a tool nevertheless can check the properties, and support searching, hyperlinking and cross-referencing.

propertydef goal numbered Hyperstring constraints unique;
propertydef created Date;
propertydef note Hyperstring;

// object HeatingControlSystem functional description
goal 1 "Provide comfortable control for the heating of a building with several rooms";
created 2006/07/13;
note "Constraints have yet to be added and discussed";
// end HeatingControlSystem
Fig. 3. Definition and use of standardized properties.

3.2. The structural view

The structural view combines the base view with information about relationships between objects Relationships in ADORA express more than classic associations do: they model all kinds of information flow between objects.
Associations. Whenever an object A accesses a public attribute of another object B or invokes an operation of B (and B is not a part of A or viceversa) we model a directed association relationship from A to B. The association has a name and may have a cardinality. In contrast to UML and other object or entity-relationship modeling languages, ADORA associations are always directed binary relationships. Modeling with directed associations has several advantages: it helps decouple objects, supports information hiding and enables modeling of contracts between objects. For example, in a phone directory system one may want to associate persons withph one numbers, but - for privacy reasons - not vice-versa. Bi-directional relationships can be modeled by two directed ones with corresponding names. Associations are graphically represented by thin lines between the associated objects. An arrowhead preceding the name of the association indicates the direction (cf. Figs. 2 and 4).

Abstract relationships. Relationships in ADORA must reflect the hierarchical structure of the model. That means, a relationship between two objects implies relationships on all hierarchical levels lying above these objects. Otherwise, the model would become inconsistent concerning information flow between objects.

We call these implied higher-level relationships abstract relationships. Fig. 4 illustrates the concept of abstract relationships by examples: let objects A and B linked by an association relationship. If A is contained in another object X and B in an object Y, then the relationship A-B implies abstract relationships X->Y, A->Y and X->B. Whenever we draw a diagram that hides A, B or both, the next higher abstract relationship must be drawn. Abstract relationships are drawn as thick lines. They can, but need not have names and cardinalities.2 In the case of partially expanded objects, we sometimes have to draw both a relationship and a corresponding higher-level abstract relationship. In this case, we indicate the correspondence by a dashed hairline (Fig. 4).

Modeling information flow. Besides associations,information flow between two objects A and B may also stem from A sending an event to B or from A referencing names defined within B. The latter typically happens when a scenario interacts with data objects in the model. These two kinds of information flow are also modeled withabstract relationships.

Thus, the structural view models the hierarchical structure and all relationships caused by referencing, accessing or transmitting information.

Direction of abstract relationships. An abstract relationship has a direction, if and only if all its underlying lower level relationships have the same direction. So if, for example, we have two highlevel subsystems S1 and S2 that are solely connected by a directed abstract relationship from S1 to S2, then we know that S2 is independent of S1 and that S1 is built upon S2.

In the view shown in Fig. 2, we have some examples of ADORA relationships. All relationships from BoilerControl to other objects are abstract ones because their origins within BoilerControl are hidden in this view. The relationships readTemp from Controller to RoomTempSensor and controlValve from Controller to RadiatorValve are associations.
Hence, they are drawn with thin lines. If we had chosen a view that hides the contents of Room-Control, we had drawn two abstract relationships from RoomControl to RoomTempSensor and to RadiatorValve, respectively.

Fig. 4. Four static views of the same model on different levels
Fig. 4. Four static views of the same model on different levels of abstraction.
Fig. 4. Four static views of the same model on different levels

3.3. The behavioral view

The behavioral view combines the base view witha model of dynamic system behavior.

In most existing modeling languages (both general-purpose suchas UML and behaviorspecific such as Statemate [18]), the behavior model and the class or activity model are modeled and kept separately. In languages supporting hierarchical structure, the behavioral hierarchy and the hierarchy of activities or classes are also modeled separately [19]. In ADORA we take a different approach, integrating the object and the behavior model.

Combining objects and states. ADORA combines the object hierarchy with a statechart-based state machine hierarchy in a single hierarchical structure [9,20]. Every object represents an abstract state that can be refined by the objects and/or the states that an object contains. This is completely analogous to the refinement hierarchy in statecharts [21] and can be given analogous semantics for state transitions. We distinguish pure states (represented graphically by rounded rectangles) and objects withstate (see Fig. 5). Pure states are either elementary or are refined by a pure statechart. Objects with state additionally have properties and/or parts other than states.

 We do not explicitly separate parallel states/state machines as it is done in statecharts. Instead, objects and states that are part of the same object and have no state transitions between each other are considered to be parallel states. Objects that are neither the destination of a state transition nor are designated as initial abstract states are considered to have no explicitly modeled state.

By embedding the behavior model into the object decomposition hierarchy, we can easily model behavior on all levels of abstraction. On a high level, objects and states may represent abstract concepts like operational modes (off, startup, operating, etc.). On the level of elementary objects, states and transitions model object life cycles.

Timing and event propagation. Harel’s semantics of statecharts [21] is based on event broadcasting and synchronous timing. While this is quite straightforward for small, simple models, it has serious drawbacks for complex models. Event broadcasting breaks the principles of localizing effects and of information hiding. Hence, modifying and maintaining models becomes hard. Synchronous timing can have counter-intuitive effects [20] and is inappropriate for modeling problems that are asynchronous by nature.

Therefore, we use a different approach to timing and event propagation in ADORA, building on our own previous work [20] and on the work by Leveson and Heimdahl [22,23]. An event is broadcast only within the object where the event originates. In order to make an event available in another object, it must be explicitly sent by the generating object and received by the target object. By default, bothbro adcasting and sending events use the quasi-synchronous timing semantics defined in [20], where state transitions take time, but the time interval is infinitesimally short and no external event can occur prior to the end of the interval. This is similar to the usual synchronous timing semantics, but avoids its problematic and often counter-intuitive effects.

When explicitly sending an event from one object to another, we may also specify the transmission to be asynchronous. In this case, the event leaves the time envelope of quasi-synchronicity and arrives sometimes later at its destination. Thus, we can model systems that operate synchronously within subsystems but asynchronously between subsystems, a situation that frequently occurs in distributed systems.

Notation of state transitions. The triggering events and triggered actions or events either can be written in the traditional way as an adornment of the state transition arrows in the diagrams, or they can be expressed with transition tables [23]. While the traditional way is easy and straightforward for small models withsimp le transition conditions, it becomes unmanageable when the triggering event is a complex combination of conditions and when there are many actions to be taken. In this situation, the tabular notation is more or less mandatory in order to keep the model  readable.

Depending on the degree of precision required, state transition expressions can be formulated textually, formally, or by a combination of both.

Fig. 5 shows the graphic representation of a behavior view with some of the variants described above. When the system is started, then for all members of the object set RoomModule the initial state HeatingOff is entered. The transition to the object HeatingOn is specified formally. It is taken when the event on is received over the relationship setRoom (cf. Fig. 2). If this transition is taken, the state LocalControlDisabled and the object RoomControl are entered concurrently. Within RoomControl, the object Controller is entered and within Controller the parallel states Init and Reading. This is equivalent to the rules that we have for statecharts. The state transitions between LocalControlDisabled and LocalControlEnabled are specified informally withtext only. The transitions within Controller are specified in tabular form.

Fig. 5. A partial ADORA model of the heating control system; base view and behavior view.
Fig. 5. A partial ADORA model of the heating control system; base view and behavior view.

3.4. The functional view

In the functional view we define the properties of an object or object set (attributes, operations, etc.) that have not already been defined by the object’s type. When there is only one object of a  certain type, the complete type information is embedded in the object definition. The functional view is not combined withoth er views; it is always represented separately in textual form.

The language for expressing the functional view is inspired by existing notations, in particular the language ASTRAL [24]. We have chosen a pre-/postcondition style. The syntax supports the expression of information on any level of formality, ranging from informal text to logic formulae.
Fig. 6 shows a small example. A syncoperation is assumed to execute quasi-synchronously, i.e. its execution takes an infinitesimally short time. This is advantageous when using such an operation in a state transition. ‘‘Normal’’ operations are assumed to execute asynchronously and take time. As the example shows, definitions can vary in their degree of formality. The operations CurrentTemp and RevertToDefault are specified formally. DefaultTemp is specified semiformally having a formal signature but informally described semantics. An informal text points to operations that are not (yet) defined at all.

// object Settings
provides ActualTemp,
  'Operations to inspect /manipulate control intervals (consisting of
  start time and desired temperature), both default and user-defined';
// requires nothing

datatype

  TempIntervals is list of TempInterval
  TempInterval is structure of (start: time, temp Temperature)

attribute

  ActualTemp: Temperature;
  DefaultIntervals: TempIntervals;
  UserSetIntervals: TempIntervals;

syncoperation CurrentTemp (t : time) : Temperature
  pre  1 <= t <= 24 * 60;
  post CurrentTemp = UserSetIntervals[i].temp and UserSetIntervals[i] <= t and
        not exists j :  integer (UserSetIntervals[i].start < UserSetIntervals[j].start <= t)
end CurrentTemp

syncoperation DefaultTemp(t : time) : Temperature
   'Same as CurrentTemp, but returns current default value'
end DefaultTemp

operation RevertToDefault
   post UserSetIntervals@pre = DefaultIntervals
end RevertToDefault

'Settins must also provide operations for setting and deleting intervals and for browsing the currently defined intervals.'

// end Settings
Fig. 6. Functional view of the object settings (cf. Fig. 5).

3.5. The user view

In the last few years, the importance of modeling systems from a user’s viewpoint, using scenarios or use cases, was recognized (for example, see [25,7,20] and many others). In ADORA, we take the idea of hierarchically structured scenarios from [20] a step further and integrate the scenarios into the overall hierarchical structure of the system.

In our terminology, a scenario is an ordered set of interactions between partners, usually between a system and a set of actors external to the system. It may comprise a concrete sequence of interaction steps (instance scenario) or a set of possible interaction steps (type scenario). Hence, a use case is a type scenario in our terminology.

We consider scenarios and objects to be complementary in a specification. The scenarios specify the stimuli that actors send to the system and the reactions of the system to these stimuli. However, when these reactions depend on the history of previous stimuli and reactions, i.e. on stored information, a precise specification of reactions withscenari os alone becomes unfeasible. The objects specify the structure, functions and behavior that are needed to specify the reactions in the scenarios properly.

In the base view of an ADORA model, scenarios are represented by ovals. In the user view, we add to the base view the actors in the system environment that the scenarios interact with and all those abstract relationships that model interactions between scenarios and objects. Frequently the user view is combined with the context view (see below) which adds those environmental elements that interact with objects, but not with scenarios (Fig. 7). For example, the scenario ManageLocalRoomTemperature, specifying the interaction between the actor User and the system, is localized within the object LocalControlEnabled.  Internally, the scenario interacts with RoomTemp-ControlPanel. RadiatorValve is an environmental object that is controlled from an object inside HeatingOn. It is part of the context view and would not be visible in a pure user view.

An individual scenario can be specified textually or by a statechart [26]. In both cases ADORA

Thus, we have a hierarchical decomposition in the user view, too. The object hierarchy of the base view allocates high-level scenarios (like Manage-LocalRoomTemperature in our heating system) to that part of the system where they take effect. The scenario hierarchy decomposes high-level scenarios into more elementary ones. As a large system has a large number of scenarios (we mean type scenarios/use cases here, not instance scenarios), this facility is very important for grouping and structuring the scenarios.

Note that the ADORA user view is a logical view of user–system interaction only; it does not include the design of the user interface.

Fig. 7. A combined user and context view of the heating control system.
Fig. 7. A combined user and context view of the heating control system.

Fig. 8. A scenariochart modeling the structure of the ManageLocalRoomTemperature scenario.
Fig. 8. A scenariochart modeling the structure of the ManageLocalRoomTemperature scenario.

3.6. The context view

The context view shows all actors and objects in the environment of the modeled system and their relationships with the system. Depending on the degree of abstraction selected for the system, we get a context diagram (Fig. 9) or the external context for a more detailed view of the system (Fig. 2). ADORA allows modeling of a richcontext, i.e. we can model relationships between actors or objects in the system environment. This is an important feature, because for properly situating a system in its environment we frequently must know not only about the system-environment interactions, but also about interactions between actors in the environment.

In addition to external elements that are not a part of the system being specified, an ADORA model can also contain so-called external objects. We use these to model preexisting components that are part of the system, but not part of the specification (because they already exist). External objects are treated as black boxes having a name only. In the notation, such objects are marked with the keyword external (for example, the object RoomTempSensor in Fig. 2). In any specification where COTS components will be part of the system or where existing components will be reused, modeling the embedding of these components into the system requires external objects.

Fig. 9. A context diagram of the heating control system (base view combined withcontext view and structural view).
Fig. 9. A context diagram of the heating control system (base view combined withcontext view and structural view).




3.7. Modeling constraints and qualities

Constraints and quality requirements are typically expressed withtext, even in specifications that employ graphical models for functional specifications. In traditional specifications and with UML-style graphic models we have the problem of interrelating functional and nonfunctional specifications and of expressing the non-functional specifications on the right level of abstraction.

In ADORA, we use two ADORA-specific features to solve this problem. (1) The decomposition  hierarchy in ADORA models is used to put every non-functional requirement into its right place. It  is positioned in the hierarchy according to the scope of the requirement. (2) The requirements themselves are expressed as ADORA standardized properties. Every kind of non-functional requirement can be expressed by its own property kind, for example performance constraint, accuracy constraint, quality, etc.).

3.8. Consistency checking and model verification

Having an integrated model allows us to define stringent rules for consistency between views, for example ‘‘When an object A references information in another object B in any view and B is not a part of A or vice-versa, then there must be a relationship from A to B in the static view.’’ A language for the formulation of consistency constraints and a compiler that translates these constraints into Java has been developed [27]. By executing this code in the ADORA tool, the tool is enabled to check or enforce these constraints. The capabilities for formal analysis and verification of an ADORA model depend on the chosen degree of formality. In the behavior view, for example, a sufficiently formal specification of state transitions allows the application of all analyses that are available for hierarchical state machines.

4. Contextual visualization—the ADORA tool

We have developed a concept for visualizing hierarchical object models with a tool and are developing a prototype of this tool.

The ADORA tool shall provide capabilities for editing, storing, visualizing and checking ADORA models. The distinguishing feature of the ADORA tool is the way we visualize the object hierarchy: we do not simply use explosive zooming, but have developed a novel concept that is based on fisheye views. In this introduction, we restrict the presentation of the ADORA tool to this important aspect.

4.1. General considerations

A good visualization concept is critical bothfor understandability and ease-of-use of graphical models. A good concept should:
Current tools operating on hierarchical model  structures normally visualize a single element with its direct successors in a single view. A few tools visualize all nodes in one view. Some tools provide scaling, map windows or overview windows to manage the complexity of big models, but most tools provide just explosive zooming. Withexplosive zooming, the global context gets lost while the zoomed node explodes entirely in the existing or a new window. As a consequence, these tools either offer views showing global context without local detail or local detail without global context. Global context and local detail in one view are realized in very few tools; full flexibility in scaling and zooming is not offered at all. Compared with the essential modeling tasks, the cognitive overhead increases too much when models become larger [12].

For the visualization of ADORA models we adapt an alternative concept for viewing graphic structures that was developed nearly 20 years ago by Furnas [28]: the so-called fisheye views. Furnas uses the analogy of a fisheye (which has a very wide angle lens) for a view concept that shows full detail in a focal point, while displaying information being further away from this focus in successively less detail. Zooming in fisheye views basically works by moving the angle and the focus of the display.

The principal idea behind fisheye view visualization is to display local detail and global context together in a well-balanced way. Local detail is required for getting all the relevant information that a user is currently focused on, while global context is needed for situating the current focus in the general context of the information being viewed (which in turn is a prerequisite for quick and easy orientation and navigation).

4.2. View generation for ADORA models

For ADORA, we modified the original fisheye view concepts in order to make them suitable for our purposes [12,17]. Firstly, we do not generate views by geometric projection of a large flat model (the way that a real fisheye lens would work). Instead we generate so-called logical fisheye views that are based on the hierarchical structure of an ADORA model and its inherent abstraction capabilities. Secondly, we allow views withmore than
one focus.

Thus, we get a model-driven visualization that fully exploits the power of a hierarchically structured model and is able to integrate local detail and global context in a single view. Such  views ease orientation and navigation in the model and minimize the cognitive overhead.

As this concept allows less interesting elements to be visualized on an abstract level together with the details of elements of special interest, we have strong capabilities for supporting the inherent abstraction mechanisms in the object model that is being visualized and thus foster the expressiveness and understandability of the model.

4.3. Navigation in ADORA models

We distinguishbetw een two types of navigation, a physical and a logical one [29]. Physical navigation is necessary when the view exceeds the size of the available display. The typical solution is scaling, scrolling or a combination of both. Physical navigation is well known, as it is the normal way of navigation in flat models.

The really interesting kind of navigation in ADORA is logical navigation through the hierarchy. Logical navigation in a hierarchical structure means finding the actual position of a local element in the global context of the hierarchy, or changing the foci of visualized elements. To handle this kind of navigation adequately, we zoom in or out. Zooming-in means that more details of a deeper hierarchical level are visualized. Zoomingout means that a more abstract view of the selected elements is produced.

4.4. The zooming algorithm

Our fisheye zooming algorithm works on any given layout, adjusting it incrementally and preserving it as far as possible. So a user may rearrange a layout without losing these rearrangements when zooming. The principal idea of the algorithm for zooming-in is illustrated in Fig. 10. The details are beyond the scope of this introduction; they can be found in [17]. Assume that Xy is the object we want to zoom-in. The algorithm works in four steps.

(1) Determine the size of the expanded object (dotted shape of X in Fig. 10). This size depends on the size and layout of the elements that have to be displayed within X in the zoomed-in view.

(2) Let C be the composite object that directly3 contains X.4 For every object Yj on the diagram which is contained in C and lies outside X; compute a shift vector VYj as follows: draw a virtual line from the center of X to the center of Yj : The two intersection points of this line with the original and the expanded shape of X define the shift vector for Yj : Then shift Yj geometrically by its shift vector.

(3) Determine the new size of C (suchth at it geometrically surrounds the resized or shifted objects it contains). Recursively apply steps (2) and (3) of the algorithm to C:

(4) Draw the contents of X into its expanded shape.


As long as the shapes of all objects on the diagram are geometrically convex and the expanded shape of X is geometrically proportional to the original one, this algorithm always produces a diagram that looks similar to the original one and does not have any overlapping shapes.

The convexity constraint is no problem, because all graphic elements in ADORA are geometrically convex. However, the expanded shape is frequently not proportional to the original one.

Relaxing the proportionality constraint while keeping the resulting diagram free of overlappings requires some modifications to the algorithm sketched above. The details are discussed in [17].

Fig. 10. The ADORA zooming algorithm.;
Fig. 10. The ADORA zooming algorithm.

4.5. Example

Figs. 9 and 2 give a brief impression of our visualization concept. Fig. 9 shows the heating control system on a very high level of abstraction. The following steps lead to the view given in Fig. 2: (1) zooming-in on MasterModule, (2) zooming-in on RoomModule, (3) zooming in on HeatingOn, (4) zooming-in on LocalControlEnabled, and (5) zooming in on RoomControl.5 A more detailed example is presented in [12].

5. Using ADORA in the software development process

ADORA is an open approachth at does not require a specific development process. It works withany process that
ADORA supports a broad spectrum of modeling methods, for example, pure object modeling, behavior-focused modeling and scenario-focused modeling.

Equally important, ADORA is flexible concerning the formality of models. Depending on the required precision and unambiguity for modeling the problem at hand, the formality of an ADORA model can vary from mostly informal, textual specifications (using the decomposition structure and standardized properties as the only formal elements) up to a completely formal specification. In particular, the object hierarchy provides a framework that allows objects specified with different degrees of formality to coexist in the same model in a well-structured way.
ADORA provides strong support for iterative and incremental development processes. Such processes typically start with a high-level requirements and architecture specification and identify work packages for incremental development based  on this high level structure. Work packages are then developed by specifying their detailed requirements, designing  their architecture in the framework of the general architecture and implementing them on this basis.

The hierarchical structure of ADORA fits such processes quite well: the high-level specifications can be expressed by high-level objects and their interrelationships. Goals, objectives and general constraints can be attached to these objects using ADORA’s standardized properties. Then, the structure of the model can be exploited for determining the work packages. When developing a work package, those objects of the high-level model belonging to the work package are specified in detail by decomposing and refining them.

ADORA also provides strong support for multilevel systems engineering and business engineering processes.

A systems engineering process is typically  characterized by a hierarchical series of requirements and design steps: after determining the principal goals (requirements), basic design decisions are taken which impose a structure on the system. In a recursive procedure, we then determine the requirements for every component of this structure, design the components, yielding subcomponents, determine the requirements of the subcomponents, etc. until we arrive at concrete hardware and software building blocks.

When using such a process, the documentation of the requirements and architecture naturally has a hierarchical structure, which can be expressed quite easily with ADORA. The Heating Control system is a typical example, where the basic structure of a single master module and one room module per room is a very high-level design decision that shapes the requirements on the lower levels. 

We also find a hierarchical intertwining of requirements and design decisions in business engineering and information systems development. There we typically have three hierarchical levels in the process: the business level, the system level (information systems comprising hardware, software and people), and the software level.

6. Conclusions

We have presented ADORA, an approach to object-oriented modeling that is based on object modeling and hierarchical decomposition, using an integrated model. The ADORA language is intended to be used for requirements specifications and high-level, logical views of software architectures.

References

[1] P.P. Chen, The entity-relationship model—toward a unified view of data, ACM Trans. Database Systems 1 (1976) 9–36.

[2] T. DeMarco, Structured Analysis and System Specification, Yourdon Press, New York, 1979.

[3] P. Coad, E. Yourdon, Object-Oriented Analysis, Prentice Hall, Englewood Cliffs, 1991.

[4] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, Object-Oriented Modeling and Design, Prentice Hall, Englewood Cliffs, 1991.

[5] G. Booch, Object-Oriented Analysis and Design with Applications, 2nd ed, Benjamin/Cummings, Redwood City, 1994.

[6] M. Glinz, Probleme und Schwachstellen der Strukturierten Analyse [Problems and weaknesses of structured analysis], in: M. Timm (Ed.), Requirements Engineering ‘91, Informatik-Fachberichte, Vol. 273, Springer, Berlin, 1991, pp. 14–39 (in German).

[7] I. Jacobson, M. Christerson, P. Jonsson, G. O. vergaard, Object-Oriented Software Engineering—A Use Case Driven Approach, Addison-Wesley, Reading, 1992.

[8] D. Firesmith, B.H. Henderson-Sellers, I. Graham, M. Page-Jones, Open Modeling Language (OML)—Reference Manual, SIGS Reference Library Series, Cambridge University Press, Cambridge, 1998.

[9] M. Glinz, Hierarchische Verhaltensbeschreibung in objektorientierten Systemmodellen—eine Grundlage f .ur modellbasiertes Prototyping [Hierarchical description of behavior in object-oriented system models—a foundation for model-based prototyping], in: H. Z.ullighoven et al., (Eds.), Requirements Engineering ‘93: Prototyping, Teubner, Stuttgart, 1993, pp. 175–192 (in German).

[10] J. Rumbaugh, I. Jacobson, G. Booch, The Unified Modeling Language Reference Manual, Addison-Wesley, Reading, 1999.

[11] M. Glinz, Problems and deficiencies of UML as a requirements specification language, Proceedings of the TenthInternational Workshop on Software Specification and Design, San Diego, 2000, pp. 11–22.

[12] S. Berner, S. Joos, M. Glinz, M. Arnold, A visualization concept for hierarchical object models, Proceedings of the 13thIEEE International Conference on Automated Software Engineering (ASE-98), 1998, pp. 225–228.

[13] S. Joos, ADORA-L—Eine Modellierungssprache zur Spezifikation von Software-Anforderungen [ADORA-L—A modeling language for specifying software requirements (in German)], Ph. D. Thesis, University of Zurich, 1999.

[14] S. Joos, S. Berner, M. Arnold, M. Glinz, Hierarchische Zerlegung in objektorientierten Spezifikationsmodellen [Hierarchical Decomposition in object-oriented specification models], Softwaretechnik-Trends 17 (1) (1997) 29–37 (in German).

[15] R. Wirfs-Brock, B. Wilkerson, L. Wiener, Designing Object-Oriented Software, Prentice Hall, Englewood Cliffs, 1993.

[16] B. Selic, G. Gullekson, P.T. Ward, Real-Time Object-Oriented Modeling, Wiley, New York, 1994.

[17] S. Berner, Modellvisualisierung f .ur die Spezifikationssprache ADORA [Model visualization for the specification language ADORA (in German)], Ph.D. Thesis, University of Zurich, 2002.

[18] D. Harel, H. Lachover, A. Naamad, A. Pnueli, M. Politi, R. Sherman, A. Shtul-Trauring, M. Trakhtenbrot, STATEMATE: a working environment for the development of complex reactive systems, IEEE Trans. Software Eng. 16 (1990) 403–414.

[19] D. Harel, E. Gery, Executable object modeling with statecharts, IEEE Computer 30 (7) (1997) 31–42.

[20] M. Glinz, An integrated formal model of scenarios based on statecharts, in: W. Sch.afer, P. Botella (Eds.), Software Engineering—ESEC ‘95, Lecture Notes in Computer Science, Vol. 989, Springer, Berlin, 1995, pp. 254–271.
 
[21] D. Harel, Statecharts: a visual formalism for complex systems, Sci. Computer Programming 8 (1987) 231–274.

[22] N.G. Leveson, M.P.E. Heimdahl, H. Hildreth, J.D. Reese, Requirements specification for process-control systems, IEEE Trans. Software Eng. 20 (1994) 684–707.

[23] N.G. Leveson, M.P.E. Heimdahl, J.D. Reese, Designing specification languages for process control systems: lessons learned and steps to the future, in: O. Nierstrasz, M. Lemoine (Eds.), Software Engineering—ESEC/FSE’99, Lecture Notes in Computer Science, Vol. 1687, Springer, Berlin, 1999, pp. 127–145.

[24] A. Coen-Porisini, C. Ghezzi, R.A. Kemmerer, Specification of realtime systems using ASTRAL, IEEE Trans. Software Eng. 23 (1997) 704–736.

[25] J.M. Carroll (Ed.), Scenario-based Design, Wiley, New York, 1995.

[26] M. Glinz, Improving the quality of requirements with scenarios, Proceedings of the Second World Congress on Software Quality, Yokohama, 2000, pp. 55–60.

[27] N. Schett, Konzeption und Realisierung einer Notation zur Formulierung von Integrit.atsbedingungen f .ur ADORA-Modelle [A notation for integrity constraints in ADORA models—Concept and implementation], Diploma Thesis, University of Zurich, 1998 (in German).

[28] G.W. Furnas, Generalized fisheye views, Proceedings of the ACM CHI 86 Conference on Human Factors in Computing Systems, Boston, 1986, pp. 16–23.

[29] D. Schaffer, et al., Navigating hierarchically clustered networks through fisheye and full-zoom methods, ACM Trans. CHI 3 (1996) 162–188.

[30] S. Berner, N. Schett, Y. Xia, M. Glinz, An experimental validation of the ADORA language, Technical Report 1999.05, University of Zurich, 1999. http://www.ifi.unizh.ch/groups/req/ftp/papers/ADORA validation.pdf.

[31] S. Berner, M. Glinz, S. Joos, A classification of stereotypesfor object-oriented modeling languages, Proceedings of the Second International Conference on the Unified Modeling Language, Fort Collins, Springer, Berlin, 1999, pp. 249–264. M. Glinz et al. / Information Systems 27 (2002) 444 425–444




1 There is no consistent notion of abstract objects in UML. In collaboration diagrams Classifier Role is used to represent abstract objects whereas in sequence diagrams Object is used for the same purpose. The UML reference manual increases the confusion by stating that collaborations use objects ([10] pp. 29, 196 and 530).
2 Cardinalities for abstract relationships can easily lead to inconsistencies. The cardinality of an abstract relationship rmust not be more restrictive than the least restrictive cardinality of the relationships that r is derived from.
3 ‘‘Directly’’ means that there is no object between C and X in the decomposition hierarchy.
4 If there is no such composite object, step (2) applies to all objects of the diagram lying outside X.
5 In order to save space, Fig. 2 has been drawn manually. When constructed with our zooming algorithm, the drawing would be considerably larger. However, it would be identical bothin topology and content withFig. 2.